Microsoft is currently in preview with a new session attribute in Conditional Access policies that Requires token protection for sign-ins. Full Details: Microsoft Entra Conditional Access token protection explained – Microsoft Entra ID | Microsoft Learn
Outside of the biggest gripe here with this only being available in Entra P2 licensing, there are still many limitations with the functionality that I wanted to outline. Myself along with others I have spoken with, have misinterpreted the fully protections this provides you so I wanted to break them down here.
Device Bound Tokens
Before we dive into the functionality, let’s quickly discuss what why you want these protections. Device Bound Token Protection helps secure your Microsoft 365 environment by ensuring that login credentials are tied to a specific device. This means that even if someone steals a token (which acts like a key to access your account), they can’t use it from another device. It’s like having a key that only works in your home—if someone tries to use it elsewhere, it won’t work. This adds an extra layer of security, preventing unauthorized access and protecting your business from potential threats like token replay attacks, AiTM, etc.
Expectations vs Reality
To Microsoft’s credit, this is still in preview so I will update this blog post accordingly when there are updates. Here is a basic breakdown on my expectations vs reality with this protection:
| Expectation | Current Preview | |
| Supports All Device Types (Windows, Mobile, etc.) | Yes | Only Windows |
| Supports All Apps | Yes | SharePoint, Exchange, Intune, Teams |
| Prevents Token Replay In Browsers | Yes | No |
| Prevents Token Replay in Client Apps | Yes | Yes |
The biggest variance for me today is that this only works on client apps and not in the browser. So effectively, even through enforcing this policy, an attacker can still replay the session token in the browser through cookies which is where we see a very high volume today. (i.e. No protection from token harvesting and replay in AiTM attacks).
If a user tries to sign-in to a client app for Outlook, Microsoft 365 apps, or Teams, they will be able to successfully sign in if they are on a device that has a device-bound token. You will see that in the sign-in logs in Entra:
Devices have to be Entra Joined, Hybrid Joined, or Registered:
You will then see the CA policy pass:
If a user tries to sign into an outlook client on a device with an unbound token, they will see the following:
In the sign-in logs you will notice the unbound token failure from a new location:
The problem here is that the attacker can still replay the token in the browser via cookies:
End-User Experience
Outside of the user experience of trying to sign into a desktop client on a non-managed device without a device bound token, I did notice that I was asked to sign in across office applications as soon as I started enforcing this policy.
Conditional Access Policies to Protect against Token Theft
Summary:
- I split this out into token theft and token replay given tokens stolen via other methods such as malware, XSS, or malicious browser extensions can still be replayed even when enforcing compliant devices or phishing resistant MFA given the grant has already been satisfied in the token.
- Since many of us are on Business Premium, there are a few different options that would prevent the initial token theft. Having a compliant or managed device is probably the method most achievable today. Phishing resistant MFA is hard to garner adoption right now and trusted locations are tough as well given the remote workforce.
- Global Secure Access (GSA) is Microsoft’s SASE solution and provides both the protection of initial token theft and replay even though methods outside of AiTM. Cons are that is pretty cost prohibitive for SMB.
- Token replay protection via the above policy has its massive holes which I outlined in this post.