MFA ends at login. Account takeover doesn't.
The login ceremony gets hardware keys and biometrics. Everything after it rides on a cookie. The session, not the password, is where takeover happens now.
Over the last decade, most teams did the responsible thing: they hardened login. Passwords grew second factors, second factors grew phishing resistance, and the front door of the average SaaS product is now genuinely difficult to walk through uninvited.
So attackers stopped walking through it. They take what the door hands out instead.
The token is the account
A successful login produces a session — a cookie, a token, some string whose possession means this request is from the person who authenticated. From that moment on, the hardware key, the biometric prompt, the carefully tuned MFA policy are out of the picture. They were consulted once. The session is consulted on every request.
This creates an asymmetry that attackers understand better than defenders. The login ceremony is minutes of scrutiny. The session is weeks of unexamined trust. If you can obtain the artifact — through an infostealer on the user’s machine, a malicious browser extension, an OAuth grant that looked routine, or a support desk talked into a reset — you skip the hardened part entirely. The stolen token does not know it moved.
Notice what this does to the security model: the thing your strongest control protects is issued once, then travels on its own. Every MFA investment terminates at the moment of issuance.
What binds a session to anything?
In most systems, the honest answer is: nothing. A bearer token is exactly what the name says — whoever bears it, is it. Replay it from another machine, another network, another continent, and the server sees a valid session doing valid things.
Some systems add heuristics: flag a new IP range, maybe force re-login on a new user agent. These help, and they also train users to expect occasional random re-prompts, which is its own cost. The structural fix is different: make the session provably bound to the device it was issued to, so that possession of the token alone is worthless. Device-bound credentials exist for the login step — that is what a platform passkey is. Extending that binding to the session layer is where the industry is slowly heading, and where the gap currently lives.
The ceremony that actually matters
Here is the reframe that follows: the security-critical event is not login. Logins happen daily from devices you already trust. The critical event is the first appearance of a new device — that is where legitimate use and takeover look most alike, and where the decision deserves the expensive checks.
Treating device enrollment as a first-class ceremony changes the questions your system asks. Not “did this request carry a valid session,” but “has this device ever been introduced, by whom, and verified how.” A takeover attempt then has to survive the strongest path you have, instead of riding a cookie past it. And enrollment events are rare enough that you can afford real friction there — friction at every login is what users revolt against; friction at “a machine we have never seen wants in” is friction they expect.
Questions worth asking about your own system
- How long does a session actually live — not the config value, the observed behavior after refresh flows are counted?
- If a session token from one machine is presented by a different machine, does anything notice? Anything at all?
- Is there any action — deleting data, changing payout details, adding an admin — that asks for fresh proof of presence, or does the morning’s cookie cover everything until midnight?
- When a new device appears on an account, is that written down somewhere a human could later review, or does it dissolve into the login logs?
None of these require abandoning what you built for login. They require noticing that the perimeter you fortified is not the one being crossed.
The uncomfortable version of the test: if your own laptop’s session cookie were replayed from a machine in another country right now, would your product treat it as you? For most products the answer is yes — and every attacker who reads a stealer log knows it.
Axowl treats device enrollment as a sealed, auditable event — a new device on an account is a recorded decision, not a login row. See how it works.