Passkeys Are Winning — Slowly — And What That Means for Your IAM Roadmap

The IAM Industry Has Chosen Graceful Degradation Over Architectural Integrity

The authentication layer has become a holding pattern disguised as progress. Passkeys are winning—adoption by Apple, Google, Microsoft and major relying parties is now measurable and accelerating—yet the industry's technical response to this transition reveals something far more troubling than slow migration: it reveals that the entire identity-access management (IAM) function has been engineered for compliance comfort rather than adversarial resistance, and that shifting to passkey-first architectures without rearchitecting the data plane will simply relocate the breach surface rather than eliminate it.

The Narrative: Passkeys as Inevitable and Sufficient

The industry story is coherent and, on its surface, reassuring. Password-based authentication has failed repeatedly—not marginally, but catastrophically. The 2022 LastPass breach exposed customer vaults encrypted with master passwords; the incident led to voluntary disclosure and regulatory scrutiny under NYDFS Part 500 and equivalent frameworks. The Optus 2022 incident (9.8 million customer records, including identity document scans) flowed partly through credential mismanagement and overprivileged access to identity data stores. The Medibank 2022 case (9.9 million records) similarly revealed credential abuse at scale. More recently, the Snowflake tenant cascade of 2024—which exposed customer data across multiple tenants despite ostensibly isolated environments—exploited credential theft and session hijacking at the application layer, a vulnerability that passwordless authentication alone does not address.

Against this backdrop, passkeys (cryptographic key pairs, typically stored in hardware-backed device enclaves like Apple's Secure Enclave or Android's Keymaster, verified via WebAuthn/CTAP2) represent a genuine cryptographic improvement over shared-secret authentication. FIDO2 certification is now mandatory for U.S. federal vendors under OMB M-22-09, adopted by NIST SP 800-63-3 and reinforced in SP 800-63-4. Microsoft's Authenticator, Apple's iCloud Keychain, Google's Password Manager, and 1Password's encrypted sync now support discoverable credentials under the WebAuthn User Verification protocol. Enterprise adoption is no longer aspirational: Okta, Ping Identity, and Auth0 now route passkey registration and assertion through standard OIDC/SAML pipelines. Github, Microsoft 365, Google Workspace, and Salesforce have issued passkey-first guidance to users. Consumer-grade adoption is slower but tracking—Dashlane, Bitwarden, and Proton Pass now embed passkey sync and management.

Yet the transition is demonstrably incomplete. SANS ISC Handler analyses from 2023–2024 document persistent reliance on password backup codes, SMS second-factor fallbacks, and recovery email addresses—all of which reintroduce shared-secret authentication at the moment of greatest access-control risk. Krebs on Security has documented social engineering attacks that bypass passkey registration by targeting recovery flows (e.g., SIM swap followed by email account compromise to reset authenticator credentials). Dark Reading's 2024 survey found that 34% of enterprises with deployed passkey infrastructure still permit password login as a fallback mechanism, creating a "weakest link" surface where an attacker can enumerate which users have adopted passkeys and target the remainder via conventional credential theft. The regulatory picture is similarly mixed: NIS2, DORA, and the UK's FCA SM&CR regime now demand "strong authentication" for critical functions (NIS2 Article 21(1)(d) requires multi-factor authentication and cryptographic key-based controls), but transitive trust—the relying party's trust in the authenticator device's integrity, the sync service's confidentiality, and the application server's correct handling of assertion data—is not mandated or uniformly tested.

The Structural Failure: Authentication Theatre Without Data Plane Redesign

The PULSE reading of this narrative is precise and uncomfortable: the industry is treating passkeys as a point control—a credential format upgrade—rather than as a forcing function for architectural redesign. Passkeys solve one problem correctly: they eliminate reusable shared secrets from the user-to-authenticator channel. They do not solve the problem that defines most contemporary breach narratives.

Consider the Snowflake incident again. Passkey deployment at the user-facing login layer would not have prevented credential theft by the application. The breach occurred because a Snowflake customer stored static credentials (API keys, not passkeys) in environment variables accessible to the application process. The attacker, having obtained those credentials via a rogue browser extension or supply-chain compromise, could then query Snowflake service APIs with full tenant permissions. Passkeys cannot protect against overprivileged application secrets, application-layer data exfiltration, or compromised third-party access tokens—because none of these attacks exploit human-derived password weaknesses.

