Passkeys alone do not close the account recovery attack path

At a glance

What this is: This is an analysis of why passkeys do not fully eliminate account takeover risk when account recovery still relies on weaker fallback credentials.

Why it matters: It matters because IAM teams can only treat passwordless as a control improvement if recovery, help desk, and reset paths are governed to the same assurance level as primary authentication.

👉 Read 1Kosmos's analysis of passkey recovery risk and identity assurance

Context

Passkeys are a stronger authenticator, but they do not solve account recovery by themselves. The real governance gap is that many organisations still attach weaker fallback methods to the same account, which creates a second authentication path with a lower assurance level than the primary one.

For IAM teams, this is not just a consumer identity issue. Any recovery process that allows a help desk, SMS code, email link, or phishable reset to outrun the primary factor undermines the assurance model across human identity programmes and can also inform how organisations think about privileged recovery for NHI-adjacent support flows.

Key questions

Q: How should security teams handle recovery for passkey-protected accounts?

A: They should govern recovery as a separate assurance flow, not a convenience feature. If the fallback path uses SMS, email, or weak help desk checks, it becomes the real attack surface. Strong programmes bind recovery to proofed identity records and require controls that are at least as strong as the primary passkey.

Q: Why do passkeys still leave account takeover risk in place?

A: Passkeys remove reusable secrets from login, but they do not eliminate weaker alternate paths attached to the same account. Attackers target those fallback paths because they are usually easier to socially engineer or intercept than the passkey itself. The account is only as secure as the weakest recovery method.

Q: What do teams get wrong about passwordless authentication?

A: They often treat primary authentication as the whole problem and ignore reset, support, and lost-device flows. That leaves a lower-assurance route that defeats the security gains of passkeys. The right view is lifecycle-based: sign-in, proofing, recovery, and support verification must all align.

Q: How can organisations tell whether recovery controls are strong enough?

A: A practical test is whether an attacker could recover access without defeating the passkey or presenting the same level of proof required at enrollment. If recovery can be completed through easily obtained personal data, SMS, or informal support intervention, the control is not strong enough for high-assurance accounts.

Technical breakdown

Why passkey recovery flows become the attack surface

Passkeys remove reusable secrets from primary login, but recovery reintroduces a trust decision outside the passkey itself. If a user can claim account loss and satisfy a weaker fallback factor, the attacker no longer needs to defeat FIDO2. They only need to exploit whatever alternate proof the organisation left in place. That makes recovery a separate control plane, not an extension of the original login flow. In practice, the security of the account is capped by the weakest recovery mechanism attached to it.

Practical implication: treat recovery as a distinct authentication journey and require the same assurance standard as primary sign-in.

How identity proofing changes passwordless assurance

Identity proofing creates a durable link between a person and a verified identity record before recovery is ever needed. Microsoft and NIST point toward stronger verification such as government ID checks plus biometric validation because those methods are harder to phish, reuse, or socially engineer than SMS or email. In governance terms, proofing gives the organisation a higher-assurance reference point for reset, support, and step-up recovery decisions. Without that reference point, passwordless adoption can still leave a low-trust escape hatch.

Practical implication: require proofing-backed recovery for any account where passwordless access is meant to replace weaker authentication.

Why help desk resets need the same assurance model as login

Help desk recovery is often where account takeover succeeds because operational convenience outruns control design. If reset agents can restore access on the basis of easily obtained personal data or weak callback methods, the attacker bypasses the passkey entirely. The right governance model treats help desk recovery as privileged access, with explicit verification rules, auditability, and documented escalation thresholds. This is especially important where the account can reach sensitive systems or support privileged workflows.

Practical implication: move help desk recovery into privileged workflow governance and remove informal reset exceptions.

Threat narrative

Attacker objective: The attacker wants to bypass passwordless authentication by using the weakest recovery path to regain control of the account.

1. Entry occurs when the attacker targets the account recovery process rather than the passkey login itself, using a lost-device or lost-factor claim to start the reset flow.
2. Credential access happens when the fallback path accepts weaker verification such as SMS, email, or support-mediated approval instead of high-assurance proofing.
3. Impact follows when the attacker successfully resets access and takes over the account without ever defeating the passkey.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

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 do not fail first at authentication. They fail when recovery is treated as a lower-assurance exception. The article shows the core governance problem: organisations modernise the front door while leaving the back door governed by older, weaker proofing methods. That creates a split assurance model inside the same account lifecycle. Practitioners should recognise recovery as the control that determines whether passwordless is real or cosmetic.

