Conditional Access Policy, Very Esential but Not Bullet Proof

Conditional Access in a Zero Trust Reference Architecture

Zero Trust is not a product. It's a design philosophy that boils down to never trust, always verify. Every access request — whether it comes from inside or outside the corporate network — is treated as untrusted until it has been evaluated against a set of signals.

In any serious Zero Trust reference architecture (Microsoft's, NIST SP 800-207, CISA's Zero Trust Maturity Model), you'll see the same building blocks:

A Policy Decision Point (PDP) that evaluates each request.
A Policy Enforcement Point (PEP) that allows or blocks the request based on the decision.
Signals flowing in: who the user is, what device they're on, where they are, what they're trying to access, and how risky the session looks.
Controls flowing out: require MFA, require a compliant device, require a managed network, block, allow, force re-authentication, and so on.

In Microsoft's stack, Conditional Access is the PDP/PEP for identity. When a user authenticates to Entra ID, CA evaluates the signals and decides whether to grant the token, grant it with extra requirements, or block it outright. Without CA, you have authentication but you don't have contextual authentication — and contextual authentication is the whole point of Zero Trust.

A defensible CA baseline for an organisation at basic-to-moderate maturity usually looks like this:

MFA for all users, with phishing-resistant methods (passkeys, FIDO2, Windows Hello for Business) prioritised over SMS or voice.
Block legacy authentication outright. Legacy auth doesn't support MFA and remains one of the most-abused attack vectors against Microsoft 365.
Require a compliant or hybrid-joined device for sensitive applications, particularly admin-tier resources.
Sign-in and user risk policies that trigger step-up authentication or block when Entra ID Protection flags something suspicious.
Stricter policies for privileged roles, combined with Privileged Identity Management (PIM) so that admin rights are time-bound and approval-gated.
Application protection policies for mobile, so corporate data on personal devices stays contained.

Why It Matters — and Why It's Not Bulletproof

Why it matters

Done well, Conditional Access gives you something close to the Zero Trust ideal: every authentication is evaluated, every session is contextual, and the blast radius of a stolen credential drops dramatically. CA is what turns "the user has the right password" into "the user has the right password, on the right device, from the right network, at acceptable risk." That distinction is the difference between credential theft being catastrophic and credential theft being contained.

This is exactly why attackers target it. Bypassing CA is not a misconfiguration finding — it's a control failure. And there are now several documented ways to make that happen.

Why it's not bulletproof

Before I dive in further, I want stress the following: No control is bullet proof, if you are relying on a single layered control in your defences, it will fail, it is just a matter of time before it does.

In June 2025, two security researchers presented their joint research titled "Finding Entra ID CA Bypasses — the structured way", and a detailed companion write-up on his Cloudbrothers blog.

‍Their work is significant because it isn't about misconfiguration. The bypasses they document are built into the platform itself. As a CA admin, you have no toggle to turn them off. They exist in the code path that decides whether your policies apply at all.

I'll walk through each bypass using the same What / So What / Now What lens, in plain English for an audience that doesn't live and breathe OAuth scopes.

Bypass 1: Excluding one resource quietly weakens others

What: If you build an "all resources" CA policy and exclude even a single application, a fixed set of permissions on Microsoft Graph and the legacy Azure AD Graph automatically stop being protected by that policy — including scopes like User.Read, People.Read, email, profile, and openid.
So what: An attacker holding valid credentials can still query directory information about your users — phone numbers, manager relationships, group memberships — without being blocked, even when you thought "all resources" meant all resources.
Now what: Audit every CA policy that contains an exclusion. Assume those exclusions silently weaken your directory-read coverage. This is documented by Microsoft, but rarely understood by admins reading the policy editor.

Bypass 2: Device Registration ignores Trusted Location

What: If you've built a "block from untrusted networks" policy as defence in depth, the Device Registration Service is not protected by it. Only an MFA grant control can guard that resource. MSRC has confirmed this is by design.
So what: An attacker with valid credentials and a satisfied MFA prompt can still join a rogue device into your tenant from anywhere in the world, and from there potentially satisfy your "compliant device" requirement on subsequent sessions.
Now what: Always pair location controls with phishing-resistant MFA on registration flows, and detect first-time device registrations from unexpected geographies in your SIEM.

Bypass 3: The Microsoft Authenticator scope bypass (VULN-14615)

