Almost every identity security conversation runs into the same confusion about Microsoft 365 Conditional Access and the different layers of identity protection available.
People often assume that enabling MFA is enough, or that passkeys automatically protect against token theft. Others believe device compliance covers session hijacking, or that Conditional Access policies alone can enforce Zero Trust. The reality is more nuanced.
The problem isn’t a lack of features: Microsoft has released powerful capabilities over the last couple of years. It’s that each control is designed to solve a very specific problem, and they don’t fully replace one another. Deploy them without understanding what they actually do (and don’t do), and you end up with false confidence and exposed gaps.
This article breaks it all down:
- What each control protects (and what it doesn’t)
- Where the overlaps are, and where they clearly aren’t
- The trade-offs in deployment, complexity and user impact
- And most importantly: where to start, based on the kind of environment you’re working in
The goal isn’t to turn on everything. The goal is to build a protection model that matches how your users work, where your risks are, and what you can realistically maintain.
The four controls you should know
Microsoft provides four advanced identity and session controls that target different parts of the attack chain:
- Passkeys: prevent phishing with passwordless, device-bound authentication.
- Compliant Device: ensures users only access data from secure devices.
- Token Protection: stops attackers from reusing stolen session tokens.
- CAE Strict (preview): monitors and revokes sessions based on location or IP anomalies.
These controls work best when combined, but each has its own strengths, gaps and deployment considerations.
1Passkeys (phishing-resistant MFA)
Eliminate passwords by using a private key stored on the device (for example a TPM or a security key).
- Strong against: credential phishing, push fatigue, MFA fatigue and fake portals.
- Weak against: token theft after sign-in, session hijacking, device-based threats.
- Considerations: require compatible devices; need a backup method (for example Temporary Access Pass); a slight learning curve for users.
2Compliant Devices
Blocks access from untrusted or non-compliant devices using MDM (for example Intune).
- Strong against: malware-infected or jailbroken devices, unencrypted laptops, enforcing BYOD restrictions.
- Weak against: credential theft, token replay, compromised sessions from otherwise compliant devices.
- Considerations: high effort in BYOD environments; requires device enrollment and policy configuration; privacy concerns in mixed personal and work use.
3Token Protection
Prevents stolen tokens from being used on other devices by cryptographically binding them to the device.
- Strong against: token replay, session hijacking, post-compromise persistence.
- Weak against: credential phishing, poor device hygiene; limited to native Microsoft 365 apps (Windows, plus macOS and iOS on MDM-managed devices).
- Considerations: transparent to users; works in native apps on Windows, and on macOS and iOS only on MDM-managed devices; protects Exchange, SharePoint and Teams; browser support is only a preview for a few Azure admin portals.
4CAE Strict Location Enforcement
Continuously validates IP and location, and revokes sessions on unexpected changes.
- Strong against: VPN-based access control, proxy or spoofed location detection, mid-session hijack detection.
- Weak against: credential theft at sign-in, token theft within an allowed IP range, device-level threats.
- Considerations: ineffective with split-tunnel VPNs; requires known, static egress IPs; best suited to fixed-location or VDI-style deployments.
How they work together
No single control covers everything. Each addresses a different part of the identity stack:
| Control | Phishing | Bad devices | Token replay | Location/IP hijack |
|---|---|---|---|---|
| Passkeys | Yes | No | No | No |
| Compliant Device | No | Yes | No | No |
| Token Protection | No | No | Yes | No |
| CAE Strict | No | No | Yes | Yes |
Deployment trade-offs
| Control | Security value | User impact | Deployment effort |
|---|---|---|---|
| Passkeys | High | Medium | Medium |
| Compliant Device | High | Medium | High |
| Token Protection | Medium | Low | Low |
| CAE Strict | Medium | Low | High |
Each control brings value. The key is to combine them in a way that matches your users, infrastructure and attack surface.
The short version
These four controls, Passkeys, Compliant Devices, Token Protection and CAE Strict, aren’t redundant. They solve different problems at different layers of identity protection:
- One handles phishing.
- Another enforces device trust.
- The others protect sessions after sign-in.
If you rely on MFA alone, or use Conditional Access without understanding the role of each layer, there’s a good chance you’re leaving real gaps, especially around token replay, unmanaged devices and session hijacking.
What actually matters is clarity
- Knowing what each control is built to protect.
- Deciding where to begin based on your users, devices and risk model.
- Being smart about user experience, deployment overhead and licensing limits.
You don’t need to roll everything out at once. But you do need a plan built on the right foundations, not assumptions.
How Griffin31 helps
Griffin31 maps all four controls. It shows exactly which ones are already working in your tenant, where the gaps are, and what the right next step is, based on your actual usage, role types and environment.
Want to know which of the four controls already work in your tenant, and where the gaps are? Griffin31 checks your tenant continuously and shows you what to fix first.