Microsoft has made browser authentication for external identity providers in Microsoft Entra ID generally available. Organizations that federate Microsoft 365 through WS-Fed or SAML 2.0 can now use passkeys, FIDO2 security keys, and eligible browser sessions for supported Microsoft app sign-ins. For small and midsize businesses, this matters most when Outlook, Teams, or OneDrive previously got stuck in an embedded WebView sign-in flow.
What Microsoft has released
The new flow moves only the external identity provider authentication step from the embedded WebView into the system browser. The Microsoft app still starts sign-in through the Microsoft identity broker; after authentication, the user returns through an app link or universal link to the broker and then back to the app. Microsoft states that the capability is generally available in the Microsoft Entra public cloud, while national clouds remain in preview while known issues are resolved.
- Federated domains using WS-Fed or SAML 2.0 are supported.
- Microsoft lists Outlook, Teams, OneDrive, Word, Excel, PowerPoint, and Microsoft To Do as tested and supported.
- The external IdP step can use passkeys, FIDO2 security keys, WebAuthn, and eligible browser single sign-on sessions.
- Linux, unmanaged macOS, and OAuth2/OIDC social identity providers are not supported.
Why this matters for SMBs
Many SMBs use Microsoft 365 but inherited an external provider or a federated domain for identity. That is where the break often appears: web apps can use modern browser capabilities, while native apps sometimes had to fall back to embedded WebViews. If the external provider blocks WebViews or requires passkeys, sign-in can fail or drift back toward passwords. The new capability closes that gap for supported apps without forcing a full redesign of the federation model.
Requirements and limits
The capability is off until a tenant administrator enables it in the relevant federation configuration. Microsoft documents the systemBrowserEnabledOn property on the InternalDomainFederation object for this purpose. Platforms are selected deliberately, for example Android, iOS, or macOS. Android requires Chrome as the default browser; iOS requires Safari with Microsoft Authenticator; for managed macOS devices, Microsoft lists Safari and Company Portal. Windows already uses a different native path for third-party FIDO, according to Microsoft Learn.
Before enabling the feature, administrators should also confirm that the existing Microsoft Entra ID configuration, broker versions, and device management state fit together. Otherwise the result is not better security but a second sign-in path that the help desk cannot explain consistently.
No deadline, but a useful October check
Microsoft does not attach a migration deadline to this release. That makes it less urgent than the already documented SMS and voice retirement, but it is still a useful operational check. If your organization has deployed external IdP passkeys or blocks WebViews for security reasons, October is a good time to verify whether Microsoft apps are still an exception. Mobile devices, shared-device scenarios, and managed Macs deserve special attention because Microsoft documents specific broker, browser, and platform boundaries for them.
Next steps for administrators
- Identify which domains in Entra ID are actually federated and which federation protocol they use.
- Compare the affected devices with Microsoft’s support matrix for Android, iOS, and managed macOS.
- Enable
systemBrowserEnabledOnfirst for one pilot platform and document the change. - Test Outlook, Teams, and OneDrive with a user whose external IdP requires passkey or FIDO2 authentication.
- Then confirm whether Conditional Access, the broker app, and the external IdP expect the same MFA behavior.
Validation should stay local and data-minimized. Microsoft explicitly states that tokens, broker-flow state, tenant IDs, user identifiers, and device identifiers must not be placed in URLs, diagnostic logs, or support notes. In a Microsoft Security Assessment, the observable sign-in chain is therefore more useful than screenshots that expose sensitive details.
Official Microsoft sources
- Microsoft Entra Blog: Sign in to Microsoft apps with passkeys from external identity providers
- Microsoft Learn: Browser authentication for external identity providers in Microsoft Entra ID
- Microsoft Graph: internalDomainFederation resource type
Whether the new browser authentication flow is useful for your Microsoft 365 environment depends on federation, devices, and IdP policy. ReByteIT reviews these points in a structured way and supports a controlled pilot – get in touch.
What does this mean for your environment?
Assess the topic in the context of your Microsoft 365 environment and define a practical next step.
You speak directly with Sebastian Kerssen – working in the Microsoft ecosystem since 2014, with personal consulting and a dedicated point of contact.
