Microsoft has made browser authentication for external identity providers generally available in Entra ID. If your Microsoft 365 domain is federated to a third-party IdP over SAML 2.0 or WS-Fed, users can now sign in to Outlook, Teams, OneDrive and the Office apps on mobile and managed Macs with the passkeys or FIDO2 security keys that IdP issued. The feature is off by default, so nothing changes until you turn it on.
What happened
Microsoft's Justin Ploegert announced general availability on the Entra blog on September 29, 2026. Until now, some Microsoft app sign-ins ran the external IdP's page inside an embedded web view. That surface could not support passkeys issued by an external IdP, so those users had no passkey or security key option. If the IdP required passkeys or blocked embedded web views, they could not sign in at all.
The fix sends only the external IdP step to the system browser. The Microsoft identity broker (Microsoft Authenticator or Intune Company Portal, depending on platform) still runs the rest of the flow. After the user authenticates at the IdP, an app link returns control to the broker and the app finishes sign-in. Microsoft's documentation lists the supported scope:
- Android: Chrome as the default browser, plus a supported broker. Minimums include Microsoft Authenticator 6.2510.6857 and Company Portal 5.0.6768.0 where applicable.
- Android shared device mode: Chrome with a supported broker.
- iOS: Safari with Microsoft Authenticator 6.8.29 or later. Microsoft recommends 6.8.37 or later for current known fixes.
- Managed macOS: Safari with Company Portal 5.2511 or later.
The tested and supported apps are Outlook, Teams, OneDrive, Word, Excel, PowerPoint and Microsoft To Do. Microsoft says other brokered apps might work but remain in preview until they are listed. Linux, unmanaged macOS and OAuth 2.0/OIDC social IdPs are not supported. Direct sign-in to the Company Portal app on Android still uses an embedded web view. Windows is not part of this flow because, per Microsoft, it already supports third-party FIDO natively. The feature is GA in the public cloud and still in preview in national clouds.
Why it matters
Organizations that put a third-party IdP in front of Microsoft 365 have had a gap in their phishing-resistant rollouts. The browser path could require a passkey, but native app sign-ins on mobile ran in an embedded web view. Users there either fell back to a weaker method or could not sign in. Any workaround that loosened IdP policy for those app sign-ins left a phishable path on the devices people use most. On the listed platforms, this change removes the technical reason for that exception.
Microsoft's docs are clear about the limits. This does not mean the Microsoft broker itself supports third-party FIDO2 keys. It means the IdP step now runs in a browser where WebAuthn works. The external IdP remains its own authentication boundary, so the strength of the credential still depends on the IdP's policy. Because the system browser is a shared surface, an existing IdP session can now carry into app sign-in. That cuts prompts, and it also means your IdP session lifetime governs more than it used to.
What to check in your environment
- List your federated domains and confirm each uses SAML 2.0 or WS-Fed. OIDC-based federation is not covered.
- Look for Conditional Access or IdP-side exceptions created for mobile or desktop Microsoft apps because of passkey sign-in failures. Plan to retire them once the feature is validated.
- Check broker versions in your MDM against the minimums above, especially Authenticator on iOS (6.8.37 recommended) and Company Portal on managed Macs (5.2511). On Android, confirm Chrome is the default browser through device policy.
- Find users on unmanaged Macs, Linux or national-cloud tenants. They stay on the old behavior or preview, and they need a different plan.
- Enable per platform through the
systemBrowserEnabledOnproperty on the domain'sinternalDomainFederationconfiguration in Microsoft Graph (valuesAndroid,Ios,Macos). Microsoft's docs say a Global Administrator makes this change. - Test with Microsoft's validation steps. Start sign-in in a supported app, confirm the system browser opens for the IdP step, and confirm control returns to the app. If sign-in stays in an embedded web view, check the protocol, platform setting and broker version.
- Review your IdP's session lifetime and step-up rules. Browser SSO sessions now feed native app sign-ins too.