Account Takeover Attacks Are Rising: Your 2026 Defence Checklist

An account takeover is the quietest incident you will ever have. Nothing goes down. No dashboard turns red. A customer logs in, except it is not the customer, and the session often looks cleaner than half of your legitimate traffic. The first you hear of it is a support ticket about a drained loyalty balance, a beneficiary nobody remembers adding, or a chargeback with a story attached.

We covered the attacker’s side of this in our piece on bot attacks against fintech platforms. This post is about the defence, because the standard answer (a WAF, an IP blocklist, a CAPTCHA, SMS codes) was built for how credential attacks worked a decade ago. In 2026 the attack arrives from residential broadband connections, solves your CAPTCHA for a fraction of a cent, proxies your MFA challenge in real time, and increasingly skips the login form entirely because it already holds a valid session cookie.

What follows is the checklist we work through with clients, and the numbers that explain why each layer earns its place.

Why account takeover is climbing in 2026

Start with the attack rates. Sift’s Q3 2025 Digital Trust Index, drawn from its global network telemetry, measured the ATO attack rate against finance and fintech platforms more than doubling year over year: up 122%, from 0.54% to 1.2%. Travel and ticketing rose 56% over the same period. In Sift’s Q1 2026 follow-up, 21% of surveyed US consumers said they had experienced an account takeover in the previous twelve months.

Then look at the supply side, because ATO is an economics problem before it is a technical one. In June 2025, Cybernews researchers catalogued around 16 billion exposed credential records across 30 separate datasets, most of them assembled from infostealer malware logs and recycled breach compilations. There is heavy duplication in that corpus, and plenty of it is stale, but the working inventory of valid username and password pairs has never been larger, and fresh stealer logs arrive weekly. Verizon’s 2026 Data Breach Investigations Report puts the consequence plainly: credential abuse featured in 39% of all breaches analysed, and 73% of ransomware victims had an infostealer infection or a credential leak in the year before the attack, half of them within 95 days of it.

The targeting is not random either. Akamai’s May 2026 State of the Internet research on financial services found that banking absorbed 60% of web attacks and 83% of attacks against API endpoints in 2025, alongside a 147% surge in advanced bot activity in late 2025. If you run a fintech or e-commerce platform, you are not somewhere in the queue. You are the front of it.

Two more numbers frame what is coming. Gartner predicted in March 2025 that AI agents will cut the time needed to exploit exposed accounts in half by 2027, by automating the boring parts of the kill chain. And in Sift’s consumer research, 75% of people said they would stop using a site after an account takeover, and 87% would tell others about it. For a sector where the account effectively is the product, that is the real cost line.

How modern attacks walk past the old defences

IP reputation is watching the wrong network

The classic stuffing defence assumed attack traffic came from data centres and known-bad ranges. It now comes from living rooms. GreyNoise’s March 2026 research analysed four billion malicious sessions over 90 days and found roughly 39% originated from residential IP space, with 78% of those addresses appearing on no reputation feed at all. Nearly 90% of residential attack IPs cycle out of use within a month, faster than blocklists can learn them. Each address might make two or three requests. Block the range and you block your own customers, because the proxy traffic exits through the same ISPs they use.

CAPTCHA is a toll booth, not a wall

Solver services, increasingly AI-driven, clear most commercial CAPTCHAs in seconds for fractions of a cent per solve. The maths matters: a challenge that costs an attacker a tenth of a cent while costing you measurable login conversion is a trade you lose twice. We made the longer version of this argument in our analysis of reCAPTCHA economics, and it has only got worse for the defender since.

Basic MFA assumed the phish was dumb

Adversary-in-the-middle kits changed that. Tooling like Tycoon 2FA (one of eleven major AiTM kits the threat intelligence firm Sekoia tracked in active use during early 2025) places a reverse proxy between the victim and your real login page. The customer enters their password and their one-time code into what is functionally your own site; the kit forwards both, collects the resulting session cookie, and the attacker is in. Rented as phishing-as-a-service from around $100 a month, this is no longer a specialist’s technique. Obsidian Security’s incident data makes the point bluntly: MFA was present and failed to stop the attack in 84% of the SaaS compromises they responded to. SMS codes, the most common second factor in consumer fintech, are the weakest of the lot.

