Microsoft Entra Passkeys for External IdP App Sign-Ins

Introduction

Microsoft is expanding passwordless sign-in options for organizations that federate Microsoft 365 authentication to an external identity provider. This update matters because it removes a long-standing limitation in Microsoft app sign-ins where embedded web views often blocked passkeys, FIDO2 security keys, or browser-based single sign-on.

What’s new

General availability introduces browser authentication for external identity providers in supported Microsoft app sign-ins. Instead of handling the external identity provider step inside an embedded web view, Microsoft now opens that step in the system browser, which supports WebAuthn and eligible existing sign-in sessions.

Supported benefits include:

• Passkeys and FIDO2 security keys from external identity providers now work in supported Microsoft apps
• Single sign-on reuse from the system browser can reduce repeated prompts
• Support for IdPs that block embedded web views, helping organizations keep stricter authentication policies
• Platform-level rollout control so admins can enable the experience only where needed

Supported Microsoft apps include Outlook, Teams, OneDrive, Word, Excel, PowerPoint, and Microsoft To Do.

Supported platforms

This capability is available for federated domains using WS-Fed or SAML 2.0 on:

• Android with Chrome as the default browser and a supported Microsoft broker
• Android shared device mode with Chrome and a supported broker
• iOS with Safari and Microsoft Authenticator as the broker
• Managed macOS with Safari and Intune Company Portal as the broker

Windows is not part of this flow because it already supports third-party FIDO sign-in natively. Linux, unmanaged macOS, and OAuth 2.0/OpenID Connect social identity provider flows are not supported currently.

Why this matters for IT admins

For Entra ID and Microsoft 365 administrators, this update helps extend an existing passwordless strategy into native Microsoft apps without creating separate authentication workarounds. It also improves compatibility with external identity providers that require browser-based authentication and reject embedded web views.

The sign-in process still uses the Microsoft identity broker to coordinate authentication and token handling, so the Microsoft app experience remains familiar while the external IdP step moves to the browser.

Next steps

Admins should:

1. Confirm the domain is federated with WS-Fed or SAML 2.0
2. Review broker app and platform prerequisites
3. Enable browser authentication for selected platforms
4. Validate sign-in behavior with the external identity provider
5. Communicate the updated sign-in experience to users

This release is a practical step forward for organizations standardizing on passkeys and phishing-resistant authentication across Microsoft apps.