Account-takeover prevention needs controls across the account lifecycle: authentication, recovery, active sessions, and sensitive changes. Start with stronger authentication and abuse controls on login, then check whether password resets or existing sessions provide another route into the account.
Bot protection helps with automated attempts. It cannot establish that a password was stolen or that the person using a valid session is its rightful owner.
Map the account flows before changing login rules
List every entry point that can create or restore account access: password login, federated login, recovery links, one-time codes, and support-assisted recovery. Include APIs and mobile flows that reach the same account service.
Then list the actions that make a compromise harder to reverse, such as changing an email address, enrolling a new authenticator, or replacing recovery details. A successful login should not silently grant a permanent right to perform all of them.
For each flow, record its existing limits, what gets logged, the owner, and how a legitimate user recovers from a wrong decision. This inventory is a planning tool, not a claim that all takeover incidents follow one pattern.
Make automated credential attacks harder
Credential stuffing reuses compromised username/password pairs; password spraying tries a small set of passwords across many accounts. OWASP's credential-stuffing guidance recommends layered defenses, including multifactor authentication, rather than relying on one request property.
Consider the unit each limit protects. An account-level budget can identify repeated attempts against one account. An IP-level budget covers a network source. Neither describes the whole problem when many accounts or shared networks are involved. Review both with the identity provider's existing controls before adding another layer.
Avoid a permanent lockout that an unauthenticated requester can trigger against any account. The protection should slow abuse without becoming an easy way to deny legitimate access. Define retry behavior and a recovery route the account owner can actually use.
Protect recovery with the same care as login
A strong login flow is less useful if recovery bypasses its protection. OWASP's recovery guidance calls for consistent account-existence responses, rate-limited requests, and reset tokens that are unpredictable, expire, and can be used only once.
Test a reset link after it has been used and after it has expired. Check what happens to existing sessions after a password reset, and make the intended behavior explicit. Protect code-sending endpoints as well as code-verification endpoints; they do different work and may have different abuse costs.
Keep support-assisted recovery in the inventory. An application control does not verify the identity of someone persuading a support agent to change an account.
Recheck identity for sensitive changes
OWASP's authentication guidance recommends reauthentication for sensitive actions and after risk events, with session handling appropriate to the result. Review email changes and authenticator enrollment as distinct operations, not incidental profile edits.
Prefer the stronger authentication options your identity system supports, including phishing-resistant options where available. Keep the enrollment and recovery path in the same review: adding a stronger factor does not help if an attacker can replace it through a weaker flow.
Notify the existing account contact about consequential changes through an appropriate channel. Make the response to an unexpected change clear. Notifications are a detection and recovery measure; they do not undo a change by themselves.
Use an account-flow control matrix
This worksheet is a suggested review method. Adapt the controls to the identity system and application you operate.
| Flow | Evidence worth reviewing | Control to check | Legitimate-user check |
|---|---|---|---|
| Login | Account attempt history, available client evidence, authentication result | Identity-provider protections and bounded retries | Shared networks and ordinary mistyped passwords |
| Recovery request | Account-target frequency and sender workload | Consistent responses and bounded delivery attempts | A user who requests the message again |
| Recovery completion | Token validity, expiry, and prior use | Single-use token handling and intended session invalidation | Expired links and lost sessions |
| Email or factor change | Current authentication strength and recent risk events | Reauthentication and change notification | A legitimate user moving devices |
| Existing session | Session state and sensitive actions | Revocation and reauthentication where required | Multiple valid devices and interrupted flows |
Test the full journey, not only the blocked request
Use test accounts and synthetic credentials in an authorized staging environment. Rehearse an ordinary login, a failed attempt followed by success, an expired reset, a reused reset, and a sensitive change. Separately simulate bounded automated attempts against those test accounts.
Record the client response, authentication result, session state, and whether the user can finish. A request classified as automated may still be an approved test or integration. An allowed browser request may still contain invalid credentials.
Choose rollback criteria before enforcement. If a new bot rule breaks login, revert that rule while retaining password, recovery, and session protections. Do not use a broad authentication bypass as the rollback plan.
Where bot protection belongs
The account-takeover use case covers the automated-traffic side of the problem. Centinel's bot-management overview explains the evidence and policy layer; the browser-automation guide goes deeper into client observations.
Place that layer around the supported requests your application can enforce. Keep password validation, authenticator verification, account permissions, and session revocation with the systems responsible for identity. Begin with the weakest account flow found in the inventory, then verify that ordinary users can still complete it.