How to stop account takeover

What it costs you

• trending_downWhatever the account holds: stored balance, loyalty points, saved payment methods, and any payout path the real owner set up and you now honour for somebody else.
• trending_downThe refund, almost always. When a customer is compromised on your service you generally make them whole regardless of whose password it was.
• trending_downTrust, which does not recover at the rate the balance does. Users who have been taken over on your platform tell people.
• trending_downSupport load at its most expensive: identity re-verification, manual recovery, and a customer who is upset and correct to be.
• trending_downRegulatory exposure where personal data was exposed in the compromised account, which is a different and slower kind of cost.

How the attack runs

1. 01

   Obtain credentials somebody else leaked

   Almost never from you. Combolists from other services' breaches are cheap and enormous, and they work because password reuse is close to universal. The attacker is betting on your users having an account elsewhere that fell over.

2. 02

   Test the list against your login

   Automated, distributed and slow enough per address to stay under naive limits. Success rates in the low single digits per cent are entirely worth it at list scale.

3. 03

   Confirm and quietly sit

   A careful operator does not act immediately. They confirm the login works, take note, and return later, because instant action is what triggers alerting and what a victim notices.

4. 04

   Change the recovery path

   The step that turns a login into ownership: swap the email, add a phone, remove a passkey, register a new device. Once recovery is theirs, resetting the password does not evict them.

5. 05

   Extract, usually through a route you allow

   Withdrawal to a new destination, a gift card purchase, a points transfer, an in-product payout. Rarely anything exotic, because your own legitimate features are the cleanest way out.

The signals that do

These are the signals that carry weight on account takeover, and why each one is the signal rather than the obvious alternative. Not all of them are ours: the ones marked you build this genuinely work and Kaidn does not check them, so you would be wiring them up yourself. Listing those unlabelled would read as a claim we cannot support.

Account takeover is the inverse of everything else on this site. The other guides are about accounts that were never real. This one is about accounts that are entirely real, belong to somebody who trusted you, and are now being operated by a stranger.

That inversion changes the detection problem completely, and it is worth being explicit about it, because a tool tuned for one is often poorly suited to the other.

You have history, so use it#

With a fake signup there is nothing to compare against. With takeover there is a real person with months of behaviour behind them, and the question is not "does this look risky" but "does this look like them".

That is why generic risk signals underperform here. A residential IP, an ordinary device and a clean email are all completely normal for an attacker who is using a proxy in the victim's country, and they are also normal for the victim. What separates them is the break from an established pattern: a device never seen on this account, on a network this user has never used, at an hour they have never been awake, going straight to the withdrawal page.

Almost none of this starts with you#

Credential stuffing works on password reuse. The passwords come from somebody else's breach, which means a compromised account is usually not evidence that your security failed.

It is also why "make our passwords stronger" is the wrong lever. Your users' passwords are already strong or weak elsewhere, and you will not fix that with a complexity rule. What you can do is detect the list being worked, which is visible across accounts even when each account sees only two or three failures.

Watch the recovery path harder than the login#

If you only harden one thing, harden this.

Login is where attention goes and where the attacker expects to be watched. The change of email address, phone number, passkey or payout destination is where a session turns into permanent ownership, and it is very often scored less carefully, or not at all.

Score those as their own events, with the login that preceded them attached. A password change from a device first seen four minutes ago is a different proposition from one made on a laptop that has been signing in for two years, and treating both as "settings updated" is how accounts are lost.

Detection has a ceiling here, and authentication is above it#

We will be straight about this, because it matters more on this page than on the others: the strongest control against credential stuffing is not scoring, it is authentication that a stolen password cannot satisfy.

Passkeys end credential stuffing for the accounts that adopt them, in a way no detection layer can match. If you can move users onto them, do that first and treat everything below as coverage for the accounts that have not migrated, the recovery flows, and the phishing cases where the user handed over a live code.

Anyone selling you detection as a replacement for that is selling you the second best option as the first.

Where we sit#

We score login and post-login events with the account's own history as context, plus device, IP and ASN reputation, velocity across accounts, and email identity. Verdicts return the checks that fired and their weights, so a step-up can be triggered on the specific signal you care about.

We do not ship the challenge itself. We return a verdict; issuing the step-up, the passkey prompt or the recovery hold is yours to implement. Tools built specifically around the login interaction, such as Castle, do that part and do it well, and running both is a coherent architecture rather than a hedge.

Score the recovery path as its own event#

The login call is the one everybody writes. This is the one that matters more:

// a change of recovery address is where a session becomes ownership
const r = await kaidn.score({
  event: "email_change",
  user_id: user.id,
  ip: req.ip,
  email: body.newEmail,
  device_id: body.kaidn_device_id,
});

// the age of the device on THIS account is the discriminator, and it is yours
const deviceIsNew = !(await db.accountDevices.exists({
  user_id: user.id,
  device_id: body.kaidn_device_id,
}));

if (deviceIsNew || r.verdict !== "allow") {
  // do not refuse; delay and notify the address you already had
  await holdChangeFor(user.id, "24h");
  await notifyOldAddress(user, r.event_id);
  return { status: "pending_confirmation" };
}

A 24-hour hold plus a mail to the address being replaced is worth more than any score on this flow, because it gives the real owner the one thing an attacker needs them not to have: time.

The session signals worth routing on#

Session risk is where takeover shows up, and these are the reasons the engine emits for it:

const r = await kaidn.score({ event: "login", user_id: user.id, ip: req.ip, email: user.email, device_id });

// Kaidn returns the verdict; issuing the step-up is yours
if (r.reasons.includes("impossible_travel") || r.verdict === "block") return stepUp(user, r.event_id);
if (r.verdict === "review") return requireEmailConfirm(user, r.event_id);

Something to check this week#

Query your last ninety days for accounts whose recovery email changed within an hour of a login from a device never previously seen on that account. That single query, which costs nothing, finds takeovers that are already complete and tells you whether this is a problem you have or a problem you are worrying about.