Account takeover

What an account takeover is

An account takeover is a third party taking control of an existing account and, from that moment on, operating with its owner's permissions.

The account was already verified. The person was already a customer. All the work of establishing who that person was had been done at the time, and it went well. What failed afterward is access control, which is a different layer and is defended with different controls.

That's why the useful comparison isn't with fraud at signup. In an identity impersonation, the organization gets it wrong when deciding who someone is. In an account takeover, the organization got it right, and then lost the account.

The term names the end state, not the technique. That is why "detecting account takeover" does not describe a concrete control until you say which route led to it.

Account takeover is a result, not a method

This is the distinction that orders everything else, and it's the one usually missing when a team tries to cover it with a single measure. Nobody executes "an account takeover." They execute an attack that ends in one.

• Phishing and smishing — the owner hands over the credential and the second factor under deception, in real time. Access arrives with a technically correct authentication.
• Credential stuffing — the credential had already leaked from another service and worked here because the person reused it. There was no deception and no intrusion.
• SIM swapping — the attacker takes over the phone line and with it the recovery channel. They don't need the password: they request a new one.

There is a fourth route growing with biometrics: access recovery resolved with a face. When an account is recovered by comparing the face of whoever is claiming it against the one from signup, the vector is a deepfake, not a password.

There are two more routes that show up often and are worth keeping on the map: social engineering against the support channel, where the attacker convinces someone on the team to reset access, and malware on the owner's device, which captures the already authenticated session.

The operational consequence is direct. A control that covers one route doesn't cover the others. Switching the second factor to one bound to the domain solves phishing and says nothing about SIM swapping. Hardening account recovery solves SIM swapping and doesn't touch credential stuffing. The defense is built per route, and then a layer is added that works for all three, which is the one that watches what happens after access.

It is not the same as fraud at signup

Both end with an attacker operating an account, and they stop at different points along the way.

• Account takeover — the account exists, has a real owner and a legitimate history. The attacker inherits that reputation, which is exactly what makes it valuable.
• Fraud at signup — the account is opened from scratch with an impersonated identity or with a synthetic identity. There is no victim with prior access and no history to inherit.

The distinction defines where to put the control. Fraud at signup is fought at identity verification. Account takeover is fought at authentication and in session signals, because signup already happened, and happened correctly.

How the attack runs, step by step

Steps 1 to 3 vary by route. From step 4 on, the sequence is the same, and that's where the detection opportunity lies.

1. Get access. Through any of the routes above.
2. Establish the session. From a new device, often from another region, at a time that doesn't match the owner's pattern.
3. Scout the account. The attacker looks before moving: balance, limits, saved recipients, stored payment methods, contact details, history. It's a read-only stretch and usually short.
4. Displace the owner. Change of email, phone or registered factors. This is the step that turns access into control, because from then on the legitimate person loses their recovery channel and stops receiving the alerts.
5. Execute. Transfer, adding a recipient, redeeming points, purchase with the stored payment method, or simply reselling the access.
6. Persist. Extra sessions left open, devices registered as trusted, forwarding rules in the email. The goal is to survive the owner's first recovery attempt.
7. The owner complains. Almost always after the operation, and almost always through a channel that no longer recognizes their contact details.

Step 4 is the most important in the sequence for two reasons. It's the one that makes the problem irreversible for the victim, and it's the most detectable of all, because a change of contact details followed by a sensitive operation is a pattern almost no legitimate owner produces.

Where it shows up in an identity journey

• Access — the moment when who is returning gets validated.
• Access recovery — the most exposed flow, because it exists precisely to let in someone who lost their factors.
• Contact information change — the step that consolidates control: when the email or phone changes, the account holder stops receiving alerts.
• High-value operation — a transfer, adding a new payee, changing limits. It is where the control taken turns into loss.

The contact-information-change step is what separates an attempt from a completed takeover, and it is the one most often left without a control of its own.

Who it affects and what it costs

The cost has three layers and only the first one shows up in the fraud report.

• Financial services — transfers, new recipients and credit drawdowns on legitimate accounts. It's the case with the highest direct loss and the highest exposure to the regulator.
• Retail and e-commerce — purchases with stored payment methods and change of shipping address. Detection usually happens in logistics, not at access.
• Betting and gaming — balance consumption and resale of already verified accounts, which are worth more precisely because they're verified.
• Loyalty and points programs — the most underestimated target. Points are convertible, almost nobody checks their balance, and most programs have weaker controls than the same company's main account.
• Corporate — an employee's account as the entry point to internal systems.

The other two layers are the management cost, which includes investigation, reversal, handling the complaint and restoring access, and the relationship cost, which is the one that lasts: the person knows they lost their account on that platform and not on another.

Which controls stop it

Controls are ordered by moment, and no product category covers all four. Naming them in full, including the ones bought elsewhere, is what makes the list actionable.

Before access, and it depends on the route.

• Domain-bound factors, such as passkeys or FIDO2 credentials — against the phishing route.
• Rate limiting at the edge and bot management — against the credential stuffing route. They're bought from infrastructure and web security vendors.
• Factors that don't depend on the phone line — against the SIM swapping route.
• Verifiable procedure in the support channel — against social engineering of the support team. It's process and training before it's product.

During the session.

• Device reputation — never-seen device, or one seen before on other unrelated accounts.
• Behavioral biometrics — typing rhythm, pointer use, navigation style. It's a product category of its own and not every identity vendor provides it.
• Context consistency — geolocation incompatible with the previous session, off-pattern time of day, network jump.
• Session risk scoring — the combination of the above into one decision, instead of loose alerts.

At the moment of change and of the operation.

• Step-up with a non-dictatable factor on a sensitive operation — asking for presence again at the transfer, not only at access.
• Out-of-band confirmation with the operation details — what gets approved shows amount and destination, and doesn't just say "authorize."
• Notification to the previous channel, not the new one — notify the change of email or phone to the details that were registered before. It's one of the few alerts the victim can see in time.
• Cooling-off period after a change of factor or contact details — a delay before enabling sensitive operations. It costs little and breaks step 4.
• Identity re-verification on account recovery — proving again who the person is, instead of accepting a code.

Afterward.

• Fraud case management — queue, criteria, traceability and the ability to reverse. It's a platform of its own and a team, not a function of an SDK.
• Correlation with security events — access logs viewed alongside the rest of the telemetry, usually in an event management system that doesn't belong to the identity domain.
• Rules on the payment side — the ones that act on the transaction, already outside access control.

A good part of what decides the outcome of an account takeover, case management, event correlation and payment rules, isn't sold by an identity vendor. A team that wants to cover this fraud in full needs at least three different kinds of vendor, and it's worth knowing that before signing with just one.

How VU approaches it

VU works in three of the four moments.

Before access, Authenticate supports seven factors, including several that don't depend on the phone line or on a reusable secret. Changing the factor is the measure that most reduces the attack surface of the three main routes.

During the session and at the operation, Protect against fraud evaluates device and behavior signals in real time, which is the layer that works for all three routes at once, because it acts after authentication has already been passed.

In recovery and in step-up, Verify proves presence again with biometrics, which closes step 4. Its liveness detection is certified by iBeta at Level 2 of its testing program, which applies the methodology of the ISO/IEC 30107-3 standard.

Subsequent case management and correlation with the rest of the security telemetry remain the work of other tools and of a team.