Zero Trust Azure: Conditional Access Policy Design

Zero Trust is not a product you buy. It is a design principle that starts with one assumption: every request is potentially hostile, regardless of where it originates. The network perimeter is gone -- or more accurately, the perimeter is now every single authentication event. In Azure, the enforcement engine for this principle is Entra ID Conditional Access, and getting the policy framework right is the difference between "we do MFA" and "we have a coherent identity security posture."

The recent wave of high-profile breaches -- Midnight Blizzard targeting Microsoft's own corporate email through OAuth app consent, Scattered Spider social-engineering help desks to bypass MFA -- all share a common thread: identity was the attack vector, and the organizations lacked granular policy controls at the authentication layer. Conditional Access is where those controls live.

Effort: 2-4 days for CA policy framework, 1 day for testing and user communication Cost: Entra ID P1: ~$6/user/month (included in M365 E3), P2: ~$9/user/month for risk-based CA Prerequisites: Entra ID tenant with P1+ license, Global Administrator or Conditional Access Administrator, emergency access account configured

What Changed in 2025

Conditional Access has matured significantly:

• Continuous Access Evaluation (CAE) is now GA and enabled by default. When a user's session is revoked or their risk level changes, the resource provider (Exchange, SharePoint, Graph) enforces the change within minutes, not hours. Token lifetimes effectively become near real-time.
• Token Protection (preview) binds tokens to the device they were issued on. Stolen session cookies from browser exports or adversary-in-the-middle attacks become unusable on a different machine.
• Authentication Strength replaces the legacy per-user MFA settings. You can now require phishing-resistant methods (FIDO2, Windows Hello for Business, certificate-based auth) in a CA policy without relying on the old MFA portal.
• Entra ID Governance integration with Conditional Access means you can combine access reviews, entitlement management, and CA policies into a single lifecycle workflow.

Why This Matters

MFA alone is not enough. Attackers have moved beyond credential stuffing to token theft, MFA fatigue attacks (repeated push notifications until the user accepts), and adversary-in-the-middle phishing that captures both the password and the MFA response in real time.

Conditional Access is the policy engine that evaluates every sign-in against a set of conditions -- user identity, device state, location, application, risk level -- and decides whether to allow, block, or require additional verification. Without it, MFA is a binary gate. With it, you have context-aware, continuous security decisions.

A real scenario from a client engagement: an attacker obtained valid credentials for a global admin account (credential phishing targeting personal email, password reuse). They attempted to sign in from a residential IP in a country where the organization has no operations. The CA device compliance policy blocked the sign-in because the device was not Intune-enrolled, and the named location policy flagged the IP as outside trusted ranges. The sign-in log showed:

{
  "userPrincipalName": "admin@contoso.onmicrosoft.com",
  "appDisplayName": "Azure Portal",
  "ipAddress": "185.220.xxx.xxx",
  "location": {
    "city": "Bucharest",
    "state": "Bucuresti",
    "countryOrRegion": "RO"
  },
  "status": {
    "errorCode": 53003,
    "failureReason": "Access has been blocked by Conditional Access policies."
  },
  "conditionalAccessPolicies": [
    {
      "displayName": "CA003-Block-HighRisk-Countries",
      "result": "failure",
      "enforcedGrantControls": ["Block"]
    },
    {
      "displayName": "CA002-Require-CompliantDevice-Admins",
      "result": "failure",
      "enforcedGrantControls": ["CompliantDevice"]
    }
  ],
  "riskDetail": "aiConfirmedSigninSafe",
  "riskLevelDuringSignIn": "high"
}

Without these CA policies, the attacker would have been prompted for MFA -- and MFA fatigue or a real-time phishing proxy could have completed the chain.

Implementation: CA Policy Framework

The most common mistake I see is creating CA policies without testing in report-only mode first. Every policy below should run in report-only for at least one week before enforcement. Audit the sign-in logs, identify edge cases, communicate to users, then flip to on.

