Account Takeovers Happen At Login. Not The Transaction

Account takeovers (ATOs) are unique in that by the time most companies become aware they have a problem, it’s already too late: When people report back to the company that they’ve been compromised, or they see fraud in the aftermath of an ATO. Ironically, these are the metrics fraud vendors are using to measure the number of ATOs they’ve seen. But by then, the challenge becomes one of clean-up rather than prevention. But both of these are consequences of the ATO problem. And in order to properly prevent account takeover, it’s essential to catch and measure ATOs where they start—at login. After all, that’s the point when the hacker commits the crime.

You want to catch as much as possible at login because that’s when your users are being compromised. Focusing on when abuse happens on your own platform, such as at the point of transaction, doesn’t put the user first. And it’s actually not an effective way to stop ATOs.

We’ve previously written about how account takeover shouldn’t be treated like a fraud problem. The clearest dangers in treating ATO as fraud lies in failing to catch ATOs, failing to protect users, and even blocking good users out of your application.

But the real reason most fraud vendors are calling ATOs “fraud” (and measuring ATOs wrong) is that they’re simply not equipped to address ATOs where they start. Fraud vendors have been trained to stop things downfunnel, such as at checkout, but they rarely have enough data to address things earlier, like before or at login. It’s a huge blind spot, given large scale attacks happen almost exclusively at login.

The login should be exactly the point at which your models start profiling, because that might be the moment that a user’s account is compromised. And that should be your goal: To stop attacks before they even really start. What’s more, the login event itself can be enough to prevent ATO for most use cases, when put in the context of typical user behavior.

Simply looking at properties like IP, location, device, time of day, mouse movements, keystrokes, etc. alone doesn’t contain enough information on whether a new login is an ATO, but to truly detect ATOs and prevent the damage they bring, you have to build your models around understanding the signals each user normally gives off—at login, across all their recognized devices, at checkout—and spotting common patterns, especially those that are indicative of malicious automated attacks no human could trigger.

That demands casting a wider net, that weights specific signals differently. Of course, casting such a wide net, and looking across the entire user journey, can be tricky.

For example, you might be thinking that this just makes the risk for false positives even worse. But here’s the thing: If you treat ATO like a security issue, your approach should be more about spotting unusual activity and challenging those anomalies by incorporating user feedback. When it’s treated like fraud, and so laser focused on the transaction, your risk score becomes correlated with the likelihood of a user committing fraud. So why not block them, just to be on the safe side?

For one, it’s simply not necessary. Traditional responses like user blocking are very blunt. But once you broaden your scope to consider the entire user journey, such one-size-fits-all approaches don’t make sense. By creating individual moats around key events, you can apply different levels of friction as the user gets more engaged with your app. Because not every anomaly is correlated with an attack, tripping the anomaly detection system shouldn’t automatically lead to a shutout. Instead, if you see a suspicious login location, challenge the user with an email or text message—and learn from their response.

The reality is that putting users first and preventing account takeovers aren’t as mutually exclusive as fraud-first approaches might have you believe. You want there to be zero incidents of real users getting locked out because they’re behaving strangely. And as such, fewer false positives. In that way, we need to turn the definition of false positives on its head.

It’s possible letting legitimate users into the experience you designed for them while shutting out true compromises completely. But it can only happen by focusing on the full user funnel, and catching ATOs where they start: at login.