Because attackers are targeting the human and process layer around registration, not the FIDO2 cryptography itself. They use impersonation, lookalike pages and real-time code capture to complete the proofing step, then bind a new passkey to the victim account under attacker control.
How vishing gets around passkeys without breaking FIDO2
Passkeys are still phishing-resistant at the cryptographic layer, but vishing campaigns do not need to beat that layer to succeed. Attackers target the enrolment or recovery workflow, impersonate support staff, and steer the victim into approving a legitimate registration flow that adds a new credential under attacker control.
That distinction matters because the control objective is not just “use passkeys”, it is “make sure the person doing the binding step is the real account owner.” A passkey can be strong and still be abused if the attacker convinces the user or help desk to complete the wrong ceremony.
Where the attack shifts: from login to registration and recovery
In many vishing cases, the attacker is not trying to replay a passkey challenge. Instead, they exploit the fact that many identity systems still allow a user to add a new authenticator, re-verify an account, or recover access through a weaker step. If that step depends on human judgement, callback discipline, or one-time codes, it can be manipulated in real time.
The practical failure is usually process trust, not protocol weakness. A victim may believe they are confirming support, resetting access, or re-registering a device, while the attacker is actually binding a fresh passkey, enrolling a new authenticator, or changing recovery contact details.
Related guidance on Passwordless and Passkeys Guide explains why passkeys are phishing-resistant for sign-in but still depend on secure recovery and rollout design. The same applies to Workforce Identity Security Guide, which treats account recovery and help desk workflows as part of the attack surface.
Why real-time impersonation works against otherwise strong authentication
Vishing succeeds when the attacker can keep the conversation moving faster than the organisation can verify it. Real-time voice social engineering, lookalike portals, and relayed codes let the attacker present a believable support flow while quietly collecting the values needed to complete a legitimate setup step.
That is why the problem often looks like “passkeys were phished” even though the actual compromise path involved a human being persuaded to approve enrolment or recovery. The attacker wins by hijacking trust at the edge of the identity process, then using the platform exactly as designed.
Deepfakes, Social Engineering and AI Impersonation Guide is useful here because it shows why out-of-band verification is stronger than voice-only assurance. For breach pattern context, MGM Resorts breach 2023 and Twilio 0ktapus breach 2022 show how social engineering can open the door to stronger downstream controls.
What organisations need to harden beyond the passkey itself
The most important defence is to treat registration, re-binding, help desk resets, and recovery contact changes as high-risk actions with separate controls. If an attacker can add a new authenticator after a successful social-engineering call, the deployment is only as resistant as its weakest support path.
Practitioners should assume that any workflow allowing credential replacement can be turned into an account takeover path unless it has strong step-up checks, independent verification, and clear rollback visibility. That includes lockout handling, SIM-swap-sensitive resets, and any process that can override a passkey without the original device.
For standards-based sign-in design, the NIST SP 800-63 Digital Identity Guidelines are the right reference point because they distinguish phishing-resistant authenticators from weaker recovery and proofing paths. For control mapping, NIST SP 800-53 Rev 5 Security and Privacy Controls aligns well with identity proofing, authentication, and auditability, while NIST Cybersecurity Framework 2.0 reinforces governance over access control and recovery processes.
Risk and Threat Considerations
Vishing against passkey deployments creates account-takeover risk wherever organisations let humans authorise enrolment or recovery without strong independent verification. The exposure is highest when support staff can override normal authentication, when help desk scripts are predictable, or when recovery channels are weaker than sign-in.
Failure mechanism: The attacker impersonates a trusted party, induces the victim or support agent to complete a legitimate recovery or registration step, and then binds a new passkey or equivalent authenticator to the account.
Impact: Once the attacker controls the newly enrolled authenticator, they can bypass the original passkey strength, persist in the account, and escalate into email, SaaS, or admin systems that trust the compromised identity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, 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 |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Defines phishing-resistant authenticators and secure proofing and recovery. |
| Recommendation — Use phishing-resistant authenticator and recovery requirements to separate sign-in from account re-binding. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Covers strong user authentication for workforce accounts touched by vishing. |
| IA-5 — Authenticator Management | Applies to lifecycle controls for authenticators, including issuance and replacement. | |
| AU-2 — Event Logging | Supports auditability of enrolment, recovery, and help desk actions. | |
| Recommendation — Enforce strong authentication for accounts that can add or change authenticators. Control authenticator issuance, rotation, and replacement with explicit approval and logging. Log authenticator changes and recovery actions so suspicious binding events can be investigated. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity Management, Authentication, and Access Control Policies and Processes Are Established and Managed | Covers governance over identity and access workflows exploited in vishing. |
| Recommendation — Formalise identity and recovery workflows so support exceptions do not bypass verification. | ||
Practitioner Guidance
What to prioritise: Treat passkey enrolment, recovery, and help desk override paths as privileged workflows, not ordinary user support. If those paths are easier to social-engineer than password reset, they are the real control point.
What to verify: Confirm that adding a new authenticator requires an independent signal the attacker cannot satisfy during the same call, such as a verified device prompt, strong callback process, or in-person proofing for sensitive populations. Also verify that every new passkey binding is logged and alertable.
Common mistake: Assuming “phishing-resistant sign-in” means “phishing-resistant account lifecycle.” The lifecycle and recovery layer must be designed as carefully as the login ceremony, or vishing simply moves the attack one step earlier.
Practitioner takeaway: Passkeys stop replay-style phishing at login, but they do not remove the need to secure the human approval step that creates or replaces trust in the account.