Recovery assurance is a human identity governance problem, not a factor selection problem. The article’s strongest signal is that identity proofing, biometric verification, and recovery policy have to be evaluated together. If a user can recover access with an SMS code or email link, the organisation has not removed the phishable credential, it has relocated it. That is an IAM lifecycle failure, not just an authentication design flaw.

High-assurance reset flows are becoming the new baseline for identity trust. Microsoft and NIST are effectively pointing toward a model where recovery must be as strong as enrollment and sign-in. That shifts passwordless programmes from factor replacement to lifecycle assurance. Teams that do not redesign reset, support, and step-up identity checks will continue to carry account takeover exposure in the very programmes meant to reduce it.

Identity assurance should be measured by the weakest recovery path, not the strongest login factor. That framing aligns passwordless, help desk workflows, and identity proofing under one governance lens. If any recovery method is phishable, the account remains phishable. Practitioners should therefore review recovery as a control boundary in its own right, because the attacker will.

Identity proofing at enrollment creates recovery debt if it is not reused later. The article points to a broader lifecycle lesson: verified identity only reduces risk if it becomes the basis for subsequent resets, support verification, and account recovery. Otherwise, organisations pay for proofing once and then give the account back through weaker channels. The implication is to govern the whole identity lifecycle as one assurance chain.

From our research:

• Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, according to The 2024 Non-Human Identity Security Report.
• Only 35.6% of organisations cite managing consistent access across hybrid and multi-cloud environments as their top NHI security challenge, according to Aembit's 2024 research.
• For a broader lifecycle lens, see Guide to the Secret Sprawl Challenge for how weak credential paths and secret sprawl persist across identity programmes.

What this signals

Recovery is becoming the decisive control boundary for passwordless programmes. If organisations leave SMS, email, or help desk resets in place, they preserve the same attack surface they were trying to remove. The programme signal is clear: measure the weakest recovery path, not the strongest login factor, and align it with the same assurance standard as authentication.

Identity proofing should now be treated as reusable lifecycle evidence. If a verified identity cannot be reused safely for reset, support verification, and account recovery, it delivers only partial value. Teams building mature IAM programmes should connect proofing, help desk policy, and reset workflows into one lifecycle control set, informed by the NIST SP 800-63 Digital Identity Guidelines.

Help desk recovery is a privileged workflow and should be measured that way. The governance question is not whether passkeys work, but whether the recovery path is still phishable. That framing also helps identity teams prepare for broader lifecycle governance across humans, NHIs, and agentic systems.

For practitioners

• Remove phishable recovery methods from passwordless accounts Eliminate SMS, email-link, and knowledge-based recovery for accounts that use passkeys, especially where access reaches sensitive systems or privileged workflows.
• Treat help desk reset as privileged access Apply explicit verification steps, audit logging, and escalation rules to support-mediated recovery so it cannot override stronger authentication controls by exception.
• Bind recovery to proofed identity records Use government ID verification and biometric checks where appropriate so a recovered account is tied back to the same assurance standard used at enrollment.
• Review the weakest recovery path first Assess every account type by its lowest-assurance fallback, because that path determines whether passwordless reduces attack surface or merely relocates it.

Key takeaways

• The core weakness is not the passkey, but the fallback route that can still be socially engineered or intercepted.
• Recovery flows must carry the same assurance level as primary authentication if passwordless is meant to reduce takeover risk.
• Identity proofing, support verification, and reset policy should be governed as one lifecycle control chain, not separate exceptions.

Key terms

• Account recovery assurance: The level of confidence an organisation has that a reset or regain-access process is really being performed by the rightful user. In mature identity programmes, recovery assurance should be close to the assurance used for primary authentication, because attackers often target the weaker path instead of the stronger one.
• Identity proofing: The process of verifying that a person is who they claim to be before issuing or restoring access. It usually relies on stronger evidence than a password or SMS code, such as government ID checks or biometrics, and it becomes especially important when recovery must not reintroduce phishable credentials.
• Phishable recovery flow: A reset or regain-access path that can be tricked by social engineering, intercepted codes, or weak support checks. These flows undermine passwordless programmes because they preserve an alternate credential path that is easier to abuse than the passkey itself.
• Help desk privilege: The authority given to support staff to verify identity and restore access for users. When not tightly governed, it becomes a high-risk control point because the help desk can override stronger authentication controls through exception handling, informal checks, or insufficient auditability.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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.

This post draws on content published by 1Kosmos: According to Microsoft and Google, passkeys alone aren't enough to stop hackers. Read the original.