- Enabling passkeys makes them available. Conditional Access with a phishing-resistant authentication strength is what makes them required.
- Use passkey profiles to give each group the right options: attested, device-bound authenticators for administrators, synced passkeys for the wider workforce only if your risk assessment allows it.
- Treat passkey registration as a sensitive event. Require a strong sign-in or a short-lived Temporary Access Pass, and alert the user to every new passkey.
- Register two authenticators per user and test recovery before you remove password fallback.
This guide assumes you know what passkeys are and why they resist phishing. If not, start with our guide to passkeys and passwordless sign-in.
Choose the right Microsoft option
Microsoft offers four passwordless options, and they are easy to confuse:
- Windows Hello for Business is the sign-in credential for Microsoft Entra joined or registered PCs, backed by the TPM. It remains Microsoft's recommended option for signing in to corporate managed Windows devices.
- Microsoft Entra passkeys on Windows are device-bound FIDO2 passkeys stored in the local Windows Hello container. They work on devices that are not Entra joined or registered, are not synced, and need a separate registration on each device. They do not sign the user in to Windows itself.
- Passkeys in Microsoft Authenticator are device-bound passkeys held in the app on the user's phone. A new phone means registering a new passkey.
- FIDO2 security keys are roaming, device-bound authenticators connected over USB or NFC.
Map the gaps before you start
Applications that federate to Entra ID through SAML or OIDC inherit passkey sign-in without changes. Applications that authenticate through RADIUS, NTLM, Kerberos with passwords, or their own login forms need upgrading, migrating, or fronting with a proxy.
Single sign-on rarely covers everything. Check for local accounts on servers and network devices, break-glass and service accounts excluded from policy, legacy authentication endpoints that still accept passwords, and applications with their own user database. Each one is a way around your passkey policy until it is closed or explicitly accepted as a risk.
Device management has limits too. You control company-managed devices, but a synced passkey in a user's personal iCloud or Google account sits outside your control.
Decide passkey types per user group
One policy rarely fits the whole organisation. A starting point:
| User group | Suggested authenticator | Notes |
|---|---|---|
| Global and privileged administrators | Attested FIDO2 security keys, two per person | No synced passkeys; tie to PIM role activation |
| Finance, HR and other high-risk roles | Device-bound: security key, Windows Hello for Business or Authenticator | Restrict to approved authenticator models where possible |
| General workforce | Windows Hello for Business on managed PCs, plus a phone passkey | Synced passkeys acceptable if your risk assessment allows |
| Shared workstations and frontline staff | Personal security keys, or Windows Hello for Business on shared devices | Never share a passkey between people |
| Contractors and guests | Their own organisation's phishing-resistant MFA through cross-tenant trust, or a security key you issue | Revoke on contract end |
Passkey profiles, available in Entra ID since March 2026, put this table into practice: each profile sets whether a group may register device-bound passkeys, synced passkeys or both. Attestation lets Entra ID confirm the make and model of the authenticator at registration. Synced passkeys do not provide attestation, so enforcing it rules them out. Enforce it for privileged and high-risk users.
Secure enrolment
Whoever registers a passkey gains a lasting way in. Require a recent strong sign-in or a Temporary Access Pass (TAP) before registration, log every new registration, notify the user by a separate channel when one is added, and give users and the service desk a quick way to see and revoke registered passkeys. Keep a TAP's lifetime short, prefer one-time use, and verify identity before issuing one.
Passkeys belong to a person. On shared workstations, give each user a security key or use Windows Hello for Business on shared devices. A TAP can bridge enrolment for shift workers without reintroducing permanent passwords.
Enforce with Conditional Access
Enabling passkeys in the Authentication methods policy does not stop users signing in with weaker methods. Enforcement comes from Conditional Access with an authentication strength. The built-in "Phishing-resistant MFA" strength accepts passkeys (FIDO2), Windows Hello for Business and certificate-based authentication. A custom strength can narrow that further, for example to specific security key models identified by their AAGUID.
Start with administrator portals, email and finance applications, then expand. For roles managed through Privileged Identity Management, require phishing-resistant authentication at role activation, so a stolen session for the user's standard account cannot be used to escalate.
Licensing
Registering and using passkeys does not need a premium licence. Conditional Access and authentication strengths need Microsoft Entra ID P1. Risk-based policies, such as requiring phishing-resistant MFA when sign-in risk is high, need P2 through Microsoft Entra ID Protection.
Plan recovery and the lifecycle
NIST expects recovery to be as strong as the authenticator it replaces. An emailed reset link fails that test. Plan each scenario before you remove passwords:
| Scenario | Response |
|---|---|
| Lost device-bound authenticator | User signs in with their second registered authenticator; the lost one is revoked. With no backup, identity-verified re-enrolment through the service desk. |
| Lost phone with synced passkeys | Passkeys remain on the user's other devices; the user secures the provider account and removes the lost phone from it. |
| Suspected compromised authenticator or sync account | Revoke the passkey in Entra ID, revoke sessions and refresh tokens, review recent sign-ins and registrations. |
| Helpdesk reset | Verify identity by a method an attacker cannot easily fake (video call with ID, manager confirmation), then issue a short-lived Temporary Access Pass. |
| Privileged account recovery | Two-person approval, identity check in person or by video, and a review of the account's activity afterwards. |
| Leaver | Disable the account and remove its passkeys in Entra ID. A synced copy left on a personal device becomes useless once the credential is deleted on the server. |
Most passkey projects meet their first real problem when a user loses their only registered device. Register two authenticators at enrolment, for example Windows Hello for Business and a phone passkey, or two security keys for administrators, and brief the service desk before you disable password fallback for any group.
Pilot and measure
Pilot with a group that represents your real users, not only IT staff: different roles, device types, locations and accessibility needs. Twenty people for four weeks is a reasonable example, not a rule. Test enrolment, daily sign-in, cross-device sign-in and a simulated lost device, including a user with no backup authenticator. Then track these measures as you scale:
| Measure | What it tells you |
|---|---|
| Users with at least two registered phishing-resistant authenticators | Coverage and recovery resilience |
| Sign-ins completed with a phishing-resistant method | Real use, not just registration |
| Sign-ins still using passwords, SMS or push, by application | Remaining fallback paths to close |
| Service desk tickets and time to recover a user who lost their authenticator | User friction and whether recovery works in practice |
Five steps to start this quarter
- Map your authentication paths: list which applications federate to Entra ID and which still accept passwords through legacy protocols, local accounts or excluded accounts.
- Set up passkey profiles: attested, device-bound authenticators for administrators, and a decision on synced passkeys for everyone else.
- Secure enrolment and recovery: require strong authentication or a TAP to register, alert users to new passkeys, and test each recovery scenario.
- Run a representative pilot: two authenticators per user, with cross-device sign-in and a lost device tested.
- Enforce by risk tier: require the phishing-resistant authentication strength for high-risk applications first, then set a dated plan to phase out password sign-in, group by group.
Ryland has delivered cybersecurity, compliance, and IT management programmes for regulated organisations across the UK and the Netherlands for over 20 years. View full profile