Microsoft SC-500: Passkeys in Microsoft Entra ID
Passkeys in Microsoft Entra ID provide phishing-resistant authentication based on FIDO2. Instead of sending a reusable password to a server, the user authenticates with a cryptographic credential protected by the device or authenticator. Microsoft Entra currently supports both device-bound passkeys and synced passkeys, which makes passkey deployment a choice about assurance, portability, device support, and user experience rather than one single authentication method.
Microsoft’s current Entra guidance now uses passkey profiles. Administrators can define the allowed passkey type, attestation and key restrictions, target different user groups, optionally allow synced passkeys, and enforce passkey use through Conditional Access authentication strengths. Up to three passkey profiles, including the Default profile, are currently supported.
Passkeys are therefore a practical authentication control inside Microsoft Identity & Security.
Understand device-bound and synced passkeys
Device-bound passkeys remain tied to a specific authenticator such as a FIDO2 security key or Microsoft Authenticator on a device.
Synced passkeys can move between supported devices through the user’s passkey provider.
Authentication strength should reflect whether the business needs maximum device binding or the usability benefits of synchronized credentials.
Use passkey profiles for targeted policy
Passkey profiles let administrators define who can use which passkey types and, where needed, which authenticator models or providers are acceptable.
Use different profiles only when groups have meaningfully different assurance requirements.
A large number of tiny policy differences makes help-desk support and authentication troubleshooting harder.
Allow self-service registration deliberately
Microsoft Entra can allow users to register passkeys through Security info when self-service setup is enabled.
Registration should be accompanied by identity-verification, device-readiness, and recovery guidance.
MFA deployment succeeds when users know how to enroll before the stronger requirement blocks an important application.
Use authentication strengths to require passkeys
Conditional Access can require the built-in phishing-resistant authentication strength or a custom strength that includes only passkeys allowed by policy.
This is useful for privileged roles, high-value applications, or administrative workflows where ordinary MFA does not provide enough phishing resistance.
Conditional Access should still determine when the requirement applies based on user, application, device, risk, and other context.
Plan for passkey recovery
Passwordless authentication does not eliminate the need for recovery. Users lose devices, security keys fail, phones are replaced, and synced providers can become unavailable.
Maintain an approved recovery path that is strong enough not to become the permanent weaker alternative attackers target.
Privileged users may need backup security keys or another phishing-resistant method stored separately.
Use attestation and key restrictions only when justified
Passkey profiles can use attestation and authenticator restrictions for organizations that need tighter control over specific hardware or providers.
Those controls can increase assurance but also narrow device compatibility and complicate replacement.
Document the security requirement that justifies the restriction rather than limiting authenticators simply because the option exists.
Roll out by risk tier
Start with privileged administrators and sensitive applications, then expand to broader users as device and support readiness improves.
Identity control is stronger when the highest-consequence accounts receive phishing-resistant authentication first.
Use pilot groups to verify platform support, registration, user education, and recovery before tenant-wide enforcement.
Monitor registration and sign-in behavior
Authentication-method reporting and sign-in logs can show whether users are registering and successfully using passkeys.
Repeated fallback to weaker methods can reveal gaps in device readiness or policy design.
Security teams should also monitor unexpected registration changes for privileged accounts.
Treat passkeys as part of the identity lifecycle
Onboarding, device replacement, role change, guest access, and offboarding all affect passkey management.
For current Entra architecture, the durable model is to choose the right passkey type, target it with profiles, enforce it through Conditional Access where consequence demands it, and keep registration and recovery operational enough that phishing-resistant authentication becomes normal rather than exceptional.
Passkey rollout should begin with device and authenticator inventory. Windows Hello for Business, FIDO2 security keys, Microsoft Authenticator, mobile operating systems, browser support, and synced passkey providers can create different user experiences. The authentication-method policy should reflect what the organization can actually support rather than what works on one administrator’s laptop.
Synced passkeys improve portability, but that portability changes the threat model. The credential can move through a provider ecosystem instead of remaining on one physical authenticator. High-assurance populations may prefer device-bound credentials, while broader employee use may benefit from the recovery and usability of synchronized passkeys.
Passkey profiles can restrict authenticators through attestation or AAGUID controls. These settings are useful for regulated or hardware-standardized environments, but they create vendor and logistics dependencies. Security teams should know how replacements, procurement, and emergency access work before enforcing a very narrow authenticator list.
User enrollment should be measured separately from enforcement. A tenant may enable passkeys without most users registering them. Track enrollment progress and set deadlines before Conditional Access starts requiring passkey authentication for critical apps.
Authentication-strength policy can create a staged path. Administrators and developers accessing sensitive control planes can be required to use phishing-resistant methods first, while other users remain on broader MFA. This creates immediate risk reduction where account compromise would have the largest blast radius.
Passkeys also change help-desk workflows. Support staff need to know how to remove a lost passkey, verify identity before registering a replacement, distinguish synced and device-bound credentials, and avoid falling back to weak temporary methods that attackers can abuse.
Privileged users should have recovery methods that do not depend on the same phone, account, or physical location as their primary passkey. A second FIDO2 key or certificate stored securely can provide resilience without weakening the normal phishing-resistant requirement.
Review Conditional Access after passkey deployment. A policy that still permits weaker methods for the same privileged application can undermine the investment if users and attackers can simply choose the easier alternative. Authentication strength should express the intended assurance, not merely enable a new option.
The long-term objective is not “replace passwords everywhere” as a slogan. It is to reduce phishing and credential-reuse risk while keeping authentication recoverable, supportable, and aligned with the consequence of the resource being accessed.
Passkey adoption should be coordinated with Temporary Access Pass or another approved bootstrap method where required. New hires and device-replacement scenarios need a secure path to register a passkey before the stronger authentication method becomes available. The bootstrap method should be short-lived and tightly controlled.
Device-bound passkeys can be especially appropriate for privileged administrators and regulated environments because the credential is not synchronized across devices. The tradeoff is more physical logistics and the need for spare authenticators or carefully designed recovery.
Synced passkeys can improve employee adoption by letting users move between devices without enrolling a separate key on each one. Security teams should review the provider trust model, device-management policy, and account-recovery implications before enabling them broadly.
Passkey sign-in should be tested against browser, mobile, Windows, remote-access, and legacy-application scenarios. A tenant can successfully enforce passkeys for modern web applications while one older application still falls back to password-based authentication through another protocol.
Telemetry should distinguish registration failure from authentication failure. Enrollment problems often indicate device or policy readiness, while sign-in failures can indicate Conditional Access, authenticator restrictions, or application compatibility. Support teams need different runbooks for each.
As passkeys become more common, administrators should periodically review older MFA methods that remain enabled. Leaving weaker methods broadly available can preserve phishing paths even after a successful passkey rollout.
Passkey policy should be documented in plain language for users and support teams: which passkey types are allowed, where registration happens, which applications require them, and how recovery works. Clear policy reduces the chance that users interpret a phishing-resistant requirement as an unexpected outage.
Administrator roles should have a stricter rollout path. Require passkeys or another phishing-resistant strength for privileged portals, validate spare authenticator availability, and verify that emergency accounts remain independent of the same policy path.
Guest and external-user scenarios should be tested separately because authentication method availability and cross-tenant behavior can differ from internal employees. Sensitive B2B applications may need explicit Conditional Access rules rather than assuming the partner’s home-tenant method satisfies the intended assurance.
Passkey profiles should be reviewed when Microsoft adds new provider or device capabilities. The policy is a living authentication standard, not a one-time migration project.
Review the enabled passkey profiles whenever authenticator policy, device standards, or privileged-access requirements change so the allowed passkey types still match the organization’s assurance model.
Keep passkey recovery and help-desk procedures tested with real devices before broad enforcement.
Review enrollment metrics regularly and remove weaker fallback methods when they are no longer required.