Why passkeys deserve more than an Enabled toggle

A passkey is a phishing-resistant FIDO2 credential. The private key remains in the authenticator while Microsoft Entra ID stores the public key. The browser binds authentication to the service's legitimate domain, so a fake sign-in page cannot obtain a response that works for the real domain.

That protection does not eliminate deployment mistakes. If Conditional Access immediately requires a phishing-resistant method from users who do not have one, they can be locked out. The safe sequence is to prepare recovery, allow registration, pilot profiles, measure adoption and only then enforce authentication strength in stages.

Understand the options before creating groups

Microsoft Entra ID supports synced and device-bound passkeys. Passkeys are available in every Entra ID edition, including Free, with no extra licence. Conditional Access, used later to require an authentication strength, requires Entra ID P1; Microsoft 365 Business Premium also includes this capability.

For administrators and highly privileged accounts, favour an attested device-bound credential, ideally two keys or a key plus another phishing-resistant method. For general users, a synced passkey can reduce support demand if the organization accepts the provider's recovery model.

Type	Examples	Benefit	Watch for
Device-bound	Microsoft Authenticator, FIDO2 key	Private key is not synced; control and attestation are possible	Plan a second method and device replacement
Synced	iCloud Keychain, Google Password Manager	Simple multi-device experience	No attestation; govern the passkey provider
Platform	Windows Hello for Business, Entra passkey on Windows	Fast on the managed workstation	Local registration on each device

1 — Prepare groups, roles and emergency accounts

Create at least a pilot group, a rollout group and a controlled temporary exclusion group. The pilot must represent Windows, macOS, iOS, Android, personal and managed devices, plus the applications people actually use. Do not limit testing to IT.

Use Authentication Policy Administrator to configure methods and Conditional Access Administrator for authentication strengths and access policies. Exclude emergency access accounts from enforcement, monitor their use and protect them with a separate strong method. An emergency exclusion is not a general troubleshooting group.

Document each group's owner and the expiry date of exclusions.
Validate browsers, mobile versions and Bluetooth restrictions across the fleet.
Plan for a lost phone, replacement device and employees without a corporate phone.
Train the service desk before the first registration campaign.

2 — Enable Temporary Access Pass before passkeys

Temporary Access Pass, or TAP, is a time-limited one-time or reusable code that bootstraps a passwordless method. Enable it in Entra ID > Authentication methods > Policies > Temporary Access Pass and initially target onboarding and support teams. An administrator can then create a TAP under Users > Authentication methods.

For onboarding and recovery, prefer a short-lived one-time TAP delivered after identity verification through an approved channel. The code is displayed only once. Each user can have only one valid TAP; creating another replaces the existing one. A TAP does not remove the account password.

Never send the TAP and username in the same unprotected message.
Revoke the TAP after registration when it is no longer required.
Remove the lost passkey from the user's authentication methods.
For an enrolment flow longer than ten minutes, test one-time TAP behaviour and issue a second TAP if needed.

Create a one-time TAP with Microsoft Graph PowerShell

Connect-MgGraph -Scopes 'UserAuthenticationMethod.ReadWrite.All'

$body = @{
  isUsableOnce = $true
  lifetimeInMinutes = 60
}

New-MgUserAuthenticationTemporaryAccessPassMethod `
  -UserId 'user@contoso.com' `
  -BodyParameter $body

3 — Create passkey profiles for each security persona

In Entra ID > Security > Authentication methods > Policies > Passkey (FIDO2), opt in to passkey profiles. This transfers the existing global configuration to a Default profile and cannot be reversed. Microsoft currently supports up to three profiles, including the default profile.

Enable Allow self-service set up so users can register through Security info. Then create profiles by useful posture rather than department: for example, Administrators — attested device-bound; Users — device-bound and synced; Authenticator pilot — device-bound with the Microsoft Authenticator AAGUID allowed.

Attestation verifies at registration that the authenticator comes from the stated provider. It does not retroactively make existing credentials compliant: enabling attestation later does not automatically block their use. Conversely, changing an AAGUID allow list can immediately make previously allowed models unusable. Test every change against already registered methods.

Suggested profile	Target	Type	Attestation
PRV-Admins	Privileged roles	Device-bound	Yes
PRV-Pilot-Authenticator	Mobile pilot	Device-bound	Yes, Authenticator AAGUID allowed
PRV-General	General users	Device-bound and synced	Based on risk assessment

4 — Test Microsoft Authenticator and cross-device flows

