Account Takeover Is Not a Login Problem.

The login receives disproportionate investment for understandable reasons. It is a single, well-defined endpoint. It generates clean metrics — attempts, failures, blocks — that are easy to report. And it feels like the boundary of the account.

But the login is the point at which the attacker has the least to lose and the organization has the least information. A valid credential arriving from a plausible device is, by construction, indistinguishable from a customer. Everything useful happens on either side of that moment.

There is also a measurement illusion. A login defence that blocks a large volume of automated attempts produces impressive numbers, while the successful takeovers pass through quietly and surface later as disputes, chargebacks or support complaints — usually categorized as something other than ATO.

Described at a strategic level — and deliberately without operational detail — most takeovers follow a recognizable arc.

Credentials are obtained externally and validated somewhere, often against a different or less defended surface than the one that ultimately suffers the loss. Access is then established on the target platform. There is frequently a reconnaissance period: the account is entered, its contents assessed, and nothing is taken. Preparation follows — contact details, credentials or payment instruments are adjusted so the legitimate owner loses visibility and control. Only then does extraction occur, through a purchase, a transfer, a redemption or a withdrawal.

The important structural observation is the gap. Access and extraction are often separated by hours or days, which is both a defensive opportunity and the reason login-time detection alone performs poorly.

Risk exists before any credential is submitted. The pre-authentication picture is mostly about population-level pattern rather than individual assessment.

Useful indicators include the distribution of attempts across accounts rather than per account, the diversity and consistency of device and environment characteristics, the coherence of network origin against the account's history, and the presence of automation-like regularity in timing. Failed-attempt patterns across the estate frequently reveal a campaign long before any individual account is compromised.

The value here is early warning and posture adjustment — raising sensitivity across an affected cohort — rather than deciding a specific login.

Once authenticated, the question changes from "are these the right credentials" to "does this behave like this customer." That is a fundamentally different and far more informative question.

Individually, none of these justifies an intervention. Collectively they form a behavioural baseline, and deviation from a customer's own baseline is a far stronger signal than deviation from a population average.

Post-login is where the loss is created and where controls deliver the highest return per unit of friction, because the customer has already demonstrated intent and the action itself carries value.

Changing the recovery address is the pivotal move in most takeovers: it converts temporary access into control and removes the owner's ability to reverse it. Contact-detail changes deserve verification through a channel that is not the one being changed, notification to the previous address, and a cooling period before other sensitive actions are permitted.

Adding an unfamiliar device or a new payment credential is ordinary customer behaviour in isolation. Doing so immediately after access from an unrecognized environment, followed quickly by use, is a materially different proposition. The sequence and its compression in time carry the signal.

Points, credits and wallet balances are frequently governed with less rigour than card transactions despite being directly convertible. Redemption, transfer and conversion should be treated as movements of value with the same controls, including velocity limits and step-up on unusual patterns.

This is the extraction point. Changes to payout destinations, first-time withdrawals to a new destination, shipping to an address added in the same session, and expedited fulfilment on high-value goods all warrant explicit treatment — verified confirmation, a deliberate delay window, or both, calibrated to value.

Rate limiting and bot mitigation are necessary. They protect infrastructure, reduce noise and raise the cost of large-scale automated attempts. They are not an account takeover defence, and treating them as one is a common and expensive error.

The reason is simple: rate limits govern volume, not validity. They do nothing about a low-volume, patient attempt using correct credentials, and they say nothing about what happens after a successful authentication.

The operational consequences of relying on volume controls during a large credential campaign are significant and frequently underestimated:

• Alert volume rises sharply, and genuine compromises are buried inside a large population of automated noise.
• Legitimate customers are locked out by thresholds tuned during an attack, driving a support surge at exactly the moment support capacity is under strain.
• That support surge becomes its own vulnerability, as pressure to restore access quickly weakens the rigour of the recovery process.
• Analyst fatigue degrades decision quality across every queue, not just the ATO queue, for the duration of the campaign.
• Blocked-attempt metrics rise, creating an appearance of control while successful takeovers proceed undetected.

Capacity planning for these periods — surge staffing, pre-agreed threshold playbooks, customer communications prepared in advance — is as much a part of ATO defence as any detection control.

Almost every organization already collects the signals needed. They sit in separate systems owned by separate teams, and the correlation that would reveal the attack is never performed.

The objective is an account-level risk view that persists across the session and updates as events occur, rather than a set of independent checkpoint decisions.

Trusted-device logic deserves particular care because it is doing more work than most organizations realize. Trust should be earned over time and behaviour rather than granted on first successful login, and it should be reduced — not merely re-evaluated — when the account undergoes a sensitive change. A device trusted before a recovery-detail change should not remain trusted after it.

Friction is a finite budget. Spent evenly across the customer base it damages conversion and retention while barely inconveniencing a determined attacker. Spent where value is at risk, it is both effective and largely invisible to legitimate customers.

Step-up verification tied to the payout, the profile change or the high-value redemption is proportionate and explainable. Blanket challenges at login are experienced as punishment by the customers least likely to be attackers.

Not every intervention needs to be a hard challenge. Notification, a delay window, a confirmation through an independent channel, or a temporary limit are all valid responses and are frequently better suited to ambiguous signals than a binary block.

Account recovery is where a well-defended platform is most often defeated, because it exists to grant access to someone who cannot authenticate. It must be held to the same standard as the primary path: verification proportionate to what the account holds, notification to prior contact details, a delay before sensitive actions resume, reduced device trust following recovery, and a support process that cannot be pressured into shortcuts. Recovery outcomes should be reviewed and measured, not assumed.

Blocked login attempts is the metric most often reported and among the least informative. A useful scorecard measures the sequence and the cost.

Two of these deserve executive attention specifically. The share of cases discovered by the customer rather than the platform indicates how much of the defence is actually working. And the ratio of cases caught before extraction to those caught after is the clearest measure of whether the program is defending the sequence or just the door.

If account takeover is currently owned by whoever owns the login, these are the positions worth adopting.

If it would be useful to review how your identity, device, behavioural and payment signals connect across the customer journey — and where the sequence is currently undefended — we are happy to have that conversation.