Microsoft 365 Security: Why Conditional Access Alone Isn’t Enough

Find out why Conditional Access (CA) policies in Microsoft 365 safeguard the issue of tokens but don’t prevent the use of stolen tokens.

Many corporations currently trust Azure AD Conditional Access rules to protect Microsoft 365 sign-ins. The conditions specified comprise requirements for granting an OAuth2 token (e.g., MFA or Trusted Network). The issue is that CA examines conditions just before giving out the token, but CA does NOT automatically defend the token.

Consequently, once attackers succeed in harvesting one valid token, attackers can freely submit the token anywhere without further restrictions unless other conditions mitigate them. In reality, researchers have demonstrated how attackers can “bypass Conditional Access rules and access M365 data outside of the company” just by requesting a token without using Continuous Access Evaluation (CAE). This clearly indicates that simply trusting CA is deceptive.

Conditional Access: Rules vs. Reality

Conditional Access (CA) is like a gatekeeper. It examines every sign-in attempt based on policies (IP location, device trust, MFA, and more) and allows or denies tokens. If the policy is not satisfied (e.g., a non-trusted location login attempt), sign-in is denied and a token is not issued.

However, after an Azure AD token is issued (once a successful login has occurred after CA verification), it stops checking that token. The attacker receiving a genuine token does not even have to login again and tries using that token till its expiry.

For instance, suppose there’s a CA policy permitting login from the office network. If an attacker gains access to a genuine token within that network, they simply replay that token from another network. The conditional policies won’t reapply again during such a replay, or CAE and other measures may be enforced.

Layered Defenses: CAE and Token Protection

In light of this gap, Microsoft has added more layers by ensuring that token revalidation occurs when these tokens are used. As Lionel Traverse states, “CAE enables validation of the security context every time an access token is used.” In other words, turning CAE on for apps (such as Exchange and Teams) requires Azure AD to revalidate every policy for every request rather than waiting for normal token expiration. CAE invalidates an access token immediately if it determines that there has been change in user status related to password resets or disabled or abnormal location.

Another critical control is the Token Protection. This is tied to the device that the token was initially issued on. Microsoft describes the function of the Token Protection as the token being “cryptographically bound” to the device secret such that the token itself will not be functional unless the device possesses the key. This basically means that the token is secured to the device that the token was generated with. This particular token will not be reusable by an attacker because the token will not be able to provide device-based proof-of-possession.

Finally, network defenses at the level of the network itself provide additional benefits too. Network firewalls or proxies can be used to control where tokens may be used (e.g., after establishing a VPN connection or when making suspicious calls to external APIs). These provide additional network defenses that can detect or prevent tokens exfiltrated to unknown destinations. Together, defenses at the application, token, and network levels make it difficult to mount token replay attacks successfully.

Tokens in the Wild: A Practical Bypass

Traverse carried out a real-life experiment to showcase how this discrepancy can be used. He made a CA rule where Outlook sign-ins were restricted to a certain IP address range only. Not surprisingly, signing in to Outlook from a blacklisted location resulted in a failure. Traverse signed in to Outlook from within his allowed IP network, obtained an application access token for Outlook, which included the CAE flag (xms_cc), and used it externally signing in to Outlook would result in failure due to CAE enforcing location restrictions correctly.

Then, Traverse obtained a new access token for Outlook without asking for CAE. This access token included full email and file access, but it didn’t possess the CAE bit. Signing in with this access token from an external network succeeded CAE restrictions were circumvented. In a nutshell, the attacker accessed the victim’s mailbox and OneDrive contents fully despite having CA restrictions in place.

• Typical Outlook token (with CAE): Recorded inside the network; replaying it outside the network proved unsuccessful, as CAE enforced the policy.
• Custom token (no CAE): Asked for through a script on a compliant device, and replaying it from the outside was successful, granting full access.

This shows that an attacker (even without admin rights) can use simple scripts or malware to request a token and use it anywhere if CAE and token binding aren’t enforced.

Enhancing Token Security in Microsoft 365

Given this risk, admins should layer multiple protections. For example:

Each of these factors makes the barrier for attackers higher. By using CA policies together with CAE, token security, device compliance, and monitoring, admins make sure that even if a token has been stolen, the data would not be breached using the stolen token.

Conclusion: Identity Security Does Not End at Login

This analysis makes one fact unmistakable. Conditional Access decides when a token is issued, but it does not control how that token is used afterward. Once a valid Microsoft 365 token exists, it can be replayed, reused, and abused unless additional protections are enforced.

Why This Threat Persists

Token misuse continues to succeed because many environments rely on point-in-time checks instead of continuous enforcement:

• Conditional Access evaluates conditions only at sign-in
• Stolen tokens remain valid until expiration
• Tokens can be replayed from new locations or devices
• MFA success does not prevent token abuse
• Visibility into post-login identity behavior is limited

This turns identity into a delayed failure point instead of an active control.

Where Xcitium Changes the Outcome

With Xcitium Identity Threat Detection and Response in place, token theft does not become a breach:

• Suspicious token usage is identified in real time
• Anomalous identity behavior is blocked immediately
• Replayed or misused tokens lose their value
• Unauthorized access attempts are stopped before data exposure

With Xcitium, a stolen token does not grant access.

Secure the Token, Secure the Tenant

Modern cloud attacks do not break passwords, they exploit trust. Protecting Microsoft 365 requires enforcing identity security continuously, not only at login.

Strengthen security where cloud attacks actually succeed.
Choose Xcitium Identity Threat Detection and Response.