Implementing Passkeys in the Enterprise

Passkeys represent the most significant shift in enterprise authentication since the introduction of SSO. Built on the FIDO2/WebAuthn standard, passkeys replace passwords with cryptographic credentials that are phishing-resistant, require no memorization, and deliver a faster login experience than traditional methods. Apple, Google, and Microsoft have all committed to passkey support across their platforms, making broad adoption inevitable. For the basics first, see passkeys 101 and what is passwordless.

Yet enterprise passkey deployment is different from consumer deployment. Enterprises must manage device policies, attestation requirements, account recovery at scale, and the coexistence of passkeys with existing authentication methods during transition. This guide addresses the enterprise-specific challenges of passkey implementation.

What You Will Learn

• How passkeys differ from traditional FIDO2 security keys in an enterprise context
• Configuring WebAuthn for enterprise requirements (attestation, allowed authenticators)
• Designing account recovery workflows that do not undermine passkey security
• Managing passkeys on corporate-managed devices
• Planning a gradual rollout from pilot to full enforcement

Prerequisites

1. SSO infrastructure, Passkeys should be deployed at the IdP level to cover all federated applications. Ensure SSO is in place.
2. IdP passkey support, Verify your IdP supports FIDO2/WebAuthn and passkeys. Most major IdPs (Okta, Microsoft Entra ID, Ping Identity) support it today.
3. Device management, An MDM solution (Intune, Jamf, Workspace ONE) for managing passkey-related policies on corporate devices.
4. User communication plan, Passkeys change the login experience fundamentally. Users need clear, advance communication.
5. Help-desk procedures, Updated account recovery and credential reset procedures for the passkey model.

Choosing a passkey provider

Most enterprises deploy passkeys through the IdP they already run. Okta (FastPass), Microsoft Entra ID, and Ping Identity all support FIDO2/WebAuthn passkeys natively, and for high-assurance roles you pair them with hardware security keys such as YubiKey.

If passkeys are core to your customer or workforce experience rather than one factor among many, specialist passwordless providers can shorten the build:

• Transmit Security offers a passwordless-first platform with passkey issuance, device binding, and risk signals, aimed at organizations that want passkeys plus fraud and identity-verification capabilities in one stack.
• MojoAuth provides a developer-friendly passwordless and passkey API (passkeys, magic links, OTP) that lets teams add phishing-resistant login quickly without building the WebAuthn plumbing themselves.

Both target application and customer identity (CIAM); for workforce SSO, deploy passkeys at your existing IdP. For a broader shortlist see best passwordless CIAM providers and the MFA and passwordless vendor directory.

Architecture Overview

Enterprise passkey architecture builds on the standard WebAuthn model with additional enterprise controls:

• Identity Provider (IdP): The WebAuthn Relying Party. Handles passkey registration, authentication, and lifecycle management.
• Platform authenticator: The user's device (MacBook with Touch ID, Windows PC with Windows Hello, iPhone/Android with biometrics) that creates and stores passkeys.
• Passkey sync fabric: Apple's iCloud Keychain, Google Password Manager, or a third-party credential manager that syncs passkeys across the user's devices.
• MDM/UEM: Manages device policies including which authenticators are allowed, whether passkey sync is permitted, and attestation requirements.
• FIDO Metadata Service (MDS): An optional service that provides metadata about authenticator models, enabling attestation-based policies.

Enterprise-specific considerations:

Synced passkeys introduce a dependency on the user's personal cloud account (Apple ID, Google Account). In a corporate context, this means:

• The security of passkeys is partly dependent on the user's personal account security.
• If the user leaves the organization, their passkeys travel with them (but become useless once the IdP account is disabled).
• IT cannot remotely wipe a synced passkey from the user's personal cloud.

For environments requiring the highest security assurance, device-bound passkeys (hardware security keys or non-synced platform credentials) remain the gold standard.

Step-by-Step Implementation

Step 1: Define Your Passkey Policy

Before any technical work, define clear policies:

