CMMC Level 2 Token Protection Setup Guide

An attacker doesn’t need your password if they can replay your token. In a CMMC Level 2 environment, that gap matters because a stolen session can expose the same CUI your MFA already protected.

When I build Microsoft Entra policies for defense contractors and the MSPs behind them, I treat conditional access token protection as one more lock on the door. Used well, it raises the bar for token theft without breaking daily work. The difference between a clean rollout and a painful one is planning, so I start there.

Why token protection matters in a CMMC Level 2 stack

CMMC Level 2 pushes me toward disciplined access control, strong authentication, managed devices, logging, and a repeatable security process. Token protection fits that model because it cuts down one ugly path attackers love, session hijacking after sign-in.

That point matters because many environments already require MFA, compliant devices, and limited admin rights. Even then, a stolen token can still have value if it works from another machine. Token protection changes that by tying supported tokens to the device that received them.

I don’t present this control as a compliance shortcut. It isn’t. CMMC Level 2 still depends on broader controls across identity, endpoints, logs, policy, training, recovery, and incident response. However, token protection supports the same security story I want to tell an assessor: CUI stays behind managed identity controls and trusted devices, and stolen sessions are harder to reuse.

For MSPs, this is part of a bigger pattern. I see it in Small Business IT programs that start with Cloud Infrastructure, move through Office 365 Migration, and later add tighter identity rules. I also see it in Data Center Technology projects, Restaurant POS Support, and Kitchen Technology Solutions, where Cybersecurity Services, Endpoint Security, and Device Hardening have to work together. Good Technology Consulting ties those controls into Innovative IT Solutions, Tailored Technology Services, Cloud Management, Infrastructure Optimization, Secure Cloud Architecture, and Business Continuity & Security. That is what a real Business Technology Partner delivers during Digital Transformation and Managed IT for Small Business work. The same discipline belongs in an IT Strategy for SMBs, even when the environment also supports defense contracts.

What Microsoft Entra token protection actually does

In Microsoft Entra, token protection is a Conditional Access session control. It binds supported tokens to the device that obtained them, using device proof stored on that device. If an attacker steals the token and tries to replay it somewhere else, Entra can reject it because the second device can’t prove it owns the token.

I like Microsoft’s own explanation because it stays close to how the feature behaves in production. Their token protection documentation covers the feature, supported scenarios, and current limits.

As of June 2026, Windows is still the clearest production path. Support for iOS and macOS has been more limited, so I validate Microsoft’s current matrix before I scope those platforms. I also stay grounded about browser traffic. Token protection helps with supported token flows, but it does not give me broad protection for stolen browser cookies or every web session pattern.

Token protection binds supported tokens to a device. It does not stop every stolen browser session.

This quick table sets expectations.

Scenario	Token protection helps	What I keep in mind
Outlook, Teams, OneDrive on supported managed Windows clients	Yes	Best first pilot path
Token replay from a different device	Yes	That is the core value
Browser cookie theft	Limited or no	I still need other controls
Legacy auth or unsupported clients	No	Block legacy auth first
Token issued to an unmanaged device	No	Use device-based grant controls before issuance

That last row trips teams up. Token protection does not decide whether the original sign-in should happen. It protects the token after issuance. Because of that, I still need strong baseline Conditional Access policies that require a compliant or joined device for CUI-related apps.

Prerequisites I confirm before touching production

I never turn on token protection first. I build the floor before I add the extra lock.

The first prerequisite is licensing. Conditional Access needs the right Entra licensing for every included user. In many SMB environments, that comes through suites already in place. In regulated tenants, especially those with government cloud needs, I verify licensing and feature availability before I draft policy.

Next, I confirm device trust. My pilot devices are usually Windows 10 or 11, Microsoft Entra joined or hybrid joined, and enrolled in Intune with a working compliance policy. If the device trust story is messy, token protection exposes the mess instead of fixing it.

Client support comes right after that. I start with Microsoft 365 apps that use modern auth and supported token flows, such as Outlook, Teams, and OneDrive on Windows. I avoid broad scope until I know which apps still rely on older flows, embedded browsers, or non-brokered sign-ins. A useful field summary appears in this T-Minus 365 breakdown, but I still treat Microsoft documentation as the source of record.

I also block legacy authentication before rollout. If a client bypasses modern auth, token protection won’t help. At that point, the better answer is removal, not exception sprawl.

Then I check emergency access. Every tenant that matters needs at least two cloud-only break-glass accounts, protected with strong credentials, monitored, and excluded from Conditional Access.

Keep emergency access accounts excluded from every Conditional Access policy. If identity controls fail during an outage, those accounts are your recovery path.

Finally, I review service accounts and automation. Token protection is for user sign-in sessions. If a workload still depends on a shared user account or headless sign-in, I fix that design first. Service principals, managed identities, and app-specific auth patterns belong in their own track.

How I roll it out without hurting the business

The safest production rollout is narrow, observable, and easy to reverse. I use a pilot group first, then a second wave, then broad rollout only after the first two are quiet.

My pilot group is small but real. I include a few IT staff, a security admin, and business users who live in Outlook, Teams, OneDrive, and Office apps all day. I don’t start with executives, the help desk queue owner, or anyone who travels with unusual device patterns.

I also scope the pilot to the apps that matter most for CUI or internal data. In many tenants, that means Microsoft 365 first. Later, if line-of-business apps rely on supported sign-in flows, I expand carefully.

