Board Risk: Why Conditional Access Alone Does Not Deliver Zero Trust

The Misconception That Keeps Getting Funded

Every quarter, security architecture reviews reveal organisations that proudly declare themselves "Zero Trust." In roughly 80% of cases, what these organisations actually mean is: "We turned on Conditional Access and require MFA." That is not Zero Trust. It is one signal evaluation point in what NIST 800-207 defines as a comprehensive architecture spanning identity, device, network, application, and data planes.

To be blunt: if your entire Zero Trust strategy lives inside Entra ID Conditional Access, you have a single-plane authentication gate, not an architecture. You are still implicitly trusting everything behind that gate.

What NIST 800-207 Actually Requires

The NIST Zero Trust Architecture publication defines three core tenets that every access decision must satisfy:

1. Continuous verification - Every access request is evaluated dynamically, not just at authentication time. Session tokens must be re-evaluated as risk signals change.
2. Least-privilege access - Users and workloads receive the minimum permissions necessary, scoped to the specific resource, for the minimum time required.
3. Assume breach - The architecture must function on the assumption that adversaries are already present inside the network perimeter.

Conditional Access addresses a fraction of tenet one. It evaluates signals at token issuance time - user risk, sign-in risk, device compliance, location, and client application. But once the token is issued, Conditional Access has no further involvement in that session unless you have explicitly configured Continuous Access Evaluation (CAE), and even CAE only covers a narrow set of critical events (user revocation, IP change, policy change).

The Five Missing Pillars

1. Device Trust Beyond Compliance

Conditional Access can require "device compliance" via Intune, but compliance policies only evaluate a checklist - is encryption on, is the OS patched, is Defender running. They do not evaluate:

• Whether the device has been rooted or jailbroken using methods that bypass SafetyNet/Play Integrity attestation
• Whether the user is operating from a virtual machine cloning a compliant device's TPM state
• Whether endpoint detection has identified active adversary tooling (Cobalt Strike, Brute Ratel) that has not yet triggered a compliance state change

True device trust requires Microsoft Defender for Endpoint risk signals feeding directly into Conditional Access via the deviceThreatLevel grant control, combined with Windows Attestation validating hardware-rooted boot integrity. Configure this in the Intune portal under Endpoint Security > Microsoft Defender for Endpoint > Connect Windows devices and set compliance policy rules requiring "Require the device to be at or under the machine risk score: Low."

2. Data Classification and Protection

Zero Trust demands that data itself carries classification metadata that governs access decisions. Without Microsoft Purview Sensitivity Labels applied consistently across SharePoint, Exchange, and Teams, your data plane is ungoverned. A user who passes Conditional Access can access every unclassified document in every site they have permissions to and in most tenants, that means nearly everything.

Deploy default sensitivity labels at the tenant level:

Set-LabelPolicy -Identity "Global Policy" -AdvancedSettings @{
    AttachContentMarkingHeaderEnabled = "True"
    DefaultLabelId = "your-internal-label-guid"
}

Mandate that labels cannot be downgraded without justification. This is configured in the Microsoft Purview compliance portal under Information Protection > Label Policies > Require justification to remove or downgrade a label.

3. Micro-Segmentation

Traditional network architectures grant broad lateral movement once a user is "inside." Zero Trust eliminates this by enforcing micro-segmentation. In Azure, this means:

• Azure Private Endpoints for all PaaS services, removing public internet exposure entirely
• Network Security Groups (NSGs) with deny-all default rules and explicit allow rules per service
• Azure Firewall Premium with IDPS (Intrusion Detection and Prevention System) inspecting east-west traffic
• Microsoft Entra Private Access replacing legacy VPN with per-application tunnels that never expose the broader network

For M365 workloads, isolation translates to strict access controls via Conditional Access Authentication Contexts restricting session-level actions, alongside Purview Information Barriers for regulatory separation.

4. Continuous Access Evaluation (CAE)

CAE is the mechanism that makes token-based access dynamic rather than static. Without CAE, a stolen access token remains valid for its full lifetime (typically 60-90 minutes). With CAE, critical events trigger near-instant token revocation:

• User account disabled or deleted
• Password changed or reset
• MFA requirement imposed after token issuance
• Administrator explicitly revokes sessions
• Network location changes from trusted to untrusted

Enable CAE enforcement in Conditional Access by creating a policy with Session > Customize continuous access evaluation > Strictly enforce location policies. Note that not all applications support CAE - verify coverage for your critical workloads in the Entra ID sign-in logs by filtering for caEnforcedPolicy entries.

5. Workload Identity Governance

Human identities get all the attention, but service principals and managed identities in Entra ID often hold far more powerful permissions - Directory.ReadWrite.All, Mail.ReadWrite, Sites.FullControl.All. These workload identities bypass MFA entirely and rarely appear in Conditional Access policies.

True Zero Trust requires:

• Conditional Access for Workload Identities (requires Entra Workload ID Premium) restricting service principals to known IP ranges
• Managed Identity preference over client secret authentication, eliminating credential rotation risk
• App consent policies preventing users from granting OAuth permissions to unverified publishers
• Regular access reviews of application permissions via the Entra ID Enterprise Applications > Permissions blade

Building Real Zero Trust: A Sequenced Approach

Here is a proven deployment sequence for regulated environments:

Phase 1 (Weeks 1-4): Deploy phishing-resistant MFA (FIDO2/WHfB) and Conditional Access baseline policies. Enable CAE strict enforcement. Configure Defender for Endpoint integration with Intune compliance.

Phase 2 (Weeks 5-8): Deploy default sensitivity labels across all M365 workloads. Configure auto-labelling policies for financial and PII data. Implement DLP policies aligned to label taxonomy.

Phase 3 (Weeks 9-12): Implement PIM for all Entra ID and Azure RBAC roles. Deploy workload identity Conditional Access. Configure Information Barriers where required.

Phase 4 (Weeks 13-16): Deploy Azure Private Endpoints for all PaaS services. Implement Entra Private Access for legacy application access. Configure Defender for Cloud Apps session controls.

Phase 5 (Ongoing): Continuous monitoring via Sentinel. Quarterly access reviews. Monthly Conditional Access policy drift analysis. Annual architecture re-assessment against evolving NIST guidance.

The Bottom Line

Conditional Access is the front door lock. Zero Trust is the entire security architecture of the building - locks on every internal door, cameras in every corridor, motion sensors on every floor, and a guard who continuously verifies that every person in the building still has a valid reason to be there. Stop confusing one control with an architecture.