Account Takeover Incident Rate

Account Takeover Incident Rate (ATOIR) is the rate at which attackers successfully compromise user accounts, measured as confirmed compromised accounts per 10,000 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.

We measure Account Takeover Incident 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.

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

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

Get the Authentication Analytics Whitepaper

Analyze your Authentication Performance with Real Numbers

10 KPIs that connect authentication performance to revenue. Track adoption, friction & conversion impact.

Download the Authentication Analytics Whitepaper

Work email *

Name *

Company *

Job title *

Get Whitepaper

For Account Takeover Incident 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.

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. The multiplier converts the fraction into incidents per 10,000 active accounts.

Typical yearly reference ranges, shown as percent of active accounts and as per 10,000.

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 attempts that never succeed or phishing reports without a confirmed compromised session.

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.

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

We can improve the following business outcomes:

• Lower fraud loss and chargebacks: If Account Takeover Incident Rate rises in high value cohorts, we diagnose weak authentication and recovery controls, we roll out phishing resistant sign in such as passkeys and tighten recovery verification, we validate with fewer confirmed takeovers per 10,000 in that cohort.
• Lower user drop off with stronger security: If Account Takeover Incident Rate falls but abandonment rises, we diagnose added friction, we tune step up policies and improve passkey enrollment UX, we validate by holding takeover rates down while sign in completion remains stable.
• Lower support contacts caused by compromise: If Account Takeover Incident 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.

• Intent and selection bias: Confirmed takeovers often skew toward accounts that transact or complain, so Account Takeover Incident 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 Incident 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.

At minimum, break down Account Takeover Incident Rate by auth method used at compromise, passkey enrolled versus not enrolled, recovery path, geography, device, and account age. Always trend both the numerator and denominator so changes in activity do not masquerade as security wins.