How to Use Passkeys With a Microsoft Account (Entra ID)

Microsoft has turned passwordless sign-in from a security-conference talking point into a configurable admin setting. Anyone searching for how to use passkeys with a Microsoft account is usually dealing with one of two different systems: a personal account for Outlook.com, Xbox, or consumer OneDrive, or a work or school account tied to Microsoft Entra ID. This guide covers the Entra ID side, because that's where Microsoft's own documentation spells out exactly how passkeys work, what changes when they're switched on, and how to roll them out. Personal Microsoft accounts follow separate setup steps that Entra documentation doesn't address, so check Microsoft's consumer account-security settings directly if that's the account in question.

For IT teams managing Entra ID, passkeys, built on the FIDO2 standard, are available today at no extra cost in every edition, including Microsoft Entra ID Free, according to Microsoft's Entra ID documentation. That means passwordless sign-in for a Microsoft work or school account through Microsoft Authenticator, a FIDO2 security key, or a third-party passkey provider, with no licensing upgrade required.

In plain terms, a passkey swaps a typed password for a cryptographic key pair. Under a properly configured setup, the verifier, in this case Entra ID, stores only the public key; the private half either stays on the device, for a device-bound passkey, or gets copied in encrypted form through a sync provider, for a synced one, per NIST's supplement to its digital identity guidelines. That split is what makes passkeys resistant to fake-login-page tricks, and to replay attacks, where a stolen credential gets reused later. The protocol blocks replay by attaching a random, one-time value to every authentication attempt, the same NIST supplement notes.

The push toward passkeys carries real numbers, though they're worth dating rather than treating as current. In an April 2024 estimate cited by NIST, more than 8 billion online accounts already had the option to sign in with a passkey, a figure describing eligibility, not actual usage. FIDO Alliance reported in 2024 that passwords remain the root cause of more than 80% of data breaches, FIDO Alliance found.

Setting up a passkey for a Microsoft Entra ID account

Passkeys are FIDO2-based credentials designed to resist phishing, Microsoft's documentation notes. A password works like a key that fits any matching lock; copy it, and anyone can use it. A passkey behaves more like a lock that only opens for one specific key that never leaves your pocket. The lock checks the key's signature, never the key itself.

Setting up a passkey for a Microsoft Entra ID account doesn't require buying dedicated hardware. Users can register through a FIDO2 security key, through Microsoft Authenticator, or through a native or third-party passkey provider, per Microsoft's documentation. Entra ID currently recognizes two types: device-bound passkeys stored on a FIDO2 security key or in Microsoft Authenticator, and synced passkeys stored through a cloud passkey provider.

On speed, FIDO Alliance's deployment guidance reports passkey sign-in as up to four times faster than waiting for a text-message code, since there's no code to deliver, FIDO Alliance says. That's a vendor-reported figure, worth treating as guidance rather than an independently verified benchmark for Entra ID specifically.

NIST's supplement to its federal identity guidelines lays out conditions under which syncable authenticators, the technical term for what most people call synced passkeys, can align with Authentication Assurance Level 2 (AAL2) requirements. It's interim guidance, issued to bridge a gap until a full revision of the underlying standard is finalized, and the conditions attached to it matter more than they sound. The next section explains why.

What enabling passkeys changes inside Entra ID

Turning passkeys on isn't a single tenant-wide switch. Admins configure them through named "passkey profiles," policy rules assigned to specific user groups that define attestation requirements, passkey type, and key restrictions, per Microsoft's documentation.

There's a built-in guardrail on registration, too: Microsoft requires users to complete multifactor authentication within the previous five minutes before they can register a new passkey. That short window works, in effect, as a check against someone hijacking an already-open session to plant their own credential.

Creating a profile and requiring people to use it are two separate steps. Assigning a passkey profile to a group makes passkey sign-in available to that group; it doesn't make it mandatory. Requiring passkeys happens through a distinct Conditional Access authentication-strength policy, which is optional and, as the rollout section below covers, should come later.

Device-bound vs. synced passkeys: the decision that shapes everything else

This is the configuration choice everything else in a rollout depends on. A device-bound passkey is created and stored on one physical device and never leaves it, whether that's a FIDO2 security key or a specific phone's Microsoft Authenticator app. A synced passkey has its private key generated by a hardware security module, encrypted on the local device, then copied to a cloud provider such as Apple iCloud Keychain or Google Password Manager, Microsoft explains.

Recovery is where the two diverge. A synced passkey can survive a lost or wiped device: restoring it through the cloud provider on a new device is what FIDO Alliance says can reduce the need for a separate account-recovery event, though exactly how that plays out depends on the provider. A device-bound passkey doesn't come with that same safety net. If it disappears with the device and no other registered method exists, an organization has to build its own recovery path rather than count on Entra ID to supply one automatically.

