Passkeys reduce phishing risk only when they are the sole usable method. If passwords, backup codes, OTP, or other legacy methods remain active, attackers can downgrade the session to one of those paths. The exposure is created by the account’s remaining authentication surface, not by the passkey itself.
Why This Matters for Security Teams
Passkeys are phishing-resistant, but only within the boundaries of the entire login journey. If an account still accepts passwords, SMS OTPs, backup codes, or help-desk recovery paths, attackers do not need to break the passkey ceremony. They simply look for the weakest remaining authentication path and use that to complete account takeover.
This is why passkey rollouts fail when teams treat them as a cosmetic control rather than a full authentication redesign. Guidance from the Ultimate Guide to NHIs — Key Challenges and Risks shows how quickly weak identity surfaces become systemic, and CISA’s cyber threat advisories repeatedly reflect the same pattern: attackers exploit the easiest available path, not the strongest one. NHIMG’s 52 NHI Breaches Analysis also reinforces that identity compromise usually follows exposed fallback paths and incomplete lifecycle controls.
For security teams, the practical issue is not whether passkeys work, but whether every alternate route has been removed, hardened, or tightly governed. In practice, many security teams encounter passkey-related phishing only after account recovery abuse or legacy login downgrade has already been used in the wild, rather than through intentional testing.
How It Works in Practice
A passkey protects the primary authentication ceremony by binding the login to a device-held credential and origin-checked cryptography. That stops common phishing kits that harvest passwords or intercept OTPs. But the account’s exposure is determined by all enabled authentication and recovery mechanisms, not just the passkey path. If a user can still authenticate with a password, an emailed reset link, or a one-time backup code, the phishing resistance is diluted.
Operationally, the right approach is to reduce the account to a single high-assurance path wherever possible and treat every exception as a risk decision. That usually means:
- Disabling password login after passkey enrolment, or strictly limiting it to transitional migration windows.
- Removing SMS and email OTP as primary factors for high-risk users and administrators.
- Reissuing backup codes as one-time recovery artifacts with tight expiry and clear revocation rules.
- Requiring step-up controls for recovery, enrolment changes, and device replacement.
- Logging and alerting on fallback usage because it often signals downgrade attempts.
Current best practice is to pair passkeys with phishing-aware recovery design, not to assume the new factor alone solves account takeover. Security teams should compare policy choices with the OWASP NHI Top 10 and the Anthropic AI-orchestrated cyber espionage campaign report to understand how adversaries chain identity abuse across otherwise trusted paths. These controls tend to break down in large enterprises with legacy SSO, shared admin accounts, or service desks that can still override authentication policy on demand.
Common Variations and Edge Cases
Tighter authentication design often increases help-desk friction and migration overhead, requiring organisations to balance phishing resistance against usability, device loss recovery, and support burden.
Some environments cannot remove every fallback immediately. Shared workstations, regulated call-centre workflows, and unionised or BYOD populations may need staged migration. In those cases, the control objective is to make fallback materially harder to abuse than the passkey path itself. That usually means shorter-lived recovery codes, stronger identity proofing for resets, and frequent review of who can approve exceptions.
There is no universal standard for fallback design yet, but current guidance suggests treating backup methods as temporary bridges, not permanent parallel access routes. Where phishing risk is highest, the account should not retain multiple equivalent authentication paths. The more ways an attacker can authenticate or recover access, the less meaningful the passkey becomes as a phishing control.
For a broader view of how identity sprawl undermines security posture, NHIMG’s Ultimate Guide to NHIs — Why NHI Security Matters Now is a useful reference, especially when teams are also governing non-human credentials alongside employee access.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Fallback auth paths create the same credential abuse risk as weak NHI lifecycle control. |
| NIST CSF 2.0 | PR.AA-1 | Phishing-resistant authentication depends on controlling all access methods, not one factor. |
| NIST AI RMF | Risk management must account for adversarial misuse of identity workflows and recovery paths. |
Eliminate or tightly govern alternate login methods and rotate recovery credentials on a strict schedule.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