passkey_policy:
  general_workforce:
    allowed_credential_types:
      - synced_passkey        # iCloud Keychain, Google Password Manager
      - platform_authenticator # Device-bound
      - security_key          # YubiKey, etc.
    minimum_credentials: 2     # At least 2 passkeys per user
    attestation_required: false
    sync_allowed: true

  privileged_users:
    allowed_credential_types:
      - security_key           # Hardware-bound only
      - platform_authenticator # Device-bound, no sync
    minimum_credentials: 2
    attestation_required: true
    sync_allowed: false
    approved_authenticators:
      - "YubiKey 5 Series"
      - "YubiKey 5 FIPS Series"

  shared_workstation_users:
    allowed_credential_types:
      - security_key           # Must be portable
    minimum_credentials: 2
    attestation_required: true
    sync_allowed: false

Step 2: Configure WebAuthn at the IdP

Configure your IdP's WebAuthn settings to enforce your policy:

Registration options for general workforce:

const registrationOptions = {
  rp: {
    name: "Contoso Corp",
    id: "contoso.com"
  },
  authenticatorSelection: {
    residentKey: "required",      // Discoverable credential (passkey)
    userVerification: "required",  // Biometric or PIN
    // Do NOT set authenticatorAttachment to allow both platform and cross-platform
  },
  attestation: "none",  // No attestation for general users
  pubKeyCredParams: [
    { type: "public-key", alg: -7 },   // ES256
    { type: "public-key", alg: -257 }  // RS256
  ],
  excludeCredentials: existingCredentials,  // Prevent duplicates
  extensions: {
    credProps: true  // Request credential properties
  }
};

Registration options for privileged users:

const privilegedRegistrationOptions = {
  rp: {
    name: "Contoso Corp",
    id: "contoso.com"
  },
  authenticatorSelection: {
    residentKey: "required",
    userVerification: "required",
    authenticatorAttachment: "cross-platform"  // Security keys only
  },
  attestation: "direct",  // Require attestation
  pubKeyCredParams: [
    { type: "public-key", alg: -7 }  // ES256 only (YubiKey native)
  ],
  excludeCredentials: existingCredentials
};

Step 3: Implement Attestation Verification

For privileged users, verify that the authenticator is an approved model:

async function verifyAttestation(registrationResponse) {
  const { fmt, attStmt, authData } = parseAttestationObject(
    registrationResponse.attestationObject
  );

  // Extract the AAGUID from authData
  const aaguid = extractAAGUID(authData);

  // Check against approved authenticator list. Populate it from the
  // vendor's published AAGUID list or the FIDO Metadata Service,
  // never from memory: AAGUIDs differ by model and firmware.
  const approvedAAGUIDs = await loadApprovedAAGUIDs();

  if (!approvedAAGUIDs.includes(aaguid)) {
    throw new Error('Authenticator not in approved list');
  }

  // Verify the attestation signature
  if (fmt === "packed") {
    await verifyPackedAttestation(attStmt, authData, registrationResponse.clientDataJSON);
  } else if (fmt === "tpm") {
    await verifyTPMAttestation(attStmt, authData, registrationResponse.clientDataJSON);
  }

  return { verified: true, aaguid };
}

Note: Attestation verification adds complexity and can break when a vendor ships a new model or firmware with a new AAGUID. Yubico, for example, issues new AAGUIDs for new FIDO2 products and when FIDO2 features are added or removed, and points to its support article for the full list. Use attestation only where the security requirement justifies the operational overhead.

Step 4: Build Account Recovery Workflows

Account recovery is the most critical enterprise passkey challenge. If a user loses all their passkeys, they need a secure way to regain access without undermining the phishing resistance that passkeys provide.

Recovery approach 1: Multiple registered passkeys Require every user to register at least two passkeys on different devices or authenticators. If one is lost, the other provides access.

Recovery approach 2: Temporary access pass The IT help-desk issues a time-limited, single-use access pass after verifying the user's identity through an out-of-band channel.