The operational consequence follows directly: synced passkeys cannot be attested, by design, per Microsoft's documentation. Device-bound passkeys can be, but only if an admin turns on attestation enforcement, the setting that lets Entra ID check an authenticator's make and model against trusted metadata and confirm it's genuine and from the stated vendor. Turn attestation off, and Entra ID can't guarantee any attribute about a passkey, including whether it's synced or device-bound, Microsoft's documentation states. In that state, any list of allowed AAGUIDs, 128-bit identifiers indicating a key's type, such as make and model, functions only as a policy guide rather than an enforceable control.

That framing points toward a risk-based choice rather than a universal rule. Where hardware provenance genuinely matters, sensitive admin roles, regulated data access, turning on attestation and restricting registration to specific AAGUIDs is the option that delivers certainty, at the cost of added registration friction and, by definition, excluding synced passkeys entirely. Where reducing lockouts and easing cross-device use matters more than that certainty, synced passkeys remain the practical choice, provided the conditions below are actually met.

NIST's guidance on this point is narrower than it can sound. Aimed at federal agencies deciding whether to accept syncable authenticators, it sets out the conditions under which those credentials can align with AAL2: keys encrypted at rest, access restricted to the authenticated user, and the sync account itself protected by AAL2-equivalent multifactor authentication, per NIST's supplement. That's federal guidance about syncable authenticators in general, not a certification of any specific Entra ID setup or cloud provider. Whether a given synced-passkey deployment meets it depends entirely on how the provider and the organization configure things.

One more consequence is easy to overlook: turning synced passkeys off inside a profile immediately blocks users from signing in with a synced passkey they already registered, even though the credential still technically exists, per Microsoft's documentation.

How to enable passkeys in the Microsoft Entra admin center

Before touching any settings, confirm the account doing the work holds at least Authentication Policy Administrator permissions, per Microsoft's documentation; that same permission level is specifically called out for enabling synced passkeys within a profile. Check device readiness too: Entra-joined Windows devices need Windows 10 version 1903 or higher, hybrid-joined devices need version 2004 or higher, and if a profile targets Microsoft Authenticator for either passkey type, users need Authenticator iOS 6.8.37 or Android 6.2507.4749 or later, all per Microsoft's documentation.

Microsoft's own documentation lays out five steps for enabling passkeys, in order:

1. Enable passkey profiles. Opt in to passkey profiles in the Microsoft Entra admin center. Existing global settings transfer automatically to a Default passkey profile.
2. Create a passkey profile. Name it, and within the same profile, define attestation enforcement, passkey type (device-bound or synced), and any key restrictions such as an AAGUID list.
3. Apply the profile to a targeted group. Assign it to a pilot group rather than the whole tenant.
4. Enable synced passkeys (optional). Select Synced as an allowed passkey type within the profile.
5. Enforce passkey sign-in (optional). Build a Conditional Access authentication-strength policy that requires passkeys for specific sensitive resources.

Steps two through four all live on the same profile screen. Step five sits in an entirely different part of the admin center, Conditional Access, and shouldn't be touched until pilot testing has actually held up.

Test recovery on purpose, not by accident. FIDO Alliance's deployment guidance specifically flags recovery as the weakest point in most authentication systems, the path attackers exploit most often, so it recommends simulating a lost device during the pilot rather than waiting to find out what happens when one actually goes missing.

FIDO Alliance's guidance also stresses monitoring implementation and adoption metrics, not just whether the feature is switched on. Translated into something trackable: enrollment completion rate, successful passkey sign-ins against fallback-to-password events, help-desk tickets tied to setup, and how the simulated recoveries actually went. If fallback stays high or a recovery test fails, that's the organization's own signal that the profile isn't ready for step five.

Once the pilot holds up, enforce narrowly. Require passkeys for the specific sensitive resources the policy targets through a Conditional Access authentication-strength policy, per Microsoft's documentation, rather than treating it as a tenant-wide cutover.

Four current limitations shape how fast that timeline can move:

• A tenant supports a maximum of three passkey profiles today, including the Default profile, with support for more listed as in development, per Microsoft Learn.
• Passkey registration isn't supported for internal or external guest users, including B2B collaboration accounts, per Microsoft Learn.
• If a user's sign-in name (UPN) changes, admins lose the ability to modify that user's existing passkeys, per Microsoft Learn.
• Administrator-driven security-key provisioning through Microsoft Graph remains in preview, not general availability, per Microsoft Learn.

Where this leaves a rollout

A rollout comes down to a short sequence of decisions, and the order matters:

• Pilot first. Build a passkey profile scoped to a small group before anything touches Conditional Access.
• Turn on attestation enforcement only where hardware provenance genuinely matters, since it's unavailable for synced passkeys regardless of policy.
• Allow synced passkeys where recovery and cross-device convenience outweigh that hardware assurance, and only once the sync provider's encryption and access controls actually meet the conditions described above.
• Hold off on Conditional Access enforcement until a simulated device-loss recovery has succeeded under the pilot, not just registration and everyday sign-in.

Pilot the profile with a small group, test a lost-device scenario deliberately, and enforce it only after users can register, sign in, and recover without leaning on an untested fallback.