Enterprise Passkey Deployment Challenges & Solutions

Passkeys have arrived in the workforce. The question is no longer "does the technology work?". The question is now "how do we operate this at scale?". The friction points have moved to the operational layer: the "chicken-and-egg" problem of initial enrollment (bootstrapping), the difference between device-bound and synced passkeys, cross-platform interoperability and recovery mechanisms that do not revert to the insecurity of a password.

This guide addresses the real-world challenges of deploying passkeys in Microsoft Entra ID environments, covering configuration pitfalls, operational workflows and recovery strategies. Specifically, we're going to address the following questions

1. What is the difference between device-bound and synced passkeys in Entra ID?
2. How do I bootstrap passkeys for new employees without passwords?
3. How do users recover when they get a new phone and lose access to their authenticator?
4. What configuration mistakes cause passkey enrollment failures?
5. How do I handle B2B guests when requiring phishing-resistant MFA?
6. Should I use hardware security keys (YubiKeys) or mobile passkeys?
7. How do I handle macOS devices alongside Windows in a passkey deployment?
8. What proactive measures prevent helpdesk overload from phone replacements?

In Entra, "passkeys" = FIDO2/WebAuthn credentials. Instead of a password, the user proves possession of a private key stored in an authenticator. It's phishing-resistant because WebAuthn binds the credential to the real sign-in origin (so a lookalike phishing site can't replay it). See Microsoft's overview in the Passkeys (FIDO2) concepts documentation.

Entra effectively supports two "modes" of passkeys that behave differently.

These passkeys are tied to one physical device (non-syncable). The private key exists on a specific hardware element (TPM on a laptop, Secure Element on a YubiKey). It is non-exportable.

In Entra, the device-bound story commonly translates into:

• Microsoft Authenticator passkeys
• Windows Hello or Windows Hello for Business (WHfB) passkeys (non-synced as of January 2026)
• FIDO2 security keys (hardware keys like YubiKeys)
• Smartcards

Microsoft's baseline setup guidance for device-bound passkeys can be found here: https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-enable-passkey-fido2

Use cases: High-privilege access, "break-glass" accounts, shared workstation environments. Downside: High friction. Loss of device means loss of credential. High operational cost (e.g. shipping YubiKeys).

These are passkeys stored in a provider ecosystem and synced across the user's devices (e.g. iCloud Keychain, Google Password Manager or third-party providers). The private key is encrypted and stored in a cloud provider's sync fabric.

As of January 2026, in Entra, synced passkeys are handled via the preview feature: Synced passkeys (preview). To enable and control synced passkeys, Entra uses Passkey Profiles (preview).

Regulatory fit: Recently validated by NIST SP 800-63B Supplement 1 as meeting AAL2 requirements. This is a massive regulatory win validating that synced passkeys are "phishing-resistant" enough for general workforce use.

Use cases: Knowledge workers, BYOD users, executive convenience. Downside: "Lower" assurance than hardware. Reliance on the security of the cloud provider's account recovery flow.

Here you find an overview of Entra's supported synced passkey providers:

In a user's Security Info page, synced and device-bound passkeys are clearly distinguished. Below you can see how a synced passkey (from 1Password) and a device-bound passkey (YubiKey 5C NFC) appear:

• AAL3 historically required hardware-based, device-bound authenticators (like YubiKeys or Smart Cards) that utilize a non-exportable private key.
• AAL2 can now be achieved with synced passkeys per NIST guidance.
• Nuance: While synced passkeys (like those in iCloud) are excellent for standard users, they may not strictly meet the AAL3 "non-exportability" requirement for the highest privilege levels. Therefore, a segmented strategy is required: Hardware keys for Admins (AAL3), Synced Passkeys for the workforce (AAL2).

To ensure devices are prepared for phishing-resistant passwordless authentication, they must run these minimum versions:

Older operating systems may require external authenticators (FIDO2 security keys) to support phishing-resistant passwordless authentication.

Microsoft recommends a user persona-based approach to credential deployment. Different roles have different security requirements and acceptable friction levels:

Portable credentials (can be used across devices):

Local credentials (device-specific):

The end goal: Most users should have at least one portable credential plus local credentials on each computing device.

When speaking to organizations that have deployed passkeys some real-worl friction points and patterns are recognized.

"The challenges are not in the tech stack but the operational layer." This confirms that technical hurdles like "Passkey not registered" errors or invisibility of Windows Hello options on personal devices are not unique anomalies but systemic friction points inherent to the current maturity of the ecosystem.

