Most passwordless initiatives measure the wrong thing. The success metric most programs use — percentage of logins that are passwordless — tells you how much of your user experience changed, but it doesn’t tell you how much of your credential attack surface has actually closed. Those are different questions, and conflating them is how organizations deploy FIDO2 across their entire workforce and still get breached through credentials.

The right metric is credential exposure: how many authentication secrets exist today that an attacker can steal and replay to get into your environment? That question exposes a gap that login-focused programs never close. Enrollment, recovery, and machine credentials are where credential risk concentrates after passkeys are deployed. Most programs never get there.

The timing is no longer ambiguous. In 2024 and 2025, Adversary-in-the-Middle phishing at scale moved from targeted nation-state technique to commodity attack. The toolkits are publicly available, require no specialized knowledge to operate, and are now used in campaigns targeting organizations across every sector. The 2022 breaches at Uber and Twilio — both companies with mature security programs — established that push MFA is not sufficient against an attacker willing to be persistent. NIST finalized the governing standard in July 2025, and by that point 87% of enterprise organizations had FIDO2 deployed or in active pilot. The technology has crossed from early adopter initiative to mainstream expectation — which makes this the wrong moment to conclude the work is done. At 87% deployment, the question is no longer whether the technology works. It is whether programs are closing the surfaces that remain after passkeys are deployed.

The Case for FIDO2 Specifically

The distinction between FIDO2 and a stronger form of MFA is not that passkeys are “more secure” — it’s that they defeat a specific attack class by design, not by detection.

Consider how modern phishing works. Adversary-in-the-Middle (AiTM) proxies don’t fake your login page — they relay the real one in real time. The user authenticates legitimately, including completing an MFA challenge, and the proxy captures the resulting session cookie. At that point, the attacker has a valid authenticated session and MFA has already been satisfied. Push notification MFA, TOTP codes, and SMS are all defeated by this approach because the second factor proves the user authenticated — it doesn’t prevent the resulting session from being replayed elsewhere.

FIDO2 defeats this because the authentication ceremony is cryptographically bound to the relying party origin. When a user registers a passkey for login.company.com, the browser encodes that origin into the credential. An AiTM proxy operating at login.attacker.com cannot satisfy the WebAuthn challenge for login.company.com — the origins don’t match, and the authentication fails before any credential is exchanged. The proxy has nothing to capture.

MFA fatigue attacks make the same point from a different angle. Uber’s 2022 breach began with an attacker sending repeated push MFA requests to an employee until exhaustion produced an approval. Twilio’s breach the same year followed a similar pattern. The vulnerability in both cases wasn’t the second factor — it was the human approval step inside the authentication ceremony. FIDO2 removes that step entirely. There is no push notification to approve, no code to hand over, no human decision point an attacker can wear down or deceive.

The framing shift matters most for regulated industries. NIST SP 800-63-4, finalized in July 2025, formally allows syncable passkeys (iCloud Keychain, Google Password Manager) at Authenticator Assurance Level 2. That changes the compliance calculus for organizations that previously required hardware-bound keys for regulated workflows. Syncable passkeys trade some device-binding guarantees for substantially lower deployment friction — the right tradeoff depends on the threat model, but the option now exists within the standard.

Sequencing Is a Risk Argument

The right deployment sequence isn’t a matter of convenience or change management preference. Each phase targets a specific slice of the credential exposure problem, and the order matters because earlier phases create the foundation later ones depend on.

Start with devices. The workstation login is the trust anchor for everything downstream. A managed device with a secure enclave and native biometric authentication — Windows Hello, Touch ID, Face ID — means the private key is generated and stored in hardware that the operating system prevents any other process from accessing. That’s not a policy control; it’s an architectural property. External USB biometric readers don’t have this property. They introduce attack surface that platform-native authentication doesn’t, and should be treated as a fallback, not an equivalent.

Shared workstations, kiosks, and industrial terminals are the genuine exception. These environments can’t support per-user device binding by design. FIDO2 hardware security keys are the right model here: the credential is bound to the physical key, not the device, and the key travels with the user. The deployment complexity is real but manageable.

Move to applications. Modern applications that support federation integrate directly with the identity provider — authentication policy is enforced once, applied everywhere. Legacy applications that don’t support SAML or OIDC require a different approach. The priority order: first, modernize — file an RFE with the vendor or update the internal app to add federation support. Second, bridge — authenticate passwordlessly to a middleware layer that replays a complex credential to the legacy application on the user’s behalf. The user never touches a password; the credential surface shrinks even though the legacy application still uses one internally. Third, vault — users check out a rotating credential from a password manager and return it on completion. Not ideal, but significantly better than a static credential the user owns and manages indefinitely.

