Account Takeover Prevention Guide

Account takeover happens when someone other than the customer gains control of a genuine account, and most of the damage is done after a login that looks legitimate. Attackers reach accounts through reused passwords, phishing that relays one-time codes, stolen session cookies, SIM swaps and, increasingly, the account recovery and support channels that exist to help locked-out customers. The FBI's Internet Crime Complaint Center reported more than 5,100 account takeover complaints with losses exceeding $262 million between January and late November 2025 for one scheme alone: criminals impersonating financial institution support staff. This guide covers attack paths, login-time and post-login controls, session risk scoring, recovery abuse, metrics and a response playbook for consumer accounts, for fraud, customer identity (CIAM), application security and contact centre teams.

Key takeaways

• Treat the login as the start of the risk, not the end. Stolen session cookies and relayed one-time codes produce successful, MFA-satisfied logins, so sensitive actions after login need their own checks.
• Remove the value of a stolen password. Phishing-resistant passkeys, breached-password screening and throttling within the limits NIST SP 800-63B-4 sets make credential stuffing and spraying unprofitable.
• Account recovery is a login path. Password reset, phone number change and support-assisted recovery must be held to the same standard as sign-in, or attackers will use them instead.
• Score the session and the action together. A new device is weak evidence on its own; a new device, a changed email address and a new payee within ten minutes is strong evidence.
• Contain completely. Resetting the password is not enough: revoke sessions and tokens, remove attacker-added factors, devices and recovery details, and reverse what the attacker changed.

How accounts are taken over

MITRE ATT&CK v20 places password attacks under T1110 Brute Force with four sub-techniques, and session theft under T1539 Steal Web Session Cookie. In OWASP's terms, brute force tries many passwords on one account, credential stuffing replays pairs from another site's breach, and spraying tries one weak password on many accounts. The table maps the main entry paths to the control that removes most of their value.

Phishing and account takeover are closely linked: the IC3 alert describes criminals using texts, calls and emails to obtain credentials including MFA codes, logging into the real site, resetting the password, and buying search adverts so their phishing pages appear above the genuine bank. For the specific mechanics of push bombing, SIM swaps and downgrade attacks, see the MFA Fatigue and Bypass Guide.

What attackers do after login, by sector

Post-login fraud follows the money. What an attacker wants tells you which actions need step-up authentication and delays.

Email takeover compounds: whoever controls the inbox receives every reset link sent to it. NIST SP 800-63B-4 forbids email as an out-of-band authenticator, although email reset links remain common. See the Email Identity and BEC Guide.

Login-time defences

NIST SP 800-63B-4 (final, July 2025) is the clearest public baseline for consumer authentication even outside US government. Its rules remove several habits that weaken accounts without slowing attackers.

