What is account takeover? How ATO attacks work and how to prevent them

Account takeover (ATO) is when someone other than the account holder gains control of an account and uses it as if they were that person. Attackers reach it through four doors: the sign-in form, the MFA step, account recovery, and sessions that are already open. Preventing ATO means closing all four, not only the login form.

Credential stuffing, phishing, SIM swapping and stolen session cookies are routes to the same result. Hardening the sign-in form is the obvious first step, and it only closes one of the four doors. This page defines account takeover, separates it from the attacks that cause it, walks through each door, and says what detection and prevention look like at each one.

What is account takeover?

Account takeover, usually shortened to ATO, is when someone other than the account holder gains control of an account and uses it. The attacker does not need to break your application. They need to be accepted by it as a legitimate user, once.

The damage falls into three buckets. Fraud, when the account can move money, place orders, or spend credits. Data exposure, when the account can read customer records, exports, or internal documents. And trust, which is the one you cannot patch: a user whose account was taken over on your product remembers that longer than any outage.

Scale is easiest to see in consumer reporting. The FBI's 2025 Internet Crime Report records 1,008,597 complaints to the Internet Crime Complaint Center, up from 859,532 in 2024, with phishing and spoofing among the most frequently reported complaint types. Cyber-enabled crime in that report cost Americans nearly $21 billion.

On the enterprise side the picture shifted this year. In the 2026 Verizon Data Breach Investigations Report, exploitation of vulnerabilities became the most common initial access vector at 31%, while credential abuse, the previous leader, fell to 13%. Credentials did not stop mattering: the human element was present in 62% of breaches, up from 60%. Attackers moved up the stack, but accounts are still the prize.

What causes account takeover?

Most of the terms people use interchangeably with account takeover are methods, and each method targets a specific door. OWASP draws the line between the sign-in attacks precisely: brute force tests multiple passwords against a single account, credential stuffing tests username and password pairs obtained from the breach of another site, and password spraying tests a single weak password against a large number of different accounts.

How do attackers get in through the sign-in form?

This is the door everyone defends, and it is still the loudest. The attacker brings credentials from somewhere else and tries them at volume.

Rate limiting by IP address is the usual first move and the weakest one. OWASP notes that credential stuffing toolkits such as Sentry MBA ship with built-in proxy networks that distribute requests across a large volume of unique IP addresses, which can defeat both IP blocklists and per-IP rate limits. Device fingerprinting raises the cost, but OWASP is equally clear that client-side defenses such as fingerprinting or JavaScript challenges can be spoofed or bypassed, so the layers behind them have to assume they will be.

The cheapest durable win at this door is refusing known-breached passwords at the moment they are set. OWASP points to ASVS v4.0 provision 2.1.7 on checking new passwords against breached password datasets, and names Pwned Passwords as a free service for it. A stuffing list only works if the password on your side matches the one on the breached side.

One sign-in path gets missed because it does not look like a login form: social sign-in that attaches an incoming OAuth identity to an existing account by email address alone. Read the three ways that broke in real projects before you implement account linking.

How do attackers get past MFA?

MFA is the highest-value control at the sign-in door. OWASP calls it by far the best defense against the majority of password-related attacks, including credential stuffing and password spraying. It is also the control attackers have spent the most effort routing around, and the routes are now off-the-shelf tooling.

Adversary-in-the-middle phishing proxies your real sign-in page, relays the user's password and one-time code in real time, and keeps the resulting session. NIST is blunt about why this works: out-of-band authentication is not phishing-resistant, and OTP authentication is not phishing-resistant. A code a human can read and type is a code a human can be tricked into typing somewhere else.

Push approvals fail differently. In SP 800-63B-4, NIST no longer accepts out-of-band methods where the subscriber only compares and approves a request, citing authentication fatigue attacks in which an attacker generates many requests until the subscriber approves one to make them stop. The standard now requires a secret to be transferred between the out-of-band device and the primary channel, such as typing a code shown on the sign-in screen into the phone.

The fix NIST writes into the standard is availability, not user education: verifiers must offer at least one phishing-resistant authentication option at AAL2, and AAL3 requires a phishing-resistant authenticator with a non-exportable private key. Offering passkeys while leaving SMS enabled as a fallback leaves the weaker factor as the one an attacker will choose, which is the subject of passkeys stop phishing, your MFA fallbacks undo it.

How is account recovery used to take over accounts?

Recovery is where a strong password and a passkey get bypassed rather than beaten. The classic version is a SIM swap: an attacker convinces a mobile carrier to move the victim's number to a SIM they control, with port-out fraud as the close variant. Any secret sent over SMS then goes to the attacker. In November 2023 the FCC adopted rules requiring carriers to authenticate customers more rigorously before SIM changes and port-outs, notify customers of those requests, and offer account locks. The bar moved, but the dependency on a carrier's identity check did not go away.

Four requirements in SP 800-63B-4 tighten this door directly:

• Use of the phone network for out-of-band verification is restricted, and verifiers should weigh risk indicators such as device swap, SIM change and number porting before sending a secret over it.
• Setting or changing the pre-registered phone number counts as binding a new authenticator, not as editing a profile field.
• An email inbox does not count as an authenticator: NIST does not allow email for out-of-band authentication, so a code sent to email can prove control of the address but cannot stand in for a second factor.
• Issued recovery codes expire: 10 minutes when sent by text message or voice, 24 hours by email, and 21 days by post within the contiguous United States.

