What is account takeover (ATO)?
By Identra · Updated
An account takeover (ATO) is an attack in which someone gains unauthorized control of a legitimate user account, typically by stealing credentials or hijacking a session, then operates inside it as the real owner. ATO is the entry point behind many serious breaches because a valid login inherits every permission the account already holds.
Key numbers
- 22% of breaches began with credential abuse, the top initial access vector (Verizon Data Breach Investigations Report, 2025)
- 62% of monitored organizations suffered at least one account takeover in 2024 (Proofpoint, 2025)
- 65% of accounts compromised in 2024 had MFA enabled (Proofpoint, 2025)
- Roughly 1% of users approve the first fraudulent MFA push they receive (Microsoft, 2022)
How do attackers take over accounts?
Most account takeovers start with one of four techniques. None of them requires a software vulnerability. Each one abuses the way people authenticate, which is why ATO scales so well for attackers and why it keeps working year after year.
The numbers back this up. Verizon's 2025 Data Breach Investigations Report found that credential abuse was the single most common way breaches began, ahead of vulnerability exploitation and phishing, and that 88% of basic web application attacks involved stolen credentials.
| Technique | How it works | What it defeats |
|---|---|---|
| Phishing and AiTM proxies | The victim signs in through an attacker-controlled page that relays the credentials and MFA code to the real site in real time | Passwords and one-time codes |
| Credential stuffing | Bots replay username and password pairs leaked from other breaches against your login page | Reused passwords |
| Session theft | Infostealer malware or a phishing proxy grabs session cookies and tokens, so the attacker skips login entirely | Passwords and MFA together |
| MFA fatigue | An attacker who already has the password floods the user with push prompts until one gets approved | Push-based MFA |
Why is ATO the entry point behind so many breaches?
A stolen account is the cheapest possible foothold. The attacker does not need an exploit, does not trip an antivirus alert, and does not have to build persistence from scratch. They simply log in, and from that moment every request they make carries the identity, permissions, group memberships, and OAuth grants of a legitimate user.
That is what makes ATO so hard to spot with traditional controls. Firewalls and endpoint tools are looking for malicious code and network anomalies, but an account takeover produces neither. It produces valid, authenticated activity from a real account. The only thing wrong with the session is who is driving it, which is why so many major incidents trace back to a single compromised login that was then used for reconnaissance, privilege escalation, and data theft.
Why doesn't MFA stop account takeover?
MFA raises the cost of ATO, but attackers have industrialized their way around it. Proofpoint's analysis of 2024 account takeovers found that 65% of compromised accounts had MFA enabled. Adversary-in-the-middle phishing kits relay one-time codes in real time, and phishing-as-a-service platforms sell that capability by subscription.
MFA fatigue attacks the human instead of the protocol. Microsoft observed more than 382,000 MFA fatigue attempts in a single year and found that about 1% of users approve the very first fraudulent push they receive. At enterprise scale, 1% is a reliable way in.
Session theft sidesteps MFA entirely. Once a user has authenticated, the session cookie or token is the proof of identity. Steal that token and MFA never comes into play again until the token expires. Phishing-resistant methods such as passkeys close the relay hole, but they do not protect a session that has already been minted.
Detection in the live session vs after the fact
Most organizations discover ATO after the fact: a suspicious mailbox rule, a fraud complaint, a data-exfiltration alert, then a forensic review of weeks of logs. By that point the attacker has finished the part of the operation that mattered to them.
Detecting ATO in the live session means treating authentication as the start of scrutiny, not the end of it. The signals are there while the attacker is still active: a login from an impossible location or a new device fingerprint, a session token replayed from different infrastructure, an unusual OAuth consent, a burst of data access that does not match the account's history.
Response has to match that timescale. Resetting a password does nothing if the attacker holds a valid session token. Effective containment revokes the live session and its tokens, forces re-authentication, and unwinds whatever persistence was added, such as new mailbox rules, app consents, or spare MFA methods.
Does account takeover apply to non-human identities?
Yes, and often with less friction. Service accounts, API keys, OAuth application credentials, and AI agents authenticate with static secrets or tokens, so there is no push prompt to fatigue and no user to notice something odd. A leaked secret is an instant, silent takeover of an identity that frequently carries broad privileges and no MFA at all.
As non-human identities come to outnumber human ones in most environments, the takeover surface shifts with them. The same discipline applies: watch what the identity does after authentication, not just whether the credential was valid at login.
How Identra thinks about it
We treat account takeover as fundamentally a runtime problem. Credentials will keep leaking, MFA will keep getting relayed or fatigued, and tokens will keep getting stolen, so the durable control is watching what every identity, human, non-human, or AI agent, actually does inside the live session and cutting access the moment behavior stops matching the identity. Treating login as the last checkpoint is how takeovers stay invisible for weeks; treating the session itself as the thing to secure is how they get caught in minutes.
Go deeper: The Non-Human Majority
Frequently asked questions
How do attackers take over accounts?
Four techniques dominate: phishing through adversary-in-the-middle proxies that relay credentials and MFA codes in real time, credential stuffing with password pairs leaked from other breaches, session theft where malware or proxies steal cookies and tokens, and MFA fatigue, where the attacker floods a user with push prompts until one is approved. None requires a software vulnerability.
Can MFA prevent account takeover?
MFA raises the cost but does not eliminate ATO. Proofpoint found 65% of accounts compromised in 2024 had MFA enabled. Phishing kits relay one-time codes in real time, fatigue attacks harvest push approvals, and session theft skips login entirely by stealing the token minted after authentication. Phishing-resistant methods like passkeys close the relay hole but not stolen sessions.
How do you detect an account takeover?
Look for live-session signals rather than waiting for forensic review: logins from impossible locations or new device fingerprints, session tokens replayed from different infrastructure, unusual OAuth consents, new mailbox rules, and bursts of data access that do not match the account's history. The account is valid; what changed is who is driving it.
What should you do after an account takeover?
Resetting the password is not enough if the attacker holds a valid session token. Effective containment revokes the live session and its tokens, forces re-authentication, and unwinds persistence the attacker added, such as new mailbox rules, OAuth app consents, or spare MFA methods. Then review what the account touched while compromised.