Microsoft Entra Browser Authentication: Enable Federated IdP Passkeys on Android, iOS and macOS

If you run a federated Entra tenant, this matters. Until now, a security key could work in the browser and then fail the moment a user opened Outlook on a phone.

Why embedded sign-in blocked passkeys​

Some Microsoft app sign-ins used an embedded WebView. That's a small browser surface drawn inside the app or the broker. It couldn't provide the browser features that WebAuthn-based passkeys need when the passkey comes from a third-party IdP.

In practice, that caused three problems:

• Passkeys and security keys didn't work. Users with credentials registered at their external IdP fell back to passwords, or couldn't sign in at all if the IdP required passkeys.
• IdPs that reject WebViews refused the sign-in. Some identity providers deliberately block embedded user agents for security reasons.
• Browser sessions weren't shared. A user already signed in to the IdP in the browser got prompted again inside the app.

Microsoft's own passkey compatibility matrix showed the gap. A localized copy of that page still says Microsoft Entra ID doesn't support passkey authentication with a third-party IdP on iOS/macOS. The workaround it described was demanding: third-party IdPs can implement their own single sign-on (SSO) extension on iOS/macOS devices if they're managed by Mobile Device Management (MDM). In other words, the IdP vendor had to build an Apple SSO extension. The new feature gives admins a native Entra setting instead. Compatibility pages can lag behind feature releases, so treat the dedicated feature documentation as the current source.

Summary: The old WebView sign-in couldn't run IdP passkey flows. The fix is to stop running the IdP step inside the WebView.

How the new sign-in flow works​

The feature is called browser authentication for external identity providers. Only the external IdP step moves to the system browser. The rest of the sign-in stays inside Microsoft's broker.

According to Microsoft Learn, the flow runs like this:

1. The user starts sign-in in a supported Microsoft app.
2. The Microsoft identity broker hands the external IdP step to the system browser.
3. The user signs in at the IdP, which Microsoft treats as a separate authentication boundary.
4. A redirect deep link returns control to the broker.
5. The broker finishes sign-in in the original app.

Depending on the platform, the broker is Microsoft Authenticator, Intune Company Portal or another supported Microsoft broker app. Microsoft's announcement says users can authenticate with passkeys or FIDO2 security keys in the system browser, and eligible browser sessions can reduce repeated prompts.

Microsoft's documentation adds an important limit: the Microsoft broker itself doesn't gain direct support for third-party FIDO2 keys. The IdP's own passkey flow simply runs in a browser that can handle it. Session reuse is also not guaranteed. Whether a browser session can be reused depends on the IdP and its policies.

Summary: The broker still controls the app sign-in. The browser only handles the IdP step, which is where WebAuthn works.

Platforms, versions and supported apps​

Microsoft Learn lists these requirements:

Tested and supported apps: Outlook, Teams, OneDrive, Word, Excel, PowerPoint and Microsoft To Do. Other brokered apps may work, but Microsoft treats them as preview until they're officially listed.

Not supported:

• Linux
• Unmanaged macOS
• OAuth 2.0/OpenID Connect social IdPs
• Direct sign-in to the Intune Company Portal app on Android, which still uses an embedded WebView (Company Portal can still act as the broker for other Android apps)

Cloud availability: The feature is generally available in the Microsoft Entra public cloud. In national clouds it remains in preview while Microsoft resolves known issues.

Windows: Windows isn't part of this rollout. Microsoft says third-party FIDO already works natively on Windows and doesn't use this browser handoff. Windows sign-in has seen its own changes: 4sysops reported that recent Entra updates included an option to replace the legacy EdgeHTML WebView with the Chromium-based WebView2 for Entra ID authentication flows.

Summary: Check three things before you enable anything: the federation protocol, the browser, and the broker version.

How to enable it​

Microsoft's short version: confirm that your domain uses a supported federation protocol, then enable browser authentication for the selected platforms.

The feature is off by default. You turn it on with the systemBrowserEnabledOn property of the domain's internalDomainFederation configuration in Microsoft Graph.

Step 1: Find the federation configuration ID.

GET /domains/{federated_domain_name}/federationConfiguration

The id value in the response is the configuration ID you'll patch.

Step 2: Choose the platforms and send a PATCH request.

PATCH /domains/contoso.com/federationConfiguration/{configuration id}

{
  "systemBrowserEnabledOn": "Android, Ios"
}

• Valid values are Ios, Android and Macos, as a comma- or space-separated list.
• Setting the property to none turns the feature off.
• Microsoft's example says a Global Administrator makes this call, with the InternalFederation.ReadWrite.All and Domain.ReadWrite.All permissions.

Step 3: Confirm the setting. Run a GET against the same configuration ID. The response should show your chosen systemBrowserEnabledOn value next to properties such as preferredAuthenticationProtocol.

A note on scripting: the documentation's PowerShell samples appear to use Update-MgDomainFederationConfiguration for the list and query steps as well as the enable step. They also use a different scope string and write the iOS value as "iOS". Check the Microsoft Graph PowerShell reference before you script this. Don't copy the sample domain or IDs into production.

A sensible rollout is to enable one platform, test with a pilot group, then add the next platform.

Summary: This is one property in Graph. It's small, but it controls authentication, so change it carefully.

What success looks like, and troubleshooting​

Microsoft's validation steps are simple observations:

1. Confirm that the protocol, platform, browser and broker meet the requirements above.
2. Start sign-in from a supported app, such as Outlook.
3. Check that the system browser opens for the IdP step. If the sign-in stays inside the app, the feature isn't active.
4. Sign in at the IdP with the passkey or security key.
5. Check that you're returned to the original app and signed in.

Common problems and what to check:

Microsoft also warns help desks not to put tokens, broker-flow state, tenant IDs, or user and device identifiers into URLs, logs, telemetry or support notes. Screenshots of redirect URLs in support tickets count too.

Analysis: a real step forward, with limits​

This is a practical change rather than a flashy one. Passkeys and FIDO2 security keys provide phishing-resistant authentication without relying on shared secrets. Until now, federated organizations could require them on the web but still had a password fallback on mobile. Closing that gap means a phishing-resistant policy can finally apply to Outlook and Teams on phones as well.

The limits are worth keeping in mind:

• Only WS-Fed and SAML 2.0 domains qualify. OIDC-based social IdP flows are out.
• Unmanaged Macs aren't covered. Personally owned macOS devices won't get this.
• Android depends on Chrome as the default browser. In fleets that standardize on another browser, that could cause a policy dispute.
• The IdP's security matters more. Microsoft calls the external IdP a separate authentication boundary. The quality of your IdP's passkey setup now directly affects your Microsoft 365 security.
• Users will see a browser open mid-sign-in. Warn them in advance. Otherwise, some will report the handoff as phishing, which is ironic for a phishing-resistant feature.

For organizations still using a third-party IdP alongside Entra, this removes one of the stronger practical reasons to migrate authentication entirely into Entra. Whether it's reason enough to keep a federated setup is a separate decision.

Summary: If you federate Microsoft 365 through SAML or WS-Fed and want to require passkeys, this closes the mobile gap. Check the version requirements, pilot one platform, and tell users about the browser handoff before rollout.