Infrastructure is a separate category. Service accounts, API keys, local admin credentials, and infrastructure automation secrets don’t authenticate people — they authenticate systems. They are not going passwordless in any meaningful sense. What they need is privileged access management: vault the credentials, require time-bound checkout with approval for sensitive access, rotate automatically on check-in. A credential that expires after four hours of use and requires an audited approval chain to access is categorically different from a standing credential embedded in a config file for two years. The goal isn’t elimination. It’s control and auditability.

One more layer belongs alongside the authentication policy: conditional access. Phishing-resistant authentication proves who you are and confirms the device binding. It doesn’t enforce whether that identity should be granted access given the current context. Conditional access is what fills that gap — evaluating device compliance posture, network and location signals, and real-time risk scores at every session, not just at enrollment. A FIDO2 credential presented from a device that failed its last MDM compliance check, or from a geographic location inconsistent with the user’s normal pattern, shouldn’t produce the same access decision as the same credential from a clean, managed device in the user’s normal context. Without conditional access, phishing-resistant credentials reduce phishing risk without enforcing the full zero trust intent.

Enrollment and Recovery Are the Attack Surface

This is the section most passwordless content skips, and skipping it is how organizations end up with strong primary authentication and a soft underbelly.

Enrollment is where the trust anchor gets established. A user’s first registration binds their identity to their device and their credential. If the identity proofing at that step is weak — a knowledge-based challenge, a help desk agent with discretion, a self-service flow without device verification — an attacker who can answer those questions or socially engineer that agent can enroll their own device as the user. Once that happens, the cryptographic strength of FIDO2 is entirely irrelevant. The attacker enrolled first.

Recovery compounds the problem. Users genuinely lose devices and need a way back in. Any recovery path that exists will be discovered by attackers, probed for weaknesses, and exploited where those weaknesses exist. Recovery paths are almost always easier to exploit than primary authentication because they were designed for urgency and convenience under distress conditions — exactly the state an attacker can manufacture through social engineering. An attacker targeting a recovery flow doesn’t need to defeat FIDO2. They need to defeat whoever answers the phone.

Lapsus$ made this pattern explicit. Their 2022 breach campaign targeting Microsoft, Samsung, Nvidia, and others didn’t break authentication protocols. They social engineered help desks and internal support staff. The authentication technology was irrelevant. The human process was the vulnerability.

The fix is designing enrollment and recovery with the same rigor as primary authentication: identity verification requirements that don’t rely on knowledge factors, device verification before binding, and consistent enforcement across every user persona. This last point is where deployments most often fail. Full-time employees on managed devices get the careful treatment. Contractors on personal devices, remote employees in other countries, and new hires pending hardware get the expedient treatment. Attackers find the expedient treatment.

Test environments don’t expose this. Test environments are populated with well-understood users on clean devices under controlled conditions. Production environments have contractors, VPN failures, support escalations, and people calling in from airports. Building enrollment and recovery test scenarios that reflect the actual user population — including the messy edge cases — is one of the highest-value investments a program can make before going live.

Strong enrollment models share a few common properties. For workforce users on managed devices, enrollment should require that the device has passed MDM compliance checks before the passkey binding is accepted — the identity provider validates device posture, not just user identity. For privileged accounts, enrollment itself should require a second independent factor: a hardware security key or a manager approval through a separate out-of-band channel. For contractors and remote employees — the highest-risk enrollment population — organizational confirmation is required before any device is bound: an enrollment link sent to the HR-of-record email address (not a user-supplied address) combined with manager sign-off. Self-service enrollment without organizational verification is the specific pattern Lapsus$-style attacks exploit. It is also the default configuration in most identity platforms.

Recovery design follows the same logic. The minimum bar for any recovery flow is two independent verification channels, at least one of which is organizational rather than possession-based. A user who loses their authenticator should not be able to recover via SMS to a phone number they supply at the time of the call — that is a single point of failure that an attacker can pre-position. The organizational channel means a manager escalation or HR verification, not a knowledge-based question. For privileged accounts, a time-delayed recovery hold is worth the operational friction: a 24-hour waiting period before a new device binding becomes active defeats the urgency tactic that makes help desk social engineering effective. An attacker who has successfully impersonated an employee at 4pm Friday cannot wait until Monday.

