Why Conditional Access Is Not Zero Trust: A Deep Dive Into Architecture, Not Configuration

“If your Zero Trust strategy is a checklist of Conditional Access policies, you don’t have Zero Trust. You have a rules engine mistaking gatekeeping for architecture.”

This article dissects the most costly misconception in enterprise security: treating Conditional Access as a Zero Trust implementation rather than as one component of a larger decision and enforcement framework. We will walk through real-world attacks that succeeded despite MFA, Conditional Access, and apparent “compliance” — and why those attacks worked against architectures that looked complete on paper.

Section 1: The Architecture Mistake That Bleeds Everywhere

Why This Matters (The Real Cost)

I've investigated three major incidents where organizations believed they had implemented Zero Trust because they had:

• ✅ Enabled MFA on all users
• ✅ Created Conditional Access policies blocking legacy authentication
• ✅ Required device compliance for access to sensitive apps
• ✅ Implemented risk-based policies flagging impossible travel

Yet, in all cases, attackers achieved lateral movement, persistence, and data exfiltration.

The reason: Architecture was missing. Policies existed. Enforcement didn’t.

What Frameworks Say (And What They Actually Mean)

NIST SP 800–207 (the Zero Trust standard) defines three core components. Here is where the translation to Microsoft Entra usually fails:

The critical misconception: Organizations assume Conditional Access is doing the enforcement. It is not. Conditional Access makes the decision. The application and the token lifetime enforce it.

The CISA Zero Trust Maturity Model goes further. It explicitly states that organizations at “Initial” maturity have:

• ✅ Policies configured
• ❌ Automation and orchestration missing

Organizations at “Advanced” maturity have:

• ✅ Policies
• ✅ Cross-system orchestration where signals from one pillar (e.g., device failure) automatically influence another pillar (e.g., application access)
• ✅ Continuous evaluation, not periodic review

So what are most organizations actually running? Initial-level implementations calling themselves “Zero Trust.”

Section 2: Why “MFA + Conditional Access” Fails Against Real Attackers

The Attack That Beat Your Setup: Adversary-in-the-Middle (AiTM)

Case Study: Singapore IT Services Firm | October 2025 | Real Incident Analysis

The Setup (Appeared Secure):

• MFA enabled on all users ✅
• Conditional Access policies requiring MFA for all cloud apps ✅
• Session controls limiting concurrent sign-ins ✅
• Risk-based CA policies blocking impossible travel ✅

The Attack Flow (AiTM Phishing):

1. Spoofed login page → User unknowingly enters credentials into attacker-controlled proxy (e.g., Evilginx2).
2. Real-time relay → Attacker forwards credentials to legitimate Microsoft 365 login.
3. MFA bypass via session theft → User completes MFA challenge, but attacker intercepts the authentication cookie.

The Resulting Compromise: The attacker now possesses:

• Valid session token (fresh from MFA)
• Authentication cookie (extracted before relay to user)
• User’s password (captured during relay)

The Execution: Attacker authenticates from a US IP address using a programmatic client (Axios/Python script). All Conditional Access policies report SUCCESS.

Why Conditional Access didn’t stop this:

• CA evaluated risk: Low (user’s own password, valid MFA)
• CA evaluated device: User’s own device
• CA evaluated location: User’s home IP (or attacker proxied through US VPN to a compliant location)
• CA decision: GRANT ACCESS ← Policy worked correctly

The Gap: The failure occurred between CA’s decision (grant) and enforcement (token validation). By the time the token reached the application, it belonged to an attacker, but the token itself was valid. Conditional Access never sees the moment of token theft because it happens after the policy decision.

Another Angle: Persistence After MFA

Case Study: Storm-0501 | August 2025 | Enterprise Ransomware

The Breach Sequence:

1. Valid credentials obtained via password spray (T1110.003) ✅ Blocked by CA initially.
2. Attacker notices: Target user has no MFA registered ⚠️.
3. Password reset forced → User locked out (CA now permits access via email token).
4. MFA registration: Attacker registers a new MFA method (Microsoft Authenticator app → attacker-controlled device).
5. Result: CA policies are now satisfied by attacker-controlled MFA until the next password reset.

Why this succeeded:

• Conditional Access policy: “Require MFA for all access” ✅ Policy correct.
• Conditional Access enforcement: User has MFA → Access granted ✅ Enforcement correct.
• Architecture Gap: No policy validated who registered the MFA. No signal flowed from the MFA registration system to Conditional Access saying “high-risk MFA enrollment detected.”

This is an orchestration failure, not a policy failure. A mature Zero Trust system would have:

1. Signal: “MFA enrolled from new device, never-before-seen location” (from Entra ID Protection).
2. Decision: “Block further access until admin confirms” (Conditional Access).
3. Enforcement: “Revoke existing tokens immediately” (Continuous Access Evaluation).

Instead, each tool worked independently.

