Supported way to enable passkey ("Face, fingerprint, PIN or security key") sign-in for Microsoft Entra users inside an iOS app — passkey appears in mobile Safari but not in our embedded sign-in surface

Question

Supported way to enable passkey ("Face, fingerprint, PIN or security key") sign-in for Microsoft Entra users inside an iOS app — passkey appears in mobile Safari but not in our embedded sign-in surface

Aman Kumar 0

I'm building an iOS application that integrates Microsoft Entra ID sign-in. Some of our customers have Conditional Access policies that require phishing-resistant authentication (passkey). When those users sign in via

mobile Safari directly, the "Face, fingerprint, PIN or security key" option appears alongside federated providers and they can complete sign-in. When the same users sign in inside our iOS app's embedded sign-in surface,

that option does not appear — only federated providers are listed — so they cannot satisfy the Conditional Access policy and receive AADSTS53003.

I want to make sure my iOS app is using a Microsoft-supported sign-in surface so passkey works correctly. I'd appreciate guidance on:

Supported iOS sign-in surfaces. Which iOS web/auth surfaces are officially supported by Microsoft Entra ID for FIDO2/passkey sign-in? Specifically: ASWebAuthenticationSession, SFSafariViewController, WKWebView, MSAL

with broker (Microsoft Authenticator). Is there a documented support matrix?

What determines which methods are shown. What does the Microsoft Entra sign-in page use to decide whether to render the passkey option — WebAuthn capability detection

(PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable()), the request's authentication context, the user's authentication-methods policy, app registration settings, or a combination?

MSAL + broker on iOS. When using MSAL for iOS with Microsoft Authenticator as broker, what makes passkey sign-in succeed end-to-end? Are there configuration steps beyond adding MSAL — app registration redirect URIs,

entitlements, broker availability checks — that are required?

Request parameters. Are there OIDC/SAML request parameters (prompt, acr_values, amr_values, authentication context class) that an app should include to ensure phishing-resistant methods are surfaced when the tenant's

CA policy requires them?

Documentation. Could you point to the canonical Microsoft Learn / Identity Platform docs covering (a) supported iOS authentication surfaces for FIDO2/passkey and (b) the request parameters above?
Repro tenant config. What's the minimum tenant configuration (authentication-methods policy, CA policy, app registration) needed to reproduce this on a test tenant so I can verify my fix?

VEMULA SRISAI 13,900 Reputation points Microsoft External Staff Moderator

2026-04-30T16:34:11.69+00:00
Hello Aman Kumar,

Thanks for the detailed scenario. This behavior is expected and is related to the iOS sign‑in surface being used with Microsoft Entra ID. Passkey (phishing‑resistant) authentication is only supported on specific iOS system browser surfaces, which explains why it works in mobile Safari but not in an embedded sign‑in experience.

Supported iOS sign‑in surfaces

Microsoft Entra ID supports passkey (FIDO2) sign‑in on iOS only when the sign‑in is performed using a system browser equivalent surface.

Supported:

ASWebAuthenticationSession (this is what MSAL for iOS uses by default)

Mobile Safari

MSAL with Microsoft Authenticator (brokered authentication)

Not supported:

WKWebView

Other custom embedded web views

There is no single published support matrix for iOS surfaces vs passkeys, but Microsoft Entra ID passkey authentication relies on WebAuthn support, which is only available on system browser surfaces on iOS.

What determines which methods are shown

The passkey option is shown based on a combination of factors:

The authentication surface (must support WebAuthn, e.g., Safari or ASWebAuthenticationSession)

Authentication Methods policy (passkeys/FIDO2 enabled)

User registration state (user already has a passkey registered)

Conditional Access policy (authentication strength requires phishing‑resistant MFA)

MSAL + broker on iOS

When using MSAL for iOS with Microsoft Authenticator as broker, passkey sign‑in works when:

The app is registered as an iOS/macOS platform in Entra ID

The redirect URI is configured (for example msauth.<bundle-id>://auth)

The app uses MSAL’s interactive sign‑in flow (system browser)

Microsoft Authenticator is installed on the device

No additional passkey‑specific configuration, entitlements, or flags are required beyond standard MSAL + broker setup.

Platform requirements (iOS 14.3+)

If the sign‑in is performed in an unsupported surface such as WKWebView, the passkey option is not rendered, even if Conditional Access requires it.

Request parameters

There are no OIDC or SAML request parameters (prompt, acr_values, amr_values, authentication context class) that an app needs to include to surface passkey.

Phishing‑resistant authentication is enforced through Conditional Access authentication strength, not through request parameters.

Documentation

Relevant Microsoft Learn documentation:

MSAL for iOS – system browser vs embedded web views: https://learn.microsoft.com/en-us/entra/msal/objc/customize-webviews

MSAL for iOS – brokered authentication with Microsoft Authenticator : https://learn.microsoft.com/en-us/entra/msal/objc/

Microsoft Entra passkey (FIDO2) authentication overview : https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-passkeys-fido2

Conditional Access authentication strengths : https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-strengths

There is no single document listing all supported iOS surfaces for passkeys.

Repro tenant configuration

Minimum configuration:

Enable Passkey (FIDO2) in Authentication Methods policy

Register a passkey for a test user

Create a Conditional Access policy requiring Phishing‑resistant authentication strength

Register the iOS app with iOS/macOS platform

Test:

Safari or MSAL system browser → passkey shown

Embedded WKWebView → passkey not shown, sign‑in fails with AADSTS53003
VEMULA SRISAI 13,900 Reputation points Microsoft External Staff Moderator

2026-05-05T19:25:09.2266667+00:00

Aman Kumar I’m following up on my previous response to see if it helped. Please feel free to reach out if you need any further assistance—I’m happy to help.