How to Deploy Passkeys in the Enterprise: A FIDO2 & WebAuthn Guide

Enterprise passkey deployment is the process of migrating your workforce from password and TOTP-based authentication to FIDO2-compliant, phishing-resistant credentials backed by asymmetric public-key cryptography. The business case has moved past debate: 86% of web application breaches involve stolen credentials, TOTP codes are interceptable by real-time phishing proxies, and SMS one-time passwords are vulnerable to SIM-swap attacks. The FIDO Alliance's 2026 data shows 87% of enterprises have deployed or are actively deploying passkeys, driven partly by genuine security posture improvement and partly by CISA's explicit guidance classifying FIDO2 and WebAuthn as one of only two phishing-resistant MFA categories that organizations should adopt. Passkey adoption is becoming a baseline security expectation in regulated industries and a procurement requirement in enterprise software evaluations.

The challenge is not enabling WebAuthn — browser support is universal as of 2026 and every major identity provider has a native FIDO2 integration. The challenge is deploying passkeys at workforce scale across the full complexity of an enterprise environment: shared workstations, legacy LDAP applications, VPN clients, contractors without managed devices, and the inevitable segments that do not fit a standard playbook. The deployments that succeed treat this as an identity architecture project with a defined recovery process, not a configuration toggle. Those that fail under-plan account recovery until the first locked-out executive forces a policy rollback, or deploy for 80% of users and declare victory while the remaining 20% become the highest-value targets for attackers who know exactly who is still on passwords. This problem overlaps directly with zero-trust architecture principles: identity is the new perimeter, and passkeys are how you harden the authentication layer that perimeter depends on.

This guide is for security engineers and platform architects who need a concrete implementation path — not vendor comparisons. We cover the FIDO2 protocol, the synced-versus-hardware security decision, IDP integration for Okta and Microsoft Entra ID, the five-phase rollout model, legacy application handling, and the account recovery design that determines whether a deployment survives its first real-world test. Pair this with your broader secrets management strategy — passkeys eliminate one credential class, but service accounts, API keys, and infrastructure secrets still require a parallel hardening track.

What Are Passkeys and How Does FIDO2 Authentication Work at the Protocol Level?

A passkey is a FIDO2 credential: an asymmetric key pair where the private key never leaves the authenticator — a device secure enclave, a hardware security key, or a passkey sync provider — and the public key is stored on the relying party server. During registration, the browser calls navigator.credentials.create() with a challenge and relying party metadata; the authenticator generates a key pair bound to that specific origin and returns the public key and an attestation statement. During authentication, the server presents a fresh random challenge; the authenticator signs it with the private key; the server verifies the signature against the stored public key. The credential is origin-scoped: a passkey registered on app.example.com carries the relying party ID in its credential data and cannot be used to authenticate to a lookalike phishing domain. This is the mechanism that makes FIDO2 categorically phishing-proof rather than just phishing-resistant — the protection is cryptographic and enforced by the browser, not dependent on the user recognizing a suspicious URL.

• →Registration flow: The server generates a random challenge and a PublicKeyCredentialCreationOptions object. The browser calls navigator.credentials.create(). The authenticator generates a new key pair scoped to the relying party ID, signs the challenge and client data hash with the new private key, and returns the public key, attestation statement, and a credential ID. The server stores the public key and credential ID against the user account.
• →Authentication flow: The server generates a fresh random challenge and calls navigator.credentials.get() with the user's registered credential IDs. The authenticator locates the matching private key, signs the challenge and client data hash, and returns the assertion. The server verifies the signature against the stored public key, validates the origin and relying party ID binding, and confirms the challenge is fresh. All checks pass — authentication succeeds.
• →Origin binding enforcement: The credential's relying party ID is embedded in every assertion and verified by the browser before the authenticator is allowed to sign. A credential registered for app.example.com will refuse to produce an assertion for attacker.com — the browser blocks the authenticator call before it touches the private key. There is no user decision involved and no way to bypass this via social engineering.
• →WebAuthn and CTAP2: WebAuthn is the browser-facing JavaScript API (navigator.credentials). CTAP2 (Client-to-Authenticator Protocol 2) governs the communication between the browser and an external authenticator — a hardware security key — over USB, NFC, or Bluetooth. Platform authenticators (device biometrics like Face ID or Windows Hello) bypass CTAP2 and communicate internally via the operating system.

