The Passkey Conundrum

Passwords have been declared “dead” many times over the past few decades, usually in response to yet another breach, credential-stuffing campaign, or phishing wave. Despite these recurring predictions, passwords have persisted—not because they are ideal, but because they are simple, widely supported, and, when implemented correctly (sufficient length, proper hashing, and no reuse), still reasonably effective.

That said, real-world usage rarely matches best practices. Password reuse, weak secrets, and phishing remain systemic problems, and the operational cost of mitigating them continues to rise. Against this backdrop, the industry has increasingly converged on passkeys as a successor to passwords rather than yet another incremental hardening measure. In this post, we examine the challenges associated with implementing and adopting passkeys, particularly where new risks emerge as old ones are reduced.

Before discussing those risks, it is worth clarifying what passkeys actually are and how they work.

What are Passkeys?

Passkeys are based on the Web Authentication standard (WebAuthn), which enables browsers and platforms to perform strong, phishing-resistant authentication using public-key cryptography. During registration, a user’s device generates a cryptographic key pair: the public key is shared with the service and stored server-side, while the private key remains securely on the user’s device. During authentication, the service issues a challenge that can only be signed by the private key, proving possession without ever transmitting a shared secret.

At the device level, this process is facilitated by CTAP (Client to Authenticator Protocol), which defines how external or platform authenticators—such as hardware security keys, secure enclaves, or biometric subsystems—communicate with the client performing the WebAuthn operation. In practice, WebAuthn handles the browser-to-server interaction, while CTAP handles the client-to-authenticator interaction. Together, they allow authentication to be bound to a specific device or trusted platform, often gated by local user verification such as biometrics or a device PIN.

By eliminating shared secrets from the authentication flow, passkeys remove entire classes of attacks that plague passwords, particularly phishing and credential replay. However, this shift also relocates trust—from memorized secrets to devices, platform vendors, cloud synchronization mechanisms, and account recovery processes. As a result, passkeys are not a silver bullet, but rather a reallocation of risk that must be understood and managed carefully.

With this foundation in place, we can now examine the risks and considerations that arise when passkeys are deployed at scale.

Cloud-synced passkeys expand the attack surface

Cloud- or password-manager–style synchronization allows private keys to be backed up and used across multiple devices, significantly improving usability. However, this also creates centralized targets and increases the blast radius if the sync provider or the underlying account (for example, a Microsoft or Google account) is compromised.

WebAuthn mitigates traditional credential phishing, but endpoint malware, compromised authenticator interfaces, biometric coercion, forced enrollment scenarios, and session hijacking remain viable attack paths that require complementary endpoint and behavioral controls. In the same way that infostealers and account-takeover tooling target browser-saved passwords today, synced passkeys may be exposed to similar risks when they are accessible on unmanaged devices or protected by weak account authentication settings.

Device-bound attestation shifts responsibility

Enterprise identity platforms can require authenticator attestation to ensure passkeys are device-bound and non-syncable, but this control is typically optional. If attestation is not enforced, credentials may be registered or used on unmanaged devices, or synced passkeys may be self-enrolled, bypassing policies,

Attestation shifts much of the identity risk to the endpoint device. While the authentication flow may appear strong, a stolen mobile device or laptop protected only by a simple 4-digit PIN may allow direct access to sensitive accounts. As stronger knowledge-based factors (passwords) are removed, responsibility for security moves towards invididual employees, which can feel a bit uncomfortable from an enterprise risk perspective.

Account recovery trade-off

If non-synced passkeys are used and a device is lost, recovery or reset procedures must be implemented. Once fallback authentication becomes available, email-based recovery, passwords, or other less secure methods crawl back to the organization. As a result, the overall security benefits of passkeys may be significantly reduced, even if usability improves.

Sync-based recovery simplifies user experience but shifts trust to the sync provider, requiring careful threat modeling and hardened recovery and account-recovery workflows.

Legacy platforms and endpoints complicate deployment

Operating systems and browsers expose different passkey behaviors, controls and APIs. Legacy applications and non-modern clients frequently require fallback authentication methods, increasing authentication complexity.

Sync services often lack enterprise-grade visibility. Administrators may have limited visibility into where credentials are stored, or which device performed an authentication event. This complicates incident response and forensic analysis unless attested hardware, strong device identity, or integrated enterprise tooling is in place.

Passkey registration and authentication flows are mediated by the browser. Malicious extensions, injected scripts, or browser vulnerabilities can interfere with WebAuthn interactions, spoof user prompts, or relay credential operations. Effective mitigation requires browser hardening, strong endpoint detection and response (EDR), and policy enforcement layered on top of existing security controls.

Enterprise Security Perspective

All of the above pose a great challenge when rolling out Passkeys to the enterprise, as authentication and recovery flows must be considered from application, compliance, endpoint, device, and workflow perspectives. And with new flows, new support and account recovery playbooks, as well as new potential attack methods and signals may be integrated into the security fabric.

What about the web/SaaS landscape?

Keep in mind that only a few hundred SaaS services have full direct support for passkeys, and as seen from the above, passkey storage and Sync modes may just be the key to understanding user behaviour and risks.

Here is a breakdown of the potential risk factors and methods.

Apple iCloud Keychain

Control model: Consumer cloud account (Apple ID)
Sync / mobility: Automatic cross-device
Primary risk factors: Apple ID takeover, consumer recovery flows, limited enterprise visibility
Enterprise security assessment: Medium–High — strong cryptography, weaker enterprise governance

Google Password Manager

Control model: Consumer cloud account (Google Account)
Sync / mobility: Automatic cross-device
Primary risk factors: Account recovery abuse, phishing, limited organization-level enforcement
Enterprise security assessment: Medium — security depends heavily on Google account hygiene

Windows Hello (TPM-backed)

Control model: Device-local, hardware-bound
Sync / mobility: Local only (unless Edge sync is enabled)
Primary risk factors: Device loss, limited portability
Enterprise security assessment: Very High — strongest local assurance with minimal cloud exposure

Microsoft Edge Passkey Sync

Control model: Cloud account (Microsoft Account or Entra ID)
Sync / mobility: Optional cross-device sync
Primary risk factors: Cloud identity compromise, policy misconfiguration
Enterprise security assessment: High — particularly when Entra ID and Conditional Access are enforced

Third-Party Password Manager (Consumer Tier)

Control model: Vendor-managed vault
Sync / mobility: Cross-platform
Primary risk factors: Master password compromise, phishing, vendor breach
Enterprise security assessment: Medium — varies significantly by vendor and user practices

Third-Party Password Manager (Enterprise Tier)

Control model: Organization-managed vault with policy enforcement
Sync / mobility: Cross-platform
Primary risk factors: Administrative misconfiguration, insider threat
Enterprise security assessment: High–Very High — when combined with SSO, MFA, device trust, and auditing

Hardware Security Key (FIDO2)

Control model: Physical possession
Sync / mobility: Physical only
Primary risk factors: Loss, limited backup and recovery options
Enterprise security assessment: Very High — lowest remote attack surface

Conclusion

Passkeys represent a meaningful step forward in authentication, but their security properties depend heavily on how they are stored, synchronized, and recovered. For organizations evaluating passkey adoption, the challenge is not whether passkeys are “more secure” than passwords in the abstract, but whether a given implementation aligns with enterprise requirements for control, visibility, and risk management.

The primary risk though, is the lack of visibility into such accounts, similar to password-based logins. To get a comprehensive inventory of passkey-based logins, consider adding the Scirge browser extension, which collects all logins from the browser, including password-based, SSO, and passkey accounts.