The help desk script matters as much as the policy. Most organizations have a rigorous enrollment and recovery policy on paper and weak enforcement in practice, because the verification steps require time that conflicts with the help desk’s primary performance metric: call resolution speed. The policy and the incentive structure have to align. If agents are measured on how quickly they close tickets, the verification steps will be the first thing to compress under pressure. That compression is the attack surface.

Machine Credentials Don’t Go Passwordless

Service accounts, API keys, OAuth grants, CI/CD pipeline secrets, and infrastructure automation credentials are outside the scope of any passkey rollout. They are also, in most enterprise environments, the credentials with the highest privilege and the weakest governance.

The pattern is consistent: machine credentials are provisioned to solve an immediate operational need, granted broader access than necessary because scoping takes time, and never deprovisioned because there is no lifecycle event that triggers it. A human changing teams gets an access review. A service account has no equivalent trigger. The result is an environment where the most powerful credentials have the longest lives and the least oversight.

This problem is getting structurally harder. AI agents operating in enterprise environments authenticate using service accounts, OAuth tokens, and API keys. They accumulate permissions over time through the same operational shortcuts that affect traditional machine identities, and they act on those permissions autonomously. The blast radius of a compromised service account has always been bounded by what the account could access. An agent adds a second dimension: it can use those permissions creatively, chain them across systems, and act at machine speed. The traditional machine identity problem, plus reasoning.

The right model is the same as for privileged human access: minimal standing permissions, time-bound credentials, automated rotation, and audit trails that make anomalous access detectable. That work doesn’t show up on a passkey adoption dashboard, but it represents a real and growing share of the actual credential attack surface — one that grows faster as agent deployment scales.

The starting point is discovery, not governance. Most organizations cannot accurately answer how many machine credentials they have, where they are, or what they can access. Before any governance model can work, there has to be an inventory: scanning source code repositories for embedded secrets, auditing OAuth grant records in the identity provider for grants made outside any formal process, reviewing service account lists in Active Directory and cloud IAM for accounts with no recent activity and no documented owner. This step consistently surfaces more credentials than anyone expected, and the ones found in unexpected places are almost always the ones with the widest permissions.

Once the inventory exists, ownership is the first governance control. Every machine credential should have a named human owner — not a team, a person. Ownership creates accountability for rotation, for scoping, and for deprovisioning when the credential’s purpose ends. Credentials without owners don’t get reviewed and don’t get rotated. In breach investigations, the credential that provided the highest-value initial access is frequently one that nobody claimed ownership of.

Rotation policy is where governance becomes operational. For credentials that can be rotated automatically — database passwords managed through a secrets vault, API keys in a secrets management platform — automated rotation on a defined schedule removes the human failure mode entirely. For credentials that require coordination to rotate because they are used by multiple systems or shared across teams, the rotation cadence should be enforced through a formal review with documented owner sign-off. The credentials that are hardest to rotate tend to be the ones that have been in place the longest and accumulated the most access. That is not a coincidence.

Why Programs Stall After the Initial Win

Passwordless programs fail in predictable ways, and understanding the patterns before they happen is more useful than any post-mortem.

The most common failure is momentum loss after the visible wins. The early phase of a rollout produces clear, reportable progress: passkey enrollment numbers climb, password reset ticket volume drops, users notice the change. Leadership gets comfortable. The program loses urgency. Enrollment and recovery hardening, legacy application migration, and machine identity governance — the work that actually reduces credential exposure — never get prioritized because they are harder to measure and less visually compelling than a rising adoption percentage. The program effectively ends at the point where it appeared to succeed.

The second is help desk drift. The enrollment verification model is designed carefully at launch. Six months later, the help desk starts accepting alternative verification for edge cases: a manager who vouches verbally, a contractor who can’t complete the standard process on a deadline, an executive escalation that bypasses the normal workflow. Each exception appears reasonable in isolation. Collectively they reopen the attack surface the enrollment design was meant to close. Attackers don’t exploit the policy. They exploit the exceptions.

The third is machine credential abandonment. The PAM deployment gets scoped to the most visible privileged accounts: domain admin, root, known service accounts. Developer-created service accounts, OAuth grants made during integrations, API keys in CI/CD pipelines and config repositories, and cloud IAM roles created for one-off automation go unmanaged. The governed accounts represent a fraction of the actual machine credential surface. The rest accumulates out of sight, until a breach investigation makes it visible.

None of these are technical failures. They are organizational ones. The programs that sustain progress treat credential exposure as a continuous operating metric rather than a project milestone. Which raises the question of how to measure it.