Device-bound passkeys in Microsoft Authenticator currently require Android 14 or iOS 17 and a supported app version. For QR-based cross-device flows, Bluetooth and an active Internet connection must be enabled on both devices. Firewalls must also permit the caBLE endpoints documented by Microsoft and the platform vendors.

Attestation and cross-device registration are not always compatible: Microsoft states that cross-device registration does not work when attestation is required. Test direct registration inside Authenticator with a TAP for the attested profile. Also verify shared devices, phones without biometric locking, MDM restrictions and users without a phone.

Same-device mobile registration with a TAP.
Web sign-in on a workstation approved from the phone.
Phone replacement and deletion of the old method.
A second recovery passkey registered before the first device is lost.
Access to legacy applications that still request a password.

5 — Run a registration campaign without enforcing sign-in

A registration campaign prompts a user to create a passkey after normal sign-in and MFA. Passkey (FIDO2) must be enabled and Allow self-service set up must be Yes. In Entra ID > Authentication methods > Registration campaign, target the pilot group, choose Passkey and allow a few snoozes so registration does not interrupt a critical day.

A tenant can target only one method in its campaign at a time: passkey or Microsoft Authenticator, not both. The passkey campaign covers device-bound and synced credentials. A user can be prompted on one device but not another because Entra evaluates whether a local passkey exists for that device-browser combination.

6 — Measure adoption before enforcement

The Authentication Methods Activity dashboard shows registered users, recent registrations and usage by method. Details can take up to 36 hours to reflect most of the tenant. Supplement the dashboard with sign-in logs, support tickets and a list of people who still have no eligible method.

Passkey registration rate by group and platform.
Actual usage rate, not just registration.
Registration failures and recurring causes.
Users with two valid recovery methods.
Service desk request volume and average handling time.

Export registration details with Microsoft Graph

Connect-MgGraph -Scopes 'AuditLog.Read.All'

$uri = 'https://graph.microsoft.com/v1.0/reports/authenticationMethods/userRegistrationDetails'
$rows = @()
do {
  $page = Invoke-MgGraphRequest -Method GET -Uri $uri
  $rows += $page.value
  $uri = $page.'@odata.nextLink'
} while ($uri)

$rows | Select-Object userPrincipalName, isMfaCapable, isPasswordlessCapable, methodsRegistered |
  Export-Csv '.\entra-authentication-methods.csv' -NoTypeInformation -Encoding UTF8

7 — Enforce authentication strength through rings

After the pilot is genuinely enrolled, create a Conditional Access policy targeting a sensitive resource or authentication context, then require the built-in Phishing-resistant MFA strength. Start in Report-only, review impact and enable it only for the pilot group. The built-in strength also accepts Windows Hello for Business and multifactor certificate authentication; create a custom strength if only specific AAGUIDs or passkeys should be accepted.

Do not start with All users and All resources. Expand resource by resource or group by group after confirming registration. Users must have an eligible method before enforcement; the interrupt flow cannot always register a passwordless method automatically at the moment access is blocked.

Ring	Scope	Activation criterion
0	Test accounts and noncritical app	Registration, sign-in and recovery succeed
1	IT and pilot administrators	Two strong methods; emergency accounts validated
2	Sensitive apps and volunteer teams	Report-only shows no unexpected blocks
3	General population	Coverage target met and support ready

8 — Separate bootstrap from everyday access

A sound Conditional Access design can reserve TAP for the Register security information action. Create a custom Bootstrap and recovery strength that includes TAP and apply it to that user action. Use a separate strength that excludes TAP and requires the intended method for everyday resources. This prevents a temporary recovery code from becoming a general-purpose access pass.

Avoid conflicting policies: if multiple policies target security information registration with different strengths, the user must satisfy every requirement. Test the full journey with a new user, a noncompliant device and a user who has lost their passkey.

Recommended recovery procedure

The goal is not the immediate disappearance of every password. It is to make passkeys easy to register and recover, then progressively move important access to phishing-resistant authentication. Connect this project to your Active Directory assessment and Kerberos AES migration: hybrid identity must remain coherent through legacy applications and services.

Verify identity with a documented process that goes beyond an inbound phone call.
Revoke sessions if device loss may be connected to an incident.
Delete the lost passkey from the user's Entra authentication methods.
Issue a short-lived one-time TAP through an authorized administrator.
Immediately register a new passkey and a backup method.
Delete the TAP and record the operation in the support ticket.

Official Microsoft sources

About the author

Marc-Antoine Lambert

Montréal-based senior IT consultant and Team Lead specializing in architecture, cybersecurity, Microsoft infrastructure, networking and business continuity.

Discuss your environment →