Infostealers skip the login entirely

The fastest-growing path to takeover involves no guessing at all. Infostealer malware on a customer’s (or employee’s) device exfiltrates saved passwords and live session cookies in bulk. The attacker replays the cookie and arrives authenticated, on a residential IP, with a browser fingerprint copied from the victim’s machine. Your login defences can be flawless and never see it. This is why the DBIR’s 95-day window between credential exposure and ransomware deployment matters: stolen credentials get used, on a schedule, by people who bought them in bulk.

The 2026 defence checklist

No single control fixes this. That is the uncomfortable starting point, and the reason the checklist below works as layers: each one makes the next attack stage more expensive, and the controls that follow assume the ones before them will sometimes fail.

1. Deploy passkeys where the value is

Passkeys remove the credential as a stealable, replayable artefact. There is nothing to stuff, and because the key is bound to your origin, an AiTM proxy gets nothing to forward. This stopped being early-adopter territory: the FIDO Alliance estimated around five billion passkeys in active use as of May 2026, with 75% of consumers having enabled one somewhere and 49% using them regularly. FIDO’s own index data also shows passkey sign-ins succeeding around 30% more often than passwords, so the security control is, unusually, also a conversion win.

• Offer passkeys to all users, but prioritise enrolment for accounts with stored payment methods, balances, or high loyalty value.
• Require phishing-resistant authentication for the actions that move money as well as at login.
• Keep the password fallback monitored: an account with a passkey that suddenly authenticates by password and SMS reset is itself a risk signal.

2. Make the MFA you keep adaptive

You will run passwords and OTPs for a long tail of customers for years. The fix is to stop applying them uniformly. Risk-based step-up (challenge the session that looks wrong, wave through the one that matches the customer’s history) cuts both fraud and friction, and the friction tolerance is there when it is explained: in Sift’s Q1 2026 survey, 93% of consumers said they would accept extra verification when it reduces fraud risk.

• Retire SMS as the only factor for money movement; prefer app-based codes or push with number matching as the floor.
• Tie step-up triggers to risk signals (new device, impossible travel, proxy indicators), not to a fixed schedule.
• For fintech specifically, use the risk-based exemptions PSD2 already gives you instead of challenging every session identically. We made the same argument for performance reasons in our Core Web Vitals piece; it holds for fraud too.

3. Judge devices and behaviour, not IP addresses

If the network address is meaningless, the question becomes: does this session behave like this customer? Device intelligence (hardware and browser characteristics, TLS fingerprints that do not match the claimed browser) and behavioural signals (typing cadence, navigation order, whether a human hesitates where humans hesitate) survive proxy rotation in a way reputation lists cannot.

• Fingerprint devices on login and bind the signal to the account history, so a familiar customer on a new device reads differently from a new device hammering fifty accounts.
• Compare each session against the individual’s profile and against your population baseline, which catches anomalies even on a first-time login.
• Treat mismatches as score inputs, not verdicts. A single signal blocks badly; combined signals decide well.

4. Score logins at the edge, before they reach origin

Detection that runs inside your application sees the attack after you have already paid to serve it. Running it at the edge changes both the economics and the data. Akamai’s Account Protector, which we deploy alongside Bot Manager, calculates a risk score for each authentication attempt in real time, combining the user’s behavioural profile (typical locations, networks, devices, activity times), population-level baselines, and reputation drawn from attack activity observed across Akamai’s platform. Action happens at the edge (allow, challenge, tarpit, deny) before the request touches your infrastructure.

• Put bot detection in front of login, registration, and password reset endpoints, the three doors attackers use.
• Feed edge risk scores into your authentication logic, so step-up decisions use signals your application cannot see on its own.
• Let the edge absorb the volume: stuffing campaigns stopped there never inflate your origin bill or your failed-login noise.