The Change Healthcare 2024 incident (second-largest breach in U.S. history; 100+ million records) similarly flowed through credential mismanagement. The attacker used credentials obtained through initial access brokers; MFA would have created friction but would not have prevented exfiltration once inside the perimeter. The persistence mechanism was API-based, not human-interactive. The data plane—the application's ability to move gigabytes of healthcare records across the network—remained unprotected by authentication improvements.

More subtly, passkey deployment deepens a structural problem: it makes the authenticator device and its sync service (Apple, Google, Microsoft, or third-party password manager) a high-value target. The Synnovis incident (2024, NHS England pathology labs; significant operational disruption) did not directly involve passkeys, but it revealed the brittleness of centralised, synchronised credential stores when those stores become ransomware targets. A passkey-native architecture where the sync service is compromised would not result in password theft (the keys themselves remain on-device), but it could result in account takeover at scale if the adversary can forge or replay WebAuthn attestations, or if the relying party's credential state database is corrupted. The cost of breach has shifted from the password database to the authenticator sync service and the authentication server's verification logic—a shift that the industry narrative treats as "solved" merely by moving the key material off the centralised server.

The regulatory failure is equally structural. NIS2 Article 19 requires "essential entities" in critical sectors to conduct risk assessments across "the systems, assets and processes that support the delivery of essential services." Passkey deployment satisfies the letter of NIS2 Article 21(1)(d) (multi-factor authentication for privileged access) but not Article 19's demand for systemic resilience. An organisation that deploys passkeys but continues to store application secrets in vaults, persist session tokens in memory without rate-limiting, or permit unencrypted data export from the application layer is compliant on paper but architecturally fragile in practice.

The PULSE Reframing: Zero-Knowledge Substrate and Adaptive Posture

Passkey-first architecture, correctly implemented, must rest on three non-negotiable principles that the industry has largely deferred.

First: zero-knowledge authentication substrate. The authenticator device holds the private key; the relying party never sees it. This is already true of passkeys. But the principle must extend to the entire authentication pipeline. The application server must not store user identifiers (email, username, UUID) in plaintext; instead, it must hash identifiers server-side using a high-entropy salt unique per relying party. The WebAuthn assertion response (including the authenticatorData and clientDataJSON) must be verified not only cryptographically but against a continuously-updated model of legitimate assertion patterns—device class, authenticator type, transaction timing, geolocation entropy. Any deviation triggers step-up authentication or denial. The sync service (Apple Keychain, Google Password Manager) should not hold plaintext authenticator metadata; it should hold only encrypted key material and non-identifying sync tokens.

This is not yet standard practice. Most passkey implementations store user identifiers and assertion metadata in plaintext in the relying party's database, trade assertion tokens for session cookies, and permit session replay for 24 hours or more—a window that transforms a forged or replayed assertion (or a stolen session token) into persistent access. Okta's passkey implementation, for instance, issues refresh tokens valid for 7 days by default; a compromised refresh token grants the attacker the same persistent access a stolen password would.

Second: data-plane isolation and cryptographic access controls. Authentication solves "who are you?"; it does not solve "what data should you see?" The Snowflake incident occurred because the answer to the second question was "everything, because you authenticated." The Change Healthcare attacker similarly had a clear path from authentication to bulk export once inside the application boundary.

Passkey-native architecture must enforce cryptographic access controls at the data plane. Every user's data should be encrypted under a key derived from the user's passkey (via PBKDF2, Argon2id, or equivalent) or a key unique to the user's session, refreshed on each authentication event. The application server should not hold plaintext data; it should hold ciphertext. Read access is gated by key derivation, write access by cryptographic proof-of-possession. A compromised session token permits no access to plaintext data, because the token does not grant the key material needed to decrypt. This is the "zero-knowledge" principle: the server cannot steal what it cannot see.

