Account takeover prevention

Account takeover is now an industrial process. The 2025 FBI Internet Crime Complaint Center received more than 5,100 ATO complaints in a single year with reported losses over $262 million, and that is a fraction of the true total because most ATO never gets reported. The defense has to keep up. This article covers what modern ATO actually looks like, the device-intelligence signals that catch it before the password check, and the step-up patterns that work without making login impossible for real users.

For the credential-stuffing-specific detail see credential stuffing. For the broader fraud framing, see ecommerce fraud prevention and payment fraud detection.

What account takeover actually looks like in 2026

The headline numbers from the 2025 IC3 report understate the actual scale, because most ATO is committed against business accounts that do not file consumer complaints and against accounts whose owners do not realize they have been compromised. SpyCloud’s read of the same data puts total cybercrime losses for 2025 above $20.9B with ATO as a meaningful contributor (SpyCloud: FBI Internet Crime Report 2025).

The three patterns that dominate in 2026:

Pattern 1: Credential stuffing into known accounts

This is the classic form. An attacker has a list of email-password pairs from past breaches. They run an automation tool that tries each pair against your login endpoint. Successful logins are sold or used directly. It dominates because password reuse remains widespread and breach data is cheap. See credential stuffing for the technical detail.

Phishing-as-a-service kits, real-time proxy phishing (Evilginx and similar), and infostealer malware all harvest authenticated session cookies. The attacker imports the cookies into their own browser and is logged in without ever knowing the password. Stolen-session replay has become the dominant MFA-bypassing vector: the victim completed MFA themselves, so the token is fully privileged, and no credential check ever fires. The catchable tell is the device. A replayed token arriving from hardware, a TLS stack, and a network the account has never used is exactly what device-level signals are built to flag, which is why session binding to device identity matters as much as the login check itself.

The FBI’s 2025 alert on ATO via impersonation of financial institution support is specifically about this (FBI: Account Takeover Fraud via Impersonation). The attacker calls or texts the victim claiming to be from their bank, talks them into providing 2FA codes or installing remote-access software, and uses that access to drain accounts. The login event itself looks like a normal authenticated session because the victim authorized it under duress.

All three patterns share a property: by the time the password check (or 2FA check) succeeds, the damage is already happening. The detection has to fire before or during the authentication, not after.

Data Where ATO attacks land, by industry

Financial services

22%
Telecoms / ISPs

18%
Computing / IT

17%
Retail / ecommerce

11%
Other

32%

Share of all 2024 account takeover incidents

Source: Imperva 2025 Bad Bot Report

ATO attacks rose 40% year-over-year and 54% over three years. Financial services bears the largest single share, but the long tail across telecom, IT, and retail means most consumer-facing apps see meaningful volume.

The device fingerprint is the highest-yield single signal

A 2026 retail-focused playbook from the MojoAuth team gives a number that is consistent with what most fraud teams report internally: roughly 78% of confirmed retail account takeovers originate from a previously unseen device (MojoAuth: Account Takeover Protection for Online Retailers).

A new device fingerprint is therefore the highest-yield single risk signal, though far from the only one. A login attempt from a device the account has never used before is overwhelmingly more likely to be ATO than a login from a device the account uses every week.

The corollary is that a device intelligence layer that resolves to a stable per-device identity (what is device fingerprinting) is the foundation of everything that follows. Without that, “new device” is unenforceable: every cookie-cleared browser looks new, every incognito session looks new, every browser update looks new. With it, “new device” is an actionable signal.

Signals that fire before the password check

A risk-based ATO defense reads signals from the moment the login page loads, well before the credentials are submitted. The signals that matter most:

Device-level signals

New device. Is this device fingerprint in the account’s history?
Device classification. Does the fingerprint look like real consumer hardware, an anti-detect browser, a headless framework, or a known emulator?
Tamper signals. Does the fingerprint look spoofed? Inconsistencies between TLS, Client Hints, JS environment, and behavioral signal.

Session-level signals

