Token Protection: The Good, the Bad, and the Assumptions

September 27, 2025

Picture the classic castle and moat defense. For years, security teams believed that building high walls and deep moats could keep adversaries at bay. The logic seemed simple: if you fortify the perimeter, everything inside is safe. However, as attackers evolved, they found ways to circumvent the moat, phishing the gatekeeper, tunneling under the walls, or simply walking in disguised as a trusted guest. The lesson became clear: perimeter defenses alone couldn’t guarantee safety.

Token protection is seen as the modern moat. Many defenders believe it is impenetrable, trusting that locked-down tokens mean identities and data are safe. In reality, attackers do not make noise. They move quietly, stealing tokens from exposed endpoints, replaying them across services, and exploiting overlooked misconfigurations. Everything feels secure until you realize an intruder is already inside, moving freely with the keys you thought were protected.

This blog explores the gap between perception and reality, examining why token protection is necessary but never sufficient, highlighting the significant gap, and how dangerous assumptions can render robust defenses illusory.

Assumptions and theoretical understanding, however compelling before empirical validation, seldom correspond with the complexities of reality.

In cybersecurity, relying on theories, assumptions, or untested scenarios is especially perilous because adversaries exploit the very gaps that defenders overlook when they implement security models or best practices without rigorous, real-world validation. Effective defense demands continuous testing, adaptation, and a willingness to challenge even the most established beliefs. In a nutshell, BE THE PURPLE.

Token In a Nutshell

Token Issued

This authentication flow starts with the user presenting credentials such as username, password, and a second factor. These credentials are sent to Entra ID. Entra ID verifies them and, if successful, issues a session token or certificate. This token is safer for ongoing use than raw credentials.

With the token, the user requests access to resources such as SharePoint Online, Exchange Online, etc. Entra ID responds with an access token specific to those resources. The access token unlocks the data, ensuring that only authenticated and authorized users can access it.

Credentials are only used initially. Tokens handle ongoing access, reducing risk and keeping sensitive data protected.

Token Theft

This authentication flow relies on tokens to grant access after the initial credential check. While credentials are only exposed once, the issued tokens become the keys to the required and available resources. If an attacker manages to steal a valid session or access token through malware, phishing, or session hijacking, they can bypass the need for usernames and passwords entirely. The attacker can use the stolen token to access cloud resources, such as SharePoint or Exchange, as if they were the legitimate user, often without triggering additional authentication challenges.

This attack vector exemplifies the shift in threat landscape, where identity and token security have become primary targets. Attackers exploit weaknesses in credential management and token hygiene to gain undetected access to cloud environments. Effective defense requires rigorous monitoring of identity flows, strict token management, and continuous validation of authentication processes to prevent unauthorized access.

Token theft is a persistent threat in modern identity environments, with attackers increasingly targeting authentication tokens to bypass traditional security controls. Entra ID Token Protection introduces a device-bound defense, ensuring that authentication tokens are cryptographically tied to both the user and the endpoint. This design makes stolen tokens useless on any device other than the one where they were issued.

Token Protection operates as a Conditional Access session control, enforcing policy on critical Microsoft 365 resources, including Exchange Online, SharePoint Online, Teams, Azure Virtual Desktop, and Windows 365. Supported applications include the OneDrive sync client, Teams native client, Power BI Desktop, Exchange and Graph PowerShell modules, Visual Studio, and the Windows App. Only Windows 10/11 devices that are Entra ID joined, hybrid joined, or registered, and Windows Server 2019 or newer are eligible, as these endpoints can issue Primary Refresh Tokens (PRTs) that are securely bound to device hardware.

The protection mechanism centers on validating the possession of a device-bound PRT during resource access. This means that even if an adversary manages to extract a token, replaying it from a different device will fail the cryptographic verification enforced by Entra ID. Administrators can scope Conditional Access policies to specific users, groups, and resources, with the flexibility to exclude emergency or break-glass accounts to maintain operational continuity.

