Authentication doesn’t necessarily end when a user enters their password or completes MFA.

After authentication, Microsoft Entra issues tokens that applications use to access resources such as Exchange Online, SharePoint Online, Teams, and other services.

And this creates an important security problem:

What happens if an attacker steals a valid authentication token?

They may not need the user’s password.
They may not need to perform MFA again.
They may simply replay the stolen token from another device.

This is where Microsoft Entra Token Protection comes into the picture.

What Is Token Protection?

Token Protection is a Microsoft Entra Conditional Access session control designed to reduce token replay attacks.

Instead of treating a sign-in session token as something that can freely be reused from another device, Token Protection uses cryptographic device binding so that supported tokens are tied to the device where they were issued.

Microsoft describes this as token binding.

In simple terms:

Normal token

User → Sign in → Token
                 ↓
          Can potentially be stolen
                 ↓
        Attacker replays token

Protected token

User → Device → Bound Token
                 ↓
          Device key required
                 ↓
      Stolen token ≠ usable elsewhere

Microsoft’s documentation specifically describes Token Protection as a way to reduce token replay by ensuring that only device-bound sign-in session tokens are accepted for protected resources.

Why Is Token Theft Dangerous?

A common misconception is:

“We have MFA enabled, so stolen credentials are not a big concern.”

MFA is extremely important, but MFA doesn’t automatically solve every token-theft scenario.

Consider this sequence:

1. User authenticates
2. Microsoft Entra issues tokens
3. Attacker compromises the endpoint
4. Attacker extracts a valid token
5. Attacker attempts to replay it

The attacker may now possess something that represents an already-authenticated session.

Microsoft explains that stolen authentication tokens can potentially be replayed to access resources without going through the original authentication process again.

That’s why modern identity security isn’t only about protecting:

Username + Password

It also needs to protect:

The authenticated session itself.

What Does Token Protection Actually Do?

Token Protection attempts to make the token useful only on the intended device.

A supported device has cryptographic keys associated with its Microsoft Entra device identity.

For example:

Windows Device
     │
     ├── Device Identity
     │
     ├── Cryptographic Key
     │
     └── Primary Refresh Token (PRT)
             │
             └── Device-bound relationship

Microsoft Entra can then verify that the authentication request is coming from the expected device-bound session.

If an attacker copies the token and attempts to use it somewhere else, possession of the copied token alone isn’t sufficient.

That’s the fundamental security idea behind Token Protection.

Microsoft specifically notes that a stolen token without the corresponding client-device key cannot be used as intended when token protection is enforced.

Token Protection vs MFA

These two controls solve different problems.

Think about it this way:

MFA
 ↓
"Are you really the user?"

Token Protection
 ↓
"Is this authenticated session being used
from the device it belongs to?"

Therefore, Token Protection should not be viewed as a replacement for MFA.

It is another layer of defense.

Microsoft explicitly recommends using Token Protection as part of a broader defense-in-depth strategy against token theft.

Token Protection vs Device Code Flow

This is especially important because these two topics are often confused.

They address different security problems.

Device Code Flow

Device Code Flow is an OAuth authorization flow designed for devices or applications where normal browser-based authentication isn’t practical.

For example:

CLI / Device
     ↓
"Go to microsoft.com/devicelogin"
     ↓
User authenticates
     ↓
Application receives tokens

The security concern is that an attacker can potentially abuse the legitimate flow and socially engineer a user into authenticating a device or session controlled by the attacker.

Token Protection

Token Protection addresses something different:

Legitimate authentication
        ↓
Token issued
        ↓
Token stolen
        ↓
Attacker attempts replay
        ↓
Token Protection
        ↓
Device binding makes replay harder

So:

Device Code Flow = authentication/authorization flow

Token Protection = session/token replay defense

They are complementary concepts, not competing features.

How Do I Enable Token Protection?

Token Protection is configured through Microsoft Entra Conditional Access.

The control is located under:

Microsoft Entra admin center

→ Protection

→ Conditional Access

→ Policies

Create or edit a Conditional Access policy and configure:

Access controls → Session → Require token protection for sign-in sessions

Microsoft recommends starting with Report-only mode before enforcing the policy.

A simplified deployment looks like this:

                Token Protection
                       │
                       ▼
             Conditional Access
                       │
             ┌─────────┴─────────┐
             ▼                   ▼
          Windows             Apple
             │                   │
             ▼                   ▼
      Supported Apps       Supported Apps
             │                   │
             └─────────┬─────────┘
                       ▼
             Protected Resources

Don’t Turn It On Globally Without Testing

This is one of the most important operational points.

Token Protection is not something I would enable blindly across an entire tenant.

Why?

Because support depends on:

• Operating system
• Device registration state
• Application
• Client version
• Resource
• Authentication method
• Device management configuration

Microsoft recommends:

1. Start with a pilot group.
2. Deploy the Conditional Access policy in Report-only mode.
3. Review interactive and non-interactive sign-in logs.
4. Identify unsupported applications/devices.
5. Resolve compatibility issues.
6. Expand the pilot.
7. Move the policy to On after validation.

This is exactly the type of Conditional Access deployment where Report-only is your friend.

What Platforms Support Token Protection?

As of Microsoft’s current documentation, support is strongest around native applications on Windows and Apple platforms.

Windows

Token Protection is generally available for native applications.

Supported resources include:

• Exchange Online
• SharePoint Online
• Microsoft Teams
• Azure Virtual Desktop
• Windows 365

