A phishing-resistant sign-in counts for nothing if the session token gets lifted five minutes later.
Stealing a token routes around authentication altogether. The attacker never needed a credential, because they took a live session instead. Token protection ties the sign-in session token cryptographically to the device it was issued on, which means a stolen token replayed from anywhere else simply fails.
- Device boundTokens cryptographically tied to the device
- GA on WindowsFor native applications
- 3 workloadsExchange, SharePoint and Teams natively
- Report onlyThe mode Microsoft says to start in
Eight things to establish before you enforce it.
What the control actually enforces
Technically it is a Conditional Access session control. Its job is to cut token replay by ensuring that when an application asks for a protected resource, only device-bound sign-in session tokens are accepted, the Primary Refresh Token being the obvious example. That binding is cryptographic and it is tied to the registered device itself.
Why a stolen token stops being useful
Registering a supported device with Entra produces a Primary Refresh Token bound cryptographically to that machine. The documented consequence is straightforward: a threat actor who steals that token cannot use it from any other device. One sentence covers the entire security benefit.
Windows is the mature platform
Native applications on Windows have this generally available. The supported device list is Windows 10 or later that is Entra joined, Entra hybrid joined or Entra registered, plus Windows Server 2019 or later that is hybrid Entra joined. In most American corporate estates that covers the bulk of the fleet.
Which resources can be protected
Three applications carry native enforcement: Exchange Online, SharePoint Online and Microsoft Teams. On Windows the list extends to Azure Virtual Desktop and Windows 365. Everything else falls outside the control entirely, no matter how the policy is worded.
Apple support is preview and has prerequisites
Support reaches macOS 14.0 and later, and iOS or iPadOS 16.0 and later. Both remain in preview, both need the Microsoft Enterprise single sign-on plug-in, and both work only on devices under MDM management. On macOS there is an alternative to that plug-in, since Platform SSO can take its place.
Browser coverage is narrow today
For browsers the picture is narrower. Support is in preview and restricted to certain web applications, browsers and device configurations reaching Azure Resource Manager, which appears in Conditional Access as the Windows Azure Service Management API resource. On iOS and iPadOS the documentation lists browser-based support as unavailable altogether.
Report-only mode first, without exception
The recommendation is explicit: build the policy in report-only mode first, gather both interactive and non-interactive sign-in logs, and leave it running long enough to span how the applications are genuinely used. Non-interactive is the half teams routinely overlook, and it is where every unpleasant surprise turns out to be hiding.
It is one layer, not the answer
Nobody positions this as a complete answer to token theft, and neither should you. Device compliance, phishing-resistant authentication, continuous access evaluation and endpoint detection each address a different face of the same problem. What token protection closes specifically is the path where a stolen token gets replayed from somewhere else.
Run it in report-only first, and make sure non-interactive sign-ins are captured alongside interactive ones.
It appears in the documentation as a deployment recommendation, and it separates an uneventful rollout from a morning spent unblocking people.
- Five steps are set out plainly. Begin with a pilot group and widen it gradually. Build the Conditional Access policy in report-only mode before token protection is enforced anywhere. Capture the interactive and the non-interactive sign-in logs together. Analyze them across enough time to reflect how the applications are actually used. Only then move known reliable users onto an enforcement policy.
- It is the non-interactive traffic that catches teams out. Background token refreshes, calls between services and requests the application initiates itself never show up in the interactive log, and those are precisely the flows that fail once a token is not device bound. Read only the interactive log and you finish the analysis confident and wrong.
- Duration matters just as much as breadth. Applications get used to a rhythm, and that rhythm includes the month-end close, the quarterly reporting run, and the tool one person opens only when a particular task lands on their desk. Seven days of report-only data catches none of those, and every one of them is a candidate for a block nobody saw coming.
- Device state is the other half of being ready. Windows machines have to be Entra joined, hybrid joined or registered to qualify. Apple devices have to be MDM-managed with either the Enterprise SSO plug-in or Platform SSO deployed. Anything sitting outside those states is not partially covered by this control. It is outside it.
Four things that make this land without an incident.
We run report-only long enough to be meaningful
The instruction is to analyze the logs across enough time to reflect normal application use. Read in practical terms, that is a complete cycle taking in month-end and any periodic process, rather than the week somebody happened to have free. Compressing this phase causes more bad enforcement days than anything else.
We look at non-interactive sign-ins too
Both interactive and non-interactive sign-in logs are called for in the deployment guidance, and the non-interactive half is where background refreshes and application-initiated requests actually live. Those are exactly the flows that fail when a token is not device bound, and none of them appear in the interactive log at all.
We scope to what is genuinely supported
On Windows, native applications are generally available. On Apple, support is still preview and demands MDM-managed devices carrying the Enterprise SSO plug-in or Platform SSO. Browser coverage is narrow everywhere and non-existent on iOS and iPadOS. Design against the published matrix rather than against where the product is heading, and you avoid believing a gap is closed when it is not.
We write down what it does not cover
It is positioned as one layer within a defense in depth approach to token theft, never as the complete answer. What genuinely earns its place as a deliverable is the boundary itself: a written statement of which platforms, resources and access paths remain exposed, so the risk that is left over becomes a known quantity instead of an assumption nobody tested.
Four phases across roughly six to eight weeks.
- 01Week 1
Establish device state and platform mix
We establish which machines are Entra joined, hybrid joined or registered, which Apple devices are MDM-managed with the Enterprise SSO plug-in or Platform SSO deployed, and what share of your access happens through a browser. Any device outside a supported state sits outside the control completely.
- Device join state inventory across the estate
- Apple device management and SSO plug-in status confirmed
- Platform mix and browser dependency quantified
- Scope defined by what is genuinely supported today
- 02Weeks 2 to 5
Report-only, and let it run properly
The policy goes in as report-only, capturing interactive and non-interactive sign-in logs together, and it stays there long enough to see a full cycle of ordinary application use. That means through month-end and through any periodic process, rather than for whichever week happened to be free.
- Report-only policy in place and logging
- Interactive and non-interactive sign-ins both captured
- Analysis covering a full application usage cycle
- Incompatible clients and flows identified with owners
- 03Week 6
Enforce for a known reliable group
The guidance is to bring known reliable users into enforcement first. In practice that means people whose access patterns you already understand from the report-only data, and who will pick up the phone quickly when something breaks instead of quietly working around it.
- Enforcement applied to a pilot population
- Support path defined and communicated
- Failures triaged against the report-only baseline
- Decision recorded on any exclusions
- 04Weeks 7 to 8
Broaden and document the boundaries
The policy then extends across the estate, and the coverage boundary gets documented: which platforms are in, which resources are in, and which access paths this control never touches. When somebody asks a year later whether token theft is handled, that written boundary is the artifact that answers them honestly.
- Broad enforcement completed
- Coverage boundary documented explicitly
- Residual token theft exposure recorded
- Review point set for preview features reaching GA
Six situations where token theft is the live risk.
A firm that already deployed phishing-resistant MFA
Once credentials become expensive to steal, attackers go after the session instead. For a business that has already done the hard authentication work, this is the obvious next control, closing the path that work left open rather than treating the job as finished.
A business that has had a session hijacking incident
When an investigation ends with the conclusion that a valid token was used from an unfamiliar location with no authentication event anywhere in the log, this is the control that answers that finding head on. Because the token is bound to its device, a stolen one is useless from anywhere else.
An organization with a well-managed Windows estate
Native applications on Windows already have this generally available, provided the devices are Entra joined, hybrid joined or registered. Where an estate already meets that description, adoption is quick, and few security controls return as much for as little effort.
A company running Azure Virtual Desktop or Windows 365
Enforcement covers both of them on Windows explicitly. If your users work inside hosted desktops, protecting those sessions against replay is an obvious fit, and the deployment model has usually satisfied the device state requirements already without anyone planning it that way.
A business standardized on managed Apple devices
On Apple the support is preview and depends on MDM-managed devices carrying the Microsoft Enterprise SSO plug-in, or Platform SSO where you are on macOS 14.0 or later. Anywhere those prerequisites already exist, a pilot is worth running. Anywhere the Macs are unmanaged, the control is simply unavailable.
An operator asked to evidence session security
Sooner or later a SOC 2 auditor, an insurance questionnaire or an enterprise customer running a security review will ask about session hijacking and token replay by name. Answering that with the control enforced on the covered paths and the residual boundary written down lands far better than describing authentication controls that address an entirely different attack.
How US organizations handle token theft.
| Feature | Token protection enforced | Strong authentication only | MFA and nothing further |
|---|---|---|---|
Credential phishing addressed | Yes | Yes | Partly |
Stolen token replayable elsewhere | No, on covered paths | Yes | Yes |
Session bound to device | Yes | No | No |
Device state required | Joined or registered | Not necessarily | No |
Coverage boundary documented | Yes | Not applicable | No |
Report-only analysis performed | Yes | Not applicable | No |
Non-interactive sign-ins reviewed | Yes | Rarely | No |
Works for unmanaged Apple devices | No, and known | Not applicable | Not applicable |
Residual exposure recorded | Yes | No | No |
Defensible answer on token theft | Yes | Partial | No |
Three columns: generally available, still in preview, and not supported at all.
Platform or resource
Windows, native applications
- Status
- Generally available
Platform or resource
Windows, browser-based
- Status
- Preview, supported web apps accessing Azure Resource Manager
Platform or resource
macOS, native applications
- Status
- Preview, requires Enterprise SSO plug-in or Platform SSO
Platform or resource
macOS, browser-based
- Status
- Preview, supported web apps accessing Azure Resource Manager
Platform or resource
iOS and iPadOS, native applications
- Status
- Preview, requires Enterprise SSO plug-in
Platform or resource
iOS and iPadOS, browser-based
- Status
- Not supported
Platform or resource
Exchange Online, SharePoint Online, Teams
- Status
- Supported for native applications
Platform or resource
Azure Virtual Desktop and Windows 365
- Status
- Supported, Windows only
Platform or resource
Azure Resource Manager in a browser
- Status
- Preview, as the Windows Azure Service Management API resource
Platform or resource
Apple devices not managed by MDM
- Status
- Not supported
Five steps, and the long one is deliberate.
- 1
Establish device state and platform coverage
Windows clients have to be Entra joined, hybrid joined or registered, and Windows servers have to be 2019 or later and hybrid joined. Apple devices have to be under MDM management with either the Enterprise SSO plug-in or Platform SSO in place. Whatever falls outside those states is not partly covered by the control, it is outside it.
- 2
Scope to the supported resources
For native applications that means Exchange Online, SharePoint Online and Teams, with Azure Virtual Desktop and Windows 365 added on Windows. Browser coverage remains preview, reaches only certain web apps talking to Azure Resource Manager, and does not exist on iOS or iPadOS.
- 3
Deploy in report-only and capture both log types
The policy is built in report-only, capturing interactive and non-interactive sign-in logs together. It runs long enough to see how the applications are genuinely used, which in practice means carrying it through a month-end and through any process that only fires occasionally.
- 4
Enforce for a known reliable group first
Users whose access patterns are already understood from the report-only data, and who will report a problem rather than find a workaround. Failures triaged against the baseline so it is clear whether something genuinely broke or was always going to fail.
- 5
Broaden, and record the residual exposure
Enforcement widens across the estate and the coverage boundary is written down, naming the platforms, resources and access paths that stay outside the control. A review date goes in the diary alongside it, because Apple and browser support are still preview and that boundary will move under you.
What US organizations ask about token protection.
Fifteen questions to answer before enforcing.
Device state
- Are Windows devices Entra joined or registered?Hybrid joined also supported.
- Are any Windows Servers in scope?2019 or newer, hybrid joined.
- Are Apple devices MDM-managed?Only managed devices are supported.
- Is the Enterprise SSO plug-in deployed?Required on iOS, iPadOS and macOS.
- Is macOS on 14.0 or later?And iOS on 16.0 or later.
Coverage
- Which resources do we need protected?Exchange, SharePoint, Teams natively.
- Do we use Azure Virtual Desktop or Windows 365?Supported on Windows.
- How much access is browser-based?Coverage there is narrow.
- Do users work on iPhone or iPad browsers?Not supported.
- Are preview features acceptable to us?Apple support is preview.
Rollout
- Is the policy in report-only first?Microsoft says to do this.
- Are we capturing non-interactive sign-ins?The commonly missed half.
- Does the analysis cover month-end?A week of data is not a cycle.
- Who are our known reliable pilot users?They report rather than work around.
- Have break glass accounts been excluded?Verify it.
Find out what share of your Windows fleet is Entra joined, hybrid joined or registered.
Whatever that number is, it caps what token protection can cover, since a device outside those states is incapable of satisfying the control. Ten minutes gets you the answer, and the answer tells you whether this is a quick win or a device management project wearing a security label.
Related Services
Explore more solutions that work great with this service
Phishing-Resistant MFA
Phishing-resistant multifactor authentication for US organizations:
Learn moreMicrosoft Entra Conditional Access Design
Conditional Access design and review for US organizations:
Learn moreConditional Access Authentication Strengths
The right credential strength for each access decision
Learn moreMicrosoft Entra ID Protection
Entra ID Protection deployment for US organizations: establishing
Learn moreMicrosoft Intune
Device management and endpoint security
Learn moreMicrosoft Entra
Identity and access management solutions
Learn more