Token Protection is not a panacea but a strategic layer in a defense-in-depth approach. It complements device hardening, threat detection, and robust access policies, significantly raising the bar for attackers seeking to exploit token replay vectors. As support expands across more applications and platforms, organizations gain a powerful tool to disrupt adversary-in-the-middle tactics and reinforce the integrity of their authentication flows.

Token Protection in Microsoft Entra ID is a feature designed to combat token theft by binding authentication tokens to a specific device. In essence, a refresh token issued on a trusted device becomes useless if it is stolen and used on any other device. This capability aims to thwart Adversary in The Middle (AiTM) phishing and session hijacking attacks, which have been on the rise. By tying tokens to device credentials such as a protected TPM key on Windows, Token Protection prevents attackers from replaying a captured token on untrusted devices. However, like any security control, determined attackers and misconfigurations can find ways to bypass it.

Note: Microsoft observed a 146% increase in AiTM token theft attacks in a recent year.

What It Does

Token Protection (previously known as token binding) establishes a cryptographic link between a sign-in token and the device to which it was issued. When enabled via Conditional Access, only device-bound refresh tokens are accepted; any “bearer” refresh token that isn’t tied to the intended device will be rejected.

In practical terms, if an attacker steals a user’s token (for example, via malware or an AiTM phishing proxy), that token cannot be used on a different device because the cryptographic secret from the original device is missing. This drastically limits token replay attacks, where a thief would otherwise impersonate a user until the token expires or is revoked.

The Good

Token Protection introduces device-bound validation for authentication tokens, meaning a stolen Primary Refresh Token (PRT) cannot be replayed from another device. This disrupts adversary-in-the-middle and token theft campaigns that previously exploited gaps in MFA and Conditional Access. The practical impact is substantial: even if an attacker manages to extract a token from a compromised endpoint, attempts to use it elsewhere will fail cryptographic checks enforced by Entra ID.

Scope and Requirements

Token Protection remains tightly scoped, supporting only select client applications and platforms. Enforcement is limited to desktop and mobile clients accessing Exchange Online and SharePoint Online on Windows 10 or 11, with coverage contingent on both device and app supporting PRT-based authentication. Browser-based sessions and other services are currently out of scope; however, support is being incrementally expanded. This limitation means that organizations relying heavily on web-based workflows or legacy applications will not benefit from token protection until future releases extend compatibility.

Devices must be Entra ID registered or joined, as only these can issue a Primary Refresh Token. Unregistered or unmanaged endpoints are blocked and unable to obtain device-bound tokens. This requirement ensures that only compliant, managed endpoints participate in the protected authentication flow, reducing the risk of credential misuse and unauthorized access vectors.

Token Protection operates on a per-user, per-device basis. The PRT is valid only for the user who performed the initial sign-in. Lateral credential usage on the same device fails policy enforcement due to the absence of a valid PRT. This restricts token portability and enforces strict device-user binding, making credential theft or token replay attacks significantly more difficult for adversaries.

For pilots, administrators should target specific users and apps, explicitly excluding break-glass or emergency accounts to prevent accidental lockouts. Careful scoping is crucial to avoid operational disruptions, particularly in environments with mixed device management states or shared access scenarios. As the feature matures, broader adoption will require thorough readiness assessments and ongoing monitoring to ensure the policy’s effectiveness and the stability of the user experience.

The feature covers high-value Microsoft 365 resources, including Exchange Online, SharePoint Online, Teams, Azure Virtual Desktop, and Windows 365. Supported applications are tightly versioned and include:

OneDrive sync client (22.217+)
Teams native client (1.6.00.1331+)
Power BI Desktop (2.117.841.0+)
Exchange PowerShell module (3.7.0+)
Microsoft Graph PowerShell (2.0.0+ with EnableLoginByWAM)
Visual Studio 2022+ (Windows authentication broker)
Windows App (2.0.379.0+)
And more

For defenders, this means that session tokens are no longer portable between endpoints, significantly reducing the blast radius of endpoint compromise. Administrators can enforce Token Protection through Conditional Access, targeting specific users, apps, and resources, and gain visibility into policy effectiveness via sign-in logs. The result is a tangible reduction in risk for organizations facing sophisticated identity attacks, as well as stronger assurance that compromised credentials alone are insufficient for lateral movement or privilege escalation.