5. Protect the session, not just the login

Cookie theft and AiTM both monetise what happens after authentication, so the session itself needs the same scrutiny as the password did. In fintech the damage is rarely the login; it is the beneficiary added two minutes later.

• Keep sessions short-lived for sensitive applications and rotate tokens on privilege changes.
• Re-authenticate (with a phishing-resistant factor) for new payees, payment method changes, withdrawal destination changes, and contact detail changes.
• Alert on the post-login sequences that precede fraud: credential change followed immediately by money movement, or one session appearing from two networks.

6. Watch the credential supply chain

Your customers’ passwords are leaking from other people’s breaches continuously, and the 95-day exposure-to-use window is long enough to act inside if you are looking.

• Screen passwords against known-breach corpora at registration, login, and reset, and force resets on matches.
• Monitor stealer-log and combo-list markets for your customer and corporate domains rather than waiting for the attack telemetry.
• When a major dump lands, treat it as an operational event with an owner and a deadline, not a news item.

7. Rehearse the bad day

Some takeovers will get through a good stack. What separates a contained incident from a reportable mess is whether the response was designed in advance.

• Build and test a mass-reset and session-revocation runbook, including the support surge that follows it.
• Track mean time to detect an ATO as a real metric. If customers report takeovers before your systems do, assume you see a fraction of them.
• Map the regulatory clocks before you need them: DORA’s four-hour initial notification for major ICT incidents and GDPR’s 72-hour window both run faster than an unrehearsed process. We covered what that means in practice in our WAF tuning post.

Where the edge fits next to your identity stack

A fair question we hear from CTOs: we already pay for a CIAM platform and a fraud engine, so what exactly does the edge add? The honest answer is that the three layers do different jobs, and the teams that struggle usually have two of them doing nothing while one drowns.

The edge layer (bot management plus account protection) owns the volume problem and the pre-authentication signal: it strips out automated traffic, scores the session before the password is even checked, and keeps the attack off your infrastructure. Your identity layer (your IdP or CIAM, passkeys, step-up policy) owns the authentication decision and should consume the edge’s risk signal rather than recompute it from weaker data. Your fraud platform owns what authenticated users do with money and remains essential for the takeovers that arrive through phishing or stolen sessions rather than stuffing.

The edge does not replace the other two. It makes them work with cleaner data, at lower cost, against a fraction of the volume. That ordering matters more than any individual product choice, which is the same conclusion we keep reaching across web application security and Zero Trust projects: architecture first, then tooling.

A 30-day hardening plan

Thirty days will not migrate your customer base to passkeys. It will close the gaps attackers find first and give you a defensible roadmap for the rest.

Week 1: measure. Establish the bot share of your login traffic and your failed-to-successful login ratio (a stuffing campaign distorts it unmistakably). Map MFA coverage by customer segment and check stealer-log datasets for your domains. List every post-login action that moves money or changes account control.

Week 2: cheap wins. Turn on breached-password screening at login and reset. Add per-account rate limits alongside per-IP ones. Tighten the password reset flow, which is usually softer than login. Remove SMS as the lone factor on money movement. Put bot detections on login, registration, and reset endpoints in observe mode.

Week 3: pilot the real fixes. Open passkey enrolment for one high-value segment. Define adaptive step-up policies against the risk signals you now collect. Review a week of observe-mode edge data and tune out the false positives, the same discipline we apply to WAF rules: detection first, blocking after the data says it is safe.

Week 4: enforce and institutionalise. Move tuned edge policies to challenge and deny. Switch on session re-authentication for high-risk actions. Agree the metrics you will hold (ATO detection time, takeover rate, challenge rate on legitimate users) and walk the incident runbook once, on a calendar invite, before reality schedules it for you.

The pattern across everything above: attackers stopped attacking your password form and started attacking the assumptions around it, that an IP address means something, that a solved CAPTCHA means a human, that a passed MFA challenge means the right human. Defence in 2026 means replacing each assumption with a measurement, and putting as much of that measurement as possible in front of your infrastructure rather than behind it.