Passkeys were supposed to end phishing. However, recent research shows that flawed implementations can undermine even the strongest cryptography.
What Happened
Between late 2024 and early 2025, security researchers from SpecterOps and Unit 42 published findings demonstrating practical attacks against passkey systems in Windows and Google Chrome. These aren't theoretical cryptographic breaks. They're implementation failures that let attackers with endpoint access either impersonate users or recover the private keys that passkeys are designed to protect.
SpecterOps found that Windows stored YubiKey authentication signatures in cleartext event logs. Unit 42 discovered that Google's synced passkey implementation exposes the Security Domain Secret in Chrome's process memory during re-registration. Both attacks require malware on the target system, but once there, they bypass what many teams consider their most phishing-resistant control.
Timeline
November 2024: SpecterOps researchers identify CVE-2026-34348, a vulnerability in Windows Event Logging Service with a CVSS score of 6.5. They discover that Windows logs passkey authentication attempts, including raw cryptographic signatures, in cleartext.
December 2024: SpecterOps demonstrates a complete attack chain that reads these logged signatures and replays them to Microsoft Entra ID, achieving successful authentication without the physical security key.
January 2025: Unit 42 publishes research showing that Chrome stores Google's Security Domain Secret in process memory during passkey re-registration. They demonstrate recovery of synced passkey private keys by dumping this memory.
February 2025: Both teams coordinate disclosure with Microsoft and Google. Patches and mitigations begin rolling out.
Which Controls Failed
Endpoint logging hygiene: Windows Event Logging Service wrote sensitive cryptographic material to disk in cleartext. This violates basic secure coding principles. The logs persisted across reboots, giving attackers a durable target.
Memory protection: Chrome's passkey re-registration process left the Security Domain Secret exposed in process memory. Standard memory dumping tools could extract it. No additional privileges were required beyond what malware typically obtains.
User verification bypass: The SpecterOps attack worked because Windows and Microsoft Entra ID didn't properly validate that user verification (the PIN or biometric check) had actually occurred. The system accepted replayed signatures that claimed verification without proof.
Defense in depth: Both attacks assume endpoint compromise, but neither system had secondary controls to detect or prevent abuse. No anomaly detection flagged authentication from logged signatures. No integrity checks caught memory manipulation.
What the Standards Require
NIST 800-53 Rev 5, Control IA-5(2) requires organizations to protect authenticators commensurate with their security category. For high-value systems, this means:
- Encrypted storage of authentication secrets
- Protection against unauthorized disclosure
- Integrity verification of authentication processes
The Windows logging issue directly violates this. Cryptographic signatures are authenticator material. Storing them in cleartext fails the protection requirement.
ISO/IEC 27001:2022, Control 8.3 (Information Access Restriction) mandates that access to information and assets be restricted based on business and security requirements. Passkey private keys and authentication signatures qualify as restricted information. Leaving them in event logs or process memory without protection violates this control.
PCI DSS v4.0.1, Requirement 8.3.1 states that multi-factor authentication must be implemented using at least two different types of authentication factors. More critically, Requirement 8.3.2 specifies that authentication factors must be independent. If malware can read both the passkey signature and replay it without user interaction, you don't have independent factors anymore.
OWASP ASVS v4.0.3, Requirement 2.8.1 requires that authentication secrets be stored using approved cryptographic methods. Event logs and unprotected process memory don't qualify. The requirement explicitly calls out protection against offline attacks, which is exactly what both research teams demonstrated.
Lessons and Action Items
Audit your passkey implementation now. Don't assume vendor defaults are secure. Check:
- Where does your OS log authentication events? Can you disable logging of cryptographic material?
- If you're using synced passkeys, what memory protection does your browser provide during key operations?
- Does your identity provider validate user verification claims, or just accept what the authenticator reports?
Strengthen endpoint controls before deploying passkeys. These attacks only work on compromised systems, but that's not a defense. If your endpoint security can't detect and block memory dumping or event log access, you're not ready for passkeys as your primary authentication method. Implement:
- Application control to prevent unauthorized process memory access
- Log monitoring that alerts on bulk event log reads
- EDR that detects credential dumping techniques
Require device-bound passkeys for high-risk access. Synced passkeys trade security for convenience. Google's implementation stores private keys encrypted in the cloud, then decrypts them locally. That creates the exposure Unit 42 found. For privileged access, administrative panels, or financial transactions, mandate hardware-bound passkeys that never leave the device.
Add behavioral analytics to your authentication pipeline. Passkeys resist phishing, but these attacks show they're not foolproof. Layer on:
- Impossible travel detection (authentication from a new location immediately after another login)
- Device fingerprinting (flag logins from systems that don't match historical patterns)
- Session risk scoring (combine authentication method, device trust, and behavior)
Test your user verification enforcement. The SpecterOps attack succeeded because the system didn't properly check that the user actually provided a PIN or biometric. If you're building or configuring passkey authentication:
- Verify that your relying party validates the
uvflag in WebAuthn assertions - Test that authentication fails if user verification is bypassed
- Don't accept authenticator attestations without verification
Update immediately. Microsoft and Google have released patches. If you're running Windows with passkey authentication or Chrome with synced passkeys, these updates close the specific vulnerabilities. But treat this as a wake-up call, not a one-time fix. The pattern here is implementation flaws in otherwise sound cryptography. That pattern will repeat.
Passkeys solve the phishing problem. They don't solve the endpoint security problem. If you're migrating away from passwords, make sure your endpoint controls can handle the new attack surface.
