Guides

Account security guide

Account Takeover Defense at the Edge: A Layered Guide

Use the edge to slow anonymous automation, but keep identity, session revocation, authorisation, and irreversible customer decisions in the systems that own them.

Published
Updated
Reading time
14 min read
On this page

Account takeover crosses system boundaries: credential stuffing, password spraying, session theft, recovery abuse, and post-login cash-out do not share one reliable signal. A WAF rule, MFA enrollment, or bot score is not enough. Use independent controls at the edge, identity service, application, fraud layer, and incident process.

Overview

Outcome

Build a graduated, measurable ATO programme that limits automated abuse while retaining accessible recovery and a clear path to reverse false positives.

Assign each layer the right decision

Layered account-takeover defense
  1. Edge

    Apply endpoint limits, malformed-request filtering, and short-lived friction.

  2. Identity

    Verify credentials, MFA, passkeys, recovery, and anti-enumeration behaviour.

  3. Application

    Issue, rotate, revoke, and authorise sessions and sensitive changes.

  4. Fraud and response

    Assess post-login behaviour, contain harm, and restore legitimate access.

The edge contributes risk signals and capacity controls. The application and identity layers remain authoritative for customer identity and account state.

Limit abuse with independent keys

Credential stuffing replays known pairs; brute force targets a password; spraying distributes a few guesses across accounts. Use separate controls per account identifier, source IP or network, route, authenticated identity, and high-value business object. Do not use an attacker-controlled lockout as the only response: it can deny a legitimate customer access.

FlowEdge roleAuthoritative role
LoginPer-route and source throttling; short-lived challengePassword, breached-password, MFA, and account decision
RecoveryRate and request-shape limitsIdentity proof, recovery-channel and authenticator controls
Session refreshOrigin protection and anomaly signalToken rotation, invalidation, and session inventory
Payment or profile changeInitial risk signalFresh authentication, entitlement, fraud, and transaction approval
Representative ATO decision event
route=/login account_key=hashed:... source_bucket=network:...
attempt_rate=high edge_action=throttle identity_action=step_up
session_action=none decision=temporary customer_review_path=available

Make phishing-resistant authentication available

Offer passkeys or WebAuthn for sign-in and step-up. NIST requires an AAL2 verifier to offer a phishing-resistant option. Do not silently weaken recovery into a path around existing MFA: require fresh authentication before password, email, phone, MFA, recovery-channel, payment, or delivery-address changes.

Secure sessions after sign-in too. Rotate the session identifier after authentication and privilege changes, maintain server-side invalidation, restrict cookies with HTTPS, HttpOnly, and suitable SameSite policy, and let customers inspect and terminate active sessions.

Measure harm and false positives

Track attempts, success/failure, reset and MFA velocity, step-up outcomes, session revocations, confirmed ATO, and post-login fraud by route and risk cohort. Track customer cost too: challenge abandonment, support contacts, appeal reversals, and recovery success. Never log passwords, raw tokens, recovery codes, or unnecessary personal data.

Troubleshooting

ATO response mistakes

  • Permanently blocking a customer from IP reputation, geography, or browser signal alone.
  • Using a visible CAPTCHA for every sign-in without accessibility and recovery alternatives.
  • Treating a successful MFA login as proof that the resulting session cannot be stolen.
  • Allowing email, MFA, or payment changes without a fresh authentication decision.

Authoritative references

Make account protection harder to bypass and easier to operate

Optimi can help align edge controls, bot signals, session evidence, and incident workflows without treating one signal as customer identity.

Review account defense