This example shows an authentication attempt to Microsoft Graph via PowerShell for the user “hector@purplexlab.onmicrosoft.com.” The process fails due to an organizational security policy enforcing token protection. The policy requires tokens to be linked to specific devices or applications, blocking access from generic PowerShell modules. This control mitigates token theft and replay attacks by ensuring only compliant applications or devices can use issued tokens.

The “Require token protection for sign-in sessions” control is enabled, mandating that authentication tokens are tied to verified devices or applications. While the feature is fully available for Windows and in preview for macOS and iOS, its scope extends to any supported platform as adoption progresses. Activating token protection enforces strict token integrity, preventing unauthorized reuse and mitigating risks associated with token theft and replay across diverse operating environments.

How It Works

When a device is registered or joined to Entra ID (Azure AD), it establishes a device credential; on Windows 10/11, this involves a private key secured by the device’s TPM. The user’s Primary Refresh Token (PRT), a long-lived refresh token that enables SSO across multiple apps, is bound to this device key. Enforcing Token Protection in a Conditional Access policy means that any refresh token presented must be a PRT bound to a compliant/enrolled device.

Suppose a refresh token is not device-bound (an unbound token). In that case, the system will automatically reject it because it does not satisfy the policy. In other words, without the device’s secret, the token cannot be used.

The token protection process begins when an attacker attempts to steal a token from a user through malware or phishing. After extracting the token, the attacker tries to use it to request access. The conditional access system reviews the request using several security layers. The device compliance service verifies whether the device meets the required security standards. The location service verifies that the request originates from a trusted location.

The risk engine evaluates the risk level of the access attempt. If any of these controls detect suspicious activity or fail to meet policy, conditional access is denied. Even if the attacker tries to replay the stolen token to the application server, replay prevention mechanisms block unauthorized access. This approach ensures that multiple independent checks protect resources from token-based attacks.

The Bad

While token protection brings a new approach and minimizes the token attack surface area, it remains vulnerable to several attack scenarios. Device-bound tokens stop replay attacks from different endpoints. Still, they do not address malware running on the protected device itself, advanced credential theft techniques, or exploitation of application-specific flaws. However, we don’t need to proceed to the advanced scenario because it can be exploited by leveraging known limitations.

Attackers with local access can still extract usable tokens if they control the device, and phishing or social engineering can lead to session hijacking before device validation occurs. Token protection also relies on application and device compatibility; unsupported clients or misconfigured policies can inadvertently create gaps in enforcement. In short, while it raises the bar for adversaries, it is not a silver bullet and should be part of a layered defense strategy.

Consider an attacker who gains access to a Windows 10 device and successfully extracts a Primary Refresh Token (PRT) bound to that endpoint. If the device is running a supported OneDrive sync client (version 22.217 or later), token protection prevents replaying the stolen token from another device. However, the attacker, with sufficient privileges, downgrades the OneDrive sync client to an older version that does not enforce token protection.

The downgraded client may accept and use the stolen token without validating its device binding, allowing the attacker to access or exfiltrate data from OneDrive as the compromised user. This scenario illustrates how legacy client versions can circumvent the protections intended by device-bound tokens, highlighting the importance of strict application version controls and monitoring for unauthorized software updates.

Excluding device categories from token protection policies creates enforcement blind spots and weakens the overall security posture. When organizations filter out Cloud PCs, Azure Virtual Desktops, Power Automate machine groups, Autopilot self-deployed devices, or Secure VMs, those endpoints can access resources without bound token validation on the device.

Attackers may target these exceptions to replay stolen tokens or exploit legacy authentication flows, increasing the risk of lateral movement and data theft. Every exception expands the attack surface, turning a strong Conditional Access control into a fragmented defense that adversaries can navigate.

Token Protection: Purple Team Reality Check

I ran a quick simulation to stress test Microsoft’s Token Protection. The target was a legitimate OneDrive for Business user with token protection enabled. The plan: extract the access token and use it from PowerShell on macOS.

