You've read the vendor whitepapers. Passkeys eliminate phishing, improve user experience, and align with FIDO2 standards. The business case looks solid.
Then you brief your architecture team, and the objections start: "Our apps can't handle FIDO2 natively." "Users will lose their devices." "We can't touch the source code on that legacy banking platform." "What about our audit trails?"
These concerns aren't wrong, but they're often based on outdated assumptions about how passkey deployment actually works. A recent FIDO Alliance webinar featuring Bartosz Cieszewski from Secfense detailed a real enterprise rollout at a major European bank serving 1.5 million users. The project introduced passkeys alongside existing authentication methods without modifying the banking application's source code, and it's currently running in a controlled production environment.
What makes this case study valuable isn't just that it worked. It's that the deployment addressed exactly the myths that stop most enterprises from moving forward.
Myth 1: You Need to Modify Your Application Code
Reality: Passkeys can be deployed without touching your application source code.
The most persistent myth is that FIDO2 support requires native integration in every application. This stops projects before they start, especially when you're dealing with legacy systems, vendor-managed applications, or codebases with complex change control processes.
The European bank deployment used an authentication broker architecture that sits between users and applications. The broker handles FIDO2 authentication, then translates the session into whatever authentication method the downstream application expects (typically session cookies or tokens). From the application's perspective, nothing changed. From the user's perspective, they're authenticating with a passkey.
This architectural pattern isn't new. You're already using similar approaches with Single Sign-On (SSO) gateways and reverse proxies. The difference is that you're now intercepting authentication flows to inject phishing-resistant credentials instead of just federating existing ones.
Myth 2: Users Will Lose Their Passkeys and Lock Themselves Out
Reality: Enterprise passkey deployment requires a recovery strategy, not a perfect one.
The fear of account lockout drives many teams to reject passwordless authentication entirely. If someone loses their device, how do they recover access?
This concern conflates consumer passkey models with enterprise deployment. In a consumer context, you might rely on device sync or account recovery flows controlled by the relying party. In an enterprise, you control the recovery process.
Practical recovery options include:
- Temporary fallback to existing authentication methods during transition periods
- Help desk workflows that verify identity through existing channels before re-enrolling passkeys
- Backup authentication factors (like TOTP or hardware security keys) registered during initial enrollment
- Device management policies that pre-register corporate devices as trusted authenticators
The webinar emphasized that the bank didn't eliminate existing authentication methods immediately. They're running passkeys alongside traditional credentials during the rollout, which means users have a fallback if something goes wrong. This isn't a weakness in the deployment, it's a pragmatic rollout strategy.
Myth 3: Passkeys Break Your Audit and Compliance Requirements
Reality: Passkey authentication generates better audit trails than passwords.
Security and compliance teams worry that moving away from traditional credentials will create gaps in audit logs or violate regulatory requirements. This concern gets the risk backwards.
FIDO2 authentication produces cryptographic proof of authentication that includes the authenticator used, the relying party, and timing information. You can log which specific device authenticated, when, and from where. Compare this to password authentication, where your logs show "user authenticated successfully" with no proof that the person entering the password was actually the account owner.
For enterprises subject to eIDAS, PSD2, or similar regulations requiring strong customer authentication, passkeys meet the technical requirements more cleanly than most password-plus-SMS implementations. The cryptographic binding between the authenticator and the user provides non-repudiation that passwords fundamentally cannot.
The compliance question isn't whether passkeys meet audit requirements. It's whether your authentication broker logs the right metadata and integrates with your SIEM properly. That's an implementation detail, not a fundamental limitation.
Myth 4: You Can't Roll Out Passkeys Gradually
Reality: Controlled rollout is the only sensible deployment strategy.
Some teams treat passkey deployment as an all-or-nothing decision: either everyone switches at once, or you can't start. This creates a false choice that delays projects indefinitely.
The bank's deployment is running in a controlled production environment precisely because gradual rollout reduces risk. You can target specific user populations (IT staff first, then high-risk roles, then general users), specific applications (start with internal tools before touching customer-facing systems), or specific use cases (maybe you enable passkeys for VPN access before you touch email).
This approach also gives you time to measure what matters: authentication success rates, support ticket volume, user satisfaction, and time-to-authenticate. If passkeys increase friction for a specific user segment, you learn that during a limited rollout instead of after you've forced the change on everyone.
Gradual rollout isn't a compromise. It's how you deploy any authentication change in a large enterprise without creating an incident.
Myth 5: Passkeys Are Only for Consumer Applications
Reality: Enterprise passkey deployment solves problems consumer rollouts don't face.
The consumer narrative around passkeys focuses on convenience and eliminating passwords. That's not the enterprise value proposition.
In an enterprise context, you're solving for phishing-resistant authentication across a heterogeneous application portfolio, often with regulatory requirements, legacy systems, and complex identity governance processes. The fact that passkeys also improve user experience is a bonus, not the primary driver.
The bank deployment demonstrates this clearly. They're not replacing passwords to make login easier (though it does). They're deploying phishing-resistant authentication because credential phishing is a material risk, and traditional Multi-Factor Authentication (MFA) methods like SMS or push notifications don't prevent it.
Enterprise passkey deployment also requires integration with existing Identity Governance and Administration (IGA) systems, support for Privileged Access Management (PAM) workflows, and compatibility with device management policies. None of these concerns exist in consumer deployments, but all of them are non-negotiable in enterprise environments.
What to Do Instead
If you're evaluating passkey deployment, focus on these concrete steps:
Map your authentication flows. Identify which applications authenticate users directly versus which rely on federated identity. The latter are easier to protect with passkeys because you can deploy at the Identity Provider (IdP) layer.
Start with high-value targets. Deploy passkeys first for privileged users, VPN access, or applications that handle sensitive data. These use cases justify the implementation effort and demonstrate security value quickly.
Design your recovery process before you start enrollment. Don't wait until someone loses a device to figure out how they regain access.
Measure authentication success rates. If passkey authentication fails more often than your existing methods, you've introduced friction without improving security. Instrument your flows so you can detect problems early.
The European bank didn't deploy passkeys because the technology was mature. They deployed passkeys because they had a specific security problem (credential phishing) and a deployment architecture (authentication broker) that let them solve it without rewriting applications. That's the model to follow.
