Why a Simple Session Revoke Change Triggered a Bigger Security Question
In February 2026, Microsoft Entra ID will replace the long standing action Revoke MFA sessions with a new control called Revoke sessions. At first glance, this looks like a minor operational improvement. In reality, it addresses a fundamental misunderstanding that has existed for years in identity security.
For a long time, administrators assumed that revoking MFA sessions immediately neutralised a compromised account. Technically, this was never true. The legacy action only reset per user MFA state. If MFA was satisfied through Conditional Access, existing sessions and access tokens often remained valid. Token issued meant access preserved.
This behaviour repeatedly surfaced during incident response scenarios, suspicious sign in investigations and lost or stolen device cases. Administrators believed they had contained the incident, while attackers continued operating with valid tokens.
The upcoming Revoke sessions action finally aligns behaviour with expectation. It terminates all active sessions, signs users out across applications and devices, and clears authentication state regardless of whether MFA was enforced per user or via Conditional Access. From February 2026 onward, this becomes the default behaviour.
This change is more than a quality of life improvement. It exposes a broader reality. Conditional Access and MFA protect the moment of authentication, not the lifetime of a session. That realisation is the starting point for this article.
Why Conditional Access Still Fails in Real World Zero Trust Architectures
Microsoft Entra ID Conditional Access is one of the most critical enforcement layers in a modern zero trust security model. It evaluates identity signals such as user risk, device state, authentication strength, location and application context before granting access to corporate resources.
Despite its maturity, Conditional Access is not absolute. Certain authentication flows, service exclusions and design decisions allow access paths where policies are not evaluated or only partially applied. Some of these behaviours are intentional and documented by Microsoft. Others are the result of misconfiguration or are actively abused by attackers.
This article explains how Conditional Access bypasses occur, why they matter from a defensive perspective, and how organisations can reduce exposure using practical and realistic controls.
Conditional Access in Context
Conditional Access functions as a policy decision engine within Entra ID. When a sign in occurs, Entra ID evaluates applicable policies and enforces controls such as multi factor authentication, compliant device requirements or access restrictions.
However, not every sign in is equal. Certain workloads, system services and authentication endpoints are excluded from Conditional Access evaluation. In sign in logs these events often appear with the status notApplied.
These exclusions are the foundation for most Conditional Access bypass scenarios.
How Conditional Access Policies Are Evaluated
Before analysing bypass techniques, it is important to understand how Conditional Access evaluation works.
Conditional Access policies are evaluated per sign in. During authentication, Entra ID determines the client app, resource, authentication method and contextual signals. All applicable policies are then processed together. If any policy results in a block, access is denied. If policies require controls, those controls must be satisfied before tokens are issued.
When a resource or client app is excluded, policy evaluation is skipped entirely for that sign in. This explains why excluded resources always appear as notApplied in sign in logs and why no other policies are evaluated afterwards.
Understanding this evaluation order is essential to understanding why bypasses exist.
Categories of Conditional Access Bypasses
1. Client Apps and Authentication Flows as a Bypass Vector
Conditional Access behaviour differs depending on the client app and authentication flow.
Browser based sign ins, modern authentication clients and legacy protocols are treated differently by Entra ID. Certain first party Microsoft clients are implicitly trusted to enable core platform functionality. These trust assumptions are frequently abused by attackers.
Specific client identifiers are allowed to request tokens without triggering all Conditional Access requirements. When combined with permissive OAuth scopes, this allows attackers to authenticate from unmanaged devices while appearing legitimate.
2. Device Compliance Not Enforced During Specific Flows
Conditional Access policies that require a compliant or hybrid joined device are not evaluated during some system initiated authentication flows. Examples include device registration, Intune enrolment and specific Microsoft Graph operations.
Attackers can abuse these well known client identifiers combined with specific OAuth scopes to obtain access tokens from unmanaged devices.
Concrete examples and technical breakdowns:
- Abuse of Microsoft client IDs and OAuth scopes in Entra ID
https://dirkjanm.io/abusing-azure-ad-oauth/ - Real world investigations into Graph abuse during initial access
https://www.microsoft.com/security/blog/2023/07/06/how-microsoft-detects-and-responds-to-identity-attacks/
3. Resource Based Exclusions and Shared OAuth Scopes
Conditional Access is evaluated per resource, not per scope. When a resource is excluded from a policy, all OAuth scopes issued for that resource are implicitly excluded as well.
This can expose user profile and directory data through Microsoft Graph without satisfying Conditional Access controls.
Real world examples:
- Microsoft case study on over permissive Conditional Access exclusions
https://www.microsoft.com/security/blog/2022/10/12/conditional-access-best-practices/ - Customer reported incidents discussing resource exclusions
https://learn.microsoft.com/en-us/answers/questions/1189019/conditional-access-excluded-resources
4. Family of Client IDs and Token Reuse
Some Microsoft applications belong to a Family of Client IDs. Applications in the same family can reuse refresh tokens obtained by another family member.
This means that if one trusted application successfully authenticates, other applications in the same family may obtain access tokens without re evaluating Conditional Access expectations such as device compliance or authentication strength.
From a defensive perspective, FOCI increases blast radius. A compromise of one trusted client can implicitly trust others.
5. Authentication Method Bypasses and Token Replay
Multi factor authentication protects the sign in event, but access tokens remain valid for their lifetime. Attackers exploit this using phishing frameworks that intercept tokens after authentication.
Incident driven references:
- CISA advisory on token replay and session hijacking
https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-144a
6. Primary Refresh Token Abuse and Device Identity Forgery
Advanced attackers target the device trust model by forging device identities and Primary Refresh Tokens. This allows them to bypass controls that rely on device compliance or authentication strength.
Documented incidents and analysis:
- MITRE ATT&CK technique T1550.001
https://attack.mitre.org/techniques/T1550/001/
7. Interpreting Conditional Access Results in Sign In Logs
Sign in logs are one of the most valuable detection sources for Conditional Access bypasses.
A result of success does not automatically mean that Conditional Access was applied. Administrators must explicitly review the Conditional Access tab in sign in details. A status of notApplied indicates that no policy evaluation occurred.
Repeated successful sign ins with notApplied status, especially from unexpected client apps or locations, should be treated as high risk.
8. Resources Fully Excluded from Conditional Access
Some Entra ID resources never trigger Conditional Access evaluation. These sign ins appear as notApplied and can be abused for password testing and reconnaissance.
Defensive Strategies That Actually Work
Understanding Conditional Access bypasses is only useful if it leads to stronger, more realistic defensive choices. The common mistake is trying to close every gap with additional Conditional Access policies. In practice, this often increases complexity without materially reducing risk.
A more effective strategy starts with accepting that Conditional Access is a control layer, not a baseline. It assumes other foundations are already in place.
Start With a Solid Security Baseline
A strong defensive posture begins with a well defined and consistently applied security baseline. Baselines establish minimum acceptable configurations for identity, devices, applications and operating systems before Conditional Access is even considered.
Without this foundation, Conditional Access is forced to compensate for weaknesses it was never designed to address. This is where bypasses become impactful rather than theoretical.
Use Conditional Access as an Enforcement Layer, Not a Safety Net
Conditional Access should enforce decisions made elsewhere, such as device trust, authentication strength and application sensitivity. It should not be used to fix structural issues like overly permissive identities, unmanaged devices or excessive API permissions.
When Conditional Access is treated as a safety net, exclusions, exceptions and technical debt accumulate. Over time, this increases the attack surface instead of reducing it.
Focus on Session and Token Reality
The February 2026 change from Revoke MFA sessions to Revoke sessions reinforces an important lesson. Identity security does not stop at authentication. Tokens and sessions must be actively considered in both design and incident response processes.
Defensive strategies should include monitoring for unusual token usage, reviewing sign ins where Conditional Access was not applied, and validating device trust continuously rather than at sign in only.
Reduce Blast Radius by Design
Limit delegated and application permissions, review Family of Client IDs exposure, and avoid broad trust assumptions. Smaller blast radius means bypasses have less impact, even when they occur.
Conclusion
Conditional Access remains a powerful control in Microsoft Entra ID, but it is not a security baseline on its own. Bypasses exist because identity systems must balance security, usability and platform functionality.
Organisations that build on a strong baseline, apply Conditional Access deliberately, and understand where controls stop are better prepared for real world attacks and incident response scenarios.
In the next article, we will explore how security baselines fit into this picture and compare CIS benchmarks with Microsoft security baselines. Understanding the differences between these approaches is key to deciding where Conditional Access should enforce policy and where baseline configuration should do the heavy lifting.
Conditional Access remains a cornerstone of Entra ID security, but it is not infallible. Understanding where it does not apply is essential to building an effective zero trust architecture.
Update 01 February 2026
Since the publication of this article, Microsoft has announced an upcoming change to Conditional Access enforcement in Microsoft Entra ID.
The update improves enforcement for policies that target all resources, even when resource exclusions and limited OAuth scopes are involved.
This announcement reinforces the core observation of this article: Conditional Access bypass scenarios often emerge from architectural and configuration decisions rather than software vulnerabilities.
Microsoft’s official announcement can be found here: https://techcommunity.microsoft.com/blog/microsoft-entra-blog/upcoming-conditional-access-change-improved-enforcement-for-policies-with-resour/4488925