• Offer a phishing-resistant option: at AAL2 verifiers must offer at least one phishing-resistant authenticator. Passkeys bind to the genuine origin, so a relay site cannot use them. See the Passwordless and Passkeys Guide.
• Password rules that help: at least 15 characters when the password is the only factor and at least 8 when it is part of MFA, a maximum of at least 64, no composition rules, no periodic changes, password managers and autofill allowed, and every new password checked against a blocklist of commonly used, expected or compromised values. OWASP also recommends checking against breached-password datasets such as Pwned Passwords.
• Throttling within limits: limit consecutive failed attempts to no more than 100 per authenticator, using bot challenges, increasing waits (NIST's example runs from 30 seconds to an hour) and risk-based techniques before that point. Hard lockouts after a handful of failures let attackers lock customers out deliberately.
• Restricted SMS: SP 800-63B-4 classes SMS and voice codes as restricted and says verifiers should check for device swap, SIM change or number porting before sending a code. Changing a registered phone number counts as binding a new authenticator, so it needs authentication at the account's level.
• Uniform responses: return the same message and timing for an unknown user and a wrong password, on sign-in, reset and sign-up, so the login cannot enumerate valid accounts.
• Bot and device signals: classify IP addresses (residential, hosting, proxy), cross-check connection fingerprints against the claimed client, and keep each account's IP and device history. OWASP advises prompting for additional authentication on a device mismatch rather than blocking, because customers own several devices. See the Bot Management Guide and the Device Intelligence and Fingerprinting Guide.

Do not use security questions: OWASP says an extra PIN or memorable word is not a second factor, and NIST prohibits knowledge-based questions and password hints.

Session risk scoring and post-login fraud

Session risk scoring evaluates the whole session, not just the login, and decides whether a sensitive action proceeds, needs step-up, waits or is blocked. NIST notes that fraud indicators may lower misauthentication risk but do not change the assurance level or replace an authentication factor, so scoring supplements authentication rather than standing in for it.

Protecting sensitive actions

• Step-up authentication: require fresh authentication before changing email, phone, password or MFA methods, adding a payee, raising limits, changing a delivery address on a pending order or transferring points. OWASP recommends step-up before large transactions and privileged configuration changes.
• Reauthentication windows: SP 800-63B-4 says AAL2 sessions should require reauthentication at least every 24 hours and after an hour of inactivity, and AAL3 sessions no more than 12 hours overall and should time out after 15 minutes of inactivity. Long-lived "remember me" cookies are what infostealers harvest.
• Cooling-off periods: after a contact detail or credential change, delay high-risk actions (new payees, withdrawals, points transfers) for a set period and notify the old email address or phone number, so the real customer can stop it.
• Session visibility: show the previous login's time and location and let customers end sessions they do not recognise.

For cookie attributes, token lifetimes, refresh token rotation and binding sessions to devices, see the Token and Session Security Guide.

Account recovery and support channels

When login is hardened, attackers move to recovery. The Meta AI Instagram account takeover showed an AI support assistant sending account recovery links to attackers, and the Coinbase insider breach showed that bribed support agents can expose the customer data attackers then use to impersonate customers.

• Reset tokens: OWASP's Forgot Password guidance calls for random, sufficiently long, single-use, expiring tokens tied to one user; reset links built from a fixed or allowlisted host, never the request's Host header; a no-referrer policy on the reset page; and rate limits on reset requests.
• No automatic sign-in after reset: make the customer sign in normally, and offer or force termination of all existing sessions.
• Two methods per customer: NIST recommends encouraging at least two separate means of authentication so that losing one does not force a weak recovery path.
• Notify old contact points: when an email address, phone number or recovery detail changes, notify the previous address or number with a clear way to reverse the change.
• Contact centre controls: agents should never ask customers to read out one-time codes; verification should use in-app confirmation or a callback to a number already on file; agent tools should show the session risk and recent changes; and changes made by phone should trigger the same cooling-off as online changes. The FFIEC's 2021 authentication guidance for US financial institutions explicitly covers customer call centres and requires enhanced controls for account maintenance such as address, password and enrolled device changes.
• AI and chat support: assistants must not be able to change contact details, disable MFA or issue recovery links without the same verification a human process requires.

See the Account Recovery and Help Desk Security Guide.

Choosing an approach

• Smaller organisations: start with the controls built into your identity platform: passkeys or app-based MFA, a breached-password check, throttling, notifications on contact changes and step-up before payment or contact changes. These remove most opportunistic takeover without a dedicated fraud team.
• Larger organisations: add a session risk engine that combines device, network and behavioural signals with business events, a dedicated bot layer, contact centre integration and case management. See the Fraud Prevention Guide for Digital Businesses.
• Regulated finance: in the UK and EEA, remote payments generally need strong customer authentication linked to the amount and payee; see the Payment Fraud Guide for exemptions.

Detection and measurement

Log every authentication and account maintenance event with the account identifier, outcome, authenticator type, device identifier, IP address and classification, user agent, session identifier and channel (web, app, API, contact centre, chat). NIST SP 800-63B-4 says the record of authenticator bindings should include the date and time of lifecycle events and should capture the source, such as IP address and device identifier. ATT&CK's detection strategy for T1110 (DET0463) describes the core analytics: many failures followed by a success, failures followed by success from the same IP or user, and attempts across a user pool in a short interval.

Metrics that show it is working

• Confirmed takeover rate: confirmed takeovers per 10,000 active accounts per month, split by entry path.
• Login success ratio: successful logins as a share of attempts per hour; a sudden fall signals stuffing.
• Phishing-resistant coverage: share of active accounts with a passkey registered, and share of logins that use one.
• Time to contain: minutes from first detection to session revocation and factor clean-up.
• Step-up outcomes: challenge pass, fail and abandonment rates per action, to tune friction for genuine customers.
• Loss per takeover: money, points or goods lost per confirmed case, which shows whether post-login controls are working.

Responding to a confirmed takeover

1. Contain: revoke all sessions, refresh tokens and remembered devices; invalidate the compromised authenticator (NIST requires a mechanism to do this immediately when compromise is suspected).
2. Remove persistence: delete attacker-added MFA methods, devices, recovery emails and phone numbers, forwarding rules, linked apps, OAuth grants and API keys.
3. Restore the owner: re-verify the customer through a channel the attacker did not control, then rebind authenticators, encouraging a passkey.
4. Reverse the damage: stop pending orders and transfers, reverse points movements, request recalls of payments and flag receiving accounts.
5. Share signals: where you federate or rely on other providers, send OpenID RISC events such as credential-compromise or account-disabled with the reason hijacking, and CAEP session-revoked so relying parties end their sessions too.
6. Learn: record the entry path and the first anomalous signal, and adjust rules. For bulk exposures from an external breach, see the Leaked Credential Response Playbook.

How to implement

1. Baseline (weeks 1 to 4): inventory every login, recovery and maintenance path, centralise their logs, and measure takeover rate and login success ratio.
2. Quick wins: turn on breached-password screening, uniform responses, throttling and notifications for contact and credential changes.
3. Shadow scoring: run session risk rules in log-only mode for two to four weeks, compare their decisions against confirmed fraud and genuine customer outcomes, and estimate challenge volumes before enforcing.
4. Pilot enforcement: enforce step-up and cooling-off for one high-value action (for example new payee or points transfer) on a small percentage of traffic, with contact centre staff briefed.
5. Passkey rollout: offer passkey enrolment after a successful sign-in, then reduce reliance on SMS for recovery once coverage grows.
6. Expand and tune: extend scoring to all sensitive actions and channels and review false positives weekly.
7. Rollback: keep every rule behind a feature flag with a named owner, so a rule causing mass challenges can be returned to log-only mode within minutes without a code release.

Where identity fits

Account takeover is a customer identity problem first: the attacker is impersonating a real person to an identity provider, and the tokens issued after login are what they keep. Customer accounts also create non-human credentials, such as API keys, personal access tokens and OAuth grants to third-party apps, which survive a password reset unless they are revoked explicitly. Include them in containment and show them to customers in account settings. See the Customer IAM (CIAM) Guide.

Framework mapping

Common failure patterns

• Treating stuffing as a password-strength problem: stuffed passwords may be long and complex; they are simply reused. The 23andMe breach began with stuffing against about 18,000 accounts and, through a data-sharing feature, reached data on nearly 7 million people.
• MFA optional where it matters: the Snowflake breach showed infostealer-harvested credentials unlocking customer environments that had no MFA enforced.
• Recovery weaker than login: a strong passkey sign-in undermined by an SMS-only reset, a support agent who changes email addresses on request, or a chatbot that issues recovery links.
• Password reset as the whole response: leaving sessions, remembered devices, attacker-added phone numbers and OAuth grants in place lets the attacker straight back in.
• Blocking on geolocation alone: impossible travel rules without device and session context generate high false positive rates, so analysts learn to ignore them.
• Unprotected side doors: the web form has bot protection, but the mobile API, the voice channel and a legacy login page do not.

Practitioner checklist

• Map every login, recovery and account maintenance path, including APIs, contact centre and chat.
• Offer passkeys to all customers and track enrolment and usage.
• Screen passwords against breached and common lists at creation and on login.
• Throttle failed attempts per account, device and network within the NIST 100-attempt ceiling, without hard lockouts that attackers can trigger.
• Require step-up authentication and a cooling-off period after contact or credential changes before payees, withdrawals, address changes or points transfers.
• Notify the previous email address or phone number of every contact detail change.
• Check SIM-change and porting signals before relying on SMS codes.
• Prohibit staff and assistants from requesting one-time codes or changing contact details without verification.
• Write a containment runbook that revokes sessions, tokens, devices, added factors and OAuth grants.
• Report confirmed takeover rate, time to contain and loss per takeover monthly.

Standards and references

• NIST: SP 800-63B-4 Digital Identity Guidelines, Authentication and Authenticator Management
• OWASP: Credential Stuffing Prevention Cheat Sheet
• OWASP: Forgot Password Cheat Sheet
• MITRE ATT&CK: T1110 Brute Force
• MITRE ATT&CK: T1539 Steal Web Session Cookie
• OpenID Foundation: RISC Profile Specification 1.0
• FFIEC: Authentication and Access to Financial Institution Services and Systems
• FBI IC3: Account Takeover Fraud via Impersonation of Financial Institution Support

Related NHI Mgmt Group resources: Customer IAM (CIAM) Guide · Bot Management Guide · MFA Fatigue and Bypass Guide · Token and Session Security Guide · Account Recovery and Help Desk Security Guide