Synced Passkeys vs. Device-Bound Passkeys: Choosing the Right Model for Each User Segment

The single most consequential architecture decision in enterprise passkey deployment is whether to allow synced passkeys — private key stored in iCloud Keychain, Google Password Manager, or a third-party passkey manager like 1Password, synced automatically across a user's devices — or mandate device-bound passkeys where the private key is generated inside hardware (a device TPM or secure enclave, or a FIDO2 hardware security key) and cannot be exported or copied. These are not equivalent security controls and should not be treated as interchangeable.

• →Synced passkeys: The private key is encrypted and synced to the cloud provider's servers, decryptable only on the user's authenticated devices. Recovery is built into the cloud account recovery flow. The security ceiling is the cloud account — a compromised Apple ID or Google Account exposes all synced passkeys for that user. Most passkey sync providers use basic-none attestation, meaning the server cannot verify whether the key resides in hardware or software. Despite these limitations, synced passkeys eliminate phishing risk entirely and represent a massive improvement over passwords or TOTP for the general employee population.
• →Device-bound passkeys — hardware security keys: The private key is generated inside FIDO2 hardware (YubiKey 5 series, Google Titan Key, Feitian ePass FIDO2-NFC) and is physically non-exportable — the design ensures the key cannot leave the device under any circumstances. Hardware keys support full attestation, allowing the server to cryptographically verify the manufacturer and model. Recovery requires a pre-registered backup key or an IT-administered recovery workflow. Suitable for privileged accounts, financial approvers, domain administrators, and regulated environments requiring hardware FIDO2 (US federal FedRAMP High and FIPS 140-2 Level 2+ requirements).
• →Enterprise recommendation — hybrid model: Issue hardware security keys to all privileged accounts (IT admins, domain admins, financial approvers, executives) and allow synced passkeys for the general employee population. This maximizes security coverage where attacks are highest-value while keeping the general deployment operationally feasible. Attempting to issue hardware keys to every employee on day one results in procurement delays, inventory management overhead, and user friction that stalls the initiative before it produces results.
• →Attestation and compliance: If your compliance framework requires verifiable hardware assurance for authentication — FedRAMP High, FIPS 140-2, PCI-DSS cardholder data systems — mandate hardware keys for those segments specifically and configure the server to reject credentials that do not carry a valid hardware attestation certificate. For HIPAA and general SOC 2 compliance, synced passkeys typically satisfy the MFA requirement.

IDP Integration: Deploying Passkeys Without Changing Every Application

The correct deployment architecture puts the FIDO2 challenge at the identity provider layer, not at each individual application. Any application that authenticates via SSO through OIDC or SAML receives passkey authentication without any application-level code changes — the IDP authenticates the user, verifies the WebAuthn assertion, and issues a session token downstream. This is how organizations with hundreds of internal applications can deploy passkeys without a multi-year engineering programme. Our security and scalability practice designs these IDP integration architectures for enterprise clients across regulated industries.

