Token stealing is one of the stealthiest attacks out there. And if you think a strong password or MFA alone is enough to keep attackers out—think again.
What is Token Stealing Attacks?
An access token is a temporary passcode that lets users access apps and resources after they log in.
Lemme give an example that happens in real-time – You’re at a coffee shop, enjoying free Wi-Fi, and you log into a web service. 🌐Everything seems fine—until a cybercriminal intercepts your session and steals your access token. Suddenly, they have full access to your account, your data, and possibly even admin controls. And the worst part? Tokens often remain valid for hours, giving attackers plenty of time to exploit them before detection.
Token stealing happens when attackers intercept authentication tokens (like JWTs in Microsoft’s ecosystem) during transmission or exploit vulnerabilities in an app to extract them. Once stolen, these tokens let attackers bypass login defenses entirely.
So how do you fight back? This is where Token Protection in Conditional Access comes in. By enforcing extra validation checks before a token can be used, Microsoft’s solution helps prevent stolen tokens from being abused—drastically reducing the attack surface.
Why Traditional Security Isn’t Enough: The Need for Token Protection
You might be thinking, “We have MFA and strong password policies—shouldn’t that be enough?” Well, not quite. While these are essential security layers, they don’t fully protect against token-based attacks. Here’s why:
- MFA Bypass : If an attacker already has a valid token, they might not need to bypass MFA—they can use the token directly.
- Stolen Devices : Lost or compromised devices often store tokens locally. If an attacker gains access to the device, those tokens become an easy entry point.
- Legacy Systems : Older apps or configurations might not enforce modern token security standards.
This is where Conditional Access with Token Protection makes all the difference. Instead of relying solely on authentication at login, token protection ensures that stolen tokens can’t be reused in a different, unauthorized context. It binds token usability to specific device—making it exponentially harder for attackers to misuse them.
Up next, let’s dive into how you can implement this in your environment.
How the “Token Protection” Option in Conditional Access Helps
Token Protection in Conditional Access is an intelligent security feature that ensures stolen tokens can’t be misused elsewhere. Token Protection creates a cryptographic bond between an access token and the device it was issued to. Here’s the flow:
- Token Issuance: When a user logs in, Azure AD generates an access token.
- Secret Handshake: The token is tied to a unique “client secret” stored on the device (think of it as a hidden password only the device knows).
- Validation Check: Before granting access to a resource (like Outlook or SharePoint), Azure AD checks if the token includes the correct client secret. If not? Access gets denied.
Even if an attacker somehow steals a token, they can’t reuse it on a different device—because the cryptographic link is missing. This makes token theft attempts practically useless.
Requirements for Token Protection in Conditional Access
To get Token Protection up and running, you’ll need a few things in place. First off, it’s part of Microsoft Entra ID Protection and will require a P2 license once generally available. Currently, the preview supports:
- Windows 10 or newer (Microsoft Entra joined, hybrid joined, or registered)
- OneDrive sync client (v22.217+)
- Teams native client (v1.6.00.1331+)
- Power BI Desktop (May 2023 release or later)
- Visual Studio 2022 with the “Windows authentication broker” sign-in option.
- Note that Office Perpetual clients aren’t on the list—those won’t work with this feature.
How to Configure Token Protection in Conditional Access
Now that we know why Token Protection matters, let’s get hands-on and set it up in Microsoft Entra Conditional Access. Here’s how:
- Go to Microsoft Entra admin center → Protection → Conditional Access.
- Create a new policy and name it something clear, like Token Protection Policy.
- Select users/groups – Start with a pilot group before rolling out org-wide.
- Select target resources: Go to Target resources > Include > Select resources and choose:
- Exchange Online
- SharePoint Online
(⚠️ Do NOT select the entire Office 365 app group—it may cause unintended failures.)
- Set platform conditions:
- Go to Conditions → Device platforms → Yes → Windows (for now)
- Client apps → Enable Mobile & Desktop Clients only
- The main hero of the blog – enforce Token Protection:
- Go to Access controls → Session → Enable Require token protection for sign-in sessions (It’s currently in Preview)
Once done, review and enable the policy. Then, monitor Entra sign-in logs to ensure everything runs smoothly. This setup ties tokens to trusted devices, preventing unauthorized reuse while keeping user access seamless.
How the Conditional Access Policy Created with Token Protection Works
Once your policy is in place, here’s what happens behind the scenes: Let’s follow a user named Issac, who works in finance:
- Morning Login : Sarah logs into her company laptop using MFA. Azure AD issues an access token, which is cryptographically bound to her device’s client secret.
- Attack Attempt : A hacker steals Sarah’s token using phishing malware.
- Access Request : The hacker tries to use Sarah’s token to log into SharePoint from their own device.
- Validation Check : Entra detects the token but notices it’s missing the client secret tied to Sarah’s laptop. 🚫 Access is denied. The attack fails before it even begins!
This is Token Protection in action—ensuring that even if a token gets stolen, it can’t be reused outside its intended device. A silent, yet powerful defense against token-theft attacks, keeping your organization secure.
Conclusion: Token Protection = A Stronger Security Posture
Token theft is the digital equivalent of pickpocketing—silent, sneaky, and all too common.
Is Token Protection worth it? Absolutely. Because, every organization deals with sensitive data, securing access tokens is non-negotiable.
So, where do you go from here? Start by testing Token Protection in a staging environment to see how it fits into your setup. While you’re at it, double down on educating your team about phishing tactics—because even the best tools can’t completely guard against human slip-ups. And remember, keeping devices compliant is non-negotiable.
A few smart moves today can shut the door on token theft attacks tomorrow.