Change control matters here because session controls can look fine on paper and still surprise users. I tell the pilot group what to expect, when to report issues, and how to capture a sign-in timestamp and app name. That shortens troubleshooting fast.

I keep the exit path simple. If the pilot causes unacceptable friction, I disable the pilot policy or remove the pilot group membership. I don’t stack five new identity changes into the same week, because that blurs the root cause.

Most importantly, I don’t confuse token protection with a stand-alone defense. My production sequence is usually this: strong MFA, device compliance or join requirement, legacy auth blocked, session visibility in logs, then token protection for supported sessions.

Step-by-step setup in Microsoft Entra

This is the flow I use in production, with the portal names current for Microsoft Entra in 2026.

1. In the Microsoft Entra admin center, go to Protection and then Conditional Access.
2. Confirm your baseline device policy is already active for the target apps. I want managed, trusted devices in place before I bind tokens to them.
3. Create or confirm three groups: a pilot group, an exclusion group for emergency accounts, and a temporary support group for rollback or testing.
4. Select Policies, then create a New policy. I use a clear name, such as “CA Token Protection Pilot for M365 on Windows”.
5. Under Assignments, include the pilot group. Exclude the emergency access accounts and any known service or automation accounts that should never use interactive user sessions.
6. Under target resources, start narrow. I usually pick the Microsoft 365 apps most used for CUI handling, rather than every cloud app in the tenant.
7. Under Conditions, scope by platform if needed. For a first deployment, I often target Windows only because it is the most proven path.
8. In Session controls, turn on Require token protection for sign-in sessions. This is the key setting.
9. If your tenant supports a useful report-only check for your draft, use it briefly to confirm scope. Then move the pilot to On and test with live sign-ins, because session behavior has to be proven in practice.
10. Save the policy, document the change ticket, and watch sign-in activity during the first few business days.

After I save the policy, I sign in with a pilot account on a supported managed Windows device. I test Outlook, Teams, OneDrive, and Office apps first. If those pass, I widen coverage in controlled stages.

I also keep policy sprawl under control. If one Conditional Access policy already requires a compliant device for the same app set, I don’t clone it five times without a reason. Clean policy design makes audits, troubleshooting, and assessor conversations much easier.

For CMMC-aligned environments, I document the business purpose, app scope, target groups, exclusions, test evidence, and rollback plan. That record does more than help the next admin. It shows that access protections were chosen, tested, and maintained with intent.

How I test and validate before wider rollout

I test token protection like a production control, not a checkbox. First, I use a fresh pilot user on a known-good Windows device that is compliant, properly registered, and signed in with modern auth. Then I validate the user’s daily apps one by one.

My first pass is boring on purpose. Outlook opens, Teams signs in, OneDrive syncs, and Office apps obtain tokens without repeated prompts. If any of those basics fail, I stop and inspect the device state before I widen scope.

Next, I review Entra sign-in logs for the pilot user. I look at applied Conditional Access policies, the client app involved, device details, and any failure reason tied to unsupported flows or missing device proof. Those logs usually tell me whether the issue is policy scope, client support, or device registration.

When I have a lab or security test window, I add a replay-focused check. I don’t do reckless token theft in production. Instead, I validate that supported sessions remain tied to the original managed device and that an equivalent session attempt from a second device fails.

These are the signals I want before rollout grows:

• Pilot users can work normally in supported Microsoft 365 clients.
• Unsupported clients are identified and either replaced or blocked.
• Sign-in logs show the intended policy path and clean device context.

If report-only looked quiet but live tests failed, I trust the live tests. Session controls earn their place by working under real client behavior.

Common problems and the fixes that save time

The most common issue I see is simple: the app isn’t using a supported flow. A browser session, an embedded web view, or an old client can bypass the part of the stack where token protection helps. In that case, I don’t fight the physics. I move the user to a supported client or block the old flow.

The second issue is missing device trust. If the device isn’t properly joined, registered, compliant, or using the expected brokered auth path, token protection may fail or behave inconsistently. I check the device object, Intune compliance state, and the user’s sign-in method before I blame Conditional Access.

Policy overlap also causes pain. One policy might require a compliant device, another might limit platforms, and the new pilot might add token protection. When those layers collide, the user only sees a broken sign-in. I map the final effective path in sign-in logs and remove unneeded overlap.

I also watch for accounts that should never have been in scope. Shared admin accounts, automation users, or stale test users create noisy failures. Tight group hygiene fixes a lot of “mystery” problems.

Another practical limit is browser risk. Microsoft has discussed token replay detection and related protections such as Continuous Access Evaluation in this Microsoft Q&A thread. That context matters because token protection is strong, but it is not the whole answer for session abuse. I still pair it with phishing-resistant MFA where I can, strong device controls, short admin exposure, and good sign-in monitoring.

If I had to reduce troubleshooting to one rule, it would be this: verify the client, verify the device, then verify the policy scope. Most failures live in one of those three places.

Closing thoughts

For CMMC Level 2 environments, token protection is worth the effort because it makes stolen supported tokens far less useful off-device. That is a strong gain for organizations that already rely on managed endpoints and Microsoft 365 for sensitive work.

I get the best results when I treat it as one layer in a larger identity plan, not as a silver bullet. A careful pilot, clean exclusions, solid device trust, and honest testing turn this feature into a practical control instead of another policy that looks good only in a slide deck.