• →Okta: Enable WebAuthn in Security > Authenticators in the Okta Admin Console. Set WebAuthn as required (not optional) in the authentication policies that apply to target user groups. Okta FastPass provides a device-bound credential for managed desktops via the Okta Verify agent — this is the recommended path for employees on managed laptops, as it delivers hardware-bound assurance without issuing external hardware keys. Enrollment can be user-initiated via the Okta End-User Dashboard or IT-triggered via enrollment prompts on next login.
• →Microsoft Entra ID: Enable FIDO2 security keys and passkeys (Microsoft Authenticator passkeys) under Authentication Methods in the Entra ID admin center. For hybrid environments with on-premises Active Directory, configure Microsoft Entra Hybrid Join — after FIDO2 authentication against Entra ID, the system issues a Kerberos TGT for on-premises AD resources, extending passkey authentication into Kerberos-protected systems without touching those systems. Conditional Access policies can then enforce phishing-resistant authentication strength as a requirement for accessing sensitive applications.
• →Ping Identity: Supports FIDO2 through PingOne MFA. Configure FIDO2 as a primary authenticator in the PingOne policy; downstream applications using PingFederate SAML or OIDC inherit passkey enforcement at the IDP layer.
• →Cross-IdP migration caveat: Passkey credentials are bound to the original relying party ID (typically your IdP's domain). If you migrate from one IDP to another, passkeys registered against the original IdP cannot transfer — credentials are by design non-portable. Plan IdP migrations as a passkey re-enrollment event and run parallel IdPs during the transition window.

The Five-Phase Enterprise Passkey Rollout

Enterprise passkey deployments fail when they attempt to migrate the entire organization simultaneously or when they go live before recovery infrastructure is tested. The five-phase model staggers the rollout to learn from low-risk segments before touching high-value ones, and it treats account recovery design as a prerequisite — a step that must be complete before any user is enrolled, not after the first lockout.

• →Phase 1 — Privileged accounts (weeks 1-4): Begin with IT administrators, security engineers, domain admins, and financial approvers. Issue hardware security keys with pre-registered backup keys. These are your highest-value targets — getting them onto phishing-resistant auth immediately reduces the attack surface most likely to result in catastrophic compromise. This phase also stress-tests IDP configuration, attestation verification, and recovery procedures against a population that can self-diagnose problems without a support queue.
• →Phase 2 — Recovery infrastructure (concurrent with Phase 1): Build and test the full account recovery workflow before any user is locked to passkey-only authentication. Required components: backup authenticator registration enforced during enrollment, Temporary Access Pass issuance workflow for device loss (Entra ID TAP or Okta equivalent), manager-confirmation or in-person identity verification before any recovery code is issued, helpdesk training with documented runbooks, and employee-facing recovery documentation in the internal knowledge base.
• →Phase 3 — Managed-device knowledge workers (weeks 5-12): General employees on corporate-managed laptops and phones. Enable synced passkey enrollment or device-bound enrollment via Okta FastPass or Windows Hello for Business. Send enrollment prompts on next login with a clear opt-in period before mandatory enforcement. Target more than 80% voluntary enrollment before making passkeys required for this group — coercive enforcement before the experience is smooth generates helpdesk load and executive pushback.
• →Phase 4 — Shared-workstation and deviceless segments (weeks 13-20): Warehouse floors, call centers, and point-of-sale environments where devices are not personally assigned. These require purpose-built solutions: one hardware security key per employee stored in a secure locker for shared-workstation use, or cross-device authentication via QR code where the employee scans with their personal phone to authenticate on the shared workstation. CTAP2 hybrid transport (supported in all major browsers) enables this second option without additional infrastructure.
• →Phase 5 — Password removal (months 4-12, segment by segment): Remove passwords from a segment only after it has sustained more than 90% passkey authentication for at least 30 days and your helpdesk has processed enough recovery events to validate the process end to end. Remove passwords per-segment, never organization-wide in a single cut-over. Track a residual password population — 5-15% is realistic for 12-18 months — and target it with a dedicated remediation track.

Handling Legacy Applications That Cannot Use WebAuthn Natively

Every enterprise application estate includes systems that cannot speak WebAuthn: mainframes, AS/400 environments, on-premises LDAP applications, VPN clients, and line-of-business software from vendors who have not added FIDO2 support. The integration pattern for all of these is consistent — deploy passkeys at the IDP and federate identity downstream using the legacy application's native protocol. The passkey sits at the front door; everything behind it continues using its existing token.

• →SAML and OIDC applications: Any application using SSO through the IDP gets passkey authentication automatically when the IDP enforces it. No application changes are required. This covers most SaaS tools and many on-premises enterprise applications that were built with federation in mind.
• →Kerberos and on-premises Active Directory: Microsoft Entra Hybrid Join issues a Kerberos TGT for on-premises AD resources after successful FIDO2 authentication against Entra ID. Windows sign-in with a hardware security key grants Kerberos access to domain resources — file shares, internal web applications, and legacy Windows servers — without modifying those resources.
• →LDAP-integrated applications that verify passwords directly: These are the most difficult case. If an application calls LDAP or AD directly with the user's password rather than delegating to an IDP, passkey enforcement at the IDP does not protect this authentication path. Solutions: deploy an application proxy (Cloudflare Access, Zscaler Private Access, or BeyondCorp Enterprise) in front of the application to enforce IDP authentication at the network perimeter, or treat the application as a residual exception with compensating controls — IP allowlisting, network segmentation, and privileged access management coverage for those accounts.
• →VPN clients: Cisco Secure Client, Zscaler Client Connector, and Palo Alto GlobalProtect all support SAML-based authentication via IDP federation. Routing VPN authentication through the IDP makes passkeys available for VPN sessions without changes to the VPN client — only IDP-side configuration is required.

Account Recovery: The Decision That Determines Whether the Deployment Survives

Account recovery is where enterprise passkey deployments most commonly fail operationally. The failure mode is predictable: the deployment launches without a tested recovery process; an executive loses their phone; IT cannot verify identity and restore access quickly; the resulting escalation generates pressure to keep passwords as a fallback. Passwords as a fallback defeat the entire security purpose of passkey deployment — an attacker who phishes the password bypasses the passkey entirely. Recovery design must be completed and tested before the first user is migrated, and the answer must not involve passwords.

• →Mandatory backup authenticator registration: Every user must register at least two authenticators during enrollment — their primary device and a backup (a second personal device or a hardware security key). Enforce this via enrollment policy; do not allow enrollment with a single authenticator. For privileged account users: issue two hardware keys and require both to be registered before the old credentials are deactivated.
• →Temporary Access Passes: Both Microsoft Entra ID and Okta support IT-issued, short-lived recovery credentials that grant a single session for new authenticator registration. The TAP issuance workflow must include verified identity confirmation — manager approval, video call with government ID, or in-person IT check-in — before any TAP is issued. TAPs must be single-use and expire within hours.
• →Synced passkey recovery path: Users with synced passkeys in iCloud or Google have a built-in recovery path through the cloud provider's account recovery flow. If a user gets a new device and restores from backup, passkeys sync automatically. Document this clearly in user guidance — it is a genuine recovery advantage of synced passkeys that partially offsets their weaker security model.
• →What not to accept as recovery: Do not allow recovery via email-only verification — email is compromisable and is a common attack path. Do not use knowledge-based authentication (security questions). Do not accept passwords as a fallback authentication method at any point in the recovery flow — this reintroduces credential phishing risk for every account that has a recovery event.

Measuring Enterprise Passkey Adoption and the Phishing Reduction Signal

Passkey deployments should instrument three metrics from day one: adoption rate (the percentage of authentications using passkeys versus passwords or TOTP across each user segment), recovery rate (how frequently users trigger recovery workflows, which signals friction and potential adoption blockers), and phishing attempt volume against your authentication layer (visible in IDP threat logs and email security platform data). The phishing reduction metric is the one that demonstrates security value to leadership — CISA's data shows phishing-resistant MFA reduces credential theft to near zero for covered accounts. Establish a baseline on all three before the deployment begins, so you can quantify the improvement rather than assert it.

• →Adoption rate target: More than 90% of authentication events using passkeys for a given segment before that segment's passwords are removed. Track per-segment, not organization-wide — the aggregate hides segments that are lagging.
• →Recovery rate interpretation: A recovery rate above 2-3% in the first 90 days indicates either that backup authenticator registration enforcement failed (users enrolled only one authenticator) or that your user communication did not clearly explain the backup enrollment step. Investigate before proceeding to the next rollout phase.
• →Phishing signal: Monitor IDP threat logs for authentication attempts from known phishing infrastructure or from unusual geographic locations. After passkey enforcement, you should see phishing-sourced authentication attempts fail at the WebAuthn layer — they will appear as failed assertion verifications with origin mismatch errors, which is the system working correctly.

Frequently Asked Questions

Does WebAuthn work across all enterprise browsers and operating systems?

As of 2026, WebAuthn is supported in Chrome, Firefox, Safari, and Edge across Windows, macOS, iOS, and Android. There are no major browser gaps for modern operating systems. Chromebook and Linux desktop support is complete as of Chrome 95+. Enterprise environments that enforce older browser versions for compatibility reasons may encounter gaps — validate against your actual browser version distribution before deployment. Internet Explorer is not supported, but IE usage in enterprise is below 1% in most organizations by 2026.

Can passkeys work with our existing SSO and SAML setup?

Yes — and this is the central architectural advantage of IDP-layer deployment. Configure passkeys as the authentication method in your IDP. Any application using SAML or OIDC through that IDP inherits passkey authentication without code changes. The FIDO2 challenge happens at the IDP, the IDP issues tokens downstream, and individual applications do not see or handle WebAuthn credentials directly. Organizations with large application estates can achieve passkey coverage across hundreds of applications through a single IDP configuration change.

What happens when an employee loses their device and cannot authenticate?

An employee who loses their primary device uses their backup authenticator — a pre-registered secondary device or hardware key — to re-authenticate and de-register the lost device. If both authenticators are unavailable simultaneously, IT issues a Temporary Access Pass after verifying the employee's identity through a manager-confirmed or in-person process. The TAP grants a one-time session for new authenticator registration. Under no circumstances should password reset serve as the fallback — this reintroduces credential phishing risk for every account that triggers a recovery event.

Can contractors and external users without managed devices use passkeys?

Yes. Passkeys stored in a user's personal device using their platform authenticator (Face ID, Touch ID, Windows Hello) work for external users accessing applications through SSO, as long as the relying party ID is correctly configured. The operational challenge is enrollment: contractors may not appear in the IDP with self-service enrollment enabled. Configure guest or external user flows that guide contractors through passkey enrollment on first access. For high-security contractor access — code repositories, production infrastructure — issue a FIDO2 hardware security key rather than relying on a personal device.

Does FIDO2 passkey authentication satisfy HIPAA, PCI-DSS, or FedRAMP MFA requirements?

FIDO2 and WebAuthn qualify as phishing-resistant MFA under NIST 800-63B AAL2 and AAL3 (hardware-bound). CISA explicitly recommends FIDO2 as the preferred phishing-resistant MFA tier. For FedRAMP High, hardware-bound FIDO2 keys on FIPS 140-2 Level 2+ validated hardware satisfy AAL3 requirements. For HIPAA, synced passkeys typically satisfy the MFA requirement for covered system access. For PCI-DSS cardholder data environments, hardware-bound passkeys are recommended given the explicit phishing-resistance requirement in PCI DSS v4.0. Confirm specifics with your compliance auditor, as control mapping depends on the exact system classification and data sensitivity.

How Belsoft Helps with Enterprise Authentication Architecture

Deploying passkeys across an enterprise touches identity architecture, IDP configuration, legacy application federation, device management, and organization-wide user experience — in a domain where a misstep locks users out of production systems and a poorly designed recovery workflow generates executive escalations within days. Belsoft's security and scalability practice designs and implements authentication infrastructure for enterprise SaaS products and internal platforms, including FIDO2/WebAuthn integration, IDP configuration hardening, and account recovery design that satisfies compliance requirements without passwords as a residual fallback.

If your organization is planning a passkey rollout or evaluating passwordless authentication for a product you are building, we can scope the architecture and implementation path. Our work spans regulated industries including healthcare, fintech, and legal, where authentication requirements carry compliance weight beyond general best practice. Book a scoping call to discuss your current authentication architecture and where passkeys fit in your security roadmap.

“Passwords are a usability failure that became a security catastrophe. Passkeys fix both — but only if you design the recovery path before the first user is migrated, not after the first lockout.”