Supported applications include Microsoft Outlook, Teams, OneDrive, Office applications, Microsoft Edge sign-in, Microsoft Graph PowerShell with WAM enabled, Visual Studio Code, and others.

Apple

Token Protection is available for supported native applications on:

• iOS
• iPadOS
• macOS

Apple platforms have additional requirements around Microsoft Enterprise SSO, MDM, and hardware-backed device registration.

Browser-Based Applications

This is where administrators need to be careful.

Token Protection is not simply “protect every browser session.”

Microsoft currently has limited browser-based support in preview for selected web applications accessing Azure Resource Manager, with specific browser, operating system, and device requirements.

So don’t assume:

“I enabled Token Protection, therefore every browser token in Microsoft 365 is now device-bound.”

That’s not how the current implementation works.

A Real-World Example

Imagine an employee uses Outlook and SharePoint from a corporate Windows laptop.

The user completes MFA.

An attacker later compromises the endpoint and manages to obtain authentication material.

Without adequate token protection, the attacker may attempt to replay a stolen session token from another system.

With Token Protection enforced for a supported application/resource combination:

Corporate Laptop
      │
      ├── Device Identity
      ├── Device Key
      └── Protected Session
              │
              ▼
        Exchange Online

The attacker copying authentication material to:

Attacker Laptop

doesn’t automatically give them the same usable device-bound session.

That is the security value of binding the authentication session to the device.

Important Limitations

This is where real-world implementation gets interesting.

Token Protection has compatibility requirements.

For Windows, Microsoft currently documents limitations including:

• Office perpetual clients aren’t supported.
• Some PowerShell scenarios accessing SharePoint aren’t supported.
• Certain Visual Studio Code extensions aren’t supported.
• Surface Hub isn’t supported.
• Windows-based Teams Rooms aren’t supported.
• Certain Azure Virtual Desktop, Windows 365, Autopilot and other device-registration scenarios have limitations.

Apple has its own limitations.

For example, Apple’s native Mail and Calendar applications don’t support Token Protection, and users can be blocked from protected resources if the policy is enforced against those scenarios.

This is why a blanket:

“Require Token Protection for everyone”

policy can create unexpected helpdesk tickets.

How Should an Enterprise Deploy It?

A practical deployment approach would be:

Phase 1 — Identify the Scope

Determine:

• Which users need protection?
• Which devices are supported?
• Which applications are being used?
• Which resources are being protected?
• Which device registration types exist?

Phase 2 — Create the Policy

Target a small pilot group.

For example:

Users:
Token Protection Pilot

Platforms:
Windows

Applications:
Supported Microsoft 365 native applications

Session:
Require token protection

Phase 3 — Report Only

Enable:

Report-only

Then monitor sign-in logs.

Microsoft’s deployment guidance specifically recommends reviewing both interactive and non-interactive sign-in activity.

Phase 4 — Validate

Look for:

• Unsupported applications
• Unsupported devices
• Unbound sessions
• Registration problems
• Application compatibility
• User impact

Phase 5 — Enforce

Once the environment is validated:

Report-only → On

Then gradually expand the policy.

Token Protection Is Not a Silver Bullet

This is important.

Token Protection reduces the value of a stolen token by binding supported authentication sessions to a device.

But it doesn’t magically prevent every token theft technique.

Microsoft recommends a broader defense-in-depth approach that includes:

• Phishing-resistant authentication
• Device security
• Risk-based Conditional Access
• Device-based controls
• Token protection
• Network controls
• Monitoring and detection

Think of identity security as multiple layers:

                 Identity Security
                       │
       ┌───────────────┼────────────────┐
       ▼               ▼                ▼
  Phishing-       Conditional       Device
  Resistant          Access         Security
     MFA               │
                       ▼
                Token Protection
                       │
                       ▼
                  Monitoring

No single control should be expected to stop every identity attack.

3 Common Mistakes

1. Thinking MFA Already Solves Token Theft

MFA protects authentication.

Token Protection addresses the replay of supported stolen authentication sessions.

They solve different problems.

2. Enabling It Without Checking Compatibility

Supported applications and device registration types matter.

Always test first.

3. Assuming Every Microsoft 365 Browser Session Is Protected

Current Token Protection support is not equivalent to universal browser token binding.

Always check Microsoft’s current supported application/resource matrix before deployment.

💡 Fixr.Cloud Insight

Here’s the easiest way I explain Token Protection to an administrator:

MFA protects the front door. Token Protection helps protect the session after you’ve entered.

If an attacker steals a password, MFA may stop them.

If they trick a user through a phishing flow, phishing-resistant authentication can make the attack significantly harder.

But if an attacker gets hold of a valid session token, you also need defenses against token replay.

That’s where Token Protection becomes valuable.

The bigger lesson is that modern identity security isn’t just:

“How did the user authenticate?”

It is also:

“Where is the authenticated session being used?”

🎯 Bottom Line

Token Protection is Microsoft’s Conditional Access mechanism for reducing token replay attacks by binding supported sign-in sessions to a device.

Remember these four points:

1. Token theft is different from credential theft.
2. MFA and Token Protection solve different security problems.
3. Token Protection should be deployed through Conditional Access and tested in Report-only mode first.
4. Application, device, platform, and resource support must be validated before enforcement.

And the simplest mental model is:

MFA verifies the user.
Token Protection helps verify the session’s relationship to the device.

Fixr.Cloud – Smarter IT, Simplified.