// Admin API: Generate temporary access pass
async function generateTemporaryAccessPass(userId) {
  const tap = {
    userId: userId,
    code: generateSecureRandom(8).toString('hex'),  // 16-character hex code
    expiresAt: new Date(Date.now() + 30 * 60 * 1000),  // 30 minutes
    singleUse: true,
    purpose: "passkey_recovery"
  };

  await storeTAP(tap);
  return tap.code;

  // The help-desk reads this code to the user over the phone
  // or sends it via a verified communication channel
}

// Login handler: Accept TAP
app.post('/auth/tap-login', async (req, res) => {
  const { userId, tapCode } = req.body;
  const tap = await getTAP(userId, tapCode);

  if (!tap || tap.expiresAt < new Date() || tap.used) {
    return res.status(401).json({ error: 'Invalid or expired access pass' });
  }

  // Mark TAP as used
  await markTAPUsed(tap.id);

  // Create session with limited scope: user must register a new passkey
  const session = await createLimitedSession(userId, {
    allowedActions: ['register_passkey'],
    expiresIn: '15m'
  });

  res.json({ sessionToken: session.token, action: 'register_passkey' });
});

Recovery approach 3: Manager approval The user requests access recovery through a self-service portal. Their manager receives an approval request via email or Slack. Upon manager approval, the user receives a temporary access pass.

Critical rule: Recovery must lead to passkey re-enrollment. Any recovery mechanism must force the user to register a new passkey before accessing applications. Never allow the recovery mechanism to become a permanent alternative to passkeys.

Step 5: Configure MDM Policies

For corporate-managed devices, configure MDM policies to support passkey deployment:

macOS (Jamf/Intune):

• Enforce a minimum macOS version that your IdP and browsers support for passkeys, and require Touch ID enrollment during device onboarding.
• Decide per user tier whether iCloud Keychain sync is allowed on managed Macs, using the restriction payloads your MDM exposes. Check Apple's device management documentation for the exact keys rather than copying them from examples.

Windows (Intune):

• Enable Windows Hello for Business with a PIN policy and biometrics, and allow FIDO2 security keys for sign-in where shared or privileged workstations need them.
• Use the settings catalog in Intune rather than hand-built JSON, so the policy matches the current schema.

Mobile (iOS/Android):

• Ensure biometric enrollment is required as part of device onboarding.
• For BYOD, use app-level passkey management rather than device-level policies.

Step 6: Plan the Gradual Rollout

Month 1, Preparation:

• Configure IdP passkey settings
• Update help-desk procedures
• Create user training materials
• Order hardware security keys for privileged users

Month 2, Pilot (IT + Security teams, 50-100 users):

• Enable passkey registration as optional
• Monitor registration rates and help-desk tickets
• Refine documentation based on feedback

Month 3, Early Adopters (500-1000 users):

• Promote passkey registration with in-app prompts
• Offer drop-in sessions for hands-on registration help
• Track metrics: registration rate, authentication success rate, help-desk volume

Month 4-5, Broad Enrollment:

• Enable passkey registration prompts for all users
• Set a grace period: "Register a passkey by [date]"
• Enforce minimum 2 passkeys per user

Month 6, Enforcement:

• Require passkey authentication for all users
• Disable password-only login
• Maintain break-glass procedures for emergencies

Configuration Best Practices

• Require discoverable credentials. Set residentKey: "required" to enable the username-less passkey experience. Non-discoverable credentials cannot be found without the user providing an identifier first.
• Allow both platform and cross-platform authenticators. Unless policy restricts to security keys only, leave authenticatorAttachment unset to support the broadest range of devices.
• Set credential display names. When users register a passkey, prompt them to name it ("Work MacBook," "Personal iPhone") so they can identify credentials in their management UI.
• Monitor credential counts. Alert when a user has fewer than 2 active credentials. Prompt them to register a backup.
• Automate credential cleanup. When an employee offboards, disable their IdP account. The passkeys become inert since they are bound to the RP ID and cannot be used at another Relying Party.

Testing and Validation