Step one: token acquisition. With the protected token in hand, I spun up PowerShell on macOS to keep things interesting. Connected to OneDrive for Business. No friction. The API authenticated without issue and provided a complete directory listing. Bottom line: Token Protection did not prevent cross-platform token replay. If you can grab the token, you can access the files. The boundary enforcement is weak; the token traveled, and so did the access. In this case, protection was more theory than practice.

Objective

Evaluate Microsoft Token Protection by extracting a OneDrive for Business access token from a legitimate user, then replaying it from a different platform (macOS PowerShell) to test boundaries.

Method

Recon & Extraction
Using browser dev tools, I located OAuth tokens in session storage under the target’s SharePoint origin. Two keys, both tied to the user’s identity, each with a JWT payload ready for export.
Token Analysis
Decoded the JWT. Claims included:

- ‎`aud`: Confirms the token is scoped for OneDrive/SharePoint.
- ‎`iss`: Identifies the issuer.
- ‎`nbf`: Standard timing control.
Replay Test
Dropped the token into a PowerShell script on macOS.
Set ‎`Authorization: Bearer $token` in the headers.
Called the OneDrive API endpoint.Result:
- Authenticated as the original user (‎`User51@PurpleXLab.onmicrosoft.com`).
- List files in the user’s OneDrive with ease.
- No alerts. The token traveled, and so did my access.

Dev Tools: Shows session storage with exposed OAuth tokens for the target domain.

JWT Claims: Decoded, confirming the lack of effective binding.

PowerShell Output: Proof of successful authentication and file listing from an untrusted device.

Takeaway

Token Protection, as currently implemented, is more of a speed bump than a roadblock. If you can extract the token, you can roam. The control doesn’t enforce strong boundaries, token replay is still in play, regardless of OS or device. Attackers won’t care about theory; they’ll use what works. So should defenders.

Note: This is where device compliance and Conditional Access policies come into play. Conditional Access can require device compliance, forcing tokens to only work on devices that meet specific security standards. But in practice, if the token isn’t cryptographically bound to the device, enforcement is weak. Once a token is loose, it can be replayed from any endpoint.

The Assumptions

Token protection is built on a stack of optimistic assumptions. It presumes that binding tokens to devices will stop replay attacks cold, making stolen credentials worthless unless you also have the original endpoint. The model expects organizations to enforce strict version control, keep every device registered, and only grant resource access to compliant endpoints. In theory, this forces attackers to compromise both user and device, raising the bar and closing gaps left by legacy authentication.

But these are just assumptions. Token protection expects perfect control over endpoints, software, and user behavior. It assumes every device is registered, every client is patched, and no one ever downgrades or bypasses controls. In reality, endpoints drift out of compliance, users break protocol, and attackers hunt for those exceptions. A single legacy client or rogue device is all it takes to blow past the model. Relying on these assumptions is asking for trouble. If you trust the docs without testing the edges, you’ll miss the cracks where real breaches happen.

Let’s get specific. Documentation paints a world where every device is pristine, every user is a model citizen, and every endpoint is locked down to the latest standard. The reality? Endpoints get lost in the shuffle, devices fall out of management, OS versions lag behind, and users often skirt controls for convenience. Attackers know this and actively look for the soft spots: that one unregistered laptop, the outdated client with a bypass, or the bring-your-own-device that IT never saw coming. Token protection’s effectiveness collapses the moment these edge cases go unmonitored.

Security teams that buy into these assumptions without conducting field tests are flying blind. It’s easy to check a box in a compliance audit, and it’s much harder to enforce airtight controls in a live, messy environment. Token protection can absolutely raise the bar, but only if you recognize the difference between the idealized model and the chaos of real-world infrastructure. If you’re not actively hunting for drift, misconfigurations, and legacy access, you’re not defending, and you’re just hoping. And hope is not a control. Purplize it!

What about Token Protection policy and configuration in Entra ID Conditional Access, hunting via Microsoft Sentinel, and how to avoid misconfigurations? In the next blog post.