Enrollment is the single hardest phase of deployment, requiring significant change management.

• Pre-registration complexity: Onboarding new employees who have no prior credentials is the primary bottleneck. The reliance on admin-mediated enrollment creates a disjointed user experience.
• Platform fragmentation: "User frustration with steps" due to independent iterations of browsers, Operating Systems and password managers. This leads to temporary inconsistencies where a flow works on Chrome/Windows but fails on Safari/macOS or fails on unmanaged personal devices while succeeding on corporate ones.

"Users don't need cryptography, they need a mental model". The terminology confusion creates cognitive load:

• Passkey
• Security Key
• Hardware Key
• YubiKey
• passwordless
• Windows Security
• Windows Hello
• Windows Hello for Business (WHfB)
• Microsoft Authenticator
• Phone Sign-in

For non-tech-savvy users or even tech-savvy ones, the differences of these terms if not obvious.

We recommend to avoid jargon like "phishing-resistant" or "key-pair" in end-user communications. Instead, focus on the "unlock" concept: "Use your face to unlock the enterprise's systems," analogous to unlocking their phone.

Strong adoption at the beginning is critical to success, but communication can only go so far. You cannot send regular emails asking users to check their authentication methods. In general, you cannot plan well for user behavior. This reality drives the need for proactive technical measures rather than relying solely on user education.

Deploying passkeys in an enterprise environment requires to understand and set up interdependent policies. Passkey are just not a feature that you can simply turn on, as it has huge impact on every employee in their daily work.

The legacy MFA and SSPR portals are deprecated. All FIDO2 configuration must occur in the unified Authentication Methods Policy blade.

• FIDO2 Security Key Method: This must be enabled and targeted. Recommend targeting "All Users" for enablement but controlling enforcement via Conditional Access.
• Key Restrictions (AAGUIDs): Every FIDO2 device (e.g. YubiKey 5 NFC, Microsoft Authenticator on iOS, Google Password Manager) has a unique Authenticator Attestation GUID (AAGUID). As a best practice, for high-security environments, utilize the "Enforce Key Restrictions" setting to Allow only specific, approved AAGUIDs. This prevents users from registering cheap, unverified "grey market" security keys.

One of the most significant configuration decisions is "Enforce Attestation".

• What it does: Forces the authenticator to cryptographically prove its make and model to Entra ID during registration.
• Conflict: Synced Passkeys (stored in software providers like iCloud Keychain, Bitwarden or Google Password Manager) generally do not support attestation because they are software-based and platform-agnostic. They cannot sign a challenge with a hardware-batch certificate.
• Trade-off:
  • Set to YES: Required for high assurance (AAL3). Ensures the key is hardware-bound. Blocks software-based passkey providers.
  • Set to NO: Allows Synced Passkeys. Lowers assurance slightly (AAL2). Enables software-based passkey providers.

You cannot apply a global "No Attestation" policy if you have high-privilege admins who require hardware keys. You must use Passkey Profiles (Preview):

• Profile A (Admins): Enforce Attestation = Yes
• Profile B (General Staff): Enforce Attestation = No

Think of Passkey Profiles as the mechanism to define:

• "These users can use synced passkeys"
• "These users must use device-bound only"
• "Attestation required vs not required" (and therefore: synced passkeys allowed vs excluded)
• "Restrict to certain authenticator types (AAGUID restrictions)"

Below you can see the Passkey (FIDO2) settings page in the Microsoft Entra admin center where you configure passkey profiles:

When editing a passkey profile, you can configure attestation enforcement, target types (device-bound, synced or both) and specific AAGUID restrictions:

Enforcement can be handled via Conditional Access (CA) policies utilizing Authentication Strengths.

• Phishing-Resistant MFA Strength: This built-in strength requires FIDO2, Windows Hello for Business (WHfB) or Certificate-Based Authentication (CBA).
• Lockout Trap: If you create a CA policy that requires "Phishing-Resistant MFA" for "All Cloud Apps" and apply it to "All Users," you will immediately lock out every user who has not yet registered a passkey. They will not even be able to log in to register one.
• "Register Security Info" Paradox: This is a specific User Action in CA. If you require Phishing-Resistant MFA to perform the action Register Security Information, you create a circular dependency (chicken-and-egg). A user cannot register their first passkey because they need a passkey to access the registration page.

Here is an overview of which authentication methods satisfy which strength requirements:

Entra ID's "System-preferred multifactor authentication" feature forces the sign-in engine to prompt the user for the most secure registered method.

If a user has both SMS and a passkey registered, the system will default to the passkey. This drives passkey adoption organically without hard enforcement. It essentially "upgrades" the user's security posture automatically once they register the credential.

Below you can see the passkey sign-in experience. The user is prompted to use "Face, fingerprint, PIN or security key" and can select their passkey from a browser extension or system credential manager:

For organizations with mixed Windows/macOS environments, macOS Platform SSO provides the Apple equivalent of Windows Hello for Business. Combined with MDM solutions, you can achieve:

• Device-bound credentials tied to the Mac's Secure Enclave
• SSO experience across native apps and web apps
• Phishing-resistant authentication that meets AAL2/AAL3 requirements

Note: macOS Platform SSO requires macOS 13+ and proper MDM configuration. The setup differs significantly from Windows WHfB, so plan for separate deployment tracks.

If your goal is synced passkeys on non-managed devices, these are the most common blockers:

It's not enough to just enable "FIDO2" generally in Entra. For synced passkeys you typically need:

• The preview feature path described in Synced passkeys (preview)
• A profile configuration using Passkey Profiles

If a group isn't targeted by a profile that allows synced passkeys, you'll get pulled back into the "device-bound only" world.

This causes most questions in security-conscious organizations:

• Entra can require attestation for some passkey scenarios (helps validate authenticator type/provenance)
• Synced passkeys do not support attestation in Entra, so if attestation is enforced, synced passkeys fail registration and you'll end up with device-bound options only

Entra lets you restrict which authenticators are allowed (often via AAGUID allow/block lists). If you allow-list only Microsoft Authenticator (or a narrow set of authenticators), third-party synced providers may be implicitly blocked. The confusion part is that the local authentication (e.g. Touch ID, Face ID, Windows biometric scan) works but the Entra login page displays an error then.

Even if passkeys are enabled, Conditional Access can effectively force users into a subset of methods (e.g. "Authenticator only" or a strength configuration that doesn't permit the intended passkey profile). In practice this creates the "Authenticator dependency" even when the plan is synced passkeys.

If external partners are B2B guest users in a resource tenant, there are known limitations around where/how they can register authentication methods. This is frequently the hidden "why doesn't it work" when the intent is "partners use passkeys in our tenant."

The most pervasive issue ("Enrollment is the hardest part") is the bootstrapping problem: How do you securely issue a high-assurance credential to a user who currently has no credentials (or only low-assurance ones)?

The Temporary Access Pass (TAP) is an architectural approach for passwordless onboarding.

• What it is: A time-limited (e.g. 1 hour), high-entropy passcode that Entra ID treats as a "strong authentication" method. It bypasses the need for a password or existing MFA.
• Workflow:
  1. Identity Verification: The new employee's identity is verified (e.g. via HR process or Manager verification).
  2. Issuance: An admin (or automated Logic App) generates a TAP for the user.
  3. "Magic" Login: The user navigates to aka.ms/mysecurityinfo. They enter their username and the TAP.
  4. Registration: Because the TAP satisfies the "Strong Auth" requirement, the user is allowed to access the Security Info blade. They click "Add Method" and register their passkey.
  5. Steady State: The TAP expires. The user now has a phishing-resistant credential. They never typed a password.

For large organizations, manual TAP issuance is unscalable. The best practice is to automate via Microsoft Graph API.

• Scenario: A new hire is processed in the HR system (Workday/SuccessFactors).
• Trigger: The provisioning event triggers an Azure Logic App.
• Action: The Logic App calls the Graph API POST /users/{id}/authentication/temporaryAccessPassMethods.
• Delivery: The TAP is securely delivered to the user's hiring manager or personal email (encrypted) for day-one access.

For remote onboarding or scenarios requiring high identity assurance, Microsoft's Entra Verified ID with Face Check provides a passwordless-first enrollment path:

1. Identity proofing: New user verifies identity via an IDV partner (government ID scan).
2. Biometric matching: Face Check compares a live selfie against the ID document photo using Azure AI Vision. Only a match confidence score is shared (no raw biometric data).
3. Verified credential issued: User receives a Verified ID credential.
4. TAP issuance: Upon successful verification, the system issues a Temporary Access Pass.
5. Passkey bootstrap: User registers their first passkey using the TAP.

The Face Check flow guides users through three steps: Verify (share credentials), Confirm (perform face scan) and Review (see match result):

This flow enables truly passwordless accounts from day one. No password is ever created.

This is often the largest source of helpdesk calls in passkey deployments. Organizations with large BYOD populations (e.g. more than 10,000 devices) can see a huge number of support calls just from users getting new phones and not knowing the process to re-register authentication methods.

When you introduce passkeys into the mix, this becomes even more critical because:

• Users install apps (like Outlook) on their new phone
• These app prompt for authentication
• MFA prompt appears on the old phone (which they may have already traded in or wiped)
• User is locked out and calls helpdesk

The goal is to shift as many cases as possible into the first two rows, minimizing helpdesk involvement.

A clever insight: Requiring a passkey for Intune enrollment forces users to complete Microsoft Authenticator setup on their new phone immediately - before they can access corporate apps.

• Today: Intune enrollment requires MFA step-up. This means if you want to log in on a new phone, you install Outlook there. However, the MFA prompt goes to the old phone.
• With passkey requirement: Users must set up Microsoft Authenticator passkeys on the new phone first to complete enrollment. This happens quickly (day of phone switch) rather than months later when the old phone is gone.

This doesn't solve recovery, but it shifts the timeline. Users register their new device while they still have access to the old one.

Hardware keys (YubiKeys, etc.) are sometimes positioned as the universal solution. In theory they are, however real-world shows more challenges:

• Logistical nightmare: Organizations that previously deployed physical tokens (like RSA SecurID) often spent years trying to eliminate them. Replacing one physical token program with another isn't appealing.
• Drop-shipping: Yubico can drop-ship keys directly to users and they don't need battery replacement every few years (unlike SecurID). But if someone forgets their key, they can't sign in (for shared desktops).
• Local IT burden: Local supervisors should not become de facto IT support for forgotten keys.
• Cost: Hardware keys add per-user cost that scales with headcount.

When hardware keys make sense:

• Tier 0 admins: Domain admins, "break-glass" accounts
• Shared workstations: Kiosk environments, factory floors, field tablets
• Contractors without BYOD: External users who won't use personal devices

Many users complain that they cannot see passkey usage options on a personal device. This is a classic "unmanaged device" friction point.

Users may be unable to add passkeys on a personal device, while it works on a corporate device. This is likely due to Intune Compliance Policies interacting with the registration flow.

• Mechanism: Windows Hello for Business (WHfB) is a platform credential. It is bound to the specific device's TPM (device-bound passkey).
• Constraint: To register WHfB, the device must typically be joined (Entra Joined or Hybrid Joined) to the tenant. A personal device that is merely "Registered" (Workplace Joined) may have policy restrictions applied via Intune that block the provisioning of WHfB containers if the device is not fully managed or compliant. See FIDO2 security key sign-in requirements.
• "Passkey" Option: On a personal device, the user should be attempting to register a FIDO2 Security Key (roaming) or a Cross-Device Passkey (on their phone), not Windows Hello for Business (unless BYOD enrollment is fully supported).
• Entra ID Visibility Issue: If "Windows Hello" does not appear as an option, the device has not completed the prerequisite MDM enrollment.

On unmanaged devices, users often try the Cross-Device Authentication (CDA) flow (scanning a QR code on the PC with their phone).

• Bluetooth Dependency: CDA requires Bluetooth enabled on both the PC and the phone. They do not need to pair, but must perform a Bluetooth Low Energy (BLE) handshake to prove proximity. Review device-bound passkeys in Microsoft Authenticator for details.
• Corporate Policy Blocker: If Bluetooth is disabled on corporate laptops via BIOS or GPO for "security," you've already broken the primary mechanism for roaming passkeys.
• Websocket Blocking: The CDA flow uses a websocket connection to cable.ua5v.com or cable.auth.com. Aggressive corporate firewalls or Zscaler configurations often block these domains, causing the QR code scan to hang or fail silently. See the Microsoft Authenticator passkey documentation.

Another pain point for enterprises is dealing with external consultants (B2B guests).

• Problem: A consultant tries to access a SharePoint site. The tenant enforces a Conditional Access policy requiring "Phishing-Resistant MFA."
• Failure: The consultant tries to register a FIDO2 key in the resource tenant. This fails. Entra ID does not support guest users registering FIDO2 keys in the resource tenant.
• Fix: Cross-Tenant Access Settings
  • Logic: Instead of forcing the guest to register a credential in your tenant, you should trust the credential they use in their tenant.
  • Configuration: Go to External Identities > Cross-tenant access settings. Select the partner organization. Under Inbound Trust, check "Trust multifactor authentication from Microsoft Entra tenants".
  • Result: When the consultant logs in using a YubiKey in their home tenant, your tenant receives a claim saying "MFA Satisfied + Phishing Resistant." Access is granted without the user needing to register anything. This outsources credential lifecycle management to the partner, reducing your liability and helpdesk load.

Often recovery decisions still lag actual rollout. Multiple recovery options exist depending on your organization's needs.

Microsoft Entra ID's new Self-Service Account Recovery (SSAR) flow (in Preview) allows for high-assurance recovery without helpdesk intervention.

1. Trigger: User cannot sign in. Selects "Recover my account."
2. Identity Verification: User is redirected to a third-party Identity Verification (IDV) provider (e.g. Onfido, IDemia).
3. Document Check: User scans their physical Driver's License, national ID or passport using their mobile camera.
4. Liveness Check: User performs a selfie Face Check. This is matched against the ID document (and potentially the photo stored in Entra ID). The matching uses Azure AI Vision Face APIs and only a confidence score is shared. No raw biometric data goes to the application.
5. Restoration: Upon success, the system automatically issues a Temporary Access Pass (TAP) to the user.
6. Re-Enrollment: The user uses the TAP to register a new passkey immediately.

Recommendation: This automated, biometric-backed recovery path is superior to "Call the Helpdesk," which is vulnerable to social engineering (Deepfake voice attacks).

If you want to offload the Service Desk but can't do full self-service, Microsoft has a native feature called My Staff.

• How it works: Delegate limited permissions to "Team Managers" (via Administrative Units in Entra).
• Flow: When a user gets a new phone and is stuck, they don't call IT. They ask their direct manager. The manager logs into the "My Staff" portal and generates a Temporary Access Pass (TAP) for them on the spot.
• Why it helps: Distributes the support load and is much faster than a ticket. It turns a "security incident" into a quick team admin task.

Since users often still have a trusted, WHfB-secured laptop, you can build a simple "break glass" intranet page.

• Build: A simple internal web app that requires WHfB sign-in (strong authentication).
• Action: Once authenticated, the user clicks "I have a new phone." The app uses the Microsoft Graph API (background service) to generate a short-lived Temporary Access Pass (TAP) and displays it on the screen.
• Result: The user types that TAP into their new phone to bootstrap the Microsoft Authenticator app. Zero helpdesk involvement.

This is the key lever to reduce "clear authentication methods" resets without weakening policy. If you have a strong laptop-as-bootstrap mechanism, your communications burden drops significantly because users can recover without knowing the perfect sequence.

Structure your rollout around Maturity Stages. Acknowledge the friction ("The technology is ready, the operations are hard") and apply these mitigations.

1. Audit Bluetooth & Firewalls: Ensure corporate laptops allow Bluetooth (for proximity checks) and whitelist the FIDO/WebAuthn relay domains (\*.cable.auth.com) to fix cross-device failures.
2. Enable Cross-Tenant Trust: Stop trying to register guest passkeys. Configure Inbound Trust for MFA for key partners to solve B2B access issues immediately.
3. Implement TAP for Onboarding: Mandate the use of Temporary Access Pass for all new user onboarding to solve the "chicken-and-egg" registration blocker.

1. Adopt a "Hybrid Assurance" Model:
   • Tier 0 (Admins): Enforce Attestation and Key Restrictions. Only YubiKeys/Hardware allowed (AAL3).
   • Tier 1 (Workforce): Disable Attestation enforcement via Passkey Profiles. Allow synced passkeys to reduce friction and cos (AAL2).
2. Plan for macOS: Deploy Platform SSO with your MDM as a parallel track to Windows WHfB.

1. Plan for SSAR: Begin a pilot for Self-Service Account Recovery with Verified ID to eliminate the helpdesk as a social engineering vector.
2. System-Preferred Auth: Enable this policy to automatically "upgrade" users to passkeys as soon as they register one, driving adoption without a hard mandate.
3. Deploy Recovery Options: Implement Manager-Assisted TAP via My Staff and/or a Self-Service Recovery Kiosk.
4. Intune Passkey Requirement: Consider requiring passkey for Intune enrollment to force early registration on new devices.

Microsoft has released a Phishing-Resistant Passwordless Workbook that organizations with logs in Azure Monitor can use to track rollout progress. Access it via the Entra admin center under Monitoring > Workbooks:

The workbook has two primary sections:

Use this tab to analyze sign-in logs and determine which users are ready for registration vs. which users may be blocked. You can filter by OS platform (Windows, macOS, iOS, Android) and credential type (Authenticator App Passkey, FIDO2 Security Key, Certificate-Based Authentication):

The workbook shows:

• User/Device Pairs Ready for Enrollment: users who can register the selected credential type
• User/Device Pairs Not Ready: users who may have registration issues (e.g. outdated OS versions)

You can export lists of users who need remediation actions (e.g. OS upgrades, device replacements or alternative credential options).

Once users are ready for phishing-resistant-only authentication, use the Enforcement Readiness tab. First, create a Report-Only Conditional Access policy that requires phishing-resistant MFA. This populates sign-in logs with data about whether access would have been blocked if enforcement was active.

The dashboard shows:

• Total users in scope
• Report Only Success - users who would pass enforcement
• Policy Not Satisfied - users who would be blocked (investigate these!)
• Device State, Device Platform and Client App breakdowns

Use the Further Data Analysis tab to investigate why certain users would be blocked. This data helps you target users for remediation before enabling enforcement.

Microsoft recommends executing deployments in waves with flexible date ranges. Monitor help desk ticket volume as a signal:

• Ticket volume increasing: Slow down deployments, communications and enforcement actions
• Ticket volume decreasing: Ramp activities back up

Create Microsoft Entra ID security groups for each wave and add groups to your policies incrementally. This prevents overwhelming support teams.

If the goal is synced passkeys without Microsoft Authenticator dependency, follow this pilot posture:

1. Enable synced passkeys (preview) Follow Synced passkeys (preview).

2. Use Passkey Profiles (preview) and target the pilot group Create/assign a profile that permits synced passkeys as described in Passkey Profiles.

3. Do not enforce attestation (at least for the pilot group) Enforcing attestation excludes synced passkeys per the Passkeys (FIDO2) concepts documentation.

4. Avoid strict AAGUID allow-lists initially Start permissive to confirm the flow, then tighten restrictions once you know which providers you want to allow. See Enable passkeys (FIDO2).

5. Confirm Conditional Access doesn't force Microsoft Authenticator Make sure CA/auth strengths still allow the passkey profile you intend (otherwise it looks like a Microsoft Authenticator dependency).

6. Validate the identity model (member vs guest) If users are guests, confirm expected supportability in your tenant model before spending time tuning profiles.

Enterprise passkey deployment is operationally complex, but the way forward is well-defined. Here are the key answers, aligned with the main operational questions raised above:

1. Device-bound vs synced passkeys: Device-bound credentials (e.g. Microsoft Authenticator, Windows Hello, YubiKeys, smartcards) are strictly tied to a single device and satisfy AAL3. Synced passkeys (e.g. iCloud Keychain, Google Password Manager) work across devices and meet AAL2. Most organizations need both: hardware authenticators for admins (AAL3) and synced passkeys for the broader workforce (AAL2).

2. Bootstrapping new employees: Use Temporary Access Pass (TAP) to solve the chicken-and-egg problem at onboarding. For large-scale deployments, automate this via the Graph API. For high-assurance use cases, supplement onboarding with Entra Verified ID and Face Check.

3. Phone replacement recovery: Offer multiple recovery methods: Self-Service Recovery Kiosk (use a laptop as bootstrap device), Manager-Assisted TAP via My Staff and SSAR (Self-Service Account Recovery) with Verified ID for edge cases.

4. Configuration mistakes: The most frequent missteps include enforcing attestation globally, not enabling preview features for synced passkeys, overly strict AAGUID allow-lists and Conditional Access (CA) policies that create circular dependencies.

5. B2B guests: Avoid registering passkeys directly for B2B guests in your tenant. Instead, enable Cross-Tenant Access Trust to validate credentials from the guest's home tenant.

6. Hardware keys vs mobile passkeys: Hardware security keys are required for certain high-security roles (admins, shared workstations) but present logistical hurdles at scale. Mobile passkeys are generally more practical for the workforce.

7. macOS alongside Windows: Use Platform SSO with JAMF/MDM to enable passkey support on macOS in parallel with Windows deployments. Plan for platform-specific workflows.

8. Proactive measures: Use Intune to identify inactive devices and nudge users for remediation before lockout occurs. Consider making passkey registration a prerequisite for Intune enrollment to foster early adoption. Build a self-service recovery workflow using laptops as bootstrap devices.

The technology is ready. The main challenge is operational execution. Recovery planning must be integral from day one, not an afterthought.

For deep-dives into enterprise FIDO2/passkey deployments, follow experts like Merill Fernando and Jan Bakker who regularly publish practical guidance on Microsoft Entra authentication.