Account takeover defence is sold under many labels, bot management, fraud detection, device intelligence, behavioural biometrics, CIAM risk engines, and buyers often end up paying twice for the same signal while missing the one that matters. This guide helps consumer platforms, retailers, banks, gaming and subscription services choose account takeover (ATO) protection on evidence. It sets out how to define requirements, the capability areas to compare across bot, device, behaviour and breached credential signals, an evaluation table, questions to put to vendors, red flags and a proof of concept plan. It is strictly vendor-neutral. For the attack patterns and the controls themselves, read the Account Takeover Prevention Guide first.
Key takeaways
- Start from your attack data, not a feature list. Credential stuffing at the login page, session cookie theft and phone-based recovery abuse need different signals; know which ones you are actually seeing.
- No single signal is enough. OWASP notes that IP blocking is easily evaded through proxy networks, CAPTCHAs can be solved by tools and services, and device fingerprints can be spoofed; buy layered signals that are combined into one risk decision.
- Protect the whole account lifecycle. Login is only one entry point: password reset, MFA change, contact detail change, session refresh and API logins must be covered too.
- Measure friction as hard as fraud. A tool that blocks attacks but challenges one genuine customer in ten will be switched off by the business within a quarter.
- Prove it on your own traffic. Run every shortlisted product in monitor mode on real traffic before signing, and score it on labelled outcomes.
Define requirements
- Threat profile: which attacks you see today (credential stuffing, MITRE ATT&CK T1110.004; password spraying, T1110.003; session cookie theft, T1539; MFA push fatigue, T1621; SIM swap and support-led recovery), with volumes from your logs.
- Surfaces: web login, mobile apps, public APIs used by your apps, partner and aggregator logins, password reset, contact centre and chat recovery. API logins matter: OWASP API Security Top 10 2023 lists Broken Authentication (API2:2023), including APIs that permit credential stuffing.
- Decision points: where a risk score must change the outcome: allow, step up, hold for review, block, or terminate sessions.
- Existing stack: your identity provider or CIAM platform, CDN or web application firewall, fraud platform and SIEM. Map which signals they already provide before buying another source.
- Constraints: latency budget at login, data residency, privacy rules on device and behavioural data, accessibility obligations, and mobile SDK limits.
- Standards to meet: OWASP ASVS 5.0 requires documented anti-automation and adaptive response against credential stuffing (V6.1.1), breached password checks at registration and change (V6.2.12), user notification of suspicious authentication attempts (V6.3.5) and the option to end other sessions after a factor change (V7.4.3).
Decision guidance: a smaller platform with one web login and a CIAM service often gets most of the value from turning on the identity provider's own risk-based step-up, breached password checks and passkeys, plus bot protection at the CDN, before buying a specialist product. A large platform with mobile apps, public APIs, high-value balances (stored cards, loyalty points, wallets) and a contact centre usually needs a dedicated risk engine that sees all channels and can act on sessions and account changes. Where a fraud platform already scores payments, ask whether it can score logins and account changes too before adding another vendor. Whatever the size, moving customers to passkeys reduces the attack surface that every product on this list is trying to police; OWASP notes that FIDO2 passkeys have made strong MFA more practical for consumer audiences.
Capability areas
| Signal or capability | What it detects | Known limits to probe |
|---|---|---|
| Bot and automation detection | Scripted logins, headless browsers, credential stuffing tools, CAPTCHA farms | Accessibility impact of JavaScript and challenge requirements; solve-rate monitoring; low-and-slow attacks spread across many IPs |
| Network and connection intelligence | Hosting and residential proxy traffic, TLS and HTTP/2 connection fingerprints that do not match the claimed client | Residential proxies make IP reputation weak on its own; blocks must be graduated and temporary |
| Device intelligence | New or emulated devices, device farms, many accounts per device | Client-collected attributes can be spoofed; customers with several devices; privacy notice and consent |
| Behavioural biometrics | Typing, touch and navigation patterns inconsistent with the account holder or with humans | Enrolment time for new customers; accessibility tools; data protection status of the data collected |
| Breached credential intelligence | Passwords known to be exposed in breaches, at registration, change and login | Only catches already published breaches; how the check preserves privacy (for example k-anonymity range queries, as used by the free Pwned Passwords API) |
| Risk engine and orchestration | Combines signals into a score and triggers step-up, holds or session revocation | Explainability of decisions; who can change rules; testing and rollback of rule changes |
| Account change protection | Risky password resets, new MFA methods, email and phone changes, new payees | Coverage of support-led changes, not only self-service |
| Session protection | Session or token replay from a new device or network after login | Whether it can terminate sessions in your application, not only score them |
| Customer notification and self-service | Alerts on new device logins and changes; customer view of active sessions | Alert fatigue; OWASP advises alerting on events such as a correct password followed by a failed MFA check |
Platforms that also handle broader fraud overlap here; see the Fraud Prevention Platform Buyer's Guide and the Bot Management Buyer's Guide to avoid buying the same layer twice.
Evaluation criteria
| Criterion | What good looks like | How to test | Suggested weight |
|---|---|---|---|
| Detection on your traffic | High catch rate of confirmed ATO and stuffing attempts | Monitor-mode scores compared with labelled incidents and fraud losses | 25% |
| Customer friction | Low challenge and block rate for genuine customers | Challenge rate and complaint volume on known-good cohorts | 20% |
| Lifecycle coverage | Login, reset, MFA change, contact change, session and API | Walk each flow in the test environment | 15% |
| Integration and latency | Fits your CIAM or IdP and CDN; meets your latency budget at peak | Load test with production-like volume | 10% |
| Explainability and control | Reason codes per decision; rule changes versioned and auditable | Review ten blocked logins with the analyst team | 10% |
| Privacy and data handling | Clear data inventory, residency options, retention limits, documented lawful basis support | Data protection review of the data processing terms | 10% |
| Vendor security and resilience | Independent assurance reports, fail-open or fail-closed choice, outage history | Assurance report review; failover test | 10% |
Questions to ask vendors
- Signals: Which signals does your decision use, and which require a client SDK or JavaScript? What happens when a client blocks them?
- Proxies: How do you detect attacks routed through residential proxy networks, where IP reputation is weak?
- Evasion: How do you detect CAPTCHA-solving services and spoofed device fingerprints, and how quickly do you update when attackers adapt?
- Breached credentials: Where does your breached credential data come from, how often is it refreshed, and do you ever receive our customers' plaintext or full-hash passwords?
- Lifecycle: Can you score password resets, MFA changes and contact detail changes, including those made by our contact centre?
- Sessions: After login, can you detect session replay and trigger session termination in our application?
- Accessibility: How does the product treat screen readers, assistive technology and customers who cannot complete challenges?
- Data: What device and behavioural data do you collect, where is it stored, how long is it kept, and is it used to train models for other customers?
- Failure: If your service is slow or unavailable, does our login fail open or fail closed, and can we choose per flow?
- Metrics: What false positive rate do customers of our size and sector see, and will you measure it on our data during the trial?
Red flags
- Detection claims stated only as percentages with no definition of the denominator or labelled data behind them.
- Reliance on IP blocklists or CAPTCHA as the main control.
- No support for monitor or shadow mode, forcing you to block from day one.
- Coverage limited to the login page, with no answer for password reset, MFA change or API authentication.
- Black-box scores with no reason codes, so analysts cannot explain a blocked customer.
- Vague answers on data reuse, retention or residency for device and behavioural data.
- Breached credential checks that require sending full password hashes or plaintext to the vendor.
Proof of concept
- Agree success criteria in advance: detection rate on labelled ATO, genuine customer challenge rate, latency at peak and analyst effort per alert.
- Label 60 to 90 days of historical login, reset and change events with known fraud outcomes, for scoring and comparison.
- Deploy each shortlisted product in monitor mode on the same traffic for at least four weeks, covering a peak trading period if possible.
- Include web, mobile app and API logins, password reset and MFA change flows, not only the main web login.
- Run an authorised credential stuffing simulation through a third-party testing firm against a test environment, and check what each product detects.
- Switch on enforcement for a small share of traffic, step-up first and block second, with a documented rollback switch.
- Compare results against your criteria, including customer complaints, support calls and accessibility feedback, then decide.
After selection, track the KPIs in the Fraud Metrics and KPIs Guide and keep the Credential Stuffing Attack Response Playbook current. Breached password checks are covered in the Breached password checks guide.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support across customer identity, fraud prevention, IAM and NHI. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Account Takeover Prevention Guide · Password Spraying and Credential Stuffing Defence Guide · Transaction Monitoring and Behavioural Biometrics Guide · Bot Management Guide