Classic brute-force makes many password attempts in a short time from a single IP. Credential stuffing tries the same password list distributed across many IPs. Low-and-slow attacks make a small number of attempts over hours. Session hijacking attempts reveal themselves after a successful login through changes in IP, user agent or behavior. Catching all of these with the same rate-limit rule is not realistic.
Using only IP-based lockout lets distributed credential stuffing slip through and unfairly affects legitimate users on shared networks. Using only user-based lockout lets attackers intentionally trigger account lockout as a denial-of-service. Using only CAPTCHA turns every login attempt into unnecessary friction and degrades user experience.
Many solutions look only at the moment of login. Yet the account takeover risk continues after login: if sensitive actions such as password change, email change, payment method addition, API token generation or fund transfer arrive in a new context, this is a post-login abuse signal. This behavior must be evaluated together with session binding and step-up MFA.
The right approach is to use the appropriate scope and signal combination for each attack class. IP, username, username_ip and composite scopes must work together with bot score, failed-auth velocity, IP reputation and session binding mismatch.
TR7 Account Takeover Protection delivers this model: it combines WAAP traffic signals with AAM access policies and manages ATO risk through a multi-layer policy graph rather than a single rule.
TR7 applies ATO defense through multi-signal scoring, attack-class-specific scope selection, graduated escalation and AAM coordination.
Bot score, failed-auth velocity, IP reputation and session binding mismatch are all evaluated on the same decision path. Decisions are made based on the actual behavioral form of the attack — not solely on IP or solely on username.
IP scope tracks single-source brute-force attempts, username scope tracks distributed credential stuffing, username_ip scope tracks targeted attacks, and composite scope tracks combinations of IP, user agent and headers. Each scope operates with its own counters and threshold behavior.
In the first stage the event is written to the audit log, then self-hosted CAPTCHA is activated, and finally lockout is applied. This model slows the attacker while minimizing unnecessary friction for legitimate users.
WAAP traffic signals can work alongside AAM lockout and step-up MFA policies. Additional verification can be triggered for users approaching the CAPTCHA threshold or exhibiting a session context change.
Account Takeover Protection brings pre-login traffic risk, login failures and post-login session behavior together in the same protection chain.
TR7 makes ATO defense graduated through the warning → CAPTCHA → lockout flow. The warning stage produces an audit trail without presenting friction to the user. The CAPTCHA stage challenges automation and offers legitimate users a controlled verification step. The lockout stage temporarily halts attempt capacity for the specific scope.
ATO attacks cannot be caught by a single scope. TR7 can run IP-based, username-based, IP+username-based and composite scope policies simultaneously on the same endpoint. Single-IP brute-force, multi-IP credential stuffing and targeted account attacks are each tracked separately. Even if an attacker stays under one scope, the other scope can still detect the behavior.
The failedAuthAttempts trigger counts failed attempts within a defined time window. This counter can be tracked per user, per IP or per composite scope. Short windows surface fast brute-force attempts; long windows reveal low-and-slow ATO behavior. Both total count and attempt density over time feed the decision.
TR7 can factor in user agent analysis, IP reputation, behavior analysis, suspicious path, header fingerprint, protocol anomalies, signal inconsistency, Tor exit node, TLS fingerprint and datacenter IP when computing the bot score. When the score reaches a defined level, a CAPTCHA or block action can be triggered. Login attempts are evaluated not only as password errors but also as automation behavior, bringing traffic quality into the ATO defense.
IP reputation subcategories such as open proxy, bad bot, attack, reconnaissance, spam and VPN IP can be used as risk signals in ATO decisions. These categories do not have to produce mandatory blocking on their own; they are evaluated alongside bot score and lockout policies. Login attempts from known bad infrastructure can be subjected to earlier friction. This approach works in combination with other signals to reduce false-positive risk.
Path hammering, rapid requests, high 404 rate, mutation requests without a referer and unexpected HTTP method usage can all be risk signals on the login surface. These indicators help distinguish credential stuffing, account enumeration and automated scanning behavior. Signals are not evaluated in isolation — they work alongside bot score and failed-auth counters. The attack becomes visible not only from password errors but also from traffic behavior.
When the CAPTCHA threshold is exceeded, TR7 can activate its own challenge flow. A controlled challenge is presented to the user without sending data to an external verification service. Incorrect CAPTCHA responses can be added to the failed-attempt counter and accelerate escalation. This provides a more controlled model for organizations with data residency and regulatory sensitivity.
TR7 can coordinate WAAP bot and lockout signals with AAM access policies. Step-up MFA can be triggered for users approaching the CAPTCHA threshold, generating a session binding anomaly or performing a sensitive action. This approach carries the login-time risk into post-login operations as well. Even if the attacker knows the correct password, they still face the additional verification barrier.
A session can be associated with IP, IP+user agent or a composite context. If IP, user agent or context changes unexpectedly after login, a session binding anomaly can be generated. This signal is particularly important in session hijacking and token reuse scenarios. Re-authentication or additional controls can be triggered on sensitive endpoints.
attemptWindowDuration defines how long failed attempts continue to be counted. If a user makes a few password errors today, they can return to clean behavior once the window expires. An attacker who accumulates enough attempts within the same window encounters CAPTCHA or lockout. This model strikes a healthier balance between security and user experience.
For each login attempt, timestamp, source IP, user agent, scope, policy ID and outcome can be recorded. Outcomes such as warning, CAPTCHA, lockout or successful pass are distinguished during incident review. Recipient details such as email or phone number are masked so the audit log does not become a secondary data leakage channel. SOC teams track attack flows using structured records.
If a quarantine action is defined after the lockout period expires, the client or scope can be placed under additional scrutiny. This makes it harder for attackers to repeat the same attempts each time the lockout duration ends. Quarantine provides ongoing risk tracking beyond classic lockout behavior and is a useful extra layer in long-running ATO campaigns.
ATO protection is operated together with ready-made policy presets, native counters, bot score curve, pool isolation, composite scope and AAM counter sharing.
TR7 can provide ready-made lockout policy examples for username, IP and username_ip scopes. The username scope focuses on credential stuffing with a longer window; the IP scope focuses on brute-force behavior with a shorter window. All thresholds, durations and actions can be adjusted to the service's needs.
Failed login attempts are tracked using fast counter structures. This approach reduces dependency on external database calls and provides low latency on the login path. Replicating counters to peer nodes in a cluster environment is important for protection continuity after failover.
The bot score can be interpreted as sensitive at low signal levels and saturating as high risk accumulates. This approach allows many small signals to compound into meaningful risk. When a new signal is added, the need to redesign the entire policy threshold from scratch is reduced.
Each pool can be bound to its own traffic protection profile. An ATO signal on one tenant or service does not affect another tenant's counters. This isolation is critical in multi-tenant SaaS and MSP scenarios.
Composite scope can combine IP, user agent, accept-language or similar header components into a single tracking key. This model provides more contextual tracking when IP or username alone is not sufficient. It offers additional visibility against rotating user agents or variable client behavior.
WAAP failed-auth counters can be coordinated with AAM lockout policies. Even if an attacker targets different login endpoints directly, the same risk behavior can be evaluated on the shared counter and policy path. This makes ATO protection consistent not only at the traffic layer but also throughout the identity flow.
Banking teams can monitor login endpoints with IP scope and SSL connection behavior together. When defined thresholds are exceeded, CAPTCHA, lockout or AAM step-up MFA is activated.
Bots making a small number of attempts from many IPs may not appear under IP scope. Username scope catches failed attempts accumulating on the same account and applies account-level CAPTCHA or lockout.
Low-volume but focused attempts against a CFO or administrator account can be tracked with username_ip or composite scope. When risk rises, step-up MFA is triggered through AAM.
If IP or user agent changes unexpectedly immediately after a user logs in, a session binding anomaly can be generated. Re-authentication can be required for actions such as fund transfers, email changes or token generation.
Integrated ATO defense against credential stuffing, brute-force, low-and-slow and session hijacking. Let's walk through a live setup on your own services.