Phishing-resistant passkeys expose the limits of password-era IAM

At a glance

What this is: This is Bitwarden’s explanation of why passkeys improve phishing resistance while leaving recovery paths, shared credentials, and non-human access risks in scope.

Why it matters: It matters because IAM teams cannot treat passwordless adoption as a complete identity control model when service accounts, integrations, and fallback access still govern real operational risk.

👉 Read Bitwarden's guidance on passkeys, secrets, and passwordless transition

Context

Phishing-resistant authentication is a control improvement, but it does not eliminate the identity risks created by passwords, recovery flows, shared access, and machine-linked credentials. In practice, passkeys reduce reuse and spoofing exposure, yet IAM programmes still have to govern the full credential estate, including secrets, integrations, and fallback paths.

That broader view is the key issue for identity teams. If passwordless is treated as a point solution rather than part of lifecycle governance, organisations can improve the login step while leaving service accounts, backup access, and shared credentials outside meaningful control.

Key questions

Q: How should security teams roll out passkeys without breaking account recovery?

A: Start with low-risk journeys, then define recovery as a controlled identity workflow rather than a convenience feature. Use step-up verification, help-desk approval, and audit logging for resets. The goal is to keep passwordless sign-in simple while making fallback paths stricter than the primary login path. That is where most account abuse begins.

Q: Why do passkeys not eliminate the need for secrets management?

A: Because most organisations still rely on service accounts, API keys, shared credentials, and application integrations that do not use passkeys. Those credentials can remain long-lived and broadly scoped, so the organisation still needs inventory, rotation, revocation, and monitoring outside the human login flow.

Q: What do security teams get wrong about passwordless authentication?

A: The most common mistake is treating passwordless as a user-experience upgrade instead of an identity control change. Teams often focus on the login screen and ignore recovery, lifecycle governance, and fallback authentication, which is where many of the real risks emerge.

Q: How do organisations know whether passkey adoption is actually reducing risk?

A: Track the share of accounts that are passkey-enrolled, the proportion of sign-ins still using passwords, and the number of recovery events that bypass the primary factor. If password use remains high or recovery is frequent, the programme is still in transition rather than truly passwordless.

Technical breakdown

Why passkeys change the authentication trust model

Passkeys replace shared secrets with public key cryptography. The private key stays on the user’s device or in a credential manager, while the relying party verifies a signed challenge with the matching public key. Because the credential is bound to the origin, a spoofed domain cannot reuse it the way a password can be phished or replayed. That materially reduces account takeover risk for human identities, especially privileged users. However, the control only covers the primary sign-in path. It does not by itself govern recovery codes, shared access, or machine credentials that live alongside the user account.

Practical implication: treat passkeys as a stronger authenticator, not as a complete identity security programme.

Why synced passkeys reduce one risk while introducing another governance question

Synced passkeys improve usability by allowing access across trusted devices without depending on one physical key or one phone. That solves a common adoption problem, but it also shifts trust into the credential manager and its recovery model. Security teams now have to ask who can restore access, how recovery is authenticated, and what happens if the sync layer becomes the new control point. In other words, the weak link moves from password reuse to recovery governance. For IAM, that makes backup access design and device trust part of the authentication architecture, not an afterthought.

Practical implication: review recovery and sync policies with the same rigor as primary authentication.

Why passwordless still leaves secrets and service accounts exposed

Passwordless sign-in only hardens one identity path. Most enterprises still operate shared credentials, API keys, service accounts, and SaaS integrations that do not use the same phishing-resistant flow. Those credentials are often long-lived, broadly scoped, and weakly observed, which means the attack surface persists even when human logins improve. The governance mistake is to measure progress by the percentage of users on passkeys while ignoring the rest of the access fabric. IAM maturity depends on whether the organisation can see and control every credential type, not just the human one.

Practical implication: inventory non-human credentials before declaring passwordless rollout complete.

Threat narrative

Attacker objective: The attacker wants durable identity access that survives stronger human login controls by exploiting the surrounding credential ecosystem.

1. Entry occurs when a user or administrator authenticates through a phishable password or a weak fallback path that still accepts reusable secrets.
2. Escalation follows when an attacker reuses recovered credentials, abuses shared access, or pivots through service accounts and SaaS integrations that were never brought into the passwordless model.
3. Impact is account takeover, unauthorized system access, and persistence through recovery paths or unmanaged non-human credentials.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Passkeys improve authentication, but they do not solve identity governance. The industry keeps framing passwordless adoption as the destination, when it is really only one control layer. Recovery flows, shared credentials, and non-human access still determine whether identity is actually governed. The practitioner conclusion is simple: passwordless reduces phishing exposure, but governance only starts when the rest of the credential estate is visible.

