The Challenge
Your organization needs to eliminate password-based attacks, but you're caught between two costly options: distributing hardware tokens to every user or continuing to rely on passwords, which remain a weak link in your security chain.
The FIDO Alliance has promoted passwordless authentication through FIDO2 standards since 2018. Early implementations required issuing physical Multi-Factor Cryptographic Devices to employees. For a 5,000-person organization, this means dealing with procurement, shipping, replacements, and help desk support for lost or broken tokens. Keeping passwords as a fallback leaves you vulnerable to phishing attacks targeting that legacy path.
Organizations implementing FIDO2 with hardware tokens face a dilemma: accept the operational burden or compromise security by maintaining password-based recovery flows. Neither option meets the core requirement: phishing-resistant authentication that scales without increasing support costs.
The Environment and Constraints
The technical environment complicates the issue. Many enterprises use hybrid identity architectures where Active Directory manages on-premises resources, while cloud applications use OAuth 2.0 and WS-Federation protocols. Any authentication change must work across both environments without disrupting existing configurations or causing multiple login prompts.
Your constraints include:
- User diversity: Remote workers without office access, contractors on personal devices, executives who won't carry separate authenticators
- Application coverage: Legacy apps supporting only username/password, modern SaaS with FIDO2 support, internal tools with custom authentication
- Recovery requirements: Users must regain access without reverting to password reset flows that reintroduce phishing risks
- Compliance mandates: Auditors expect phishing-resistant authentication for privileged access, not just improvements over passwords
The FIDO Alliance's push for passkeys addresses these constraints by embedding the cryptographic authenticator in devices like laptops, phones, or tablets. No separate hardware is needed. The private key stays on the device, and the public key registered with your identity provider can't be phished because there's no shared secret to steal.
The Approach Taken
Implementing passkeys requires changes to your authentication flows, not just enabling a feature.
Start with high-risk targets, not a universal rollout. Focus on user groups where phishing risk justifies the effort: privileged access accounts, finance teams handling wire transfers, executives targeted in email compromise attacks. These groups need phishing-resistant authentication immediately, and they're small enough to manage without overwhelming your help desk.
Map your authentication paths. Document every authentication method: VPN access, cloud SSO, direct application login, privileged access management sessions. For each, determine if the application supports FIDO2 (WebAuthn API), requires OAuth 2.0 Authorization Code Flow with device-bound credentials, or needs a session broker to convert legacy authentication into passkey-compatible flows.
Configure device registration carefully. When a user registers a passkey, the private key binds to that specific device. You need policies for:
- Multi-device registration: Users should register passkeys on both their laptop and phone to avoid lockouts if a device is lost
- Device attestation: Verify that the passkey comes from a trusted platform (iOS Keychain, Windows Hello, Android Keystore) and not a software emulator
- Registration ceremony security: Require existing authentication before allowing passkey registration to prevent account takeover during setup
Eliminate password fallbacks gradually. The security benefit disappears if users can bypass passkeys by clicking "forgot password." Disable password authentication for migrated accounts, but maintain a secure recovery path: require manager approval plus a temporary hardware token for account recovery, or use Just-in-Time Elevation to restore access through a separate privileged workflow.
Test federation edge cases. Passkeys work well for direct authentication, but federated scenarios add complexity. If your Service Provider expects a SAML assertion with specific attributes, verify that your Identity Provider includes those attributes when the user authenticates with a passkey. Test Back-Channel Communication flows where the application validates the session without front-end redirects.
Results and Metrics
Organizations moving from passwords to passkeys report measurable security improvements, though specific outcomes depend on implementation scope and user population characteristics.
The FIDO Alliance's research shows that phishing-resistant authentication eliminates credential theft attacks that trick users into entering passwords on fake login pages. The cryptographic challenge-response protocol used by FIDO2 verifies the relying party's identity before releasing credentials, so even a perfect phishing site can't complete authentication.
Operational metrics shift noticeably. Password reset tickets drop because users can't forget a passkey stored in their device's secure enclave. Account lockouts from failed password attempts disappear. Help desk time previously spent on "I forgot my password" moves to device registration support and "I lost my phone" recovery requests.
The tradeoff: device dependency becomes a single point of failure. If a user's laptop dies and their phone is at home, they can't authenticate until they retrieve a registered device or complete your recovery workflow. This is why multi-device registration isn't optional, it's a reliability requirement.
What They Would Do Differently
Early passkey implementations treated device registration as a one-time setup event. That's a mistake. Devices break, get replaced, and fall out of compliance. You need continuous registration management:
- Automated nudges when a user has only one registered device
- Compliance checks that flag devices running outdated operating systems that can't maintain secure enclaves
- Deprovisioning workflows that revoke passkeys when devices leave your MDM inventory
Another lesson: don't assume users understand the security model. "Your login is now tied to your device" sounds simple until a user tries to authenticate from a borrowed laptop and can't. Training should cover what happens when they lose a device, how to register a new one, and why they can't share passkeys like they used to share passwords.
Federation complexity surprised several implementation teams. Applications that worked fine with password-based SAML suddenly failed with passkey authentication because the Identity Provider sent different assertion attributes or used a different Subject identifier format. Test your federation metadata configurations thoroughly before migrating production users.
Takeaways for Your Team
Passkeys solve the phishing problem, not the access governance problem. You still need Role Engineering to prevent over-privileged accounts, Certification Campaigns to review entitlements, and Compliance Reporting to prove who accessed what. Phishing-resistant authentication protects the authentication ceremony; it doesn't replace your Identity Governance and Administration architecture.
Plan for a multi-year transition, not a forklift upgrade. Legacy applications won't support FIDO2 immediately. You'll run hybrid authentication for years, which means maintaining expertise in both password-based flows and passkey protocols. Budget for that complexity.
Device management becomes identity management. If authentication depends on devices, your MDM policies, device compliance checks, and hardware refresh cycles directly impact authentication availability. Coordinate with your endpoint management team before you commit to passkeys.
Recovery workflows need as much design attention as registration. The worst time to discover your recovery process doesn't work is when an executive loses access before a board meeting. Document, test, and drill your recovery procedures with the same rigor you apply to disaster recovery.
The FIDO Alliance's vision of a passwordless future is technically sound and operationally achievable, but it requires rethinking authentication as a device-bound capability rather than a knowledge-based credential. If you're still treating passwords as your primary authentication factor, you're accepting phishing risk that the technology to eliminate it already exists.
