The working reference for designing, deploying and operating phishing-resistant, passwordless sign-in across an Entra ID workforce tenant: methods, policy, Conditional Access, rollout, recovery and troubleshooting.
No sections match that search. Try a method name (e.g. “FIDO2”), a term (“AAGUID”) or a date (“2027”).
Passwordless authentication replaces the password as the primary credential with something the user has (a device-bound or synced private key) unlocked by something they are or know locally (biometric or PIN). The secret never leaves the authenticator and is never typed into a web page, so there is nothing for an attacker to phish or replay.
These two terms are often confused:
login.microsoftonline.com), so an adversary-in-the-middle page cannot obtain a usable assertion. Passkeys (FIDO2), Windows Hello for Business, Platform SSO on macOS and certificate-based authentication qualify.The target state is phishing-resistant passwordless: every user has at least two phishing-resistant credentials, Conditional Access requires them by authentication strength, and the password is no longer used in daily sign-in.
Microsoft now designs Entra on the assumption that users sign in without passwords. System-preferred authentication now applies to first-factor sign-in, so users with a passkey or certificate registered no longer see a password prompt at all. Tenants without a plan will get these changes on Microsoft’s schedule.
Dates are for the worldwide/GCC cloud unless noted. The next upcoming milestone is highlighted automatically based on today’s date.
Group-targeted FIDO2 configuration with a passkeyType of device-bound, synced or both. Existing FIDO2 settings migrate into a “Default passkey profile” (worldwide migration May to June 2026; GCC High/DoD October 2026).
Up to 10 passkey profiles per tenant with a dedicated 20 KB policy allocation. Entra ID account recovery (government ID + biometric verification via partners) became generally available.
Device-bound passkeys in the Windows Hello container for unmanaged, personal and shared PCs. Passkeys for Entra External ID (customer) tenants also reached GA.
Strongest registered method is offered first at primary sign-in. Order: TAP, passkey, CBA, Authenticator, external MFA, TOTP, telephony, QR code, password.
Users enabled for SMS/voice are auto-enabled for passkeys (all types allowed) and nudged by a registration campaign with unlimited snoozes. Opt-out of auto-enablement via Graph is available until 1 Feb 2027.
Organizations that must keep SMS/voice can contract a carrier through the Microsoft Security Store and bear the cost directly. Entra passkeys on Windows reach GCC High/DoD during October.
Security questions are phased out as a self-service password reset method.
Applies to all users except Global Administrators and external users. Users whose only MFA method is SMS/voice get a blocking prompt to register a passkey.
After this date only customer-managed telecom can deliver SMS/voice codes.
If a tenant still has users whose only MFA method is SMS or voice, those users will be forced through passkey registration at their next sign-in after 1 Feb 2027. Run Microsoft’s SMS/voice usage analyzer now and schedule the migration yourself.
Entra supports several passwordless credentials. They differ in where the key lives, whether they can sign in to the device itself, whether the authenticator can prove its make and model (attestation), and what they cost to issue. Filter the table to the properties you need.
| Method | Phishing-resistant | Key storage | Device sign-in | Attestation | Unmanaged devices | Best fit |
|---|---|---|---|---|---|---|
| Windows Hello for BusinessCloud Kerberos Trust / key / cert trust | Yes | TPM on the PC | Yes | TPM-backed | No | Managed Windows, primary sign-in |
| Platform SSO (macOS)Secure Enclave key | Yes | Secure Enclave | Yes | No | No | Managed Macs |
| Entra passkey on WindowsGA May 2026 | Yes | Windows Hello container | No | No | Yes | Personal, shared or unjoined PCs |
| FIDO2 security keyUSB / NFC / BLE | Yes | Hardware key | YesEntra / hybrid joined | Yes | Yes | Admins, shared devices, high assurance |
| Passkey in Microsoft Authenticator | Yes | Phone secure hardware | No | Yes | Yes | Roaming credential, BYOD, backup |
| Synced passkeyiCloud Keychain, Google Password Manager, third-party managers | Yes | Provider cloud, synced | No | No | Yes | Broad workforce, contractors, easy recovery |
| Certificate-based authSmart card / PIV / CAC, multifactor binding | Yes | Smart card or device cert | Yes | PKI-issued | Yes | Federal and regulated, existing PKI |
| Authenticator phone sign-inNumber match push | No | Phone | No | No | Yes | Transitional only |
| QR code + PINFrontline, shared mobile | No | N/A | No | No | Shared mobile | Frontline where keys aren’t practical |
The default for managed Windows. A TPM-protected key pair per user per device, unlocked by face, fingerprint or PIN. Issues the Primary Refresh Token at Windows sign-in, so browser and app SSO follow.
Stores a device-bound Entra passkey in the Windows Hello container on PCs that aren’t joined or registered. Used for web and app sign-in; not for signing in to Windows itself.
Portable hardware authenticators. The strongest option for privileged roles and shared workstations. Use attestation plus an AAGUID allow list to restrict to approved models, and buy FIPS-validated keys where policy demands.
Device-bound passkey held in Microsoft Authenticator (iOS/Android). Signs in on the phone directly, or on another device via QR + Bluetooth proximity (hybrid transport). A good second credential for Windows Hello users.
Passkeys stored and synced by a platform or third-party credential manager. Easy to use and recover, but you are relying on the security of the provider account. Cannot be attested, so enforcing attestation in a profile excludes them.
Native Entra CBA with X.509 certificates on smart cards (PIV/CAC) or devices. Configure the binding as multifactor for it to count as phishing-resistant. Removes the need for AD FS in many federal environments.
Some links in this box are affiliate links; the site may earn a commission if you buy through them. Check each model’s AAGUID, attestation and certification status against your passkey profile before buying.
At registration the authenticator generates a key pair scoped to the relying party ID. Entra stores only the public key and, when available, the authenticator’s AAGUID and attestation. At sign-in Entra sends a challenge; the browser passes it to the authenticator only if the page origin matches the relying party. This origin check is what stops phishing proxies.
For hybrid-joined and Entra-joined devices that still need on-premises Kerberos (file shares, legacy apps), Cloud Kerberos Trust is the recommended model. It needs no PKI and no certificate deployment to clients. Entra ID issues a partial Kerberos TGT from a read-only-DC-style AzureADKerberos object in AD; a writable domain controller exchanges it for a full TGT.
Everything below lives under Entra admin center › Protection › Authentication methods unless noted. Manage methods only in the converged Authentication methods policy; the legacy MFA and SSPR method settings are retired.
A passkey profile is a named set of FIDO2 rules assigned to groups. Build profiles by persona rather than one tenant-wide rule.
| Setting | Options | Guidance |
|---|---|---|
| Passkey type | Device-bound · Synced · Both | Device-bound only for privileged roles; both for general workforce. |
| Enforce attestation | On · Off | On restricts to device-bound authenticators that can prove their model. Synced passkeys and Entra passkeys on Windows cannot attest. |
| Key restrictions | Allow list · Block list (AAGUIDs) | Allow-list approved security key models and Authenticator for admins. Use a block list to exclude specific providers. |
| Target | Groups | Up to 10 profiles per tenant. Assign break-glass accounts to the privileged profile. |
| Profile | Target | Type | Attestation | Keys |
|---|---|---|---|---|
| PK-Privileged | Tier-0/1 admin accounts, break-glass | Device-bound | On | Allow: approved FIDO2 models |
| PK-Workforce | All employees | Both | Off | Open, or block-list unapproved providers |
| PK-Frontline | Shared-device workers | Device-bound | On | Allow: issued security keys |
| PK-External | Contractors in tenant | Both | Off | Open |
Verify against the current Microsoft documentation and vendor metadata before building an allow list.
| Authenticator | AAGUID |
|---|---|
| Microsoft Authenticator (iOS) | 90a3ccdf-635c-4729-a248-9b709135078f |
| Microsoft Authenticator (Android) | de1e552d-db1d-4423-a619-566b625cdc84 |
| Windows Hello | 08987058-cadc-4b81-b6e1-30de50dcbe969ddd1817-af5a-4672-a2b9-3e3dd95000a96028b017-b1d4-4c02-b4b3-afcdafc96bb2 |
A time-limited passcode that satisfies strong authentication so a user can register passwordless credentials without ever knowing a password. Enable it for all users who will onboard passwordless, prefer one-time use, and keep lifetimes short (hours, not days).
# Scopes: UserAuthenticationMethod.ReadWrite.All Connect-MgGraph -Scopes "UserAuthenticationMethod.ReadWrite.All" New-MgUserAuthenticationTemporaryAccessPassMethod ` -UserId "new.hire@contoso.com" ` -BodyParameter @{ lifetimeInMinutes = 480; isUsableOnce = $true }
Set the campaign to target passkey-enabled users and prompt for a passkey (Microsoft Authenticator is the alternative target). The 1 Sep 2026 change enabled a Microsoft-managed campaign with unlimited snoozes for SMS/voice users; set your own snooze limit once communications have gone out.
Only if you need time to stand up a customer-managed telecom provider. The opt-out is valid until 1 Feb 2027 and does not move the retirement dates.
PATCH https://graph.microsoft.com/beta/policies/authenticationmethodspolicy Content-Type: application/json { "optOutSettings": { "passkeyDynamicMigration": true } }
Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber $domain = $env:USERDNSDOMAIN $cloudUpn = "hybrid.admin@contoso.com" # Hybrid Identity Administrator $domainCred = Get-Credential # Domain Admin in $domain Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $cloudUpn -DomainCredential $domainCred Get-AzureADKerberosServer -Domain $domain -UserPrincipalName $cloudUpn -DomainCredential $domainCred
Rotate the AzureADKerberos key periodically (Set-AzureADKerberosServer -RotateServerKey) as you would krbtgt, and include the object in your AD tiering model: it is Tier 0.
Registered passkeys only improve security once Conditional Access requires them. Use authentication strengths as the grant control rather than “Require MFA”.
| Built-in strength | Includes | Use for |
|---|---|---|
| Multifactor authentication | Any MFA combination, including SMS and voice | Legacy baseline only |
| Passwordless MFA | Phishing-resistant methods + Authenticator phone sign-in | Transitional workforce policy |
| Phishing-resistant MFA | WHfB / platform credential, passkeys (FIDO2), CBA multifactor | Target state; mandatory for admins |
Create a custom strength when you need to require a specific authenticator, for example “passkey with AAGUID in the approved security key list” for Tier-0 roles.
| ID | Policy | Assignment | Grant |
|---|---|---|---|
CA-PWL-01 | Admins require phishing-resistant MFA | All directory roles · all resources | Custom strength: attested device-bound passkey |
CA-PWL-02 | Protect security info registration | All users · user action: register security information | Compliant device or TAP-inclusive strength |
CA-PWL-03 | Workforce phishing-resistant (pilot, then all) | Pilot group, then all users · all resources | Phishing-resistant MFA |
CA-PWL-04 | Sensitive apps require device-bound credential | Tier-1 apps (finance, HR, source control) | Custom strength excluding synced passkeys |
CA-PWL-05 | Block legacy authentication | All users · legacy clients | Block |
Keep two cloud-only emergency access accounts excluded from the CA-PWL policies, each with its own FIDO2 security keys stored in separate secure locations. Alert on every sign-in to them.
Pick the user population to see the recommended primary, roaming and fallback credentials, and the design notes that matter for that group.
Six phases, each gated on the previous one. Tick items as you complete them; progress is saved in this browser only.
Most user friction happens on day one and when a device is lost. Design both processes before the pilot.
| Scenario | Self-service path | Assisted path |
|---|---|---|
| New laptop, phone still available | Sign in with Authenticator passkey via QR/Bluetooth, provision WHfB | Not needed |
| Phone lost, laptop available | Sign in with WHfB, register new Authenticator passkey, delete old one | Not needed |
| All credentials lost | Entra account recovery: government ID + selfie liveness check via verification partner, then register new credentials | Helpdesk verifies identity and issues TAP |
| Security key lost (admin) | Use second registered key | Revoke lost key; issue replacement via PAM-controlled process |
The helpdesk issuing a TAP becomes the new phishing target. Require verified identity (video call with ID, manager approval or Verified ID presentation) before any TAP is issued, and log every issuance.
Entra ID does not let you delete a user’s password outright, and hybrid identities still carry an AD password. In practice, you take the password out of daily use and stop disclosing it to users.
Apps that only speak LDAP bind, NTLM or basic auth will keep passwords alive. Front them with Entra application proxy / private access with pre-authentication, or modernize them to SAML/OIDC.
| KPI | Source | Target |
|---|---|---|
| Users passwordless-capable | User registration details (isPasswordlessCapable) | ≥ 95% of in-scope users |
| Users with ≥ 2 phishing-resistant methods | User registration details (methodsRegistered) | ≥ 90% |
| Sign-ins using phishing-resistant auth | Sign-in logs, authentication details | ≥ 90% interactive sign-ins |
| Users with SMS/voice as only MFA | SMS/voice usage analyzer | 0 before 1 Feb 2027 |
| TAPs issued per week | Audit logs | Trending down after onboarding |
Connect-MgGraph -Scopes "AuditLog.Read.All" $r = Get-MgReportAuthenticationMethodUserRegistrationDetail -All $r | Group-Object IsPasswordlessCapable | Select-Object Name, Count $r | Where-Object { $_.MethodsRegistered -contains "mobilePhone" -and $_.MethodsRegistered.Count -eq 1 } | Select-Object UserPrincipalName # SMS-only users
SigninLogs | where TimeGenerated > ago(30d) and ResultType == 0 | mv-expand d = parse_json(AuthenticationDetails) | where tobool(d.succeeded) == true | summarize SignIns = dcount(CorrelationId) by Method = tostring(d.authenticationMethod) | order by SignIns desc
| Symptom | Likely cause | Check / fix |
|---|---|---|
| Passkey registration blocked: “authenticator not allowed” | Attestation enforced or AAGUID not in allow list for the user’s profile | Confirm profile membership and AAGUID; synced passkeys can’t satisfy attestation |
| Authenticator passkey QR flow hangs on PC | Bluetooth off or blocked on the PC | Enable Bluetooth; hybrid transport needs proximity |
| WHfB works but on-prem file shares prompt | No on-prem TGT from Cloud Kerberos Trust | Run dsregcmd /status and check OnPremTgt : YES; klist cloud_debug; confirm AzureADKerberos object and DC patching |
| Domain Admin can’t get on-prem SSO with WHfB | Privileged groups denied by AzureADKerberos replication policy | By design; use a separate admin account and PAW |
| User still asked for password | No phishing-resistant method registered, or app forces password (legacy/federated) | Check authentication methods on the user; review sign-in log authentication details |
| CA blocks user “does not meet authentication strength” | Registered method not included in the required strength | Sign-in log › Conditional Access tab shows the strength evaluated; register an included method |
| Entra passkey on Windows not offered | Windows Hello AAGUIDs on a block list, or attestation enforced in the user’s passkey profile | Review the user’s profile; Entra passkeys on Windows can’t satisfy attestation |
REM Look for AzureAdPrt : YES, CloudTgt : YES, OnPremTgt : YES dsregcmd /status REM Cloud Kerberos Trust state klist cloud_debug REM Reset WHfB for the signed-in user, then re-provision certutil -deletehellocontainer
They are phishing-resistant, so they stop credential phishing, the most common attack against sign-in. The residual risk moves to the security of the user’s Apple, Google or password-manager account. Allow them for general workforce access and require device-bound credentials for privileged roles and your most sensitive apps via custom authentication strengths.
Yes, on managed Windows. WHfB signs the user in to Windows and issues the Primary Refresh Token, giving SSO to everything after. Entra passkeys on Windows are for unmanaged and shared PCs and cannot sign in to the device.
Until their SMS/voice retirement date, they can keep snoozing (unless you set a limit). After 1 Feb 2027 (1 Jul 2027 for Global Admins and external users), a user whose only method is Microsoft-provided SMS/voice must register a passkey to finish signing in.
Yes, via a customer-managed telecom provider from the Microsoft Security Store (from 30 Oct 2026). You contract and pay the carrier. Treat it as a time-limited exception with a documented end date.
Guests authenticate in their home tenant. Configure cross-tenant access settings to trust MFA (and device compliance) from partner tenants you trust, and require an authentication strength for guests on sensitive resources.
Device-bound, hardware-backed authenticators: PIV/CAC via CBA, FIDO2 security keys (FIPS-validated where required) and platform authenticators such as WHfB. Synced passkeys are generally positioned at AAL2. Confirm against your agency or regulator’s current guidance.
Entra changes monthly. Re-verify dates and limits against these pages at each review.