Passkey Rollout: Deployment Guide for Enterprise IAM

Your users will encounter passkey prompts whether you're ready or not. Google, Microsoft, and Apple are pushing FIDO2-based authentication across their platforms, and your enterprise identity stack needs a plan before users start creating passkeys in consumer accounts that you can't govern.

This guide walks you through deploying passkeys in a controlled enterprise environment. You'll configure FIDO2 authentication, integrate it with your existing Identity Provider, and establish governance controls to prevent shadow enrollment.

The Problem: Consumer Passkey Adoption Is Outpacing Enterprise Governance

The FIDO Alliance has spent over a decade building the standards that make passkeys work. Now that major platforms support them, your users are creating passkeys for personal Gmail and Microsoft accounts using the same devices they use for work.

Here's what makes this urgent: passkeys stored in consumer password managers (iCloud Keychain, Google Password Manager) live outside your MDM policies and identity governance controls. When a user leaves, you can't revoke those credentials. When they authenticate to a SaaS app using a passkey synced through their personal Apple ID, you have no visibility into that authentication event in your SIEM.

Deploying enterprise-managed passkeys solves this. You control the authenticator lifecycle, enforce device compliance policies, and maintain audit trails that survive user departures.

What You Need Before Starting

Identity Infrastructure:

• An Identity Provider that supports FIDO2 (Okta, Microsoft Entra ID, Ping Identity, or Auth0)
• A user directory with active accounts (Active Directory, LDAP, or cloud directory)
• SAML or OAuth 2.0 federation configured for your target applications

Device Management:

• MDM solution deployed to corporate devices (Intune, Jamf, Workspace ONE)
• Device compliance policies defined (OS version, encryption, patch level)
• Ability to push configuration profiles to managed devices

Technical Requirements:

• HTTPS endpoints for your Identity Provider (FIDO2 requires TLS)
• User devices running supported operating systems (Windows 10 1903+, macOS Ventura+, iOS 16+, Android 9+)
• Access to your IdP's admin console with privileges to modify authentication policies

Governance Decisions:

• Which user populations will get passkeys first (start with IT and security teams)
• Whether passkeys will be optional, preferred, or required
• Fallback authentication methods (TOTP, SMS, or Multi-Factor Cryptographic Device)
• Attestation requirements (do you need to verify the authenticator model?)

Step-by-Step Implementation

Phase 1: Configure Your Identity Provider

For Microsoft Entra ID:

1. Navigate to Azure Portal → Entra ID → Security → Authentication methods
2. Enable FIDO2 security key under Method policies
3. Set Attestation enforcement to "Required" if you need to restrict authenticator types
4. Define allowed FIDO2 key types using the AAGUIDs from your approved vendor list
5. Assign the policy to your pilot user group

For Okta:

1. Go to Security → Authenticators → Add Authenticator
2. Select "Security Key or Biometric Authenticator (FIDO2 WebAuthn)"
3. Configure attestation: choose "Direct" for full device verification
4. Edit your authentication policy to include FIDO2 as an allowed factor
5. Set enrollment requirements: "Optional" for pilot, "Required" for production rollout

For Ping Identity:

1. Access PingOne admin console → Authentication → Authentication Policies
2. Create a new policy or edit existing
3. Add FIDO2 as an authentication method
4. Configure registration flow: enable "User self-service enrollment"
5. Set relying party ID to match your domain

Phase 2: Deploy to Pilot Users

Create a pilot group of 20-50 users from your IT organization. These users will surface edge cases before you expand.

Enrollment Process:

1. Send pilot users to your IdP's self-service portal
2. Guide them to Security Settings → Authentication Methods
3. Click "Add passkey" or "Register FIDO2 device"
4. The browser will prompt for platform authenticator (Face ID, Windows Hello, Touch ID) or external authenticator
5. User completes biometric or PIN verification
6. Passkey is registered and appears in their authentication methods list

Test Authentication Flow:

1. Have pilot users sign out completely
2. Navigate to a SAML-federated application
3. Redirect to IdP login page
4. Enter username (or skip if using discoverable credentials)
5. Browser prompts for passkey authentication
6. User verifies with biometric or device PIN
7. User lands in target application without entering a password

Phase 3: Configure Conditional Access

Lock down where and how passkeys can be used.

Microsoft Entra ID Conditional Access:

