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.

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, Azure AD, Ping) added this support in 2023-2024.
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.

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
  const approvedAAGUIDs = [
    "2fc0579f-8113-47ea-b116-bb5a8db9202a",  // YubiKey 5 NFC
    "fa2b99dc-9e39-4257-8f92-4a30d23c4118",  // YubiKey 5 USB-A
    "cb69481e-8ff7-4039-93ec-0a2729a154a8",  // YubiKey 5 USB-C
    // Add other approved AAGUIDs
  ];

  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 may break with firmware updates that change the AAGUID. Use it 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):

<!-- Require Touch ID enrollment -->
<key>RequireTouchID</key>
<true/>

<!-- Allow iCloud Keychain passkey sync (for general workforce) -->
<key>AllowCloudKeychainSync</key>
<true/>

<!-- Minimum firmware version for secure enclave support -->
<key>MinimumOSVersion</key>
<string>14.0</string>

Windows (Intune):

{
  "windowsHelloForBusiness": {
    "state": "enabled",
    "pinMinimumLength": 6,
    "biometricsAllowed": true,
    "enhancedSignInSecurity": true,
    "useSecurityKeys": true
  }
}

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

| Problem | Cause | Solution | |---------|-------|----------| | Passkey not syncing to new device | User not signed into the same cloud account | Verify iCloud/Google account is signed in on both devices | | "No passkeys available" on login | Credential was device-bound, not synced | Register a synced passkey or register separately on each device | | Attestation fails after authenticator firmware update | AAGUID changed in new firmware | Update the approved AAGUID list; consider using FIDO MDS for dynamic lookups | | User cannot register on corporate laptop | Browser or OS version too old | Enforce minimum OS/browser versions via MDM | | Help-desk social engineering during recovery | Weak identity verification | Require video call + manager approval for passkey recovery | | Passkey prompt does not appear | WebAuthn JavaScript not triggered by user gesture | Ensure the API call is in a click handler, not auto-triggered |

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. 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.

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 robust account recovery workflows, leverage 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.

FAQs

Q: Can passkeys completely replace passwords today? A: For most users, yes. The main exceptions are shared workstations without security key support, legacy applications that cannot integrate with the IdP, and edge cases where no biometric hardware is available. Plan for 90-95% coverage at enforcement, with exceptions managed on a case-by-case basis.

Q: What happens to passkeys when an employee leaves? A: Disable the employee's IdP account. The passkeys become useless because they are bound to your domain (RP ID). The ex-employee may still have the credentials on their device, but they cannot use them to authenticate since the IdP rejects the account.

Q: Are passkeys compliant with regulations (SOX, HIPAA, PCI-DSS)? A: Yes. Passkeys meet or exceed the authentication requirements of all major compliance frameworks. FIDO2/WebAuthn is recommended by NIST (SP 800-63B AAL2 and AAL3), and the phishing resistance it provides often exceeds what auditors expect.

Q: How do passkeys work on shared devices (kiosks, conference rooms)? A: Use hardware security keys (YubiKey, Feitian) that users carry with them and badge into the shared device. Alternatively, use the cross-device authentication flow where the user scans a QR code on the shared device's screen with their phone.

Q: Should I use attestation? A: For general workforce, no — it adds complexity without proportional benefit. For privileged users in regulated environments, yes — it ensures only approved hardware authenticators are registered.