FIDO2 security keys in Azure AD Conditional Access: Acceptance in OAuth 2.0 Authorization Code flow with PKCE remains undefined

Answer

Yes. Azure AD will accept a registered FIDO2 security key as the MFA factor for an OAuth 2.0 Authorization Code flow with PKCE, provided the interactive sign-in is performed in a WebAuthn-capable browser. The client application does not present the key directly; Azure AD prompts for it during the browser-based authorization request and Conditional Access evaluates the MFA grant there.

Confirmed facts

• Conditional Access MFA enforcement occurs at the Azure AD authorization endpoint, not inside the client.
• FIDO2 Security Key is an Azure AD Authentication Method that can be required by Conditional Access.
• Authorization Code + PKCE is the supported public-client flow for Azure AD. PKCE is handled by the client library or by the browser redirect.
• MSAL libraries for web, .NET, Python and Java redirect interactive authentication to the system browser or a compliant embedded web view. The redirect lands on login.microsoftonline.com where WebAuthn is used.

Likely explanation for uncertainty

Documentation emphasizes browser sign-in, which creates the impression that app sign-in is different. In practice the app sign-in is browser sign-in. The only variable is whether the browser surface used by the app supports WebAuthn. If it does, FIDO2 works. If it does not, the FIDO2 prompt cannot complete and the flow fails.

Required configuration for this case

1. Azure AD tenant: FIDO2 Security Key enabled in Security > Authentication methods, and the test user is in the target users/groups.
2. User: FIDO2 key registered via My Security Info / My Sign-ins. Registration is separate from the OAuth flow.
3. Conditional Access: Policy targets the client app and user/group, with grant control Require multifactor authentication. FIDO2 is selected as an allowed or required method in the Authentication Methods policy.
4. Client app: Public client using Authorization Code + PKCE. Use an MSAL library and configure interactive auth to use the system browser. Do not force a legacy embedded web view.

If FIDO2 is not accepted

Failure is almost always a web view capability issue, not a protocol issue. Workarounds that avoid WebAuthn dependency are:

• Microsoft Authenticator push notification or OTP
• SMS / voice if enabled
• Temporary Access Pass for break-glass

These methods work in any WebAuthn-capable or limited web view.

Verification you can run

• Initiate Auth Code + PKCE with system browser and observe the Azure AD sign-in logs. Authentication Method should show FIDO2 Security Key and Conditional Access shows Success for MFA.
• Test WebAuthn support in the same web surface the app uses by visiting a WebAuthn test page. If registration/authentication fails there, FIDO2 will fail in Azure AD.

Assumption: Azure AD Premium P1/P2 is in use and the app registration is configured as a public client with PKCE. Uncertainty remains around custom embedded web views on older OS versions where WebAuthn is not available.

One diagnostic detail that changes the recommendation: which browser surface your app uses for interactive auth — system browser vs embedded web view, and the OS/WebView version. Confirm that to decide if FIDO2 can be relied on or if you must fall back to Authenticator-based MFA.