Token Protection

Token protection (formerly token binding) is a Microsoft Entra ID Conditional Access capability that cryptographically binds access tokens to the device they were issued on. When the token is presented to a resource service, the binding is verified — a stolen token replayed from a different device fails. Mitigation for token theft attacks including adversary-in-the-middle (AitM) phishing and post-compromise lateral movement. Configured as a CA control: "Require token protection for sign-in sessions." Available for specific workloads (Exchange, SharePoint, Microsoft Graph) with broader coverage rolling out. Combine with phishing-resistant MFA (FIDO2, passkeys) and Continuous Access Evaluation for the strongest defence against modern token attacks.

What problem this solves that MFA alone doesn't

Even with strong MFA in place, a successful adversary-in-the-middle phishing attack can capture not just a password and MFA approval, but the actual session token issued after that successful authentication — and a token, once captured, can be replayed from the attacker's own machine to impersonate the user without needing to re-run the authentication at all. This is precisely why "we have MFA everywhere" doesn't fully close the phishing risk on its own: the attack has moved from stealing credentials to stealing the token issued after a legitimate, MFA-verified sign-in. Token protection addresses that specific gap by cryptographically tying the token to the device that requested it, using a key that stays on the device and never travels with the token itself — so a copied token, presented from a different machine, fails validation regardless of how the token was obtained.

Worked example

An employee falls for a convincing phishing email that leads to an adversary-in-the-middle proxy site. The proxy relays the employee's password and MFA approval to the real Microsoft sign-in service in real time, and in the process captures the resulting session token — a technique that would normally hand the attacker a working, authenticated session with no further challenge needed. With a Conditional Access policy requiring token protection for the affected workload, the token that's issued is bound to the employee's actual device via a private key that never leaves it. The attacker, operating from their own separate machine, can replay the stolen token, but the resource service (Exchange Online, in this case) checks the binding, finds it doesn't match the requesting device, and rejects the request — the phishing attack still succeeds at capturing credentials and an initial token, but that stolen token is useless for continuing access from anywhere but the original, legitimate device.

Where coverage currently sits

Token protection was introduced first for Outlook Desktop's connections to Exchange Online, then extended to Microsoft Graph and SharePoint Online for supported clients, with Microsoft continuing to broaden both the resource and client coverage over time. Because coverage is incremental rather than universal on day one, a Conditional Access policy requiring token protection needs to be scoped and tested against the specific workloads and client versions it actually supports — requiring it broadly before client support catches up can unexpectedly block legitimate sign-ins from otherwise-supported apps running an older build.

Common pitfalls

Token protection is a meaningful layer, not a replacement for phishing-resistant MFA — it stops a stolen token from being used elsewhere, but the initial phishing interaction can still capture other things the token protection control doesn't cover, depending on exactly how the attack unfolds. The strongest practical position pairs token protection with FIDO2 or passkey-based sign-in (which prevents the credential capture in the first place) and Continuous Access Evaluation (which shortens how long any token, stolen or not, remains valid once account state changes).