Stopping Account Takeover in CIAM: Bot, Fraud and ATO Defense

Account takeover (ATO) is the attack customer identity systems face most often, and most of it is not clever. Attackers replay passwords leaked somewhere else, spray common passwords across many accounts, relay one-time codes through phishing proxies, or walk in through a weak recovery flow. Stopping it means layering controls at four points: before the password is checked, at authentication, after login, and at recovery.

How customer accounts actually get taken over

• Credential stuffing. Automated replay of leaked username and password pairs. In July 2026 Chick-fil-A disclosed that credential stuffing compromised 13,322 loyalty accounts over three days in June, using credentials from an unrelated source. It was the company's second incident of the same class since 2023.
• Password spraying. One common password tried across thousands of accounts, staying under per-account lockout thresholds. Microsoft's Digital Defense Report counts roughly 600 million identity attacks a day against Microsoft Entra, 97% of them password attacks.
• Phishing proxies and OTP relay. The kit sits between the customer and the real site, captures the password, and forwards the one-time code before it expires. In July 2026 CTM360 described InsureOTP, a kit doing exactly this against insurance portals.
• Session theft. A stolen session skips login entirely. Gyazo's September 2026 breach exposed login session IDs for 23.62 million accounts.
• Recovery abuse. Keycloak patched CVE-2026-18963 on August 19, 2026, a reset-flow flaw that let a crafted request skip the email token and set a new password for any account.

Layer 1: stop automation before the password check

The OWASP Credential Stuffing Prevention Cheat Sheet is explicit that no single control is enough. The practical stack:

• Rate limits by account, IP, and network, with progressive delays rather than hard lockout. Hard lockout hands attackers a way to lock your customers out. NIST SP 800-63B caps consecutive failed attempts per account at 100.
• Bot detection using device and connection fingerprinting, with a challenge shown only when the risk score calls for it, not to every customer.
• Breached-password screening. NIST SP 800-63B requires verifiers to check passwords against lists of commonly used and compromised values. Screen at signup, at password change, and at login, and force a reset when a match appears.

Some platforms build this in. The Stytch profile notes device fingerprinting and bot defense alongside authentication, and Akamai Identity Cloud pairs customer identity with Akamai's edge bot management.

Layer 2: make the credential worthless to replay

Rate limits slow stuffing down. Passkeys end it, because there is no shared secret to replay, and the signature is bound to your domain so a phishing proxy cannot produce one. Amazon says more than 175 million customers have passkeys enabled, an older figure than the 465 million Identity Week reported in May 2026, and Microsoft reports phishing-resistant MFA stops over 99% of password attacks.

The catch is the fallback. In September 2026 CloudSEK found the BigBear phishing service disabling WebAuthn in the victim's browser so users fell back to a factor the proxy could relay, with completed compromises at 258 organizations. A passkey reduces ATO only as far as the weakest remaining login path allows. For accounts holding stored value or payment methods, gate or remove the password and SMS fallback once a passkey is enrolled. The passwordless CIAM guide covers a rollout that does this without hurting conversion.

Layer 3: score the session, not just the login

Login is one moment; fraud happens after it. Risk-based authentication scores each session on signals such as a new device, unfamiliar network, impossible travel, and velocity, then applies step-up authentication before sensitive actions: changing the email or phone number, adding a payment method, changing payout details, or redeeming points. Authsignal is a drop-in layer for exactly this on top of an existing identity stack, and Transmit Security scores sessions natively as part of every flow.

Two cheap controls belong here too. Revoke every active session when a password changes or compromise is suspected, and notify the customer on new-device sign-in and on any change to their contact details, which OWASP also recommends.

Layer 4: treat recovery as login

Every control above is worthless if the reset flow hands over the account on request. Hold recovery to the same assurance level as sign-in. Require step-up before an email or phone change, never allow an email change and a password reset in the same unverified session, and avoid SMS-only recovery for high-value accounts, since SMS codes are the factor OTP relay kits are built to steal.

Choosing a platform

Ask vendors to show, not describe: the bot and stuffing controls at login, breached-password screening, passkey enrollment with fallback gating, step-up hooks at arbitrary actions, and session revocation by API. The how to evaluate CIAM guide turns those into test cases. Compare the field in the best CIAM platforms, best CIAM for fintech, best CIAM for high scale, and best passwordless CIAM providers rankings, and for a capability matrix across platforms, see Deepak Gupta's CIAM Compass.

The goal is asymmetric cost: invisible to the honest customer, expensive for the bot. Stuffing and spraying are volume businesses, and they stop when the volume stops paying.