Is Microsoft's passkey gating is UA-based, not capability-based?

Question

Is Microsoft's passkey gating is UA-based, not capability-based?

Aman Kumar 0

Test: ship the UA patch to a TestFlight build, sign in with a test account, observe whether the "Face, fingerprint, PIN or security key" option appears.

Shubham Sharma 17,930 Reputation points Microsoft External Staff Moderator

2026-04-30T15:54:35.45+00:00
Hello Aman Kumar

Thank you for reaching out to Microsoft Q&A.

Right now the Entra ID “passkey” (WebAuthn CTAP2) rollout is gated by user-agent (UA) strings, not by probing for on-device WebAuthn/Ctap2 capabilities. In other words, if your patched UA looks like a supported browser, you’ll see the “Face, fingerprint, PIN or security key” option—even in a TestFlight build—regardless of whether the underlying WebAuthn/KDF support is truly functional.

What to try next:

Confirm your patched UA exactly matches one of our “allowed” UA patterns (e.g. a recent Safari or Chrome on iOS/Android).

Clear your browser cache or install fresh to avoid stale feature flags.

Sign in again with your test account and verify the option appears.

If it doesn’t show up even with a matching UA, we might need to check:

• That the preview/feature-flag for passkeys is enabled in your tenant

• Your TestFlight app isn’t dropping or overriding the UA you’re injecting

Hope that clears things up!

References

• Learn how Entra ID passkey (passwordless) is currently gated by UA:

https://learn.microsoft.com/azure/active-directory/authentication/howto-authentication-passwordless-passkey

• FAQ on passkey rollout in Microsoft Entra ID:

https://learn.microsoft.com/azure/active-directory/authentication/adpasskey-faq

If the answer is helpful, kindly upvote it. If you have extra questions about this answer, please click "Comment".
Shubham Sharma 17,930 Reputation points Microsoft External Staff Moderator

2026-05-05T07:41:32.2+00:00

Aman Kumar

Following up to check if the resolution provided was helpful. Let us know if you need any further assistance.

1 answer

Your answer

Shubham Sharma 17,930 Reputation points Microsoft External Staff Moderator

2026-04-30T15:54:35.45+00:00

Hello Aman Kumar

Thank you for reaching out to Microsoft Q&A.

Right now the Entra ID “passkey” (WebAuthn CTAP2) rollout is gated by user-agent (UA) strings, not by probing for on-device WebAuthn/Ctap2 capabilities. In other words, if your patched UA looks like a supported browser, you’ll see the “Face, fingerprint, PIN or security key” option—even in a TestFlight build—regardless of whether the underlying WebAuthn/KDF support is truly functional.

What to try next:

Confirm your patched UA exactly matches one of our “allowed” UA patterns (e.g. a recent Safari or Chrome on iOS/Android).

Clear your browser cache or install fresh to avoid stale feature flags.

Sign in again with your test account and verify the option appears.

If it doesn’t show up even with a matching UA, we might need to check:

• That the preview/feature-flag for passkeys is enabled in your tenant

• Your TestFlight app isn’t dropping or overriding the UA you’re injecting

Hope that clears things up!

References

• Learn how Entra ID passkey (passwordless) is currently gated by UA:

https://learn.microsoft.com/azure/active-directory/authentication/howto-authentication-passwordless-passkey

• FAQ on passkey rollout in Microsoft Entra ID:

https://learn.microsoft.com/azure/active-directory/authentication/adpasskey-faq

If the answer is helpful, kindly upvote it. If you have extra questions about this answer, please click "Comment".
Shubham Sharma 17,930 Reputation points Microsoft External Staff Moderator

2026-05-05T07:41:32.2+00:00

Aman Kumar

Following up to check if the resolution provided was helpful. Let us know if you need any further assistance.

Answer 1

The provided information does not describe how Microsoft Entra ID or Microsoft account sign-in endpoints gate passkey experiences at the protocol level (for example, whether they key off user agent strings vs. actual WebAuthn/FIDO2 capability detection).

From the context, only the following is documented:

Passkeys are supported on specific OS versions and browsers (for example, Edge/Chrome/Safari 16+/109+ on supported platforms).
To use a passkey, the user selects Other ways to sign in → Face, fingerprint, PIN, or security key, and the device/browser then opens the platform security UI.
Known issues mention Bluetooth requirements and orphaned passkeys, but not the gating logic.

There is no explicit statement in the context about whether the appearance of the "Face, fingerprint, PIN, or security key" option is controlled by UA sniffing, by WebAuthn/FIDO2 feature detection, or by some combination of both plus policy.

References: