--- url: 'https://www.corbado.com/blog/enterprise-passkey-deployment-challenges' title: 'Enterprise Passkey Deployment Challenges & Solutions' description: 'Deploy passkeys in Microsoft Entra ID at scale. Covers enrollment challenges, synced vs device-bound, recovery strategies and troubleshooting common errors.' lang: 'en' author: 'Vincent Delitz' date: '2026-01-16T09:01:42.039Z' lastModified: '2026-03-25T10:01:32.699Z' keywords: 'synced passkeys entra, fido2 workforce, temporary access pass' category: 'Passkeys Strategy' --- # Enterprise Passkey Deployment Challenges & Solutions ## Key Facts - **NIST SP 800-63B Supplement 1** validates synced passkeys meet AAL2 requirements, making them phishing-resistant enough for general workforce use without hardware keys. - The **Temporary Access Pass (TAP)** solves the bootstrapping paradox: a time-limited passcode lets new employees register a passkey without ever setting a password. - Enforcing **attestation** in Microsoft Entra ID blocks all synced passkeys. Use Passkey Profiles to apply it selectively: required for admins, disabled for general staff. - A **segmented assurance model** is essential: hardware keys satisfy AAL3 for admins and privileged roles, while synced passkeys deliver AAL2 for the broader workforce. ## 1. Introduction: operational reality of enterprise passkeys for employees 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](https://www.corbado.com/glossary/authenticator)? 4. What configuration mistakes cause [passkey enrollment](https://www.corbado.com/blog/passkey-creation-best-practices) failures? 5. How do I handle B2B guests when requiring [phishing](https://www.corbado.com/glossary/phishing)-resistant MFA? 6. Should I use [hardware security keys](https://www.corbado.com/blog/best-fido2-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? ## 2. Understanding passkeys in Microsoft Entra In Entra, **"passkeys" = FIDO2/WebAuthn credentials**. Instead of a password, the user proves possession of a **private key** stored in an [authenticator](https://www.corbado.com/glossary/authenticator). It's **phishing-resistant** because WebAuthn binds the credential to the real sign-in origin (so a lookalike [phishing](https://www.corbado.com/glossary/phishing) site can't replay it). See Microsoft's overview in the [Passkeys (FIDO2) concepts documentation](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-passkeys-fido2). Entra effectively supports **two "modes" of passkeys** that behave differently. ### 2.1 Device-bound passkeys in Entra 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](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/yubikey)) - **Smartcards** Microsoft's baseline setup guidance for [device-bound passkeys](https://www.corbado.com/faq/are-passkeys-device-specific) can be found here: [https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-enable-passkey-fido2](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](https://www.corbado.com/glossary/yubikey)). ### 2.2 Synced passkeys in Entra These are passkeys stored in a provider ecosystem and synced across the user's devices (e.g. [iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain), [Google Password Manager](https://www.corbado.com/blog/how-to-use-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)](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-synced-passkeys). To enable and control synced passkeys, Entra uses [Passkey Profiles (preview)](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-passkey-profiles). **Regulatory fit:** Recently validated by [NIST SP 800-63B](https://www.corbado.com/faq/nist-sp-800-63b-supplement-passkey-adoption) Supplement 1 as meeting **AAL2** requirements. This is a massive regulatory win validating that synced passkeys are "[phishing](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/device-bound-synced-passkeys) providers: | Passkey provider | Windows | macOS | iOS | Android | | --------------------------------------------------- | --------------------------- | ---------------------------- | --------------------------- | --------------------------------------------------------- | | Apple Passwords (iCloud Keychain) | N/A | Natively built in. macOS 13+ | Natively built in. iOS 16+ | N/A | | Google Password Manager | Built in to Chrome | Built in to Chrome | Built in to Chrome. iOS 17+ | Natively built in (excluding Samsung devices). Android 9+ | | Other passkey providers (e.g. 1Password, Bitwarden) | Check for browser extension | Check for browser extension | Check for app. iOS 17+ | Check for app. Android 14+ | In a user's Security Info page, synced and [device-bound passkeys](https://www.corbado.com/faq/are-passkeys-device-specific) are clearly distinguished. Below you can see how a [synced passkey](https://www.corbado.com/blog/device-bound-synced-passkeys) (from [1Password](https://www.corbado.com/blog/1password-passkeys-best-practices-analysis)) and a [device-bound passkey](https://www.corbado.com/blog/device-bound-synced-passkeys) (YubiKey 5C NFC) appear: ![passkey account settings](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/passkey_account_settings_946c956180.png) ### 2.3 Regulatory alignment: NIST AAL levels - **AAL3** historically required **hardware-based, device-bound** [authenticators](https://www.corbado.com/glossary/authenticator) (like [YubiKeys](https://www.corbado.com/glossary/yubikey) or Smart Cards) that utilize a non-exportable private key. - **AAL2** can now be achieved with synced passkeys per [NIST](https://www.corbado.com/blog/nist-passkeys) guidance. - **Nuance:** While synced passkeys (like those in iCloud) are excellent for standard users, they may not strictly meet the [AAL3](https://www.corbado.com/blog/nist-passkeys) "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). ### 2.4 Device readiness requirements To ensure devices are prepared for phishing-resistant [passwordless authentication](https://www.corbado.com/glossary/passwordless-authentication), they must run these minimum versions: | Platform | Minimum Version | Notes | | -------- | ------------------------------------------------- | --------------------------------------------------------------- | | Windows | 10 22H2 (for WHfB), 11 22H2 (for best passkey UX) | Older versions may require FIDO2 security keys | | macOS | 13 Ventura | Required for Platform SSO Secure Enclave Key | | iOS | 17 | Required for passkey sync and cross-device flows | | Android | 14 | Required for synced passkeys; older versions need security keys | Older operating systems may require external [authenticators](https://www.corbado.com/glossary/authenticator) (FIDO2 security keys) to support phishing-resistant [passwordless authentication](https://www.corbado.com/glossary/passwordless-authentication). ### 2.5 User persona credential recommendations 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): | User Persona | Recommended | Alternatives | | --------------------------------- | ------------------- | ------------------------------------------------------ | | Admins and highly regulated users | FIDO2 security keys | Passkey in Microsoft Authenticator, Smart Card | | Non-admin workforce | Synced passkey | FIDO2 security key, Passkey in Microsoft Authenticator | **Local credentials** (device-specific): | User Persona | Windows | macOS | iOS | Android | | ------------ | ----------- | -------------------------------------- | ------------------------------- | ------------------------------- | | Admins | WHfB or CBA | Platform SSO Secure Enclave Key or CBA | Passkey in Authenticator or CBA | Passkey in Authenticator or CBA | | Non-admins | WHfB | Platform SSO Secure Enclave Key | Synced passkey | Synced passkey | The end goal: Most users should have at least one **portable** credential plus **local** credentials on each computing device. ## 3. Experiences from live Passkey Deployments When speaking to organizations that have deployed passkeys some real-worl friction points and patterns are recognized. ### 3.1 Operational shift **"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. For enterprise operations, the key is to separate expected and unexpected failures in monitoring. Bucket [WebAuthn errors](https://www.corbado.com/blog/webauthn-errors) explicitly and track [`NotAllowedError`](https://www.corbado.com/blog/webauthn-errors), [`AbortError`](https://www.corbado.com/blog/webauthn-errors), and [Credential Manager passkey errors](https://www.corbado.com/blog/webauthn-errors) as distinct signals. Our [authentication analytics](https://www.corbado.com/blog/authentication-analytics-playbook) playbook provides a framework for classifying these signals, and [passkey analytics](https://www.corbado.com/blog/passkey-analytics) covers passkey-specific KPIs like activation and login rates. ### 3.2 Enrollment: the "make-or-break" moment 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. ### 3.3 Mental model gap "Users don't need cryptography, they need a mental model". The terminology confusion creates cognitive load: - Passkey - [Security Key](https://www.corbado.com/glossary/security-key) - Hardware Key - [YubiKey](https://www.corbado.com/glossary/yubikey) - passwordless - Windows Security - [Windows Hello](https://www.corbado.com/glossary/windows-hello) - [Windows Hello](https://www.corbado.com/glossary/windows-hello) for Business (WHfB) - Microsoft [Authenticator](https://www.corbado.com/glossary/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. ### 3.4 Communication limitations 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. ## 4. Microsoft Entra ID configuration deep-dive 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. ### 4.1 Authentication methods policy The legacy MFA and SSPR portals are deprecated. All [FIDO2](https://www.corbado.com/glossary/fido2) configuration must occur in the unified [Authentication Methods Policy](https://www.threatscape.com/cyber-security-blog/common-entra-id-mfa-mistakes-you-might-be-making/) 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](https://www.corbado.com/glossary/fido2) device (e.g. [YubiKey](https://www.corbado.com/glossary/yubikey) 5 NFC, Microsoft Authenticator on [iOS](https://www.corbado.com/blog/webauthn-errors), [Google Password Manager](https://www.corbado.com/blog/how-to-use-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](https://www.corbado.com/glossary/aaguid). This prevents users from registering cheap, unverified "grey market" security keys. ### 4.2 Attestation: the critical decision point 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](https://www.corbado.com/glossary/icloud-keychain), [Bitwarden](https://www.corbado.com/blog/passkey-analysis-bitwarden-developer-survey-2024) or [Google Password](https://www.corbado.com/blog/how-to-use-google-password-manager) Manager) generally **do not** support [attestation](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/attestation)" policy if you have high-privilege admins who require hardware keys. You must use [Passkey Profiles (Preview)](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-synced-passkeys): - _Profile A (Admins):_ Enforce [Attestation](https://www.corbado.com/glossary/attestation) = **Yes** - _Profile B (General Staff):_ Enforce Attestation = **No** ### 4.3 Passkey Profiles explained Think of [Passkey Profiles](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-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: ![passkey fido2 settings selected profiles](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/passkey_fido2_settings_selected_profiles_8fad7bfc7a.png) When editing a passkey profile, you can configure attestation enforcement, target types (device-bound, synced or both) and specific [AAGUID](https://www.corbado.com/glossary/aaguid) restrictions: ![passkey fido2 settings](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/passkey_fido2_settings_800cee0438.png) ### 4.4 Conditional Access & authentication strengths Enforcement can be handled via Conditional Access (CA) policies utilizing [Authentication Strengths](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-strengths). - **Phishing-Resistant MFA Strength:** This built-in strength requires [FIDO2](https://www.corbado.com/glossary/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](https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-all-users-security-info-registration), 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: | Authentication method combination | MFA strength | Passwordless MFA strength | Phishing-resistant MFA strength | | ----------------------------------------------------- | :----------: | :-----------------------: | :-----------------------------: | | FIDO2 security key | ✅ | ✅ | ✅ | | Windows Hello for Business or platform credential | ✅ | ✅ | ✅ | | Certificate-based authentication (multifactor) | ✅ | ✅ | ✅ | | Microsoft Authenticator (phone sign-in) | ✅ | ✅ | | | Temporary Access Pass (one-time use and multiple use) | ✅ | | | | Password plus something the user has | ✅ | | | | Federated single-factor plus something the user has | ✅ | | | | Federated multifactor | ✅ | | | | Certificate-based authentication (single-factor) | | | | | SMS sign-in | | | | | Password | | | | | Federated single-factor | | | | ### 4.5 System-preferred authentication Entra ID's "System-preferred multifactor authentication" feature forces the sign-in engine to [prompt the user for the most secure registered method](https://www.token2.com/site/page/default-mfa-method-for-microsoft-entra-id-users). If a user has both SMS and a passkey registered, the system will default to the passkey. This drives [passkey adoption](https://www.corbado.com/blog/passkey-adoption-business-case) 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](https://www.corbado.com/glossary/security-key)" and can select their passkey from a browser extension or system credential manager: ![1password passkey entra](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/1password_passkey_entra_e261b05849.png) ### 4.6 macOS considerations: Platform SSO For organizations with mixed Windows/macOS environments, **macOS Platform SSO** provides the Apple equivalent of [Windows Hello](https://www.corbado.com/glossary/windows-hello) for Business. Combined with MDM solutions, you can achieve: - Device-bound credentials tied to the Mac's [Secure Enclave](https://www.corbado.com/glossary/secure-enclave) - [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso) experience across native apps and web apps - Phishing-resistant authentication that meets [AAL2](https://www.corbado.com/blog/nist-passkeys)/[AAL3](https://www.corbado.com/blog/nist-passkeys) requirements **Note:** macOS Platform [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso) requires macOS 13+ and proper MDM configuration. The setup differs significantly from Windows WHfB, so plan for separate deployment tracks. ## 5. Common misconfigurations: why "it only works with Microsoft Authenticator" If your goal is **synced passkeys on non-managed devices**, these are the most common blockers: ### 5.1 Synced passkeys not enabled/targeted 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)](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-synced-passkeys) - A profile configuration using [Passkey Profiles](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-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. ### 5.2 Attestation enforced (blocks synced passkeys) 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](https://www.corbado.com/blog/why-passkey-implementations-fail) registration and you'll end up with device-bound options only ### 5.3 AAGUID allow-listing blocks providers Entra lets you restrict which [authenticators](https://www.corbado.com/glossary/authenticator) are allowed (often via [AAGUID](https://www.corbado.com/glossary/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](https://www.corbado.com/faq/is-face-id-passkey), Windows biometric scan) works but the Entra login page displays an error then. ### 5.4 Conditional Access forces certain passkey types 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. ### 5.5 B2B guest vs member accounts 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." ## 6. Operational challenges & solutions ### 6.1 Bootstrapping paradox 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)?** #### 6.1.1 Temporary Access Pass (TAP) The [Temporary Access Pass (TAP)](https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-temporary-access-pass) 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. #### 6.1.2 Automation via Graph API For large organizations, manual TAP issuance is unscalable. The best practice is to [automate via Microsoft Graph API](https://janbakker.tech/how-to-create-a-temporary-access-pass-using-logic-apps/). - **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. #### 6.1.3 Microsoft Entra Verified ID for high-assurance onboarding For remote onboarding or scenarios requiring high identity assurance, Microsoft's [Entra Verified ID](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-deploy-phishing-resistant-passwordless-authentication) 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](https://learn.microsoft.com/en-us/entra/verified-id/using-facecheck) 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): ![Microsoft Entra Verified ID Face Check flow showing Verify, Confirm and Review steps](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/face_check_b5a23174b0.png) This flow enables **truly passwordless accounts from day one**. No password is ever created. ### 6.2 Phone replacement problem (the hidden scale challenge) 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 #### 6.2.1 Scenario matrix for phone replacement | Scenario | User has old phone | User has trusted laptop | Solution | | --------------- | ------------------ | ----------------------- | ----------------------------------------------------------------------------------------------------------- | | **Best case** | Yes | Yes | Guide user to add new passkey while old phone still works. Shift to "happy path." | | **Common case** | No | Yes | **Laptop as bootstrap:** Use WHfB-authenticated session to register new phone passkey (Self-Service Kiosk). | | **Worst case** | No | No | Helpdesk intervention or SSAR with identity verification unavoidable. | The goal is to shift as many cases as possible into the first two rows, minimizing helpdesk involvement. #### 6.2.2 Intune enrollment trick 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. ### 6.3 Hardware security keys come with logistics issues 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 ### 6.4 Unmanaged device challenges Many users complain that they cannot see passkey usage options on a personal device. This is a classic "unmanaged device" friction point. #### 6.4.1 "Passkey not registered" error analysis 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](https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-passwordless-security-key-windows). - **"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. #### 6.4.2 Cross-Device Authentication (CDA) failures On unmanaged devices, users often try the **Cross-Device Authentication (CDA)** flow (scanning a [QR code](https://www.corbado.com/blog/qr-code-login-authentication) 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](https://www.corbado.com/passkeys-for-energy) (BLE) handshake to prove proximity. Review [device-bound passkeys in Microsoft Authenticator](https://janbakker.tech/things-you-should-know-before-rolling-out-device-bound-passkeys-in-microsoft-authenticator-app/) 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](https://www.corbado.com/blog/qr-code-login-authentication) scan to hang or fail silently. See the [Microsoft Authenticator passkey documentation](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-enable-authenticator-passkey). ### 6.5 B2B and external identities 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](https://www.corbado.com/blog/best-fido2-hardware-security-keys) in the resource tenant. **This fails.** Entra ID [does not support guest users registering FIDO2 keys](https://learn.microsoft.com/en-us/answers/questions/1192906/cannot-register-fido2-key-for-guest-users-on-resou) 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. ## 7. Recovery strategies Often recovery decisions still lag actual rollout. Multiple recovery options exist depending on your organization's needs. ### 7.1 Self-Service Account Recovery (SSAR) with Verified ID Microsoft Entra ID's new [Self-Service Account Recovery (SSAR)](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-account-recovery-overview) flow (in Preview) allows for high-assurance recovery without helpdesk intervention. ![Account Recovery flow using Microsoft Entra Verified ID showing the 4-step process](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/account_recovery_microsoft_entry_recovery_8c9f369047.png) 1. **Trigger:** User cannot sign in. Selects "Recover my account." 2. **Identity Verification:** User is redirected to a third-party [Identity Verification](https://www.corbado.com/blog/digital-identity-guide) (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](https://learn.microsoft.com/en-us/entra/verified-id/using-facecheck). 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). ### 7.2 Manager-Assisted TAP (My Staff portal) 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. ### 7.3 Self-Service Recovery kiosk (intranet) 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. ## 8. Recommendations for Passkey Enterprise Deployments Structure your rollout around **Maturity Stages**. Acknowledge the friction ("The technology is ready, the operations are hard") and apply these mitigations. ### 8.1 Immediate actions ("Fix-It" phase) 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. ### 8.2 Strategic decisions ("Architecture" phase) 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](https://www.corbado.com/blog/passkeys-single-sign-on-sso) with your MDM as a parallel track to Windows WHfB. ### 8.3 Future-proofing ("Optimization" phase) 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. ### 8.4 Troubleshooting matrix | **Error message / symptom** | **Root cause** | **Remediation strategy** | | ---------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | | **"Passkey not registered"** (Windows Desktop) | Policy enforces "Attestation," but user is using a non-attested method (e.g. Google Password Manager, iCloud Keychain, 1Password). | Use **Passkey Profiles** to disable "Enforce Attestation" for standard users. | | **"Passkey not registered"** (Mobile App) | Specific AAGUID for Microsoft Authenticator (Android/iOS) is missing from the "Key Restrictions" whitelist. | Add AAGUIDs: Android: `de1e552d-db1d-4423-a619-566b625cdc84` iOS: `90a3ccdf-635c-4729-a248-9b709135078f`. | | **Registration Loop / Greyed Out Options** | User has no existing MFA and CA requires Phishing-Resistant MFA to access "Register Security Info". | **Bootstrapping Failure.** Issue a **Temporary Access Pass (TAP)** to bypass the MFA check for the initial session. | | **QR Code Scan Fails / Spins** | Bluetooth disabled on one device, or firewall blocking `cable.auth.com` WebSocket. | Enable Bluetooth (proximity check). Whitelist FIDO relay domains. | | **Guest User Registration Fails** | Entra ID blocks guest FIDO2 registration in resource tenants. | **Do not fix.** Enable **Cross-Tenant Access Trust** to accept the home tenant's MFA claim instead. | ## 9. Monitoring deployment with the Phishing-Resistant Passwordless Workbook Microsoft has released a [Phishing-Resistant Passwordless Workbook](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-deploy-phishing-resistant-passwordless-authentication) that organizations with logs in Azure Monitor can use to track rollout progress. Access it via the Entra admin center under **Monitoring > Workbooks**: ![Microsoft Entra workbooks showing Phishing-Resistant Passwordless Deployment option](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/phishing_resistant_passwordless_workbook_6b06c63518.png) The workbook has two primary sections: ### 9.1 Enrollment Readiness Phase 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](https://www.corbado.com/blog/webauthn-errors), [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android)) and credential type (Authenticator App Passkey, FIDO2 [Security Key](https://www.corbado.com/glossary/security-key), Certificate-Based Authentication): ![Enrollment Readiness Phase showing device readiness breakdown with User/Device Pairs Ready vs Not Ready](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/enrollment_phase_165ed80a39.png) 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). ### 9.2 Enforcement Readiness Phase 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. ![Enforcement Readiness Phase showing policy satisfaction breakdown with Further Data Analysis](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/detail_analysis_workbook_1c0931ee47.png) 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. ### 9.3 Wave-based rollout with help desk monitoring 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. ## 10. Synced Passkey pilot checklist If the goal is **synced passkeys without Microsoft Authenticator dependency**, follow this pilot posture: 1. **Enable synced passkeys (preview)** Follow [Synced passkeys (preview)](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-synced-passkeys). 2. **Use Passkey Profiles (preview) and target the pilot group** Create/assign a profile that permits synced passkeys as described in [Passkey Profiles](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-passkey-profiles). 3. **Do not enforce attestation (at least for the pilot group)** Enforcing attestation excludes synced passkeys per the [Passkeys (FIDO2) concepts documentation](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-passkeys-fido2). 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)](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-enable-passkey-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. ## 11. Conclusion 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](https://www.corbado.com/blog/nist-passkeys). Synced passkeys (e.g. [iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain), [Google Password](https://www.corbado.com/blog/how-to-use-google-password-manager) Manager) work across devices and meet [AAL2](https://www.corbado.com/blog/nist-passkeys). 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](https://www.corbado.com/blog/introducing-passkeys-large-scale-overview) 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](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/best-fido2-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. Once the infrastructure is solid, focus on optimizing [passkey login](https://www.corbado.com/blog/passkey-login-best-practices) adoption to ensure passkeys become the primary authentication method across your workforce. ## Frequently Asked Questions ### Why does enabling phishing-resistant MFA in Conditional Access lock out all my users? Creating a Conditional Access policy requiring phishing-resistant MFA for all cloud apps immediately blocks any user who has not yet registered a passkey, including blocking access to the Security Info registration page itself. This circular dependency, called the 'Register Security Info' paradox, means you must issue a Temporary Access Pass to affected users before enabling enforcement so they can complete initial registration. ### How do I handle B2B guest users when my tenant requires phishing-resistant MFA? Entra ID does not support guest users registering FIDO2 keys in a resource tenant, so attempting to enforce passkey registration for guests will fail. The correct fix is to configure Cross-Tenant Access Settings under External Identities to trust MFA claims from the guest's home tenant, meaning a YubiKey used in their own organization satisfies your phishing-resistant MFA requirement without any registration in your tenant. ### What causes cross-device QR code authentication to fail silently when signing in with a passkey? Cross-Device Authentication requires Bluetooth enabled on both the PC and the phone to complete a BLE proximity handshake, so any corporate policy disabling Bluetooth will break the flow entirely. The flow also uses a WebSocket connection to cable.auth.com, which firewalls or Zscaler configurations frequently block, causing the QR code scan to hang or fail without a clear error message. ### How do I monitor which employees are ready for phishing-resistant MFA enforcement before I turn it on? Microsoft's Phishing-Resistant Passwordless Workbook, accessible via the Entra admin center under Monitoring > Workbooks, provides an Enrollment Readiness view showing which user/device pairs can register by platform and credential type. For enforcement readiness, create a report-only Conditional Access policy requiring phishing-resistant MFA so sign-in logs reveal which users would be blocked before you activate live enforcement. ### What is the best recovery strategy for employees who get a new phone and lose access to their passkey? The recommended approach is layered: a Self-Service Recovery Kiosk using a WHfB-secured laptop generates a Temporary Access Pass via Graph API and covers most cases without helpdesk involvement. For users without a laptop, Manager-Assisted TAP via the My Staff portal delegates recovery to direct managers, and Self-Service Account Recovery with Entra Verified ID biometric Face Check handles edge cases requiring full identity re-verification. ## Further reading For deep-dives into enterprise FIDO2/passkey deployments, follow experts like **[Merill Fernando](https://au.linkedin.com/in/merill)** and **[Jan Bakker](https://www.linkedin.com/in/jan-bakker/)** who regularly publish practical guidance on Microsoft Entra authentication.