An endpoint admin at your organisation opens a freshly enrolled Windows 11 laptop, launches Microsoft Edge, and sees a prompt to sign in and sync — with a Google option sitting right next to the Microsoft button. They're not sure if it was always there, or if something changed. It was always technically possible, but Edge now surfaces the Google sign-in path more prominently. For personal devices that is fine. For managed corporate endpoints, it is a data governance problem worth addressing before someone clicks it.
Why this matters for managed endpoints
Edge's browser profile sync works the same way regardless of whether the identity is a Microsoft account, an Entra ID work account, or a Google account. Once signed in, Edge begins syncing the following to the cloud storage of whichever identity is used:
- Saved passwords — including passwords for internal apps, SharePoint, admin portals, and anything else the user has saved in Edge
- Browsing history — including URLs to internal systems, SharePoint libraries, Teams deep-links, and any sensitive resource the user has visited
- Bookmarks and favourites — which often contain named links to internal tools
- Form fill data — names, addresses, and any typed data Edge has captured
- Extensions — including any corporate extensions the user has installed
If the sync identity is a personal Google account, all of this flows to Google's infrastructure. Your Microsoft Purview DLP policies, Conditional Access rules, and Intune device compliance checks have no visibility into what Google does with it. For regulated industries — financial services, healthcare, legal, government — this creates a compliance gap that most information governance teams would consider unacceptable once they know it exists.
The three policies you need to know
Microsoft provides three Edge policies that work together to control identity and sync behaviour. You should understand all three before deciding what to deploy, because they have different effects and different blast radii if misconfigured.
| Policy | What it controls | Recommended value |
|---|---|---|
NonMicrosoftAccountSignInEnabled | Whether the Google (and other non-Microsoft) sign-in button appears in the Edge profile dialog | Disabled (0) — remove the option entirely |
BrowserSignin | Whether users can sign in to Edge at all, and whether sign-in is optional or forced | 2 (Force sign-in) — require users to sign in, which combined with RestrictSigninToPattern locks it to corporate accounts |
RestrictSigninToPattern | A regex pattern that limits which accounts are accepted as the Edge profile identity | .*@contoso\.com (replace with your domain) — only corporate accounts match |
The tightest configuration for a managed endpoint is all three together: remove the Google option, force sign-in, and restrict it to your corporate domain. NonMicrosoftAccountSignInEnabled = 0 alone is a good start but a user can still add their Microsoft personal account — RestrictSigninToPattern closes that gap.
How to configure via Intune Settings Catalog
All three policies are available natively in the Intune Settings Catalog — no custom OMA-URI needed for most deployments. Navigate to:
Search for each setting by name in the Settings Catalog picker. Add all three to a single profile and assign it to your managed Windows device group:
- Search for "Enable sign-in to Microsoft Edge using non-Microsoft accounts" — set to Disabled. This removes the Google button from the profile sign-in dialog.
- Search for "Browser sign-in settings" — set to Force users to sign-in to use the browser (value 2). This ensures Edge always has an authenticated profile.
- Search for "Restrict which accounts can be used as Microsoft Edge primary accounts" — set to Enabled and enter your domain regex in the text field:
.*@contoso\.com(replacecontoso\.comwith your tenant's domain, escaping the dot).
OMA-URI paths (for custom profiles or scripting)
If you prefer custom OMA-URI profiles, or need to deploy these via a script or Graph API call, here are the exact paths. All three use the Integer or String data types as shown:
| Policy | OMA-URI | Type | Value |
|---|---|---|---|
| NonMicrosoftAccountSignInEnabled | ./Device/Vendor/MSFT/Policy/Config/Edge~Policy~microsoft_edge~Signin/NonMicrosoftAccountSignInEnabled | Integer | 0 (Disabled) |
| BrowserSignin | ./Device/Vendor/MSFT/Policy/Config/Edge~Policy~microsoft_edge~Signin/BrowserSignin | Integer | 2 (Force) |
| RestrictSigninToPattern | ./Device/Vendor/MSFT/Policy/Config/Edge~Policy~microsoft_edge~Signin/RestrictSigninToPattern | String | .*@contoso\\.com |
Group Policy paths (co-managed or GPO-only environments)
For environments using Group Policy — either standalone or co-managed — all three settings are available in the Microsoft Edge ADMX templates. Download the latest ADMX from the Microsoft Edge for Business download page and import into your central store.
| Policy | GPO path |
|---|---|
| NonMicrosoftAccountSignInEnabled | Computer Configuration › Administrative Templates › Microsoft Edge › Identity and sign-in › Enable sign-in to Microsoft Edge using non-Microsoft accounts |
| BrowserSignin | Computer Configuration › Administrative Templates › Microsoft Edge › Identity and sign-in › Browser sign-in settings |
| RestrictSigninToPattern | Computer Configuration › Administrative Templates › Microsoft Edge › Identity and sign-in › Restrict which accounts can be used as Microsoft Edge primary accounts |
BrowserSignin = 2 (Force sign-in) without also setting RestrictSigninToPattern means Edge will force a sign-in but will accept any Microsoft account — including a personal @outlook.com or @hotmail.com. Always pair BrowserSignin with RestrictSigninToPattern on managed endpoints.How to verify the current state on a device
Before deploying the policy, you can check whether any managed device already has a non-Microsoft account set as the Edge profile identity. On the device itself, run this PowerShell one-liner as the logged-on user — it reads the Edge profile preferences file directly:
To verify the policy registry keys are applied after Intune sync, run this second check as administrator — it reads from the machine-level policy hive, not the user profile:
When all three policies are applied, the output should look like this:
gpupdate /force or trigger an Intune sync.Proof it worked: what the policy enforcement looks like
Once the policy applies, the Edge sign-in dialog changes. The Google option no longer appears — users see only the Microsoft account path. If RestrictSigninToPattern is also applied and they attempt to sign in with a personal Microsoft account (e.g. @outlook.com), Edge will reject it at the account picker with the message: "This account isn't allowed. Contact your administrator."
Is it worth enabling? Our recommendation
For personal devices in a BYOD scenario where the user owns the hardware — possibly fine, user preference. For any Intune-managed, Entra-joined, or co-managed corporate endpoint, the answer is no. The risk of corporate credentials and browsing history leaving Microsoft's cloud boundary is not offset by any enterprise value that Google sync provides. The Microsoft Entra identity gives users cross-device sync across all their corporate devices without any Google dependency.
Deploy all three policies as a single Settings Catalog profile, assign to your Windows devices group, and set RestrictSigninToPattern to your tenant's primary SMTP domain. For tenants with multiple domains, the pattern accepts a pipe-separated regex: .*@contoso\\.com|.*@fabrikam\\.com.