What: Bader discovered that when the Microsoft Authenticator mobile app requested a very specific combination of permissions, the "require compliant device" control was silently skipped. The granted access included the ability to read a user's registered authentication methods, including phone numbers used for MFA. He reported it in January 2025; Microsoft fixed it in April and the researchers disclosed publicly at TROOPERS in June.
So what: The fix is itself instructive — Microsoft did not actually close the CA bypass. They restricted what the resulting token could do. The token is still issued, just with less power. The gap in CA enforcement is still there; Microsoft just narrowed what flows through it.
Now what: Treat scope-based corner cases as a class of risk that may exist with other apps you haven't tested. Watch sign-in logs for unusual scope combinations on first-party Microsoft applications.

Bypass 4: Device Management Service via the Teams app ID

What: The Device Management Service resource is not protected by the "compliant device" control when a token is requested using the Microsoft Teams application ID. MSRC closed this case as "by design," and as of late 2025 the bypass remains in place.
So what: No public exploit chain has been published, but the gap exists, and Microsoft has chosen to leave it. That's exactly the kind of detail that belongs in a CISO's risk register, not buried in someone's research slides.
Now what: Document this in your tenant risk register. Re-validate annually whether Microsoft's position has changed.

Bypass 5: Resources permanently excluded from CA enforcement