Section 3: What Conditional Access Actually Is (And What It Isn’t)

The Real Role: Policy Engine, Not Firewall

Conditional Access is a policy decision engine, exactly as NIST 800–207 defines the PE component. Its job is to:

1. Evaluate a sign-in against predefined conditions (user, device, location, risk, time, etc.).
2. Make a binary decision (grant, deny, require MFA).
3. Output a token if the decision is grant.

That’s it. It does NOT:

• Validate tokens at the application layer.
• Monitor token usage after issuance.
• Enforce session revocation in real-time without CAE integration.
• Evaluate post-authentication behavior.
• Know if the token was stolen after issuance.

Why Organizations Conflate MFA with Zero Trust

Traditional Model (ADFS / On-Premises Era):

User → Login → MFA Challenge → Token Issued (8-24h lifetime) → Implicit Trust for Duration → Application Grants Access

This model worked when users were on corporate networks and token theft meant on-premises physical access was required.

Zero Trust Model (NIST 800–207): Every Request (or session change) → [Policy Engine] Evaluate Identity + Risk + Context → [Decision] Grant/Deny → [PEP - Application] Enforce + Monitor continuously → [Signal] Detect changes → [Re-evaluation] Immediate policy re-assessment

The difference: One trusts the token. One trusts the context at the moment of use.

The Signals You’re Missing (And Attacks Exploit)

Here is what an advanced Zero Trust system monitors that Conditional Access policies typically don’t coordinate with:

Example: Device Compliance Failure

• 9:00 AM: User passes CA policy (device compliant) → Token issued (28h lifetime with CAE).
• 2:00 PM: Device detected with malware → Marked non-compliant.
• 3:00 PM: User still accessing sensitive data with 9:00 AM token.
• Without CAE: Access continues until token expires (or user logs out).
• With CAE + ZT architecture: Access revoked by application in <15 minutes.

Section 4: The Root Cause — Gateway Thinking vs. Control Plane Thinking

Architectural Anti-Pattern: The Overstuffed Policy

We see this constantly in field engagements:

Policy Name: "All Users - Risk Based Access"

• Assignments: All users EXCEPT Cloud admins, Executives, Service accounts, Developers, Partners.
• Conditions: High User Risk AND Medium Sign-in Risk AND Outside allowed countries AND Non-compliant Device.
• Controls: Require MFA OR Password change OR Device compliance.
• Session: Limited to web browser, no device access, IP limited.
• Exclusions: “But exclude this user (VP exception)”, “And this user (contractor)…”

Problem: This policy is impossible to audit, maintain, or enforce consistently.

More importantly: It assumes a gateway mentality. It tries to make one decision at one point in time and assumes that decision remains valid for hours.

The Zero Trust Alternative: One Policy = One Decision

Instead of one mega-policy handling everything, build separate decision points:

Policy: “Block High-Risk Credentials”

• Condition: User risk = High (Identity Protection ML).
• Control: Block access + notify security team.
• Cadence: Continuous (re-evaluated by CAE).

Policy: “Require MFA for Sensitive Apps”

• Condition: Application = (Exchange, SharePoint, Teams).
• Control: Require MFA.
• Cadence: Per sign-in.

Policy: “Require Device Compliance for Remote Access”

• Condition: Network location = Non-corporate.
• Control: Require device marked compliant.
• Cadence: Per sign-in (CAE monitors device state).

Policy: “Revoke Access if Device Becomes Non-Compliant”

• Condition: Device fails health check post-authentication.
• Control: Revoke token via CAE.
• Cadence: Continuous.

Each policy has one clear purpose, is auditable, and feeds signals to other systems.

Section 5: Why Frameworks Are Screaming for Orchestration

What NIST, CISA, and CIS Actually Require (Not Just Recommend)

NIST SP 800–53 Rev. 5 | IA-2 & AC-3 The control language is specific:

• IA-2: “Authenticate users based on strength of authentication proportionate to risk.”
• AC-3: “Enforce access control decisions based on context (not just identity).”

Translation: Generic MFA doesn’t satisfy this. MFA that varies by risk level does.

• IA-11 explicitly requires: Re-authentication “if device state changes” and at “periodic intervals.”

CISA Zero Trust Maturity Model | Orchestration CISA explicitly separates maturity levels based on orchestration.

“Orchestration ensures that signals from one pillar meaningfully influence enforcement across other pillars. Without orchestration, policies remain disconnected rules.”

CIS Controls v8.1 | Control 6 CIS doesn’t just say “manage access.” It says:

• Manage access continuously.
• Perform automated revocation upon role change.
• The key word: Continuous. That’s not a one-time policy. That’s orchestration.

Section 6: Building the Right Architecture (Before Building Policies)

The Four Architectural Questions (Answer These First)

Before creating a single Conditional Access policy, a Zero Trust architect must answer:

1. Who Makes the Access Decision?