Identity programmes that optimise for login security alone are measuring the wrong boundary. Passkeys protect the human authentication moment, yet most real compromise paths live in backup access, delegated integrations, and service credentials. That means the effective control boundary is the full access lifecycle, not the front door. Practitioners should evaluate identity risk by credential type and persistence, not by whether users have adopted passkeys.

Shared secrets remain the decisive weak point in mixed human and machine environments. The article’s strongest implication is not about passkeys themselves but about coexistence: passwords, recovery codes, SaaS tokens, and service accounts will remain present during the transition. That creates a governance gap where one part of the estate is hardened while the rest remains exposed. The practitioner conclusion is to align secrets governance with passwordless rollout rather than treating them as separate workstreams.

Passkey adoption will push IAM teams toward lifecycle governance, not just authentication engineering. The more organisations move away from passwords, the more they expose gaps in offboarding, backup access, and shared credential management. This is where human IAM, NHI governance, and recovery design converge. The practitioner conclusion is that passwordless success depends on lifecycle discipline across all identity types, not on stronger sign-in alone.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to the State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, which helps explain why passwordless rollouts do not eliminate the broader credential problem.
• For a deeper control model, see OWASP Non-Human Identity Top 10 and the Guide to the Secret Sprawl Challenge.

What this signals

Secret sprawl becomes the hidden limiter of passwordless programmes. Even when passkeys reduce phishing exposure, the surrounding environment still contains passwords, recovery secrets, API keys, and service accounts that do not inherit the same protection. That means IAM teams should expect the hard part to move from authentication rollout to access inventory and lifecycle control, especially where machine access remains fragmented.

Passkey adoption will accelerate convergence between IAM and NHI governance. Once the human login path is hardened, unmanaged non-human credentials become more visible as a parallel risk domain rather than a separate operations issue. Teams that already track secrets sprawl should use that visibility to tighten recovery controls, shared access, and integration review before those gaps become the next breach path.

The practical signal to watch is whether passwordless adoption is shrinking the use of reusable credentials or merely improving the front-end experience. If recovery codes, shared accounts, and service tokens remain outside policy, the programme has improved authentication but not reduced attack surface.

For practitioners

• Map every fallback access path Document recovery codes, backup devices, shared credentials, and break-glass accounts alongside primary passkey sign-in. If any of those paths can be used without equivalent assurance, the passwordless programme is only partially effective.
• Inventory non-human credentials Include service accounts, API keys, SaaS tokens, and integrations in the same identity inventory used for human users. The goal is to see which credentials still bypass phishing-resistant authentication entirely.
• Bind recovery to governance Set approval, verification, and logging requirements for account restoration so that credential recovery is not easier to abuse than the primary authentication flow.
• Separate adoption metrics from risk metrics Track passkey rollout separately from exposure in shared access, stale secrets, and unmanaged integrations. A high passkey adoption rate can coexist with a weak overall identity posture.
• Review shared access before expanding passwordless Identify where teams still share credentials for operational convenience and replace those pathways with governed access models before declaring the transition complete.

Key takeaways

• Passkeys reduce phishing risk, but they do not remove the need to govern recovery paths, shared access, and non-human credentials.
• The real control boundary is the full credential estate, not the primary login step, because weak links often sit in backup access and integrations.
• IAM teams should measure passwordless success by reduced reliance on reusable secrets and stronger lifecycle governance, not only by enrollment rates.

Key terms

• Passkey: A passkey is a passwordless credential based on public key cryptography. A private key stays on the user’s device, while a public key is stored by the service. During login, the device signs a challenge after local unlock, which reduces phishing and eliminates shared secret reuse.
• Recovery Path: The set of backup methods, reset flows, and help-desk procedures that restore access when a user loses their primary credential. Recovery paths often become the weakest part of identity governance because they can reintroduce shared secrets, manual override, or inconsistent verification standards.
• Shared Secret: Any credential or factor that can be known by more than one party and copied or reused, such as a password, OTP, or recovery code. Shared secrets are fragile because once exposed, they can often be replayed to bypass identity controls.
• Non-Human Credential: A non-human credential is a secret used by software, automation, or an AI agent to authenticate or act on a system’s behalf. Examples include API keys, tokens, certificates, and service account secrets. These credentials need lifecycle governance because they often persist beyond the human task that created them.

What's in the full article

Bitwarden's full blog post covers the operational detail this post intentionally leaves for the source:

• How its vault model handles passkey storage, sync, and end-to-end encryption across trusted devices.
• Practical transition guidance for keeping passwords, recovery codes, shared access, and secrets in scope during passwordless rollout.
• Examples of how organisations can manage non-human access alongside passkeys without losing visibility into legacy credentials.
• Product-level detail on how phishing protections and breach alerts fit into day-to-day credential hygiene.

👉 Bitwarden's full post covers the passkey model, recovery considerations, and remaining credential risks in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.