What should organisations do when passkeys are deployed but account takeovers still occur?

Why This Matters for Security Teams

Passkeys reduce phishing risk at the authentication step, but they do not eliminate account takeover when attackers pivot into recovery, device binding, or support workflows. That is where many real-world compromises now happen. NHI Management Group’s Ultimate Guide to Non-Human Identities shows that 80% of identity breaches involved compromised non-human identities such as service account and API keys, which is a reminder that attackers prefer the weakest identity control path, not the strongest one.

For human accounts, the same pattern appears when a help desk, SMS recovery, email fallback, or device reset path is trusted more than the passkey itself. Cases like the Meta AI Instagram Account Takeover illustrate how support-channel trust can be abused even when primary controls are modern. NIST’s SP 800-53 Rev. 5 Security and Privacy Controls reinforces that identity assurance has to cover the full lifecycle, not just the login ceremony. In practice, many security teams encounter takeovers only after recovery abuse or device re-enrollment has already been used to reissue trust.

How It Works in Practice

The practical response is to treat passkeys as one control in a broader identity assurance chain. If account takeovers continue, the first question is whether the recovery path is stronger than the attacker. That means reviewing how a user proves possession of a device, how a new device is bound, what triggers fallback authentication, and which channels are allowed to override a passkey.

Effective controls usually combine the following:

• Require strong device binding before a passkey can be enrolled or transferred.
• Protect recovery with step-up verification that is harder to socially engineer than email or SMS.
• Log and alert on re-enrollment, credential reset, and support-assisted changes.
• Limit recovery agents to narrowly defined workflows with supervisor approval for high-risk cases.
• Use risk signals such as new geography, new device, impossible travel, and recent change history before allowing recovery.

This is consistent with the broader lifecycle and remediation failures described in NHI Management Group’s research, especially the finding that only 20% of organisations have formal processes for offboarding and revoking API keys. The lesson is the same for user identity: credentials and trust relationships must be revoked or revalidated quickly, or attackers keep the advantage. Guidance from NIST SP 800-53 also supports tightening authentication recovery, access enforcement, and audit logging around identity changes.

Where current guidance suggests caution is in how much reliance to place on any single control. Passkeys materially improve phishing resistance, but they do not solve insider abuse, SIM swap style recovery abuse, compromised devices, or support-channel impersonation. These controls tend to break down in high-volume consumer support environments because exception handling becomes the attacker’s easiest path.

Common Variations and Edge Cases

Tighter recovery controls often increase user friction and support cost, so organisations have to balance fraud reduction against abandonment and help desk load. That tradeoff is especially visible in consumer apps, executive accounts, and regulated environments where downtime is expensive.

One common edge case is device loss. If recovery is too weak, attackers can hijack the account during replacement. If it is too strict, legitimate users get locked out and staff start bypassing the process. Another issue is cross-channel trust: an identity team may secure the web login but leave account resets exposed through contact-center scripts, email links, or legacy mobile flows. Current guidance suggests the safest pattern is to make every fallback path at least as strong as the passkey flow, but there is no universal standard for this yet.

For organisations with high fraud pressure, the right question is not whether passkeys are deployed, but whether every path that can reissue trust is instrumented, reviewed, and constrained. Research such as the GitLocker GitHub extortion campaign shows how quickly attackers exploit adjacent trust paths once a primary control is bypassed.

Related resources from NHI Mgmt Group

• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?
• How can organisations reduce the blast radius of compromised agent identities?
• When does a short-lived API key still create material risk?