Account recovery has become the new ATO attack surface

At a glance

What this is: This is a CISO-focused analysis of why account recovery has become the highest-risk identity pathway, with attackers increasingly bypassing login controls and targeting trust-based workflows instead.

Why it matters: It matters because IAM teams have to secure recovery, support, and privileged-change flows as identity controls, not treat them as convenience features that sit outside core access governance.

By the numbers:

• In 2025, criminals stole more than $262 million through account takeover schemes.
• 83% of organisations experienced at least one account takeover attack last year.
• 82% of phishing emails are now AI-generated., generated.

👉 Read Trusona's guide to preventing account takeover through recovery workflows

Context

Account takeover, or ATO, is a form of identity abuse where an attacker gains control of a legitimate account by exploiting weak verification, social engineering, or recovery workflows. The primary problem in this article is not login failure, but the trust assumptions built into support processes, reset flows, and exception handling.

That matters for IAM because recovery journeys are part of the identity plane, not side channels. When organisations rely on email access, phone possession, or knowledge-based answers, they create a control gap that attackers can turn into privileged access, fraud, or customer-facing compromise.

Key questions

Q: How should security teams reduce fraud risk in account recovery workflows?

A: Security teams should require multiple independent proofs for recovery actions, especially when the action can move money, change credentials, or restore access. Voice, video, and challenge questions should be treated as weak signals, not final authority. Stronger workflows combine step-up checks, transaction context, and manual review for high-risk cases.

Q: Why do email and phone-based identity checks fail in ATO attacks?

A: Email and phone possession are no longer strong proof of identity because attackers can buy breached data, intercept codes through SIM swaps, or impersonate victims with deepfake-assisted pretexts. Those signals may show channel access, but they do not reliably prove the person requesting access is legitimate.

Q: What breaks when recovery workflows are treated as convenience features?

A: Support teams end up making identity decisions without the controls normally applied to authentication or authorisation. That creates a low-friction route for attackers to obtain reset permissions, change factors, or alter account details, which is often enough to complete an account takeover.

Q: Who is accountable when a fraudulent recovery or approval occurs?

A: Accountability sits with the organisation that designed the workflow and the controls that govern it. If a recovery or approval path allowed action without adequate verification, that is a governance failure, not just a user mistake. Frameworks such as NIST Cybersecurity Framework 2.0 help teams assign control ownership and review the process.

Technical breakdown

Why account recovery flows become the real attack surface

Recovery flows are designed to restore access when a user is locked out, so they often relax the usual authentication checks. That makes them attractive to social engineers, especially when attackers can provide stolen personal data, hijacked phone numbers, or convincing pretexts. The technical failure is not the recovery workflow itself. It is the absence of strong identity assurance at the moment access is re-issued. In IAM terms, the recovery transaction becomes a privilege grant event, which means it needs the same scrutiny as any other authentication or authorisation step.

Practical implication: Treat recovery as a protected authentication path and apply step-up verification before access is reset or reissued.

Why legacy identity signals no longer prove who is asking

Email possession, knowledge-based questions, and even phone-based one-time codes are increasingly weak identity signals. Data breaches and social media make personal knowledge easy to guess, while SIM swaps and number-porting attacks let criminals intercept code delivery. Deepfake voice and video also reduce the value of human judgment in service desks and call centres. The core mechanism is signal substitution: attackers do not defeat verification, they impersonate the signals that verification expects. That is why identity assurance has to move from static indicators to authoritative validation.

Practical implication: Remove weak recovery factors from high-risk workflows and map each signal to a specific fraud or impersonation failure mode.

How high-risk identity decisions should be logged and governed

When account recovery, privileged actions, or financial changes are approved, the organisation is making an identity decision with downstream security consequences. Those decisions need traceability, fraud context, and clear ownership so that support staff do not become the weakest decision point in the chain. This is especially important in environments where customer portals, help desks, and privileged workflows share the same trust model. ATO succeeds when those decisions are treated as operational convenience rather than governed identity events.

Practical implication: Require audit trails for every recovery and account-change decision so investigators can reconstruct who approved what, when, and on what basis.

Threat narrative

Attacker objective: The attacker wants to bypass ordinary login controls by using the organisation's own recovery process to obtain trusted access and then monetise that access through fraud or deeper compromise.

1. Entry occurs through account recovery, help desk interaction, or another exception flow where the attacker presents enough stolen or fabricated identity evidence to be treated as legitimate.
2. Escalation happens when the attacker uses recovered access to reset authentication factors, intercept communications, or request privileged account changes without triggering stronger verification.
3. Impact follows when the attacker takes over the account, conducts fraud, changes financial details, or uses the foothold to broaden access across connected services.

Breaches seen in the wild

• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Account recovery is now a governed access path, not a support function. Organisations still design recovery as an operational exception, but attackers treat it as the fastest route to trusted access. Once that path is abused, the issue is not authentication failure at the login screen. The issue is that the identity programme allowed a lower-assurance pathway to issue higher-assurance access, which means recovery governance now belongs in IAM and fraud control together.

Legacy identity proofing creates account recovery trust debt: The use of email possession, phone numbers, and knowledge-based checks was designed for a world where those signals were harder to obtain or spoof. That assumption fails when data breaches, SIM swaps, and AI-assisted impersonation make those signals easy to counterfeit. The implication is that practitioners must re-evaluate which identity events are still safe to trust, because the old proofing model no longer matches the threat model.

Recovery workflows expose the identity blast radius concept: A single weak decision in support or exception handling can unlock customer portals, privileged changes, and downstream financial harm. That is why recovery can no longer be measured only by convenience or call resolution time. It has to be measured by the size of the blast radius if the decision is wrong, which makes ATO prevention a governance problem as much as a detection problem.

Identity assurance must become part of zero trust enforcement. Zero trust is not compatible with assuming that an account recovery request is legitimate just because it arrives through a familiar channel. Recovery is a decision point where trust is granted, so it needs stronger verification, traceability, and policy control than many login flows. Practitioners should treat high-risk recovery as an access-control event with fraud implications, not as a user-service exception.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• For a broader view of lifecycle failure modes, the 52 NHI Breaches Report shows how access that outlives governance becomes the breach path.

What this signals

Account takeover is increasingly a governance failure at the boundary between IAM, support, and fraud operations. As recovery pathways become the attacker's preferred entry point, security teams need to measure those journeys by assurance quality, auditability, and blast radius rather than convenience or completion time.

Recovery trust debt: this is the accumulation of weak proofing choices that remain in place because they were once operationally acceptable. The next programme priority is to identify where those legacy signals still control access decisions and replace them before attackers do.

With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, per The State of Non-Human Identity Security, it is clear that identity governance gaps are not limited to end users. Recovery, delegation, and third-party access all need the same assurance standard.

For practitioners

• Harden recovery as a high-risk access path Apply stronger verification to password resets, account unlocks, and recovery escalation flows before credentials or factors are reissued. The recovery journey should be governed like any other privileged access request, not handled as a low-friction support action.
• Replace weak proofing signals Retire knowledge-based questions and phone-possession checks for sensitive workflows, and use authoritative identity validation where the business impact of impersonation is high. This is especially important for customer portals, help desks, and financial changes.
• Instrument support decisions for auditability Log who approved each recovery or privileged change, what evidence was used, and whether step-up verification was required. That gives security, fraud, and compliance teams a defensible record when incidents are investigated.
• Map ATO paths to fraud and IAM controls Review account takeover scenarios jointly across IAM, PAM, support operations, and fraud teams so recovery abuse is not treated as a siloed issue. Use the attack path to identify where identity decisions need stronger policy enforcement.

Key takeaways

• Account takeover succeeds when recovery workflows are trusted more than the identity signals behind them.
• The evidence points to a broad control gap, with organisations losing hundreds of millions to ATO and still relying on weak verification paths.
• IAM teams should govern recovery like an access-control event, with stronger verification, auditability, and cross-team accountability.

Key terms

• Account Recovery: Account recovery is the process used to restore access when a user cannot authenticate normally. In mature IAM programmes, recovery is treated as part of the trust chain because a weak reset path can bypass stronger login controls and become the easiest route to account takeover.
• Account Takeover: Account takeover is unauthorized use of a legitimate account after an attacker obtains valid access through stolen credentials, tokens, or trusted integrations. The key security problem is that the resulting activity often looks normal to logs and controls, which makes containment and attribution harder than in a forced-entry breach.
• Identity Assurance: The confidence an organisation has that a person or system is truly who it claims to be before access or action is granted. In modern IAM, assurance depends on evidence quality, channel trust, and the strength of verification around high-risk decisions.
• Recovery Workflow: A recovery workflow is the sequence of checks and actions used to restore access after a credential issue or account lockout. It includes verification, credential issuance, synchronization, and audit logging. Weak recovery workflows are attractive to attackers because they often sit outside the strongest authentication controls.

What's in the full article

Trusona's full article covers the operational detail this post intentionally leaves for the source:

• The account recovery and support workflow examples that show where impersonation typically succeeds.
• The practical deployment pattern for adding authoritative identity verification without redesigning the entire identity stack.
• The fraud, customer experience, and incident response angles that matter once recovery abuse has already occurred.
• The product-specific implementation guidance for securing high-risk workflows such as resets, privileged actions, and external portals.

👉 Trusona's full post covers the recovery-path attack surface, identity verification logic, and deployment examples.

Deepen your knowledge

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