Beyond push notifications: engineering phishing-resistant FIDO2 and passkey controls

Separate MFA completion from phishing resistance

Start by separating MFA completion from phishing resistance. Microsoft's authentication-strength table includes password plus push notification under MFA, but not phishing-resistant MFA; Authenticator phone sign-in is passwordless, but also absent from the phishing-resistant category. For an AiTM assessment, approving a prompt does not establish that a phishing-resistant method was used. The supplied evidence does not document proxy-kit session-cookie theft or number-matching behaviour. Treat both as separate validation items, rather than claiming that number matching closes the AiTM gap.

FIDO2 changes the authentication ceremony rather than merely changing the prompt. Passkeys use origin-bound public-key cryptography and require local user interaction. WebAuthn supports browsers; CTAP handles communication with authenticators. Entra sends a challenge, the authenticator locates the credential using the hashed relying-party identifier and credential identifier, and the user unlocks the private key with biometrics or a PIN. The authenticator signs the challenge, and Entra verifies the signature before issuing a token. This documents phishing-resistant authentication, not comprehensive protection for issued sessions.

Evidence: Conditional Access authentication strengths, Authentication methods in Microsoft Entra ID - passkeys (FIDO2)

Design registration policy before enabling passkeys

Recommended deployment sequence: identify target groups, choose acceptable passkey types, then configure profiles through an Authentication Policy Administrator. Entra supports synced passkeys and device-bound passkeys on FIDO2 security keys and in Microsoft Authenticator. Enabling profiles transfers existing global settings into a Default profile and cannot be reversed. The documented limits are three profiles, including Default, and a 20 KB policy size. Review these constraints before designing group segmentation. Passkey availability across Entra editions does not remove the separate licensing requirement for Conditional Access.

Choose attestation deliberately. Synced passkeys do not support it; enforcing attestation permits only device-bound passkeys. Without attestation, Entra cannot guarantee passkey attributes, including whether a credential is synced or device-bound. AAGUID allowlists without attestation should therefore be treated as policy guidance, not strict security controls. Crucially, attestation enforcement applies during registration: enabling it later does not block previously registered, unattested credentials from signing in. Recommended practice is to review existing registrations separately rather than treating a policy change as retrospective validation.

Evidence: How to enable passkeys (FIDO2) in Microsoft Entra ID, Conditional Access authentication strengths, Authentication methods in Microsoft Entra ID - passkeys (FIDO2)

Require the right methods at resource access

Enabling a method is not the same as requiring it. The Authentication methods policy governs availability; Conditional Access authentication strengths restrict acceptable combinations for particular access scenarios. Conditional Access requires Entra ID P1. Recommended practice is to require a phishing-resistant strength for sensitive resources, then decide whether the built-in strength matches your requirements: it also accepts Windows Hello for Business or platform credentials and multifactor certificate-based authentication. For narrower requirements, assess a custom strength. Do not combine Require multifactor authentication and Require authentication strength in one policy.

Review group overlap before calling the design restrictive. When users fall within multiple passkey profiles, registration and authentication succeed if the credential fully satisfies any one applicable profile; requirements are not cumulatively tightened. Excluded-group membership in the passkey authentication-method policy overrides inclusion and blocks registration and sign-in. AAGUID restrictions affect both operations, so removing a previously allowed authenticator can prevent existing users from signing in. Recommended practice is to inspect overlapping memberships and assess credential impact before changing allowed authenticator models.

Evidence: How to enable passkeys (FIDO2) in Microsoft Entra ID, Conditional Access authentication strengths

Validate registration, access and reauthentication separately

Use a staged review sequence: first check supported devices and providers, then test registration, then access to protected resources. Users must have completed MFA within the preceding five minutes to register a passkey. Also check the global Allow self-service set up setting: when disabled, Security info registration is unavailable even if the method is enabled. Recommended pilot tests should cover allowed and excluded users, permitted and blocked authenticators, and overlapping profiles. Record expected outcomes before testing rather than interpreting any successful sign-in as success.

Finally, test how users reach the required authentication method. Authentication strengths are evaluated after initial authentication, so users may still enter passwords before satisfying the required strength. If Windows Hello for Business is required but was not the primary method, users must restart the session and select an appropriate sign-in option. Authentication strength and sign-in frequency can also be satisfied at different times. Recommended acceptance criteria should distinguish registration, method enforcement and reauthentication; do not assume a frequency policy demands a fresh passkey ceremony.

Evidence: How to enable passkeys (FIDO2) in Microsoft Entra ID, Conditional Access authentication strengths