1. Cross-platform registration: Register passkeys on macOS (Touch ID), Windows (Windows Hello), iOS (Face ID), Android (fingerprint), and a hardware security key. Verify all work for login.
2. Cross-device authentication: Register a synced passkey on an iPhone and verify it is available for login on a Mac and iPad signed into the same iCloud account.
3. QR-code cross-device flow: On a desktop without a registered passkey, verify that the browser offers a QR code that the user can scan with their phone to authenticate.
4. Account recovery: Simulate user losing all passkeys. Walk through the full recovery flow: identity verification, temporary access pass, new passkey registration.
5. Attestation enforcement: For privileged user flow, attempt registration with an unapproved authenticator and verify it is rejected.
6. Offboarding: Disable a user's IdP account and verify that their passkeys can no longer authenticate.

Common Pitfalls and Troubleshooting

Security Considerations

1. Synced passkey trust model. Synced passkeys depend on the security of the user's cloud account (Apple ID, Google Account). If an attacker compromises the cloud account, they can access the synced passkeys. NIST SP 800-63B-4, final since July 2025, allows syncable authenticators "for applications that seek to implement up to AAL2" and rules them out at AAL3, which requires a non-exportable private key. For high-security roles, mandate device-bound credentials (hardware security keys).
2. Phishing resistance is the primary value. The reason to deploy passkeys is that they are origin-bound and cannot be phished. Never undermine this by offering fallback authentication methods (like SMS OTP) that are phishable. During the transition, accept the fallback risk but set a firm deadline for deprecating weak methods.
3. Lost credential recovery is the attack surface. Attackers will target the recovery workflow. Make recovery deliberately difficult: require multi-channel identity verification, manager approval, and mandatory re-enrollment.
4. Credential theft at the IdP. The IdP stores public keys, not private keys, so a breach of the IdP database does not compromise passkeys. However, the IdP's authentication logic is still critical, a compromised IdP could be modified to accept any credential.
5. Insider threat. A user with legitimate passkeys has legitimate access. Passkeys do not protect against insider threats. Pair passkey authentication with authorization controls, monitoring, and DLP.

Passkey platforms and vendors

Beyond the workforce IdPs covered in "Choosing a passkey provider" above (Okta FastPass, Microsoft Entra ID, Ping Identity, paired with YubiKey hardware keys), these platforms support passkeys and are worth evaluating depending on where identity sits in your stack.

Customer identity (CIAM) with passkeys:

• Auth0 provides passkeys and WebAuthn with adaptive MFA and attack protection in a broad, extensible platform, with Organizations for B2B multi-tenancy.
• MojoAuth is a developer-first passwordless and passkeys platform that also acts as an OIDC and SAML identity provider, so one project can add passkey login and app SSO quickly with transparent pricing.
• Descope offers a visual, no-code flow builder with passkeys first-class, useful for iterating on enrollment and step-up journeys without redeploying code.
• Stytch is an API-first platform with passkeys, strong session control, and device-fingerprinting fraud prevention.
• Microsoft Entra External ID is Microsoft's customer identity product (distinct from Active Directory) with passwordless and passkey support for external users.

B2B SaaS enterprise SSO (add passkeys alongside enterprise SSO and SCIM):

• WorkOS pairs AuthKit passkeys and magic links with enterprise SSO, SCIM directory sync, and a customer admin portal.
• SSOJet focuses on enterprise SSO and SCIM provisioning for B2B products, with a self-service onboarding flow for customer administrators.

Phishing-resistant workforce and hardware:

• HYPR and Beyond Identity deliver device-bound, phishing-resistant passwordless for the workforce, with desktop login and device trust.

For a scored shortlist, see the best passwordless CIAM providers ranking, and for self-hostable options, the top open-source MFA and passwordless tools.

Conclusion

Passkeys are the future of enterprise authentication. They eliminate the largest attack vector, phishable credentials, while delivering a faster, simpler user experience. The enterprise implementation challenges are real but manageable: define clear policies by user tier, build resilient account recovery workflows, use MDM for device management, and roll out gradually with strong communications.

Organizations that move early gain a security advantage and reduce their attack surface immediately. The technology is ready, the platform support is universal, and the user experience is superior. The only barrier is organizational will.