---
url: 'https://www.corbado.com/kpi/account-takeover-rate'
title: 'Account Takeover Rate'
description: 'How often active accounts are confirmed compromised in a period, reported per 10,000 active accounts to quantify real security harm.'
lang: 'en'
---

# Account Takeover Rate

## What is the Account Takeover Rate?

**Account Takeover Rate (ATOR)** is the rate at which attackers successfully compromise
user accounts, measured as a percentage of confirmed compromised accounts relative to
active accounts in a reporting period. It matters because it measures realized harm, not
just attempted attacks and it connects authentication quality to fraud loss, support load
and trust.

> **Key facts on Account Takeover Rate**
> 
> - **What it captures**: Confirmed unauthorized account access that resulted in compromise
>   during the period
> - **Primary use**: Quantify real security impact and prioritize controls that prevent
>   takeovers
> - **Interpretation**: Typical ranges vary, but many consumer systems target well under
>   **0.01%** per year

## Where does the Account Takeover Rate fit in the login funnel?

We measure **Account Takeover Rate** after a user reaches an authenticated state and only
when we can confirm the account was controlled by an attacker. Measurement boundary is
from accounts that are active during the reporting window to accounts with a confirmed
takeover during the same window.

```mermaid
flowchart LR
    OA((Offer Auth))
    SA((Success Auth))
    AU((Authenticated Use))
    AC((ATO Confirmed))

    OA --> SA --> AU --> AC
```

Account takeovers often spike when attackers use
[credential stuffing](https://www.corbado.com/glossary/credential-stuffing) with newly leaked password lists.
When a [data breach](https://www.corbado.com/glossary/data-breach) exposes credentials from another service,
attackers test those username and password pairs against your login, exploiting users who
reuse passwords. Takeovers are identified after a successful login because a challenge
would have stopped the attacker from obtaining a valid session.

## How to calculate the Account Takeover Rate?

For **Account Takeover Rate**, we count each account at most once per reporting period,
even if multiple malicious sessions occur. We then normalize by the number of active
accounts in the same period.

> $$\text{ATOR}=\frac{\text{Compromised Accounts}}{\text{Active Accounts}}$$

`Compromised Accounts` is the number of distinct accounts with at least one confirmed
takeover event in the period. `Active Accounts` is the number of distinct accounts that
were active in the period.

Typical yearly reference ranges:

| Performance band | Approx percent of active accounts per year |
| :--------------- | :----------------------------------------: |
| Strong           |                Under 0.01%                 |
| Typical          |               0.05% to 0.15%               |
| Critical         |                 Over 0.20%                 |

### Numerator: Compromised Accounts

Count an account in `Compromised Accounts` when we have confirmation of unauthorized
access with evidence of attacker control, for example confirmed fraud actions, verified
user report with corroborating telemetry or a completed incident review. Do not count
blocked attacks, suspicious logins that were challenged successfully,
[credential stuffing](https://www.corbado.com/glossary/credential-stuffing) attempts that never succeed or
[phishing](https://www.corbado.com/glossary/phishing) reports without a confirmed compromised session.

| Detection signal                                | What it indicates                               | Action                                    |
| :---------------------------------------------- | :---------------------------------------------- | :---------------------------------------- |
| Single IP successfully logs into many accounts  | High quality credential list in use             | Flag all sessions from that IP for review |
| IP with many failed attempts suddenly matches   | Credential stuffing hit after brute forcing     | Confirm takeover, invalidate session      |
| User reports unauthorized activity              | Potential takeover with corroborating telemetry | Investigate and confirm before counting   |
| Unusual device or location after password login | Session hijack or credential reuse              | Verify with user before confirming        |

### Denominator: Active Accounts

Count an account in `Active Accounts` when it had meaningful activity in the same period,
commonly at least one successful authentication or a verified session. Do not count
disabled accounts, known test accounts or synthetic monitoring identities. Keep the
activity rule stable over time, because changing it will move the metric without changing
security.

### How to use Account Takeover Rate to improve outcomes

We use **Account Takeover Rate** to reduce confirmed compromise, then validate that
reductions reflect fewer real takeovers, not weaker detection.

Risk-based challenging is an effective way to reduce **Account Takeover Rate** without
introducing MFA for all users or requiring stronger authentication methods like passkeys.
By triggering challenges only when signals indicate elevated risk (unusual IP, new device,
impossible [travel](https://www.corbado.com/passkeys-for-travel)), you block most
[credential stuffing](https://www.corbado.com/glossary/credential-stuffing) attempts while keeping friction low
for legitimate users.

We can improve the following business outcomes:

- **Lower fraud loss and chargebacks**: If **Account Takeover Rate** rises in high value
  cohorts, we diagnose weak authentication and recovery controls, we roll out
  [phishing](https://www.corbado.com/glossary/phishing) resistant sign in such as passkeys and tighten recovery
  verification, we validate with a lower takeover rate in that cohort.
- **Lower user drop off with stronger security**: If **Account Takeover Rate** falls but
  abandonment rises, we diagnose added friction, we tune step up policies and improve
  [passkey enrollment](https://www.corbado.com/blog/passkey-creation-best-practices) UX, we validate by holding
  takeover rates down while sign in completion remains stable.
- **Lower support contacts caused by compromise**: If **Account Takeover Rate** is flat
  but support contacts spike, we diagnose remediation burden and unclear recovery, we
  improve account recovery journeys and automated containment, we validate with fewer
  contacts per takeover and faster resolution time.
- **Lower abuse exposure from fallback methods**: If takeovers cluster around recovery or
  one time codes, we diagnose weak fallback, we reduce risky fallback options and add
  stronger recovery proof, we validate by segmenting incidents by recovery path.

### Blindspots and common pitfalls of Account Takeover Rate

- **Intent and selection bias**: Confirmed takeovers often skew toward accounts that
  transact or complain, so **Account Takeover Rate** can understate harm in silent
  segments.
- **Missing telemetry or inconsistent logging**: If `ato_confirmed` events are not
  consistently emitted, or confirmation rules vary by team, the metric moves due to
  process changes, not attacker success.
- **Mix shifts across segments**: If the active population shifts toward new geographies,
  new device types, or higher risk cohorts, **Account Takeover Rate** can rise even if
  controls are unchanged.
- **Detection lag**: Takeovers are often confirmed days later, so short reporting windows
  can look better or worse depending on investigation backlog.
- **Definition creep**: Mixing blocked attempts into the numerator will inflate the metric
  and blur the difference between prevention and detection.