Who is accountable when a passkey is enrolled through social engineering?

Why This Matters for Security Teams

When a passkey is enrolled through social engineering, the problem is not the cryptography of the passkey itself. The failure is upstream: an attacker persuaded a human operator or support workflow to approve an identity event that should have been treated as high risk. That is why accountability extends beyond the individual victim and into the identity programme, helpdesk governance, and application ownership.

This is a familiar pattern in real incidents. Social engineering campaigns repeatedly exploit recovery channels, enrollment exceptions, and weak verification steps that were never designed for adversarial pressure. NHIMG’s MGM Resorts Breach 2023 — Scattered Spider and Caesars Entertainment Breach 2023 — Scattered Spider show how identity workflows become the attack path when assurance is too easy to satisfy. NIST’s NIST SP 800-63 Digital Identity Guidelines make clear that identity proofing and authenticator binding must be appropriate to the risk, not merely convenient.

In practice, many security teams discover enrollment abuse only after a support desk has already accepted a fraudulent reset or recovery request.

How It Works in Practice

Accountability should be assigned to the people who controlled the enrollment path, not only to the person who was deceived. In mature programs, the identity team defines the assurance level for passkey enrollment, the helpdesk owner enforces step-up verification for recovery, and the application team removes fallback methods that bypass strong authentication. The question is less “who clicked yes” and more “who made yes sufficient.”

A defensible operating model usually has four parts. First, enrollment and recovery actions are treated as privileged identity events with explicit approval criteria. Second, helpdesk staff follow a script that resists persuasion and requires independent verification for resets. Third, the application only accepts passkey binding through a controlled registration flow, with no silent fallback to weaker methods. Fourth, every enrollment event is logged with enough context for later review, including device, channel, and approver identity.

• Use strong identity proofing for enrollment and recovery, aligned to risk.
• Remove SMS, email-only, or knowledge-based fallback where passkeys are intended to be primary.
• Require step-up checks for any authenticator reset or re-registration.
• Treat helpdesk exceptions as governed security decisions, not operational convenience.

For teams mapping this to control intent, NIST SP 800-53 Rev 5 Security and Privacy Controls is useful for access enforcement and auditability, while Ultimate Guide to NHIs shows the broader governance pattern: identity events fail when lifecycle controls are weak and visibility is incomplete. The same lesson applies to human credentials, even when the authenticator is modern and phishing-resistant.

These controls tend to break down when enrolment is outsourced to a generic service desk that lacks risk context, because the operator ends up acting as the attacker’s proxy.

Common Variations and Edge Cases

Tighter enrollment controls often increase friction for legitimate users, requiring organisations to balance phishing resistance against support burden and recovery time. That tradeoff becomes sharper for executives, contractors, and remote workers, where exception handling is most tempting and most dangerous.

Best practice is evolving for edge cases. There is no universal standard for whether every passkey reset must require in-person verification, but current guidance suggests the higher the account privilege, the stronger the reproofing should be. For high-risk accounts, a second factor alone is not enough if the recovery channel itself can be socially engineered. For lower-risk consumer experiences, organisations may accept lighter controls, but they should do so knowingly and document the residual risk.

One practical distinction is between accountable failure and malicious compromise. If a user was impersonated through vishing, the user is the victim, not the accountable control owner. If the helpdesk ignored policy, accountability sits with the process owner and their management chain. If the application allowed passkey enrollment to be bypassed through legacy fallback, the application team shares responsibility because the control design permitted weak assurance. The ENISA Threat Landscape reinforces that social engineering remains a durable tactic because it targets process weaknesses, not just technical ones.

In other words, passkey compromise through social engineering is usually a governance failure expressed through a human conversation.

Related resources from NHI Mgmt Group

• Why do AI-cloned voices make social engineering harder to stop?
• Who should be accountable when authenticated users abuse access after a social engineering attack?
• Who is accountable when social engineering defeats identity controls?
• Who is accountable when social engineering leads to credential compromise?