CA001: Baseline MFA for All Users

Every user, every app, every time. The emergency access (break-glass) account is the only exclusion.

{
  "displayName": "CA001-Baseline-RequireMFA-AllUsers",
  "state": "enabledForReportingButNotEnforced",
  "conditions": {
    "users": {
      "includeUsers": ["All"],
      "excludeGroups": ["grp-BreakGlass-Accounts", "grp-DirSync-Accounts"]
    },
    "applications": {
      "includeApplications": ["All"]
    }
  },
  "grantControls": {
    "operator": "OR",
    "builtInControls": [],
    "authenticationStrength": {
      "id": "00000000-0000-0000-0000-000000000002"
    }
  }
}

CA002: Device Compliance for Admin Roles

Privileged accounts must sign in from Intune-managed, compliant devices. No exceptions beyond break-glass.

CA003: Block High-Risk Countries

Named locations define trusted office networks and blocked geographies. I maintain two named location sets: trusted corporate IPs and a blocklist of countries where the organization has no business operations.

{
  "displayName": "CA003-Block-HighRisk-Countries",
  "state": "enabledForReportingButNotEnforced",
  "conditions": {
    "users": {
      "includeUsers": ["All"]
    },
    "applications": {
      "includeApplications": ["All"]
    },
    "locations": {
      "includeLocations": ["named-location-id-high-risk-countries"],
      "excludeLocations": ["AllTrusted"]
    }
  },
  "grantControls": {
    "operator": "OR",
    "builtInControls": ["block"]
  }
}

CA004: Session Controls for Browser Access

Limit persistent browser sessions and enforce sign-in frequency for sensitive apps.

CA005: Risk-Based Block for Impossible Travel

Entra ID P2 provides real-time risk detection. Block sign-ins flagged as high risk (impossible travel, anonymous IP, malware-linked IP).

Real-World Results

After deploying this five-policy framework in a 200-user organization, here is what the first 30 days looked like in the Entra ID sign-in logs:

Total sign-in events:           47,832
Successful (policy satisfied):  46,591  (97.4%)
Blocked by CA policy:              847  (1.8%)
  - CA003 (country block):         612
  - CA005 (high risk):             134
  - CA002 (non-compliant device):  101
MFA challenged (CA001):         12,440  (26.0%)
Report-only failures:             394  (0.8%)

The 612 country-block events were almost entirely automated reconnaissance -- bots cycling through known credentials against the tenant. Before CA003, these showed up as "failed MFA" events, which is a different problem (it trains analysts to ignore MFA failures as background noise). Blocking at the CA layer before the MFA prompt keeps the signal-to-noise ratio clean.

The 101 non-compliant device blocks caught two legitimate cases: an IT admin signing in from a personal laptop during an incident, and a new hire whose device had not completed Intune enrollment. Both were resolved within hours. The remaining 99 were unauthorized sign-in attempts from unmanaged devices.

Key Takeaways

• Report-only mode first, always. Run every CA policy in report-only for at least a week. Audit the logs. Communicate to users. Then enforce.
• Emergency access accounts are non-negotiable. If you lock yourself out of your own tenant because every CA policy blocks your break-glass account, you will have a very bad day. Exclude them from all policies and monitor their usage with alerts.
• Authentication Strength over legacy MFA. Stop using the per-user MFA portal. CA policies with Authentication Strength give you granular control over which MFA methods are acceptable per scenario.
• Named locations are your first filter. Blocking sign-ins from countries where you have no operations eliminates a massive volume of automated attacks before they ever reach the MFA prompt.
• Device compliance closes the token theft gap. A stolen session cookie is useless if the CA policy requires a compliant device that the attacker does not have.

Zero Trust identity is a foundational requirement for NIS2 compliance -- the directive explicitly mandates access control and identity verification. Pair this with a strong CSPM posture through Defender for Cloud to cover both the identity and infrastructure layers. For help designing your Zero Trust architecture, see our cloud consulting services.