Time-on-page before submit. Real users spend several seconds reading the form. Credential stuffing scripts often submit within milliseconds of page load.
Field interaction pattern. Tab vs click navigation, paste vs type into the password field, focus and blur events. Credential stuffing scripts skip these.
Behavioral snapshot. Mouse movement, scroll, keyboard cadence. Even imperfect data on these is enough to separate human from script.

Network-level signals

IP class. Residential ISP, mobile carrier, datacenter, known VPN, known proxy provider. Datacenter IPs for retail logins are overwhelmingly automated.
IP reputation. Has this IP been associated with abuse against your service or others?
Impossible travel. The same account just logged in from Texas 30 minutes ago and now from Singapore. Either the user is on a flight with in-flight wifi or the credentials are in someone else’s hands.

Account-history signals

Account-device graph. Has this device been used by other accounts? Has this account been accessed from other devices? Both can be normal (shared family device, multiple devices per user) and both can be abuse (one device controlling many accounts, one account being shared across an organization).
Velocity. How many login attempts in the last hour? Last day? Across IPs?
Sequence. Was the login preceded by a password reset, a 2FA disable, or a contact information change?

A risk model combines these into a single score. The score is checked at the moment of submit, before the credentials are validated.

The password-check ordering trap

A common architectural mistake is to implement the risk check after the password is validated. The reason this matters is timing leakage. If the bot detection returns a 200 for valid passwords and a 403 (or a different latency) for invalid passwords, the attacker can use the difference as an oracle for which credentials are valid, even without the bot detection succeeding.

The right ordering:

Page load: SDK starts collecting fingerprint and behavioral signal.
Form submit: risk score is computed.
Risk-gate first. If the session is high-risk for automation (independent of credential validity), serve a generic challenge or block before checking the password.
Credential check second.
If credentials valid and risk is acceptable: log in.
If credentials valid but risk is high: step-up.
If credentials invalid: respond with a generic invalid-credentials error, with timing constant across all paths.

The timing-constant invalid-credentials response is the part most implementations get wrong.

Step-up patterns that work

Step-up authentication is the layer between “allow” and “block.” It demands additional proof from the user without rejecting the session outright. Note that step-up proves account ownership rather than humanness. A CAPTCHA at login does neither well, and if a humanness check is what you actually need, CAPTCHA alternatives impose that cost without taxing every user. The patterns that work in 2026:

Passkey verification on a recently-used device

If the account has a passkey registered on a device the user owns, a step-up that asks for passkey verification is low-friction (Touch ID, Face ID, Windows Hello) and phishing-resistant. The challenge cannot be replayed because the cryptographic response is bound to the origin. Passkeys are also the durable endgame here: an account with no password has nothing to stuff, nothing to phish, and nothing to relay, so every account migrated to passkey-primary authentication permanently exits the ATO pipeline.

Email or SMS magic link

A one-time link sent to the account’s verified email or phone. The user clicks it, and the original session is upgraded. Friction: 30 to 90 seconds depending on the message delivery. Useful as the default fallback when passkeys are not available.

Avoid SMS for high-value accounts because of SIM-swap risk. The FBI’s 2025 guidance specifically warns against SMS-based MFA for accounts where the financial cost of compromise is high. The send endpoint also needs its own protection against SMS pumping fraud.

TOTP authenticator app

The classic six-digit code from Google Authenticator, Authy, 1Password and similar. Strong protection against credential reuse, weak against real-time phishing because the code can be relayed.

Push notification to a known mobile device

An app the user has installed shows a notification: “Approve sign-in from [city] on [device]?” The user taps approve or deny. Strongest user experience, requires a mobile app deployment.

Re-authentication with the previous device

If the account has a recent (less than 7 days) authenticated session on a different device, the new device can be required to confirm via that previous device.

The right pattern is to support multiple options and let the user choose, falling back gracefully. Requiring step-up on every login regardless of risk fails over time, because users will turn it off or switch services.

Adaptive MFA: friction proportional to risk