• Answer: Entra ID as the Policy Engine.
• What this means: All access decisions flow through a centralized identity platform. No app has unilateral authority to grant access.
• What it doesn’t mean: “We enabled CA policies” (that’s an implementation detail).

2. Based On Which Signals?

• Answer: Identity, Device State, Behavior/Risk, Privilege Level, AND Environmental Context.
• Common failure: Only using Identity + Device. Attackers with valid credentials pass all those checks. You need behavioral signals (anomalous login, impossible travel, new location).

3. Who Enforces the Decision?

• Answer: The Application (PEP) and the Token System. Not just Conditional Access.
• What this means: CA makes a decision and issues a token. The application validates the token and decides whether to honor it based on token binding and post-authentication signals.
• Real-world example: Microsoft’s own implementation requires apps to validate tokens against Entra ID’s token introspection endpoint. This is CAE.

4. When Is the Decision Re-evaluated?

• Answer: Continuously, not once at login.
• Current state: Conditional Access re-evaluates at next sign-in.
• Mature state: Every request triggers a lightweight re-evaluation. Risk signals (User Risk, Device Malware, Privilege Change) flow continuously.

Section 7: Real Architectural Failures (And How To Spot Yours)

Anti-Pattern #1: Policy Sprawl Without Orchestration

• What you see: 25+ policies with generic names (“MFA Policy”, “Legacy Block”), each with 15 exclusions.
• What’s happening: No central logic. Policies contradict each other. Admins add exclusions instead of fixing user flows.
• Why attacks succeed: Attacker finds the exclusion (“Contractors excluded from MFA”) or the gap (“Legacy app X has no policy”).

Anti-Pattern #2: Evaluating Risk Statically, Not Continuously

• What you see: Risk evaluation happens at sign-in time only.
• What’s happening: Token theft or device compromise occurring post-authentication goes undetected.
• Real example: User signs in at 9:00 AM (Low Risk). Device infected at 11:00 AM. Token valid until 5:00 PM. Result: Five hours of exposed access.

Anti-Pattern #3: MFA Without Token Protection

• What you see: MFA enabled, but token lifetime is standard (28h) and no token binding policies.
• What’s happening: MFA proves the user was there at sign-in time. It does not prove the user is there when the token is used.
• Why attacks succeed: AiTM attacks exploit this gap. The Singapore case had MFA enabled. It didn’t help.

Section 8: The Call to Action — Audit Your Architecture

Honest Self-Assessment: Where Do You Stand?

Answer these four questions about your Conditional Access deployment:

1. Decision Making: “If I asked my security team, ‘Who decides whether User A can access Resource B?’, would they all give the same answer? Or would some say ‘CA policies,’ others say ‘the app,’ others say ‘device management’?”
2. Signals: “We monitor 5+ signal types (identity risk, device risk, location, behavior, privilege). True or false?”
3. Enforcement: “Aside from CA policies, do your applications validate tokens against Entra ID’s token introspection endpoint (CAE)? Are your teams trained to do this?”
4. Re-evaluation: “If a device becomes non-compliant 2 hours after a user gets a token, how long before that user loses access? Seconds? Minutes? Or when the token expires?”

Scoring:

• All four: You’re at Advanced maturity.
• Two or fewer: You have policies. You don’t have Zero Trust architecture. This is where attacks succeed.

Your Next Steps (Concrete Actions)

• Week 1–2: Visibility. Audit current CA policies. Identify “mega-policies” and split them. Review sign-in logs for MFA coverage vs. exclusions.
• Week 3–4: Architecture Decisions. Answer the four architectural questions. Document the gaps.
• Month 2: Pilot Orchestration. Enable CAE for sensitive apps. Enable Entra ID Protection. Create one atomic policy (e.g., “Block high-risk sign-ins”).
• Month 3: Hardening. Integrate CA with Intune health signals. Implement token binding. Train app teams on CAE integration.

Conclusion: Architecture Before Configuration

Zero Trust is not a button you press, a baseline configuration, or a set of policies you enable and forget.

Zero Trust is:

• Continuous evaluation architecture.
• Identity as the control plane (not the firewall).
• Orchestration between identity, device, network, app, and data security.
• Observable, measurable, auditable.

Conditional Access is powerful. But it is one component of the Policy Engine (NIST PE). Without the other components — real-time signal orchestration, application-level enforcement, continuous re-evaluation, and behavioral monitoring — you have a rules engine, not a Zero Trust architecture.

The attacks that succeeded in Singapore, against Storm-0501’s targets, and in countless other 2024–2025 incidents didn’t fail because Conditional Access didn’t work. They succeeded because Conditional Access was the only decision point. Once the token was issued, the game was over.

Your next action: Answer the four architectural questions. If you can’t answer them with certainty, you don’t have an architecture. You have policies. And policies alone don’t win against sophisticated attackers.