Practical implementation requires domain-specific primitives. For transactional data (banking, healthcare, commerce), end-to-end encryption (E2EE) at the application layer, with keys held client-side, is now technically mature. For operational data (logs, configuration, audit trails), searchable encryption or order-preserving encryption (OPE) permits server-side filtering without plaintext access. For identity data specifically—the data most vulnerable to cascade effects—cryptographic commitments (e.g., HMAC-based identity proof without leaking the identity value itself) can replace plaintext storage.

Third: continuous adversarial posture adjustment. Passkeys are cryptographically sound but executed within a threat landscape that changes monthly. The MITRE ATT&CK framework documents credential abuse techniques (T1555 Credentials from Password Stores, T1621 Multi-Factor Authentication Interception) that are increasingly automated and distributed. Relying parties must not treat passkey deployment as "set and forget"; instead, they must instrument continuous measurement of assertion patterns—device fingerprints, assertion frequency, geolocation entropy, temporal clustering—and adjust policies in real time.

This requires active adversarial simulation. Red-team exercises should include passkey replay attacks (where the attacker obtains a valid authenticatorData/clientDataJSON pair from a compromised device and attempts to use it elsewhere), attestation spoofing (forging a DeviceCheck or Android SafetyNet attestation), and authenticator phishing (rendering a fake WebAuthn prompt on a compromised device). Relying parties should measure how many such attacks are caught before data exfiltration, not after. If the answer is "we don't know," the architecture is not yet mature.

Implications for the IAM Roadmap

For organisations holding or transferring critical data—financial services, healthcare, telecommunications, public infrastructure—passkey adoption is necessary but not sufficient. The roadmap should proceed through stages.

Stage one: credential format migration. Replace password-based authentication with passkey registration and assertion for human users. Preserve fallback mechanisms (security keys, OTP) but remove email-based recovery flows. This satisfies NIS2 Article 21(1)(d) and OMB M-22-09. Timeline: 18–36 months, depending on user base size.

Stage two: application-layer access control redesign. Implement cryptographic data-plane controls. Move from coarse-grained identity-based access (grant Alice read access to the entire patient record database) to fine-grained, ciphertext-aware access (Alice can decrypt only records encrypted under keys she possesses). For regulated data (GDPR, HIPAA, UK DPA 2018), this is compliance-mandatory. Timeline: 24–48 months.

Stage three: operational resilience hardening. Implement continuous adversarial measurement. Deploy YARA/Sigma rules for authenticator-level anomalies (unusual device types, assertion frequency spikes, geolocation clustering). Instrument red-team exercises biannually, with pass/fail criteria based on attack detection latency and data exfiltration prevention, not merely credential compromise. Timeline: ongoing.

The organisations that have moved through all three stages (including some major financial services and healthcare operators, though contractual confidentiality prevents naming) report substantially reduced breach risk. The organisations that have completed only stage one—and there are many, particularly in mid-market enterprise—remain exposed to the full catalogue of post-authentication attack techniques: session hijacking, API key theft, database exfiltration, and lateral movement. They have upgraded the front door whilst leaving the windows open.

Regulatory Pressure and the Next Cycle

NIS2 and DORA enforcement begins in earnest in 2024–2025. The SEC's 4-day breach disclosure rule (effective February 2023) has already driven faster incident reporting, which in turn has exposed the gap between "we deployed passkeys" and "we designed the application for post-breach resistance." APRA CPS 234 (Australia's cyber resilience standard for banks and insurance) explicitly requires cryptographic controls over data-plane access, not merely credential strength. The MAS Threat Resilience Review (Singapore) similarly mandates "system-wide resilience" rather than "strong authentication."

Organisations that interpret these standards narrowly (passkeys satisfy the letter, move on) will face a gap-closure cycle beginning in 2025–2026, when audit findings quantify the risk. Organisations that interpret them structurally (passkeys enable, then mandate, full authentication-to-data-plane redesign) will have built the architecture that survives the next generation of intrusions.

---

Qualified operators in critical infrastructure, financial services, and regulated data environments are invited to request a technical briefing on zero-knowledge substrate architecture and post-breach-resistant design, under executed Mutual NDA.