Token Theft - The Threat That Keeps Security Teams Up at Night

7 min read

I’ve lost count of how many conversations I’ve had about token theft this year. It keeps coming up — customer calls, community meetups, security architecture reviews. Every single one. And honestly? It deserves the attention. Token theft has quietly become the number one identity threat for organisations, and the awkward reality is that a lot of the defences we’ve relied on just aren’t cutting it anymore.

So here’s my breakdown of what’s going on, why it matters, and what you can actually do about it today.

What Is Token Theft and Why Should You Care?

When someone authenticates to Entra ID, they get tokens — access tokens and refresh tokens — that prove who they are to the services they’re hitting. Those tokens are the reason you don’t have to type your password in every five minutes.

Token theft is pretty much what it sounds like. An attacker nicks those tokens and replays them from their own device. The token’s already been through authentication, MFA and all, so the attacker doesn’t need the user’s password or to pass an MFA challenge. They just become that user. Simple as that.

Think about it. You’ve rolled out MFA, built out your Conditional Access policies, run phishing awareness training — and someone can sidestep the lot by grabbing a token. That’s what makes this so uncomfortable.

How AitM Attacks Work

The technique driving most token theft right now is Adversary-in-the-Middle (AitM) attacks, sometimes called reverse proxy phishing. The flow goes something like this:

Attacker sends the victim a phishing email pointing at a fake sign-in page
That fake page sits between the user and the real Microsoft sign-in page — it’s acting as a reverse proxy
User types in their credentials on the fake page, and the proxy just forwards them straight to the real Microsoft login
Microsoft asks for MFA. The user completes it, and yep — that passes right through the proxy too
Microsoft issues tokens. The attacker grabs them as they come back through
Now the attacker has valid, fully authenticated tokens they can use from wherever they want

The user? They see a completely normal sign-in. They probably won’t notice a thing. But the attacker’s already got their session tokens and access to everything that user can reach.

What caught me off guard when I first looked into this was how accessible the tooling has become. Evilginx2 and similar frameworks have put these attacks within reach of a much wider pool of threat actors. This isn’t some nation-state capability anymore — it’s commodity phishing with a nasty twist.

What Makes MFA Insufficient?

I want to be clear here — MFA is still important and you absolutely need it enabled. Don’t take this as a reason to ditch it. The problem is that traditional MFA methods — push notifications, phone calls, even TOTP codes — they all authenticate the user, not the device or the session itself.

Because the authentication passes through the attacker’s proxy, the real user is the one completing the MFA challenge. Legitimately. The tokens that get issued afterwards are what the attacker steals. So MFA stopped the password guessing, but it did nothing to stop the token being intercepted.

This is exactly why the industry’s moving towards phishing-resistant authentication — FIDO2 security keys and passkeys. These are bound to the origin (the real Microsoft sign-in URL), so they flat-out won’t work against a fake proxy site. If the URL doesn’t match, authentication fails. End of story.

What Defences Do We Have?

Continuous Access Evaluation (CAE)

CAE is probably the most significant defence against token theft that’s available right now. Without it, access tokens stay valid until they expire — typically an hour. With CAE, events like an account being disabled, a password change, or a network location shift can trigger near-instant token revocation.

So if an attacker steals a token and tries to use it from a completely different IP address, CAE can spot it and kill the token. It’s not bulletproof though — if the attacker’s working from a similar network location, CAE might not fire. But it does shrink the window of opportunity significantly.

CAE should be on by default for supported Microsoft apps, but I’d recommend double-checking it’s actually working in your environment. I’ve seen Conditional Access policies accidentally break it without anyone realising. Also worth reviewing which of your apps actually support CAE.

Token Protection in Conditional Access (Preview)

This is the one a lot of us have been waiting for. Token protection (you might hear it called token binding) ties tokens to the device they were originally issued to. If someone steals a token and tries to replay it from a different machine, it gets rejected.

Under the hood, it uses a proof-of-possession mechanism linked to the device’s Trusted Platform Module (TPM). The token is cryptographically bound to the hardware. Steal it, move it to another machine — useless.

Here’s the honest bit though. Token protection is still in preview, and the coverage is limited right now. As of mid-2025, it handles sign-in token protection for Windows devices accessing certain Microsoft services. Browser-based scenarios? Not fully there yet. Mobile? Same story. And apps need to actually support it, which narrows the practical reach quite a bit.

Worth testing and keeping an eye on, absolutely. But it’s not a silver bullet yet.

Phishing-Resistant Authentication

If you want the single most effective preventative control against AitM attacks, this is it. FIDO2 security keys and Windows Hello for Business are your main options:

FIDO2 security keys — origin-bound, won’t authenticate to a proxy. They’re the gold standard for phishing resistance and the thing I push hardest in design workshops
Windows Hello for Business — gives you device-bound, phishing-resistant authentication on Windows
Passkeys — growing in support and a much more user-friendly route to phishing-resistant auth

You’ll want to use authentication strength policies in Conditional Access to enforce phishing-resistant methods. At minimum for privileged accounts, but ideally for anyone touching sensitive resources.

Practical Recommendations

Here’s what I’d be prioritising right now:

Get phishing-resistant MFA onto all admin accounts. Use authentication strength policies. No exceptions, no excuses.
Check that CAE is actually working. Pull up your sign-in logs, look for CAE claim presence, and make sure your Conditional Access policies aren’t accidentally breaking it.
Shorten token lifetimes where you can. Shorter tokens mean less time for attackers to work with. Conditional Access session controls let you limit sign-in frequency for high-risk scenarios.
Set up monitoring for token replay. Impossible travel detections, sign-ins from dodgy infrastructure, sessions where the IP flips mid-stream — Entra ID Protection picks up some of this, but you’ll want custom detection rules in Sentinel to cover the gaps.
Start testing token protection even though it’s still preview. Get familiar with it now so you’re not scrambling when it hits GA.
Talk to your users. They need to understand that MFA doesn’t make phishing links safe. Teach them to check URLs and use phishing-resistant methods where they can.
Think about managed device requirements. Requiring device compliance through Conditional Access is a layer that AitM can’t easily get around — the attacker’s machine won’t be compliant or managed.

The Uncomfortable Truth

Token theft shows up a pretty fundamental flaw in how we do identity security today. We’ve built systems where bearer tokens grant access, and bearer tokens can be stolen. That’s it. The industry’s working on fixing this through token binding and proof-of-possession, but we’re not there yet — not for every scenario.

Until we are, defence in depth is the play. No single control is going to stop token theft outright. But stacking phishing-resistant MFA, CAE, device compliance, and solid detection rules together — that makes life much harder for attackers.

This isn’t going away anytime soon. It’ll be a top priority for security teams well through 2025 and beyond. If you want to compare notes on your approach or share what’s working for you, drop me a message.