Policy: Require Compliant Device for Passkey Enrollment
- Users: All users
- Cloud apps: Microsoft Entra ID user registration
- Conditions: User actions → Register security information
- Grant: Require device to be marked as compliant

Okta Device Trust Policy:

1. Navigate to Security → Device Trust
2. Create policy: "Passkey Enrollment Requires Managed Device"
3. Set condition: Device management state = Managed
4. Apply to authentication policy controlling FIDO2 enrollment

This prevents users from enrolling passkeys on unmanaged personal devices.

Phase 4: Expand Deployment

After two weeks with the pilot group:

1. Review authentication logs for FIDO2 events
2. Check for failed enrollments or authentication attempts
3. Interview pilot users about friction points
4. Document common support questions

Then expand in phases:

• Week 3-4: IT department (200-500 users)
• Week 5-6: Security and compliance teams
• Week 7-8: Executive leadership
• Week 9+: General user population in batches of 1,000

For each phase, send communication 48 hours before enabling the policy. Include screenshots of the enrollment flow and a FAQ covering device compatibility.

Validation: How to Verify It Works

Test Authentication Success:

Run these tests with a pilot user account:

1. Authenticate to your IdP directly using a passkey
2. Access a SAML-federated SaaS application (confirm single sign-on works)
3. Access an OAuth 2.0 application (verify Authorization Code Flow completes)
4. Test from multiple device types (Windows laptop, macOS, iPhone)

Verify Audit Trails:

Check your SIEM for these events:

• FIDO2 enrollment events (source: IdP audit log)
• Successful FIDO2 authentications with device metadata
• Failed authentication attempts (wrong device, user cancelled)
• Passkey revocation events

Query your IdP's audit API for FIDO2-specific event types. In Microsoft Entra ID, filter for "Register security info" and "User authenticated using FIDO2." In Okta, search for system.authenticator.lifecycle.enroll and policy.evaluate_sign_on.

Confirm Governance Controls:

1. Remove a test device from MDM
2. Verify the user can't enroll new passkeys on that device
3. Confirm existing passkeys on non-compliant devices are blocked from authentication
4. Test passkey revocation: delete a user's passkey from the IdP, confirm they can't authenticate

Check Fallback Methods:

Disable a user's passkey and verify they can still authenticate using your defined fallback (TOTP, SMS, or hardware token). Never deploy passkeys as the only authentication method until you've tested account recovery flows.

Maintenance and Ongoing Tasks

Monthly:

• Review passkey enrollment rates by department
• Identify users with multiple passkeys and validate each device is managed
• Audit users still authenticating with passwords; send targeted enrollment reminders
• Check for deprecated authenticator models (reference FIDO Alliance metadata)

Quarterly:

• Review attestation reports to identify unauthorized authenticator types
• Update allowed AAGUID list based on new approved devices
• Test disaster recovery: can you restore passkey registrations from backup?
• Audit Conditional Access policies for gaps (unmanaged devices, legacy authentication)

Annually:

• Rotate FIDO2 server certificates
• Review and update authentication policy based on threat landscape
• Evaluate new FIDO2 features (discoverable credentials, large blob storage)
• Conduct tabletop exercise: what happens if your IdP's FIDO2 service fails?

User Lifecycle Events:

When a user leaves:

1. Revoke all registered passkeys immediately (same day as termination)
2. Verify revocation appears in audit log
3. Confirm the user can't authenticate using cached credentials

When a device is lost:

1. User reports loss through helpdesk
2. Admin locates passkey by device identifier in IdP console
3. Delete the specific passkey
4. User enrolls replacement passkey on new device

Support Escalations:

Build a runbook for common issues:

• "Passkey prompt doesn't appear" → Check browser version, verify HTTPS, confirm FIDO2 enabled in policy
• "This device can't be used" → Validate device compliance state in MDM
• "I deleted my passkey by accident" → Guide user through re-enrollment, verify old passkey is revoked
• "Passkey works on laptop but not phone" → Check cross-platform authenticator sync settings, confirm both devices are managed

The FIDO Alliance provides implementation guidance and a conformance test suite at fidoalliance.org. Use their tools to validate your server configuration before production rollout.

Your users are going to use passkeys. The question is whether they'll use ones you control or ones synced through consumer accounts you can't see. Deploy now, govern tightly, and you'll eliminate password resets while strengthening your authentication posture.