TL;DR: account takeover fraud explained
- What sets ATO apart: ATO is not new account fraud and it is not payment fraud: the attacker inherits a real account with real history, verified payment methods, and established trust signals, so the fraudulent activity blends in and post-hoc detection is significantly harder.
- The evidence: Javelin found $13.5B in US ATO losses in 2025 across 6 million victims, an 18% year-on-year jump, while Verizon DBIR 2026 shows stolen credentials appear in 39% of all breaches. Server-side rate limits do not stop residential-proxy stuffing at human-equivalent request rates.
- The decision: If you already run login rate limiting, IP reputation, and CAPTCHA, the missing piece is a per-session verdict at authentication that flags device ID change, TLS-based VPN, and session cadence anomalies before the POST, so step-up only fires for risky sessions.
Short on time? See cside's account-takeover detection. It covers everything below in one deployment.
Account takeover fraud (ATO) is when an attacker uses stolen credentials to log into an existing account that belongs to someone else. Because the account is real, with real history and saved payment methods, the fraud is hard to spot once it happens.
ATO is different from new account fraud, which creates fake accounts from scratch, and from payment fraud, which targets individual transactions without first compromising an account. In ATO the attacker inherits a real account with real history, real payment methods, and real trust signals, so the fraudulent activity blends in with normal behavior. The fuel for these attacks is credential availability: breach databases holding hundreds of millions of email and password pairs are widely circulated and cheap to buy.
How ATO differs from other fraud types
Account takeover fraud is commonly confused with new account fraud and payment fraud, but the three are distinct attack types that need different prevention controls and hit at different points in the user journey.
Account takeover fraud compromises an existing account using valid credentials. The account has legitimate history. The attacker inherits the trust signals tied to that account: a verified email, saved payment methods, loyalty points, and purchase history.
New account fraud creates a synthetic or fraudulent account from scratch. The attacker builds a new identity, often using fabricated or stolen personal data. There is no prior account history, so detection relies on identity verification at registration rather than anomaly detection on an established account.
Payment fraud targets a single transaction, not the account itself. Card-not-present fraud and card skimming are payment fraud: the attacker has card data but may not have account access. ATO, by contrast, is about persistent account control.
The distinction matters for prevention architecture. New account fraud is stopped at registration. Payment fraud is stopped at the transaction level. ATO is stopped at the authentication layer, before the attacker gains the session that makes every subsequent action look legitimate.
How a credential stuffing ATO attack works
The dominant delivery mechanism for ATO in 2026 is credential stuffing: automated, high-volume testing of stolen username and password pairs against login endpoints. Here is how a typical attack unfolds.
Step 1: Credential acquisition. The attacker buys a credential list from a breach database or dark web marketplace. Lists with tens of millions of email and password pairs sell for negligible cost. The credentials come from unrelated breaches (a retail site, a streaming platform, a forum) but get tested against the target platform because people reuse passwords across services.
Step 2: Automated login attempts. The attacker deploys bots to test the list against the target's login endpoint. To dodge rate limiting and IP blocking, the attack is spread across thousands of residential proxy IP addresses, each making a small number of requests. From the server's perspective, each request looks like a different user on a different network.
Step 3: Successful logins identified. Success rates vary with the quality of the credential list and how unique passwords are among the target's users. A subset of the tested credentials will match valid accounts on the platform.
Step 4: Account takeover and mutation. For each successful login, the attacker moves fast: changing the registered email address, adding a new payment method, removing the existing ones, and starting a withdrawal or purchase. The goal is to finish monetising before the real account holder notices the access.
Step 5: Monetisation. How the attacker cashes out depends on the platform. On e-commerce sites, stored payment methods fund purchases. On iGaming platforms, balances are withdrawn. On financial platforms, funds are transferred. On loyalty platforms, points are redeemed or sold.
The scale of the problem
Javelin Strategy & Research 2026 found that 6 million consumers were ATO victims in 2025, an 18% increase over 2024. Total ATO losses reached $13.5 billion.
| Year | US account takeover losses |
|---|---|
| 2024 | ~$11.4 billion |
| 2025 | $13.5 billion |
Source: Javelin Strategy & Research 2026 Identity Fraud Study.
These figures reflect detected and reported fraud, so the real incidence is higher. Many victims do not immediately realise their account has been compromised, and businesses often discover ATO only when chargebacks, support tickets, or withdrawal anomalies pile up enough to trigger a review.
The credential supply driving these attacks is substantial. The Verizon Data Breach Investigations Report 2026 found that stolen credentials appear in 39% of all data breaches. The breach databases fuelling today's ATO attacks were populated by yesterday's breaches at companies with no connection to the target platform.
Why server-side tools see ATO too late
The conventional response to credential stuffing is server-side: rate limiting on login endpoints, IP reputation blocking, and CAPTCHA challenges. These controls have genuine value against high-volume, low-sophistication attacks. They do not stop modern credential stuffing run through residential proxy networks at human-equivalent request rates.
More to the point, server-side tools evaluate the request only after it arrives. By the time a login POST reaches your server, the attacker has already picked that credential pair, already routed through a residential proxy, and already passed whatever client-side checks your login page applies. The signals that expose the attack, including the device fingerprint, the VPN connection, the session cadence, and the absence of expected browser environment characteristics, exist only in the browser.
A browser-layer detection tool collects these signals before the request is submitted, so the verdict is available at the moment of authentication rather than after the fact.
How cside detects account takeover
cside runs a lightweight script in the visitor's browser and analyzes more than 250 signals per session. On a login page, the relevant signals include:
Device fingerprint. cside maintains high-accuracy device fingerprinting across incognito mode, VPN connections, and cookie-clearing. A credential stuffing bot that tries to appear as a new device on every request is exposed by fingerprint consistency, not by IP address.
Network context. TLS handshake fingerprint TLS fingerprinting identifies VPN and proxy connections. A login routed through a residential proxy or anonymising VPN is flagged at the session level, not just the IP level.
Session cadence. Automated login attempts have characteristic timing patterns. Even credential stuffing tools built to mimic human speed produce session cadence that differs from genuine human behavior across a population of requests.
Device ID change at login. One of the clearest ATO signals is a known account authenticating from an unknown device. cside correlates device fingerprints across sessions, so it can flag when an account that has always logged in from one device fingerprint suddenly presents a completely different one.
The output is a real-time, per-session verdict returned before authentication completes, flagging automated and high-risk sessions. Your platform can use that verdict to require step-up authentication, block the session, or silently flag the account for fraud team review, without adding friction for legitimate users whose device fingerprint and session context match their history.
For a fuller guide to building ATO prevention into your authentication stack, see cside's account takeover use case. For tactical detail on the delivery mechanism, see what is credential stuffing.
