TL;DR: Passkeys replace reusable passwords with phishing-resistant cryptographic credentials, but Bitwarden argues that recovery paths, shared access, service accounts, and legacy sign-ins still leave organizations exposed. The shift makes authentication stronger, yet also exposes the broader identity stack that conventional login-focused security often ignores.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Bitwarden's blog post: Passkeys make phishing-resistant authentication more practical, but the move only works if teams also govern recovery paths, shared access, service accounts, and legacy sign-ins.
Why it matters: IAM teams need to treat passkeys as one control in a wider identity programme, because stronger human login alone does not remove credential and access risk across the rest of the stack.
Context
Passkeys are a phishing-resistant authentication method built on public key cryptography rather than shared secrets. The point is simple: the user proves possession of a private key without sending a reusable password to the service, which removes a common theft and replay path.
The governance problem is that most environments do not operate on passkeys alone. Passwords, recovery flows, shared access, service accounts, SaaS integrations, and legacy applications still create identity risk outside the main login path, so authentication modernisation has to be treated as an identity lifecycle issue, not a login feature update.
For IAM and NHI programmes, the question is not whether passkeys are stronger than passwords. The question is whether the rest of the access model, including recovery and non-human credentials, is ready for a passwordless transition without creating new blind spots.
Key questions
Q: What should organisations do when passkeys are not enough on their own?
A: Add session and authorization controls that limit damage after login. Bind sessions to devices where possible, shorten token lifetimes for sensitive actions, and monitor consent grants, endpoint compromise, and unusual recovery events. Passkeys protect authentication, but they do not prevent OAuth abuse or post-login session theft.
Q: Why do passkeys improve security but not eliminate identity risk?
A: Passkeys remove the shared secret that attackers usually steal, guess, or phish, which is a major improvement. But identity risk shifts into device trust, account recovery, enrolment, and fallback. If those controls are weak, an attacker can still gain access without ever defeating the passkey cryptography itself.
Q: What breaks when recovery flows are weaker than primary authentication?
A: Privilege controls become easy to route around. A strong sign-in flow does not compensate for a weak password reset, device recovery, or help-desk verification process. Attackers often target the exception path because it is designed for user convenience, so organisations should evaluate recovery with the same rigor as first-factor login.
Q: How should IAM teams govern passkeys across multiple platforms?
A: Treat passkeys as lifecycle-managed authenticators, not as a one-time login feature. Define where they are stored, how they sync, who can share them, and how they are deleted during offboarding. The main failure mode is inconsistent control across Apple, Google, and Microsoft ecosystems, which creates invisible governance drift even when the user experience looks seamless.
Technical breakdown
Why passkeys resist phishing better than passwords
Passwords are shared secrets, so they can be guessed, reused, replayed, or captured through phishing and other forms of deception. Passkeys replace that model with asymmetric cryptography. The private key remains on the user device or in a credential manager, while the service verifies the matching public key. Because the credential is bound to the original domain, a spoofed site cannot reuse it. That makes passkeys materially different from password managers, which still support password-based authentication even when they improve password quality.
Practical implication: treat passkeys as a control that removes reusable secret exposure from the login flow, not as a complete identity programme.
Why recovery paths become the real weak point
When organisations move to passwordless sign-in, the primary authentication factor gets stronger, but account recovery often stays built around older assumptions. Lost devices, replacement hardware, backup access, and helpdesk reset workflows can all reintroduce weaker controls if they are not governed as carefully as the primary sign-in method. In practice, many breaches and takeovers succeed at the recovery layer rather than the login layer. That is where password-era IAM habits survive even after passkeys are introduced.
Practical implication: govern recovery as a first-class authentication path, with the same scrutiny you apply to sign-in.
Why shared access and service accounts still matter in a passkey world
Passkeys solve human authentication better, but they do not remove the need to manage shared credentials, service accounts, OAuth integrations, or machine-driven access. Those identities do not authenticate through a person-centric login ceremony, so they remain governed by secrets, tokens, certificates, or delegated access patterns. Bitwarden’s point is that credential risk persists outside the user sign-in flow. A passkey programme that ignores these access paths merely shifts attention away from the least visible parts of the estate.
Practical implication: inventory and govern non-human credentials in parallel with passkey rollout, because they sit outside the passwordless win.
Threat narrative
Attacker objective: The attacker’s objective is to bypass the stronger login control by using weaker surrounding identity paths to gain unauthorized access.
- Entry begins at the password or recovery layer, where phishing, reuse, or social engineering can still capture access if the environment has not moved fully to phishing-resistant sign-in.
- Credential access then expands through recovery workflows, shared accounts, OAuth tokens, or other non-human credentials that sit outside the primary passkey flow.
- Escalation occurs when attackers use those alternate paths to reach privileged systems, SaaS data, or business-critical applications.
- Impact is account takeover or unauthorized access despite the presence of passkeys, because the surrounding identity stack still contains reusable or weakly governed credentials.
Breaches seen in the wild
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
- Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Passkeys do not fix password-era IAM by themselves: The control improvement is real, but it only applies to the primary sign-in path. If recovery flows, shared access, and service accounts still operate on older assumptions, the programme remains partially password-era in practice. The practitioner conclusion is that authentication modernisation must be judged across the whole identity stack, not by login strength alone.
Recovery is now the highest-value attack surface in passwordless programmes: Once passwords stop being the default entry point, attackers and users both concentrate on fallback paths. That shifts governance pressure onto helpdesk resets, device replacement, backup codes, and delegated access approvals. The implication is that the security of the transition will be determined by the weakest recovery path, not the strongest passkey implementation.
Shared credentials and non-human access remain outside the passkey story: Passkeys are designed for user authentication, not for service accounts, integrations, or other machine-driven access. Those identities still need lifecycle ownership, revocation discipline, and visibility because they can outlive any human login hardening. The practitioner conclusion is that passwordless roadmaps must be paired with NHI governance or they only solve half the problem.
Phishing-resistant authentication is exposing a broader identity blind spot: As the login edge becomes more secure, legacy access methods become easier to ignore. That can create false confidence if teams measure progress only by passkey adoption rates. The implication is that IAM maturity now depends on whether the organisation can govern the credentials that remain after passwords start to disappear.
Credential risk is shifting from the user secret to the access relationship: The article points to a broader change in identity security. The decisive question is no longer just whether the credential is phishable, but whether the surrounding access path is owned, observable, and revocable. The practitioner conclusion is to align passkey deployment with full access lifecycle governance.
From our research library:
- eBay's passkey data shows 55-60% of passkey adoption happens on mobile, against around 20% on desktop.
What this signals
Passkey adoption should trigger a review of the whole access chain, not just the login method: Teams that stop at phishing-resistant sign-in risk leaving recovery workflows, shared access, and machine credentials untouched. The stronger the primary factor becomes, the more visible the remaining weak paths should be.
Credential governance now spans human and non-human access together: Passwordless authentication changes how people sign in, but service accounts, SaaS tokens, and integration secrets still need lifecycle ownership. IAM programmes that separate those domains will miss the real residual risk.
Passwordless transition programmes need a control map, not a feature rollout: Passkeys can reduce phishing exposure, but only if the organisation has a plan for legacy applications, backup access, and offboarding the credentials that remain in circulation.
For practitioners
- Map every recovery path Inventory backup codes, helpdesk reset flows, device replacement processes, and delegated recovery approvals so they are reviewed alongside the primary passkey journey.
- Govern non-human credentials in parallel Track service accounts, OAuth tokens, SaaS integrations, and other machine credentials as a separate control surface instead of assuming passkey adoption reduces their risk.
- Remove shared access dependencies Identify where shared accounts still support business operations and replace them with accountable, individually managed access paths wherever the application can support it.
- Keep legacy sign-ins under active control Maintain strong password policy, breach monitoring, and visibility for applications that cannot yet support passwordless authentication, because those paths remain exploitable.
- Tie passkey rollout to access lifecycle governance Measure adoption against the full set of credentials and recovery methods so that passwordless progress does not hide unresolved identity risk.
Key takeaways
- Passkeys reduce phishing exposure by removing reusable secrets from the primary sign-in flow, but they do not automatically modernise the rest of IAM.
- Recovery paths, shared access, service accounts, and legacy applications can keep identity risk alive even after passwordless rollout begins.
- The right response is to govern passkeys as part of a wider access lifecycle programme that covers both human and non-human credentials.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centers on moving away from password-based authentication toward phishing-resistant passkeys. |
| NHI-07 — Long-Lived Secrets | Passwords, recovery codes, and legacy credentials remain long-lived secrets during the transition. | |
| NHI-10 — Human Use of NHI | Shared access, service accounts, and machine-driven access remain part of the credential estate. | |
| Recommendation — Use NHI-04 to replace reusable login secrets with phishing-resistant authentication paths. Reduce long-lived credential exposure by governing every remaining secret in the access stack. Separate human sign-in modernization from governance of service accounts and other non-human access. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article is about managing authenticators across passwords, passkeys, and recovery paths. |
| Recommendation — Apply IA-5 to govern authenticator lifecycle, recovery, and revocation across the identity stack. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Passkey rollout still requires control over permissions and alternate access paths. |
| Recommendation — Map passkey adoption to PR.AA-05 so entitlements and fallback access stay governed. | ||
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 credentials: Shared credentials are passwords, tokens, or access secrets used by more than one person or system. They weaken attribution and revocation because no single identity owns the secret cleanly, which increases blast radius when the credential is exposed or abused.
- Passwordless Authentication: An authentication approach that removes passwords and uses a device-bound cryptographic key plus local user verification. It reduces phishing and replay risk, but it only improves assurance when enrollment, recovery, and revocation are tightly governed.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on July 22, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org