What: Several Microsoft-internal resources are never evaluated by Conditional Access. The sign-in logs report ConditionalAccessStatus: notApplied regardless of how your policies are configured. These include Microsoft Intune Checking, Windows Notification Service, Microsoft Mobile Application Management, the Azure MFA Connector, OCaaS Client Interaction Service, and the Authenticator App resource.
So what: Microsoft argues these endpoints only return non-sensitive metadata. Bader's practical concern is sharper: because these endpoints don't enforce MFA, an attacker holding stolen credentials can use them to validate username/password pairs without triggering the failed-MFA error code in your sign-in logs. That makes them a quiet password-spraying oracle baked into the platform.
Now what: Build SIEM detections for high-volume authentication to these specific resource IDs from the same source. Pair Conditional Access with per-user MFA on highly privileged accounts, since per-user MFA does still protect these resources (a quirk in Microsoft's own implementation).

The takeaway from all five bypasses is the same: Conditional Access is necessary but it is not sufficient. Treating it as a single watertight perimeter is a strategic error.

Now What: Six High-Level Recommendations

The point of this article is not to undermine CA. It's to design around its limits. Here are six recommendations that translate the research into action. They are deliberately framed at a level a CISO or technical lead can sponsor, with enough specificity that an Entra ID admin can pick up and implement.

1. Build additive policies (AND, not OR) and think in cheese-layers

What: Construct CA so that sensitive access requires multiple independent controls — MFA AND compliant device AND trusted network — rather than any one of them.
So what: Every bypass discussed above defeats one control at a time. If your policy is structured as "MFA or compliant device," a single bypass may be enough to grant access. If it's structured as "MFA and compliant device" across two separate policies, the attacker has to defeat both. This is the Swiss cheese model applied to identity: stack enough independent slices and the holes are unlikely to line up.
Now what: Refactor any policies that combine controls with OR logic into separate, additive policies. As a baseline, require phishing-resistant MFA for all users, then layer compliant device, network controls, and risk-based controls as separate policies on top.

2. Turn on Continuous Access Evaluation, and use Strict Location Enforcement where the risk justifies it

What: Continuous Access Evaluation (CAE) tells resource providers in near-real time when something has changed — a user is disabled, a password is reset, risk is elevated, or the session is moving outside a permitted location. Without CAE, an issued access token remains valid until it expires (typically up to an hour), regardless of what has happened in between. With CAE, that revocation window collapses to minutes. Universal CAE extends this to anything accessed via Global Secure Access, and Strict Location Enforcement re-evaluates the token's source IP on every request.
So what: Several of the bypass paths above end with the attacker holding a valid token. The longer that token is usable, the more damage they can do. CAE narrows the post-bypass window; Strict Enforcement closes off token replay from a different IP entirely.
Now what: Verify CAE is enabled and not being overridden in your tenant. For high-sensitivity user populations and for Global Secure Access workloads, evaluate Strict Enforcement mode — knowing it will increase re-authentication frequency for mobile users. Make this a deliberate trade-off, not an accident.

3. Add Token Protection and shorten session lifetimes for sensitive workloads

What: Token theft (via infostealers, malicious browser extensions, or AiTM phishing kits) is now a parallel attack path that doesn't require defeating CA at all — it just steals the token after CA fired correctly. Microsoft's Token Protection feature binds a sign-in session to a specific device, making stolen tokens unusable elsewhere. Session lifetime controls force re-authentication at intervals you choose.
So what: Even if CA works exactly as intended, a stolen token from a compromised endpoint sidesteps the entire policy engine. Token protection ensures that a token harvested from an attacker's machine simply doesn't work.
Now what: Enable Token Protection (currently in preview/general availability for specific workloads — check what applies to your tenant) for high-risk applications and admin sessions. Shorten sign-in frequency for privileged roles. Pair this with endpoint detection that hunts for known token-stealing tooling.

4. Engineer break-glass and contingency access properly

What: Tightening Conditional Access without rock-solid emergency access is how organisations lock themselves out of their own tenant. Microsoft's guidance is to maintain at least two cloud-only emergency access ("break-glass") accounts, named to avoid being identified in password-spray attacks, secured with FIDO2 hardware keys, and excluded from policies in a way that lets them sign in even if your CA configuration is broken. In addition, Microsoft recommends maintaining a set of disabled contingency CA policies (named with an EM01 - ENABLE IN EMERGENCY prefix) that can be turned on if your primary MFA provider fails or another disruption occurs.
So what: Without this, a board-level conversation about hardening CA always runs into the same objection: "we can't tighten it, we'll lock ourselves out." With it, you can implement aggressive controls confidently because you know there's a tested recovery path.
Now what: Stand up two cloud-only break-glass accounts on the *.onmicrosoft.com domain, secured with FIDO2, named obscurely (not breakglass@…), and with monitored sign-in alerting. Build a Restricted Management Administrative Unit around them. Author your ENABLE IN EMERGENCY contingency policies. Test the break-glass process at least twice a year — if you have not tested it under failure conditions, you do not have emergency access, you have an assumption.

5. Bring workload identities into Conditional Access — they are the forgotten attack surface

What: Service principals, app registrations, and managed identities are users too, in the sense that they hold tokens and access resources. By default, CA policies scoped to users do not apply to service principals at all. Microsoft offers Conditional Access for workload identities (Workload Identities Premium licence) and Continuous Access Evaluation for workload identities, but both have to be turned on deliberately and scoped directly to the service principal — not via group membership.
So what: Many of the worst Microsoft 365 breaches in recent years have hinged on compromised app registrations or over-permissioned service principals operating outside any meaningful CA control. The bypass research in this article is largely about user-context tokens, but workload identities operate in an even less controlled environment by default.
Now what: Inventory your service principals (start with Get-MgServicePrincipal or use a tool like Maester / EntraScopes). Apply location-based and risk-based CA policies to high-privilege service principals. Prefer managed identities over app registrations with secrets where the workload supports it. Enable CAE for workload identities and enforce risk-based blocks for any flagged as risky in ID Protection.

6. Continuously test policies and detect bypass indicators in your sign-in logs

What: A static review of policy JSON in the portal does not tell you how policies behave at runtime. Two open-source tools change that: Maester is a security test automation framework that validates whether your CA configuration actually achieves what you think it does, and EntraScopes (released alongside the TROOPERS25 talk) lets you query first-party applications, the resources they access, and the scopes pre-consented to them.
So what: Several of the bypass behaviours above leave fingerprints in SigninLogs — ConditionalAccessStatus: notApplied on resources you'd expect to be covered, or individual policies showing failure while the overall sign-in is success. If you don't ingest these logs and detect on those patterns, the bypass happens silently.
Now what: Run Maester against your tenant on a regular cadence (monthly is reasonable; weekly for high-criticality environments) and triage every failure. Build SIEM detections for sign-ins to the always-bypassed resources listed above, mismatched policy/sign-in outcomes, and first-time access from unfamiliar app IDs to sensitive resources. Make these part of your standard threat-hunt rotation, not one-time checks.

Bottom line for the Board and Senior Management

If a board member asks you whether Conditional Access protects the organisation, the honest answer is: yes, but it isn't a single switch and it isn't watertight. CA is the policy engine of identity-centric Zero Trust, and any organisation without it is not doing Zero Trust in any meaningful sense. At the same time, recent public research has shown with vendor confirmation that there are corner cases where CA is silently bypassed, some by misconfiguration, some by design, and some by undocumented platform behaviour.

The implication isn't to lose faith in the control. It's to stop treating it as the only control. Build additive policies. Shorten the post-bypass token window with CAE and token protection. Engineer your emergency access so you can tighten the rest with confidence. Bring workload identities into the perimeter. Test continuously, and detect on the indicators that bypasses leave behind.

That's what Zero Trust actually means in practice.

If you'd like a review of your Conditional Access posture against this research and the broader Zero Trust reference architecture, get in touch with the Spartans Security team.