For years, most identity security conversations have focused on protecting the authentication process. We have moved from passwords to multifactor authentication, Conditional Access, device compliance, risk-based policies, passwordless authentication, and increasingly phishing-resistant methods such as passkeys and FIDO2 security keys. All of these controls make it significantly harder for an attacker to authenticate as another user.
The problem is that authentication is only the beginning of the session.
Once Microsoft Entra ID has authenticated a user, tokens are issued that allow applications to access resources without forcing the user to authenticate every few minutes. This is fundamental to how Microsoft 365 and modern cloud authentication work, but those tokens also become valuable targets. If an attacker can steal a usable token or authenticated session, they may no longer need the user’s password or need to complete MFA again.
This is where Microsoft Entra Token Protection becomes important. Instead of concentrating solely on how a user authenticates, Token Protection helps protect what happens after authentication by making supported tokens more difficult to replay from another device.
Why Token Theft Is a Problem
When a user signs in to Microsoft 365, Microsoft Entra ID does not continuously ask them for their password and MFA response every time Outlook downloads an email or Teams makes a request. Instead, authentication results in tokens that applications can use to access services on the user’s behalf.
There are several types of tokens and session artifacts involved in Microsoft Entra authentication, including access tokens, refresh tokens, Primary Refresh Tokens (PRTs), session cookies, and device-related credentials. They serve different purposes and have different lifetimes, but from an attacker’s perspective, the objective can be very similar: obtain something that represents an authenticated user.
This changes the attack considerably. Rather than attempting to authenticate as Liam using Liam’s password, the attacker attempts to become the session that has already authenticated as Liam.
That distinction is important because many of our strongest controls sit at the authentication boundary. If an attacker steals the resulting session rather than the credentials used to create it, simply strengthening the password policy does very little to solve the problem.
MFA Does Not Automatically Protect the Session
MFA remains one of the most important identity security controls we can deploy, and organizations should absolutely continue using it. However, MFA primarily helps protect the authentication process. It does not mean that every token or session created after successful authentication is automatically protected against theft.
Adversary-in-the-Middle phishing is a good example. Instead of presenting the victim with a completely fake login page, an attacker can proxy the authentication process between the user and the legitimate identity provider. The user may authenticate against the real Microsoft Entra ID service and even successfully complete MFA, while the attacker attempts to capture information associated with the resulting authenticated session.
The attacker has not necessarily defeated MFA. The legitimate user completed it for them.
Phishing-resistant authentication methods can significantly improve our defenses against this type of attack, but the bigger lesson is that identity security cannot end when MFA succeeds. We also need controls that protect the authenticated session that comes afterward.
The Problem with Bearer Tokens
Many access tokens work on the principle that possession of a valid token is enough to present it to the intended resource. The resource validates the token and, assuming everything checks out, accepts it as proof that the request is authorized. That model works extremely well for usability and scalability, but it creates an obvious problem when tokens can be copied. If an attacker steals a usable bearer token and can successfully replay it from another system, possession of the token can effectively become possession of the user’s authenticated identity for whatever access that token provides.
This is the problem Token Protection is designed to make considerably harder.
Instead of allowing a supported token to exist independently of the device, Token Protection introduces a cryptographic relationship between the token and the device on which the authentication session was established. Microsoft refers to this concept as token binding and sender-constrained tokens.
The important idea is straightforward: stealing the token should not necessarily be enough to use it.
What Is Microsoft Entra Token Protection?
Microsoft Entra Token Protection is a Conditional Access session control designed to reduce the risk of token replay attacks. It requires supported sign-in session tokens to be cryptographically bound to the device on which they were originally issued.
On supported Windows devices, this works with the Primary Refresh Token and the cryptographic material associated with the device. Where available, hardware protection such as the Trusted Platform Module can help protect the secrets involved. The result is a significant change in how we think about a stolen token.
An attacker might successfully obtain the token, but the token is associated with cryptographic material that remains on the legitimate device. Copying the token onto another computer therefore does not automatically provide everything required to successfully replay the authenticated session against a protected resource. Rather than simply asking whether a token is valid, the authentication architecture can now consider whether that token is being presented by the device it belongs to.
How Token Protection Fits Into Authentication
At a high level, a supported Windows device establishes its relationship with Microsoft Entra ID and receives a Primary Refresh Token. That PRT and its associated cryptographic material allow the device to participate in Single Sign-On without continually asking the user to authenticate again.
When Token Protection is required through Conditional Access, supported applications and resources expect the sign-in session to use the appropriate device-bound protection. The token is therefore not intended to behave like a completely portable credential that can simply be copied from one system to another.
This creates an additional security boundary around the authenticated session. An attacker now has to overcome more than simply obtaining a valid token because the legitimate device becomes part of proving that the token can be used.
That is an important evolution in identity security. We are moving from protecting credentials to protecting authentication, and now towards protecting the session and the tokens created by that authentication.
Conditional Access Is Where We Enforce It
Token Protection is configured through Microsoft Entra Conditional Access using the Require token protection for sign-in sessions session control.
This makes Token Protection another component of the Conditional Access architecture rather than a separate security product. Policies can determine which users, applications, resources, and conditions require protected sessions. However, this is not a setting I would simply enable across the entire tenant.
Token Protection has specific requirements around supported platforms, clients, authentication scenarios, and resources. Unsupported combinations can cause authentication failures, so Microsoft recommends beginning with Report-only mode and reviewing the impact before moving to enforcement.
This is especially important when dealing with Microsoft 365. It may be tempting to target the complete Office 365 application group, but support needs to be validated for the applications and resources actually being used. A broad policy can create unintended problems for clients that do not support the required token behavior.
Understand the Device Requirement
One of the most important things to understand about Token Protection is its relationship with the device. The protection relies on having the appropriate device-bound authentication state, including the Primary Refresh Token. An unmanaged or unregistered device does not automatically have the same capabilities as a properly registered Windows device. This is why Token Protection fits particularly well into a broader device-based Conditional Access strategy.
If your organization already requires managed or compliant devices for important applications, Token Protection adds another layer to that trust relationship. The device is no longer simply something Conditional Access checks before allowing access. It can also become part of the cryptographic protection of the authenticated session. That makes device identity increasingly important within the overall identity architecture.
Token Protection Should Be Part of a Layered Strategy
Token Protection does not replace the other controls we already use. It strengthens a particular part of the authentication chain, which means it works best when combined with the other layers surrounding identity and endpoint security. A mature approach would typically include controls such as:
- Phishing-resistant authentication where appropriate.
- Conditional Access based on user, device, application, location, and risk.
- Managed and compliant devices.
- Microsoft Entra ID Protection for user and sign-in risk.
- Continuous Access Evaluation.
- Endpoint protection and monitoring.
- Token Protection for supported sessions and resources.
The important point is not that every organization must immediately enable every control. It is that each one solves a different part of the problem.
MFA makes unauthorized authentication harder. Device compliance helps establish whether the endpoint should be trusted. Token Protection makes supported tokens harder to replay elsewhere. Continuous Access Evaluation helps services react when circumstances change after the session has already been established. Together, those controls provide a much stronger security boundary than any one of them could provide on its own.
Where Continuous Access Evaluation Fits
Continuous Access Evaluation, or CAE, is worth mentioning because it also deals with what happens after authentication, but it solves a different problem.
Traditionally, once an access token was issued, that token could continue being valid until its configured lifetime expired. If something important changed during that period, there could be a delay before the existing session was forced to respond to that change.
CAE allows supported services and clients to react to critical events during an existing session. If the user account is disabled, credentials change, or another supported security event occurs, access can be reevaluated rather than simply waiting for the existing token to expire naturally.
Token Protection and CAE therefore complement each other. Token Protection helps address whether a protected token can be replayed from somewhere it does not belong, while CAE helps determine whether an existing session should continue to be trusted when the surrounding security state changes. Both demonstrate why modern identity security increasingly needs to look beyond the initial login.
Planning a Token Protection Deployment
I would approach Token Protection in the same way I approach most significant Conditional Access changes: understand the environment first, build a targeted policy, observe what happens, and then progressively enforce it.
Start by identifying the users and applications where Token Protection provides the greatest value. Confirm that the devices and applications meet Microsoft’s current support requirements and make sure supported clients are current before introducing enforcement.
Then create the Conditional Access policy in Report-only mode. Review the sign-in logs, identify unexpected clients or unsupported scenarios, and understand what would have happened if the policy had been enforced.
For Windows deployments, client-app selection also needs attention. Browser and desktop authentication scenarios do not necessarily behave identically, and Microsoft specifically documents considerations around browser-based applications and MSAL.js. This is another reason not to treat Token Protection as a simple tenant-wide checkbox.
Once you understand the impact, start enforcement with a controlled population and expand from there.
Think About the Policies Around It
Token Protection should also make you review the rest of your Conditional Access architecture. For example, if Token Protection is enforced for supported Windows devices, what happens when the same user attempts to access the application from an unknown or unsupported platform? You do not want an attacker to avoid one control simply by presenting themselves through a different access path.
Complementary Conditional Access policies can require device compliance, restrict unsupported platforms, control unmanaged devices, and apply stronger authentication requirements where necessary.
This is why Conditional Access policies should be designed as a collection rather than individually. Each policy should contribute to the overall access model without accidentally creating a weaker alternative path around another control.
Why Token Protection Matters
For me, the biggest reason to pay attention to Token Protection is that it changes one of the assumptions we have traditionally made about authentication. We have spent years making it harder to steal passwords and harder to successfully authenticate with stolen credentials. MFA, passwordless authentication, Conditional Access, risk detection, and phishing-resistant credentials have all dramatically improved that part of the process.
Attackers adapt.
If authentication becomes harder to compromise, an authenticated session becomes increasingly attractive. Rather than stealing the credentials required to create the session, attackers can focus on stealing the session itself.
Token Protection helps change the economics of that attack. A token that only works in combination with cryptographic material associated with the legitimate device is considerably less useful when copied somewhere else. That does not eliminate token theft, but it makes successful replay significantly more difficult in supported scenarios.
Final Thoughts
Microsoft Entra Token Protection represents another important step in the evolution of identity security. We started by protecting passwords, then strengthened authentication with MFA and phishing-resistant credentials, added device trust and risk-based Conditional Access, and are now increasingly protecting what happens after authentication has completed. That last part matters.
Successful authentication should not mean we stop evaluating trust for the rest of the session. The device, the token, the application, the user’s risk, and changes to the surrounding security state all need to remain part of the decision.
Token Protection provides another layer by binding supported tokens to the device they were issued to, making it harder for an attacker to simply steal an authenticated session and replay it elsewhere.
I would not deploy it blindly across an entire tenant, but I would absolutely be evaluating it. Start with the supported scenarios, use Report-only mode, understand how it interacts with your existing Conditional Access policies, and then progressively introduce enforcement.
Protecting authentication is still important. Protecting what authentication creates is becoming just as important.