Microsoft Entra Passkeys: Architecture Decisions for Phishing-Resistant Authentication
How to choose between synced and device-bound passkeys, enforce them with Conditional Access authentication strengths, secure registration and recovery, and address what passkeys do not solve — including session theft, device trust, and credential custody.
Introduction
I do not treat passwordless and phishing-resistant as the same thing. They are separate properties that happen to overlap in some methods but not others. Microsoft Authenticator phone sign-in is passwordless MFA — but it is not phishing-resistant. A FIDO2 security key is both passwordless and phishing-resistant. A passkey can satisfy phishing-resistant MFA without a password — but if the sign-in flow also requires the user to enter a password, the overall experience is no longer passwordless.
This distinction matters because the credential you choose, the policy you enforce, the registration process you trust, and the session controls you layer around it produce materially different security outcomes. Microsoft Entra passkeys reduce phishing risk, but they do not eliminate session theft or token replay.
My architecture rule: secure registration → choose the right credential type → enforce the right authentication strength → protect the device and session → design resilient recovery.
Why Microsoft Entra Passkeys Matter Now
Beginning September 1, 2026, Microsoft began rolling out its passkey-by-default transition, automatically enabling passkeys and registration prompts for users currently enabled for SMS or voice authentication. This is distinct from an organization enforcing phishing-resistant access — it makes passkeys available and encourages adoption through registration campaigns, but does not require them through policy.
Microsoft-provided SMS and voice authentication delivery retires February 1, 2027. Organizations using customer-managed telecom providers can continue, but the default Microsoft delivery path ends. Credential migration needs to be underway.
Microsoft’s July 2026 Secure Future Initiative progress report shows phishing-resistant MFA protecting 99.97% of its internal user and device pairs.
What Microsoft Entra Passkeys Actually Prove
A passkey is a FIDO2/WebAuthn credential. During authentication, the authenticator signs a challenge from the relying party (Microsoft Entra, identified by the relying party ID) using the private key. The private key is never sent to Microsoft Entra or the relying party. Device-bound passkeys keep it on the authenticator; synced passkeys securely synchronize encrypted key material through the credential provider.
RP ID / origin binding. The authenticator verifies the relying party’s origin before releasing the credential. A phishing proxy on a different domain cannot obtain the signature — the origin check fails silently. This is the property that makes passkeys phishing-resistant.
Local user verification. The authenticator requires a biometric, PIN, or device unlock before signing. This satisfies the “something you are” or “something you know” factor locally.
What the passkey does not prove. The passkey does not prove the device is managed, compliant, or free of malware. It does not prove the resulting session token cannot be stolen. It does not prove the endpoint has been assessed by Defender or enrolled in Intune. Those are separate architectural controls.
Microsoft Entra Passkey Architecture Decisions
Credential types: synced vs device-bound
This is one of the key architecture decisions for passkey deployment:
Property Synced passkeys Device-bound passkeys Credential storage Synced across devices via platform credential manager (iCloud Keychain, Google Password Manager, or similar) Bound to a single authenticator; cannot be extracted or synced Private key Encrypted and synchronized through the credential provider Remains on the authenticator hardware Recovery Provider’s account-recovery model restores access on a new device Lost authenticator requires re-registration with a new credential Attestation Not supported — authenticator attributes cannot be cryptographically verified Supported where the authenticator provides it Administrative visibility Administrators cannot enumerate every device holding a synced copy Credential is on one known authenticator Recommended population Broader workforce — phishing resistance with practical recovery Administrators and highly privileged users — tighter credential custody
Microsoft recommends device-bound credentials for administrators and highly privileged users. For broader populations, synced passkeys provide phishing resistance with practical recovery.
Without attestation, Microsoft warns that authenticator attributes — including whether a credential is synced or device-bound — cannot be guaranteed. An AAGUID identifies an authenticator type, not an individual compliant workstation.
Microsoft implementations are not interchangeable
Method Passwordless Phishing-resistant Device-bound Notes Passkeys in Microsoft Authenticator ✓ ✓ Yes — cannot be synced or restored to another device Authenticator backup does not restore passkeys Synced passkeys (iCloud, Google, etc.) ✓ ✓ No — synced via provider Provider’s account security becomes part of the trust model FIDO2 security keys ✓ ✓ Yes Hardware-based; strongest custody for emergency and privileged access Windows Hello for Business ✓ ✓ Yes; TPM-backed when hardware security is required/configured Software-backed provisioning is possible when a usable TPM is unavailable; require hardware-backed for privileged users Microsoft Entra passkey on Windows (Preview) ✓ ✓ Yes Can operate without Entra device registration; does not replace WHfB device sign-in Microsoft Authenticator phone sign-in ✓ No N/A Passwordless MFA but not in the Phishing-resistant MFA strength
Profiles and policy overlap
Passkey profiles control which credential types are permitted. A credential is permitted if it fully satisfies any applicable profile. Broad group membership can undermine an administrator-specific restriction — if an admin is also a member of a group with a permissive profile, the permissive profile allows registration.
Microsoft currently supports up to 10 passkey profiles per tenant, including the Default profile, subject to the dedicated 20-KB passkey policy limit. After you opt in to passkey profiles, you cannot opt out.
How I Deploy Microsoft Entra Passkeys
Step 1: Configure the Authentication methods policy. Enable passkeys (FIDO2) for the target populations. Configure profiles to control synced vs device-bound and attestation requirements. I always review the Authentication methods policy and Conditional Access together — enabling a method does not mean the tenant requires it.
Passkey (FIDO2) enabled for a targeted group rather than all users. SMS and voice are disabled. Enabling a method here permits registration — Conditional Access authentication strengths determine whether the method is required for access.
Step 2: Secure registration with Temporary Access Pass. Verify identity before issuing a TAP. Keep validity short. Use single-use passes where practical. The clean pattern is a Conditional Access policy targeting the Register security information user action with an authentication strength that permits TAP, rather than allowing TAP for general resource access. Registration and recovery are part of the security architecture — a strong passkey deployment can be weakened by poor identity verification or overly broad TAP usage.
Microsoft’s September 9, 2026 guidance specifically identifies passkey-themed social engineering targeting registration and recovery flows, recommending hardened security-info registration, blocking unnecessary device-code and authentication-transfer flows, and monitoring authentication-method changes.
Step 3: Enforce with Conditional Access authentication strengths. One common mistake is enabling passkeys but not enforcing them with Conditional Access authentication strengths. Method enablement permits use; Conditional Access determines acceptable methods for protected resources. Use the built-in Phishing-resistant MFA strength for privileged roles. Use a custom authentication strength when only particular credential types or AAGUIDs should qualify.
Require authentication strength with Phishing-resistant MFA selected. The warning confirms this cannot be combined with Require multifactor authentication in the same policy. Report-only mode is selected for safe deployment.
Enabling attestation later does not block previously registered unattested credentials. Key restrictions have different behavior and affect both registration and authentication. Plan attestation requirements before broad registration.
Step 4: Pilot by user, device, and application. I recommend piloting passkey deployment by user type, device, browser/client, and application, because support and user experience can vary across sign-in paths. Phone-based cross-device authentication introduces Bluetooth and connectivity requirements. Test browser, native-app, broker, operating-system, and remote-session paths separately. Measure successful passkey sign-ins alongside registration totals — I have seen organizations focus on registration numbers without checking whether users are actually signing in with passkeys or falling back to weaker methods.
Get Hasib Munib’s stories in your inbox
Join Medium for free to get updates from this writer.
Step 5: Remove weak fallback methods. Plan replacement credentials and identity verification before removing older methods. Microsoft specifically identifies dormant credentials and weak help-desk recovery as paths around strong sign-in. Microsoft-provided SMS/voice delivery retires February 1, 2027. Disable weaker methods for populations that have completed passkey registration and validated their sign-in experience.
Common Microsoft Entra Passkey Mistakes
Equating passwordless with phishing-resistant. Authenticator phone sign-in is passwordless MFA but not phishing-resistant. The built-in Phishing-resistant MFA strength also accepts Windows Hello for Business and multifactor CBA — it is not passkey-only.
Assuming the strictest passkey profile wins. A credential is permitted if it satisfies any applicable profile. Broad group membership can override an administrator-specific restriction.
Treating an unattested AAGUID as proof. Without attestation, authenticator attributes cannot be guaranteed.
Confusing device-bound credentials with managed devices. Microsoft Entra passkey on Windows (Preview) can operate without Entra device registration. A device-bound credential does not prove device compliance.
Assuming Authenticator backup restores passkeys. Passkeys in Microsoft Authenticator are device-bound and cannot be restored onto another device through Authenticator backup.
Assuming enforcement removes passwords. An authentication-strength policy can allow initial password entry while requiring a stronger method before resource access. It does not itself delete the password.
Assuming passkeys eliminate session theft. Endpoint compromise and stolen session artifacts require separate prevention, detection, and session controls.
What Microsoft Entra Passkeys Do Not Solve
I do not assume a device-bound credential means the endpoint itself is trusted. I still evaluate device compliance, endpoint protection, and session controls separately.
Device trust. Passkeys prove identity, not device health. Combine passkey authentication with Intune device compliance through Conditional Access where managing endpoints for sensitive access.
Session and token protection. Once a session token is issued, the passkey’s role is complete. Token Protection binds tokens to specific devices for supported applications. Native Token Protection is generally available on Windows, iOS/iPadOS, and macOS for Exchange Online, SharePoint Online, and Teams. Azure Virtual Desktop and Windows 365 support is Windows-specific. Browser support remains Preview for selected Azure Resource Manager web scenarios on Windows and macOS.
Application sessions. Individual applications may issue their own session cookies or tokens. A passkey-protected Entra session does not automatically protect every downstream application session.
Alternative authentication flows. Block unnecessary device-code authentication and retain narrowly scoped exceptions only for verified device scenarios. A passkey deployment is incomplete if legacy or device-code flows remain available as bypass paths.
B2B / guest access. Passkey registration is not currently supported for internal or external guest/B2B users in the resource tenant. Microsoft expects broader B2B passkey support later in 2026. Home-tenant authentication and cross-tenant MFA trust determine usable phishing-resistant methods for guests.
What I Recommend in Production
Administrators and privileged roles. Device-bound passkeys or FIDO2 security keys. Phishing-resistant MFA strength enforced. Device compliance required. Hardware-backed Windows Hello for Business where applicable. Separate recovery credentials. Help-desk recovery hardened.
Broader workforce. Synced passkeys for phishing resistance with practical recovery. Phishing-resistant or Passwordless MFA strength depending on readiness. Measured migration from SMS and voice before the February 2027 retirement.
Emergency access. Independent FIDO2 security keys on two cloud-only accounts. Excluded from Conditional Access policies that could block sign-in. Tested regularly.
Microsoft Entra Passkey Deployment Checklist
→ Credential-type decision documented: synced passkeys for workforce, device-bound for administrators and privileged users. → Authentication methods policy configured with appropriate passkey profiles; attestation requirements set before broad registration. → Registration secured with TAP via Conditional Access targeting the Register security information user action; short validity, single-use where practical, identity verified. → Conditional Access authentication strength enforced: Phishing-resistant MFA for administrators, appropriate strength for workforce. → Profile overlap reviewed: administrator-specific restrictions not undermined by broad group membership. → Pilot validated across user types, devices, browsers/clients, and applications; actual passkey sign-ins measured alongside registrations. → SMS and voice disabled for populations with validated passkey sign-in experience; February 2027 retirement tracked. → Help-desk recovery and credential-replacement procedures hardened; registration and method-change monitoring configured. → Device compliance required alongside passkey authentication for sensitive access; hardware-backed WHfB required for privileged users. → Token Protection enabled for supported applications and platforms; session controls configured. → Device-code and legacy authentication flows blocked with narrow documented exceptions. → Emergency access accounts configured with independent FIDO2 security keys, excluded from restrictive policies, and tested. → B2B passkey limitations documented: guest registration unsupported in resource tenant; cross-tenant MFA trust evaluated.
Microsoft References
→ Passkey authentication concepts — Microsoft Entra — WebAuthn, RP ID binding, credential models, and local user verification.
→ Enable passkeys (FIDO2) and profiles — Microsoft Entra — Profile semantics, synced vs device-bound, 10-profile limit, policy constraints, and attestation.
→ Enable synced passkeys — Microsoft Entra — Sync model, provider custody, and administrative-visibility limitations.
→ Microsoft Entra passkey on Windows (Preview) — Comparison with Windows Hello for Business; device-registration independence.
→ Passkey vendor attestation — Microsoft Entra — Attestation requirements, AAGUID restrictions, and supported authenticators.
→ Passkey FAQ — Microsoft Entra — Recovery, revocation, Authenticator backup limitations, and device visibility.
→ Passkey compatibility matrix — Browser, native-app, and cross-device support.
→ Conditional Access authentication strengths — Built-in and custom strengths, AAGUID filtering, and enforcement mechanics.
→ Configure Temporary Access Pass — Bootstrap configuration, single-use vs multi-use, and recovery scenarios.
→ Token Protection — Microsoft Entra — Session binding; GA on Windows, iOS/iPadOS, macOS; Preview browser support.
→ Passkeys by default and SMS/voice transition — Microsoft Learn — September 2026 rollout, February 2027 retirement, and customer-managed telecom alternatives.
→ Passkeys are the default authentication method — Microsoft Security Blog, July 2026 — SFI 99.97% figure and passkey-by-default transition.
→ Passkey-themed social engineering — Microsoft Security Blog, September 2026 — Securing registration, recovery, and method-change flows against social engineering.
→ Microsoft Entra releases and announcements — 10-profile maximum, 20-KB passkey-policy allocation, and current feature status.
→ Authentication strengths for external users — B2B guest-authentication limitations and cross-tenant MFA trust.
→ Manage emergency access accounts — Cloud-only accounts, phishing-resistant credentials, and validation.
→ Security architecture design — Azure Architecture Center — Identity within the broader security architecture.
The Microsoft Learn references above reflect documentation current as of September 2026. Microsoft Entra passkey capabilities, authentication-method policies, and Conditional Access features change — verify against the latest documentation before deploying.