Measuring Credential Exposure Reduction

The credential exposure framing only works if there is something to track and report. Four metrics cover the problem accurately enough to be defensible upward.

The first is phishing-resistant authentication coverage: the percentage of human authentication events completed using FIDO2 credentials rather than passwords, push MFA, or TOTP. This is the headline metric and the most visible to leadership. It should be tracked by user segment — workforce, privileged users, contractors, remote employees — because aggregate numbers mask the gaps in the populations attackers target most. A 94% overall coverage number that conceals 60% coverage among contractors is not a 94% posture.

The second is federated application coverage: the percentage of enterprise applications that authenticate through the identity provider rather than maintaining their own credential store. Applications outside federation are credential exposure by definition — they hold passwords, session tokens, or shared secrets that exist outside your visibility and control. The number starts high in most organizations. It should be tracked as a shrinking debt over time, not a static snapshot.

The third is machine credential hygiene: the percentage of known machine credentials that have a documented owner, a defined expiry or rotation schedule, and have been rotated within that schedule. This number starts low in almost every organization and should be expected to. What matters is the trajectory. An organization that starts at 20% and reaches 75% over 18 months has materially reduced its machine credential exposure. An organization that starts at 20% and stays there has a governance program that exists on paper.

The fourth is mean time to deprovision: how long, on average, between when a user’s employment ends (or a service account’s purpose ends) and when all associated credentials are revoked across all systems. Extended deprovisioning windows are one of the most common initial access vectors in insider threat and post-departure breach investigations. Reducing this number reduces the blast radius of any departure, whether voluntary, involuntary, or adversarial.

Tracked together on a regular cadence, these four metrics give a CISO a picture of credential exposure reduction that is independent of the passkey adoption percentage — and that captures the surfaces most programs leave unaddressed.

What a Mature Program Actually Looks Like

A mature passwordless program is not one where every login is passwordless. It’s one where credential exposure is actively managed across all three surfaces: login flows, lifecycle flows, and machine identities.

Every human authentication flow uses phishing-resistant credentials, and no flow depends on push MFA or TOTP as the primary factor. Enrollment requires identity verification that doesn’t reduce to knowledge factors or help desk discretion. Recovery paths carry the same verification bar as primary authentication. Machine credentials have documented owners, defined expiry, and rotation policies that are enforced automatically, not manually. New applications are designed with passwordless from the start rather than treated as a future retrofit.

The financial case has also shifted in ways that make this easier to justify. Cyber insurers have increasingly factored phishing-resistant authentication into premium and coverage terms. Organizations that can demonstrate FIDO2 deployment across their workforce are in a materially better position in underwriting conversations than those still relying on push MFA or passwords — and that translates into a direct CFO conversation that security teams rarely have leverage for otherwise. Quantifying credential exposure reduction against breach probability and improved insurance terms is one of the more effective ways to sustain program momentum past the initial rollout, when the visible wins are behind you and the harder work remains.

Most programs get the login flow right. The ones that are reducing credential exposure are the ones that treated enrollment and recovery as authentication surfaces from day one, never stopped counting machine identities as part of the problem, and kept measuring long enough to see the organizational failure modes before they set in.

The natural next layer beyond a mature passwordless program is continuous session evaluation. FIDO2 solves how sessions are established. It doesn’t address what happens after a valid session is issued when something changes — a device fails a compliance check, a threat detection fires, a credential is reported compromised. Continuous Access Evaluation Protocol (CAEP) enables identity providers and relying parties to share real-time risk signals, revoking or downgrading sessions in seconds rather than waiting for token expiry. That closes the dwell time gap between authentication and revocation, building directly on the phishing-resistant foundation described here.

Sources

  1. FIDO Alliance / HID Global, 2025 State of Passwordless Security Survey — 87% enterprise FIDO2 deployment or pilot figure
  2. NIST SP 800-63-4, Digital Identity Guidelines, National Institute of Standards and Technology (July 2025) — AAL2 allowance for syncable passkeys
  3. Uber Technologies, Security Update (September 2022) — MFA fatigue attack disclosure
  4. Twilio, Incident Report: Employee and Customer Data Accessed (August 2022) — SMS phishing and session compromise disclosure
  5. CISA Advisory AA23-040A, Scattered Spider (2023) — Lapsus$-affiliated threat actor tactics including help desk social engineering
  6. OpenID Foundation, Continuous Access Evaluation Protocol (CAEP) Specification — real-time session revocation standard