Recovery at AAL2 is also not a single step. NIST requires two recovery codes obtained by different methods, or one recovery code plus authentication with a single-factor authenticator already bound to the account, or repeated identity proofing. Security questions are out: OWASP advises against them as an authentication challenge, pointing at ASVS 5.0 requirement 6.4.2, which excludes knowledge-based questions.

If your recovery path still leans on SMS codes, why SMS is not a secure MFA method covers the channel, and OTP bots covers the automation that harvests those codes at scale.

How are open sessions hijacked?

The last door needs no credentials at all. An attacker holding a stolen cookie or token skips authentication entirely, which is why token replay is the attack MFA cannot help with.

NIST treats the session as its own security boundary. A relying party must not interpret the presence of an access token as an indicator that the subscriber is present. Session secrets are erased or invalidated when the subscriber logs out, and bearer-token session secrets should not be persistent. Session cookies must only be sent over HTTPS, should be HttpOnly, and should set SameSite to Lax or Strict.

Time limits do the rest of the work. At AAL2 the overall reauthentication timeout should be no more than 24 hours and the inactivity timeout no more than one hour, against 30 days at AAL1.

What are the signs an account has been taken over?

Detection here is about noticing the shape of a session rather than the credential behind it. NIST lists the session characteristics worth monitoring: usage patterns, velocity and timing, behavioral biometrics, device and browser characteristics, geolocation, and IP address characteristics. The signals that matter in practice:

• An unrecognized device signing in, with no prior history on the account.
• Impossible travel: two successful sign-ins from locations too far apart for the time between them. How that detection works, including its false positives, is its own post.
• A changed recovery email, phone number or MFA method, especially soon after a sign-in from somewhere new.
• Concurrent sessions from new locations, or a dormant account that suddenly becomes active.
• A correct password followed by a failed MFA challenge. OWASP singles this one out as worth telling the user about, because it means someone already has the password.

Two design decisions make those signals usable. Notify out of band: NIST requires a notification through an independent channel when an authenticator is added and whenever account recovery happens, and requires support for at least two notification addresses per account. And show users their own sessions, with a way to end the ones they do not recognize, which OWASP recommends for any app that allows concurrent sessions.

One caveat worth keeping. NIST allows fraud indicators such as an unexpected geolocation or IP block to inform risk, but says explicitly that using them does not change the assurance level of a transaction or substitute for an authentication factor. Risk signals should lower the bar for a challenge, never replace one.

How do you prevent account takeover?

Layers do not each stop one attack. They raise the number of independent things an attacker has to get right. By door:

Common questions

Does MFA prevent account takeover?

It prevents most of the cheap, automated versions. OWASP calls MFA by far the best defense against the majority of password-related attacks. It does not prevent the targeted versions, because NIST states plainly that out-of-band and OTP authentication are not phishing-resistant, and an adversary-in-the-middle proxy or a stolen session cookie bypasses the challenge entirely. MFA moves the attacker from the sign-in door to the other three.

What is the difference between account takeover and credential stuffing?

Account takeover is the result. Credential stuffing is one technique for reaching it, defined by OWASP as testing username and password pairs obtained from the breach of another site. Brute force, password spraying, phishing, SIM swapping and session theft are alternative techniques with the same destination.

Is SMS-based MFA good enough?

NIST classifies out-of-band verification over the public phone network as restricted and tells verifiers to weigh risk indicators such as SIM change and number porting before sending a secret over it. It beats no second factor, and it is weaker than authenticator apps and passkeys. Treat it as a fallback you are actively migrating users off.

What should I log so an ATO is investigable afterwards?

Enough per attempt to reconstruct the session: device, location, user agent, IP address and the time of the attempt. Add the authenticator lifecycle on top, since NIST requires a notification whenever an authenticator is bound or account recovery runs. Without those two streams you can tell a user their account was taken over, but not when it started or which door it came through.

Where do AuthKit and Radar fit?

AuthKit covers the factors and the session clocks. It ships passwords, passkeys and MFA, per-organization sign-in policies such as requiring SSO or MFA for a given customer Confirm, and drop-in widgets for profiles and active sessions. Session behavior is three settings on the application: maximum session length, access token duration, and inactivity timeout. The inactivity timeout has to be longer than the access token duration, and both have to be shorter than the maximum session length; this post explains how to pick them. To end a session before its limit, revoke it with POST /user_management/sessions/revoke and list a user's live sessions with GET /user_management/users/:id/sessions, as covered in sign out everywhere with the Sessions API. Revoking stops the session from being refreshed, and access tokens already issued stay valid until they expire, which is the real argument for a short access token duration.

Radar covers detection on sign-in and sign-up attempts. It detects bots, including AI agents and search engine crawlers, brute force attacks, impossible travel, unrecognized devices, and stale accounts with no successful sign-in in 60 days, and it blocks disposable or known fraudulent email domains. You can add custom allow and deny rules for IP ranges, user agents, devices and users. For each event it records device, location, user agent and IP address, which is the record you want when you investigate a suspected takeover. How Radar works goes deeper.

Sources

• 2026 Verizon Data Breach Investigations Report, executive summary
• FBI 2025 Internet Crime Report announcement
• NIST SP 800-63B-4, Authentication and Authenticator Management (including the session management and authenticator events and account recovery sections)
• OWASP Credential Stuffing Prevention Cheat Sheet
• FCC Report and Order on SIM swap and port-out fraud (November 2023)
• WorkOS Radar docs and AuthKit session settings