I’ve been looking at the recent announcement that the Microsoft 365 Copilot app is being renamed to the Microsoft Copilot app, along with the ability to use both work and personal accounts from the same application.
As I posted on LinkedIn:
Microsoft is doing to Copilot what they did to Teams – bring the personal (consumer) and work versions into a single app.As per Message Center MC1454108 – The Microsoft 365 Copilot App will be renamed the Microsoft Copilot app.
Before this app rename, the ability to pick both personal and work accounts from the one app has gone live (for me at least), the hint on this was seeing ‘Work’ next to my account on the bottom left.
The app experience is different to Teams currently, where Teams will open a second window with the other account. Copilot however, closes off the window/account completely and reloads with the newly selected account. There appears to be a few bugs around account management so we’ll see if this experience changes.
The other big catch here is personal Copilot can now be accessed via https://copilot.cloud.microsoft/ – so if you’re blocking copilot.microsoft.com etc via these instructions https://learn.microsoft.com/en-us/copilot/manage#how-to-ensure-users-access-copilot-chat you’ll need to ensure you’re blocking it using ‘Tenant Restrictions’ – read the MC article for administrator advice!
For me at least, the account switching experience is already live. The first hint was seeing “Work” appear next to my account in the bottom left of the application. Unlike Teams, which happily opens another window when switching between work and personal accounts, Copilot completely unloads the current account and reloads the application against the selected identity.
There’s still a few rough edges around account switching, but that’s not what caught my attention. The line that interested me from the Message Center article was:
Admins can continue to limit Microsoft account (personal) access to the Copilot app using Tenant Restrictions.
On the surface that sounds simple enough. Organisations that don’t want users accessing consumer Copilot can use Tenant Restrictions and carry on as normal.
The more I thought about it though, the less obvious it became how Microsoft expects this to work and I didn’t really know anything about what Tenant Restrictions actually were.
Tenant Restrictions aren’t a Copilot control
Historically, Tenant Restrictions have been an identity control. They’re used to control where users can authenticate, and which tenants they can access from managed devices and networks. They are not a Copilot-specific setting, nor is there much granual app defining.
Now that Microsoft is merging the work and personal experiences into a single application, what does “limit Microsoft account (personal) access” actually mean in practice? Is the Copilot application itself checking Tenant Restrictions and preventing the account from being added?
The Message Center post doesn’t really explain the mechanics behind it, so I started learning about tenant restrictions, and testing.
What I found
After some testing, it appears there is more involved than simply enabling Tenant Restrictions. Frustratingly, when I asked M365 Admin Center Copilot for Message Center around how to do this, it described a way to achieve this using Conditional Access – by using an ‘Account Type’ field and defining that as a Microsoft Account. Sadly this doesn’t actually exist after I attempted recreating the steps it described, which a different Copilot confirmed for me.
The scenarios covered by Tenant Restrictions are listed here – Copilot isn’t mentioned, but “Authentication and data plane protection for Microsoft tenant or consumer accounts” is. A scenario that isn’t supported is “Per-user tenant restrictions for Microsoft accounts.” – so if you want to be more granular than blocking all consumer accounts, you’re out of luck.
The actual steps as far as I can work out are:
1. Create a Tenant Restriction in Entra, that defines the ‘Microsoft Account’ tenant by using it’s GUID 9188040d-6c67-4c5b-b112-36a304b66dad, and block access to it. The steps for this are laid out at Configure Tenant Restrictions – Microsoft Entra ID – Microsoft Entra External ID | Microsoft Learn
2. As per the documented “Tenant restrictions v2 on the client side“, you need clients to obey the configured tenant restriction. There are multiple methods of achieving this:
Option 1: Use universal tenant restrictions v2 as part of Microsoft Entra Global Secure Access. Included in Entra Suite, which is included in Microsoft 365 E5 licensing now, is the first barrier. The second barrier is actually adopting and rolling out Global Secure Access which is a rather large project to take on just to protect from this scenario. If you’re already onboard great, you probably just need to turn on or configure Global Secure Access and Universal Tenant Restrictions – Global Secure Access | Microsoft Learn and you’re done.
Option 2: Set up tenant restrictions v2 on your corporate proxy. For companies actually using a proxy, this seems to be just blocking the sign in URLs used by Microsoft Accounts, maybe with an element of finding those URLs in header requests too. I didn’t think we’d be going into the depths of the network traffic world to solve this scenario, but it seems complex and again doesn’t just target Copilot. A user logging into Hotmail is out, for example.
Option 3: Enable tenant restrictions on Windows-managed devices (preview). Moving on from the point that this is only in preview, this is where Intune or Group Policy can set a registry setting to define the tenant the device sits in, and list any tenants to block. Another scenario that doesn’t cover unmanaged devices, and I don’t have a Mac to see how that side of it would work when deploying settings via Intune, but this one I can actually try without requiring the complexity of options 1 and 2.
I thought my group policy poking around days were long gone, but under Computer Configuration > Administrative Templates > Windows Components > Tenant Restrictions is a single option called Cloud Policy Details. Here you define your own Azure AD Directory ID (someone add this to your list to update to Entra ID!) and the Policy GUID, which is obtained from the first step once you’ve added the Microsoft Accounts tenant in Entra.
Once those controls were in place, the personal account sign-in started failing. Instead of receiving a friendly message explaining why access was blocked, applications would start hitting authentication loops, throwing generic sign-in errors and repeatedly prompting for credentials.
The Copilot app behaved in much the same way, although I could sometimes get a prompt in between sign-in windows.
The end result was that the account couldn’t successfully authenticate, but the experience didn’t feel like a deliberate block. It felt more like authentication was breaking somewhere along the way.
So what is actually happening?
M365 Copilot and Copilot Chat appears to no longer have any native ability to prevent consumer access in what was once an enterprise only application, since the Copilot app also exists and served that purpose.
Instead, Copilot relies on the underlying Microsoft identity platform. When those identity controls prevent authentication, Copilot simply inherits whatever behaviour occurs when sign-in fails.
If that’s what’s happening, Microsoft’s statement is technically correct. Tenant Restrictions can be used to limit access to personal accounts in the Copilot app. What I’m less convinced about is whether administrators reading that statement would understand the controls involved, or the unfriendly user experience that currently results from them.
I am sure this space will evolve and change rapidly, but it is a new risk that has been introduced and to be aware of.