14.8 Token Protection (Token Binding)

Token Protection (Token Binding)

Token protection binds the session token to the specific device that completed authentication. A token bound to Device A cannot be used from Device B — making token replay from attacker infrastructure impossible.

How token protection works

When token protection is enforced via conditional access, the authentication process binds the issued token to the device’s cryptographic identity (the device key stored in the TPM). When the token is presented to a resource server, the server verifies that the presenting device matches the device the token was bound to. If the device does not match (the attacker imported the token into a different machine), the token is rejected.

What this prevents: All forms of token replay where the attacker uses the token from a different device — which is every AiTM token replay scenario. The attacker’s machine is not the user’s device, so the token binding check fails.

What this does NOT prevent: Token abuse from the same device (malware on the user’s device using the local token). For device-level token theft, endpoint protection (Module 2) is the control.

Deployment

Prerequisites:

• Entra ID P2 (included in E5)
• Devices must be Entra ID joined or hybrid joined (BYOD/unmanaged devices cannot satisfy token binding)
• Windows 10/11 with TPM 2.0

Before enabling: Determine what percentage of your sign-ins come from managed (Entra joined) vs unmanaged (BYOD, personal) devices:

1
2
3
4
5
6
7

// Managed vs unmanaged device sign-in distribution
SigninLogs
| where TimeGenerated > ago(30d)
| where ResultType == "0"
| extend IsManaged = iff(isnotempty(tostring(DeviceDetail.deviceId)), "Managed", "Unmanaged")
| summarize SigninCount = count(), UniqueUsers = dcount(UserPrincipalName)
    by IsManaged

If >80% of sign-ins are from managed devices: Token protection is deployable with manageable impact. The <20% on unmanaged devices will need an alternative access path (e.g., OWA via browser without token binding, or MAM-enrolled mobile devices).

If >50% of sign-ins are from unmanaged devices: Token protection will disrupt a significant portion of your workforce. Deploy to a pilot group first. Plan a device enrollment strategy before tenant-wide rollout.

Conditional Access policy configuration:

Policy name: “Require token protection for desktop applications” Assignments: All users (or pilot group initially) Cloud apps: All cloud apps (or Exchange Online + SharePoint Online initially) Conditions: Client apps → Browser, Mobile apps and desktop clients Session: “Require token protection for sign-in sessions”

Blast radius: Users on unmanaged devices (no Entra join, no TPM) cannot satisfy the token protection requirement. They are blocked from the protected applications. Tenant-wide for users in policy scope. Significant for BYOD-heavy environments.

Cost impact: £0 additional licensing. Device enrollment effort varies — Entra join is free but requires IT deployment time.

Rollback: Disable or modify the conditional access policy. Effect is immediate — token protection is no longer required.

Staged rollout:

• Week 1: Enable for IT team only. Verify no disruption.
• Week 2: Enable for pilot group (20 users across departments). Monitor for blocked sign-ins.
• Week 3-4: Enable for all managed devices (using device filter in the CA policy conditions).
• Month 2+: Expand to include additional device types as enrollment progresses.

Verify after deployment:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

// Verify token protection is enforced
SigninLogs
| where TimeGenerated > ago(7d)
| where ConditionalAccessPolicies has "token protection"
| extend TokenProtectionResult = tostring(
    parse_json(tostring(ConditionalAccessPolicies))
    | mv-expand parse_json(tostring(ConditionalAccessPolicies))
    | where tostring(parse_json(tostring(ConditionalAccessPolicies)).displayName) has "token protection"
    | project tostring(parse_json(tostring(ConditionalAccessPolicies)).result))
| summarize
    Granted = countif(TokenProtectionResult == "success"),
    Blocked = countif(TokenProtectionResult == "failure")
    by bin(TimeGenerated, 1d)

Compliance mapping: NIST CSF PR.AC-7 (Authentication — token binding extends authentication protection to the session). ISO 27001 A.8.5 (Secure authentication). SOC 2 CC6.1 (Logical access controls). CIS v8 6.3 (Require MFA for externally exposed applications — token protection ensures MFA cannot be bypassed via token theft).

Subsection artifact: The complete token protection deployment guide with prerequisites, managed-device assessment query, staged rollout plan, blast radius, rollback, and verification. This is part of the CAE/Token Protection Deployment Guide artifact.

Knowledge check

Token protection troubleshooting

After deploying token protection, you may encounter these issues:

Problem: Users on unmanaged devices blocked. Token protection requires a device key from the TPM — available only on Entra joined or hybrid joined devices. BYOD/personal devices do not have this key and cannot satisfy the requirement.

Solution: Use device filters in the conditional access policy to exclude unmanaged devices. These users continue with standard (non-bound) tokens. Accept the trade-off: unmanaged devices are more vulnerable to token theft but blocking them may be unacceptable for the business.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// Monitor token protection policy: blocked vs granted
SigninLogs
| where TimeGenerated > ago(7d)
| where ConditionalAccessPolicies has "token protection"
| extend PolicyResult = case(
    ConditionalAccessStatus == "success", "Granted",
    ConditionalAccessStatus == "failure", "Blocked",
    "Other")
| summarize count() by PolicyResult, bin(TimeGenerated, 1d)
| order by TimeGenerated desc

Problem: Specific application incompatible with token protection. Some legacy thick clients and third-party applications do not support the token protection claim.

Solution: Create an application exclusion in the conditional access policy for the incompatible application. Document the exclusion as a known risk: the excluded application is vulnerable to token theft. Evaluate whether the application can be updated or replaced.

Problem: Windows Hello for Business conflict. Token protection and Windows Hello for Business both use device-bound credentials. In some configurations, enabling both causes sign-in loops.

Solution: Test with a pilot group before tenant-wide deployment. If conflicts arise: contact Microsoft support for the current guidance on co-existence settings.