The default password-plus-2FA approach charges the friction tax on every user, every login. The mature approach is adaptive: skip 2FA when the risk is low, require it only when the risk is high enough to justify the friction.

The signals that drive the adaptive decision are the same risk signals above. A login from a known device, normal IP, and normal time of day for the user does not need 2FA; the device intelligence already proves the user is who they say they are. A login from a new device on a datacenter IP at 3am requires 2FA, and probably step-up beyond it.

A useful rule of thumb: in a typical consumer product, 95 to 98% of legitimate logins are obviously legitimate to a competent risk model. Skipping friction on those logins reclaims a meaningful share of the user-experience cost of authentication.

ATO does not end at login. A compromised account may sit dormant for hours or days before the attacker takes a value-extracting action (changing the payout address, transferring funds, exporting data, deleting account history). Monitoring inside the authenticated session is essential.

The signals that should drive post-login interventions:

Account changes that increase risk. Adding a new payout method, changing email, changing phone, disabling 2FA, adding a new authenticator device, requesting an API key.
Value-extracting actions. Transferring funds, exporting data, sending mass messages, changing user roles.
Behavioral shifts within the session. The session was idle for an hour and then suddenly resumed with different mouse and timing patterns. The user typically operates from one geography and is now navigating from another.

For each of these, the response is step-up. Reauthenticate before the action. Send a notification to the user’s other devices. Hold the action in a review queue for high-value cases.

What not to do

Three patterns that come up regularly and fail in production:

Hard-block on new device. Real users buy new devices, reinstall browsers, use a friend’s laptop on holiday. Blocking new devices alienates users and drives them to support. Use step-up, not block.

Trust the IP allow-list. IPs change. Residential users get rotated by their ISP. Travelling users hit different IPs every day. Allow-listing IPs as the primary trust signal will fail.

Treat 2FA as the only defense. 2FA defeats password-only attacks but not session cookie theft or real-time phishing, so it has to be one layer among several.

How Foil supports ATO prevention

Foil’s role in ATO defense is the device intelligence and risk-classification layer. The SDK collects device, network and behavioral signals and produces a sealed token; verifying it server-side returns a stable device identity (the visitor fingerprint) and a per-session decision. The application uses these to drive risk-based authentication, adaptive MFA, and step-up decisions.

For an integration sketch in Express middleware:

import { Foil, safeVerifyFoilToken } from "@abxy/foil-server";

const client = new Foil({ secretKey: process.env.FOIL_SECRET_KEY });

app.post('/api/login', async (req, res) => {
  const result = safeVerifyFoilToken(req.body.foilToken, process.env.FOIL_SECRET_KEY);
  const { account } = req;

  // Risk-gate before checking credentials
  if (!result.ok || result.data.decision.verdict === 'bot') {
    return res.status(401).json({ error: 'invalid_credentials' });
  }

  const credentialsValid = await checkCredentials(req.body);
  if (!credentialsValid) {
    return res.status(401).json({ error: 'invalid_credentials' });
  }

  const { decision, visitor_fingerprint, session_id } = result.data;
  const visitorId = visitor_fingerprint?.id;

  // Compare against the visitor fingerprints previously attached to this account
  const isKnownDevice = visitorId
    ? await deviceHistory.contains(account.id, visitorId)
    : false;

  const session = await client.sessions.get(session_id);
  const isImpossibleTravel = await checkImpossibleTravel(account.id, session.network.location);

  if (!isKnownDevice || isImpossibleTravel ||
      session.network.anonymity.hosting ||
      decision.risk_score > 0.7) {
    return requireStepUp(req, res, account);
  }

  // Record the device-account link for future known-device checks
  await client.sessions.attachClientUser(session_id, account.id);
  return loginSuccess(req, res, account, visitorId);
});

The middleware does not encode any specific authentication logic. It uses the decision and the visitor fingerprint to decide whether to risk-gate, whether to step-up, and what to log. The credential check and the step-up flow are the application’s.