Account Takeover Fraud: Protect Recovery and High-Risk Changes

Account takeover fraud occurs when someone gains unauthorized access to another person's existing account. Stolen credentials may get an attacker to the login screen. A compromised recovery channel or a convincing call to support may let them replace the factor that was supposed to keep them out.

That makes recovery a security decision, not an administrative shortcut. Before restoring access, a business needs evidence about the person making the request, a way to connect that evidence to the right account, and a policy for deciding what happens next.

What is account takeover fraud?

The FBI's Internet Crime Complaint Center describes account takeover as unauthorized access to an existing online account, such as a bank, payroll, health savings, or social media account, with the goal of stealing money or information.

Unlike synthetic identity fraud, account takeover starts with an account that belongs to a real user. The attacker is trying to act through that account or take control of it.

How do attackers take over accounts?

Attackers can use credentials exposed in a breach, phishing, malware, weak or reused passwords, and social engineering. They may also target the channels used to recover access. A SIM swap, for example, can put SMS codes in the wrong hands, as the FTC explains.

These paths can reinforce each other. An attacker with a password may still need a second factor. Instead of defeating that factor at login, they may try to reset it through support or a recovery flow. The business then faces a different question: who is allowed to replace the means of signing in?

Why recovery needs its own controls

Recovery must work precisely when a legitimate customer cannot use the credential the login flow normally checks. A reset link, phone-number change, device replacement, or agent-assisted MFA reset can create a new route into the same account.

NIST's digital identity guidance addresses account recovery separately from ordinary authentication and describes different recovery methods. The right method depends on the account and its risk. A help desk should not treat a plausible story, familiar personal details, or possession of a newly supplied contact channel as sufficient proof of account ownership.

Protect recovery as a boundary of its own: define acceptable evidence, decide when to hold or escalate a request, and notify the account holder through an established channel when appropriate.

Where MFA stops and identity verification helps

MFA checks whether a claimant controls an additional authenticator. Phishing-resistant factors make unauthorized sign-in harder. But when someone says a factor is lost, MFA cannot by itself tell the business who should receive its replacement.

Identity verification can add evidence about the person requesting recovery. Depending on the flow, that may include a checked identity document, a supported digital credential, and a check connecting the presenter to the evidence. The result still has to be matched to the account owner and the pending request. A passed identity check does not, by itself, authorize a reset.

See the distinction between identity verification and authentication.

When should a business ask for stronger evidence?

Apply more friction where an impersonator could cause greater harm. Candidates include:

• Account recovery or MFA replacement: before issuing a new way to sign in.
• Contact-detail changes: before replacing the email address or phone number used for alerts and recovery.
• Payout changes or large withdrawals: before funds move to a new destination or a high-value transaction completes.
• Help desk access requests: before an agent resets a worker's credentials or grants access. See workforce identity verification.

These are policy decisions, not automatic outcomes of a verification check. Consider notifying the account owner through a previously trusted channel after recovery, consistent with NIST's recovery guidance.

How to add identity verification to recovery

Start with one action where a mistaken reset would matter. Decide when the check is required, which evidence is acceptable, and how your team will handle a failed or incomplete check.

1. Create a request associated with the account and the specific recovery action.
2. Collect appropriate identity evidence through a supported digital ID or a document check with liveness.
3. Validate the result on your server. Verify its signature, match it to the pending request, and reject expired or previously processed results.
4. Apply your recovery policy. Approve, deny, or send the case to review. Issue a new authenticator only after that decision.
5. Record the decision and notify. Keep the audit evidence your process requires and alert the account holder through an established channel.

Stile supplies identity evidence and a signed result that your workflow can connect to the recovery request. Your team remains responsible for matching the person to the account, deciding whether they may regain access, and securing the account after recovery. Explore account takeover prevention, or follow the quickstart.