CA Policy Advisor — eusebio@it-sec

Conditional Access — Enterprise Knowledge Base

Fundamentals

How Conditional Access Works — The If-Then Engine

Conditional Access is not a firewall and it is not a VPN. It is a policy engine that sits between a user completing their first-factor sign-in and actually reaching the resource they requested. Every sign-in is evaluated against all applicable CA policies simultaneously.

The logic is simple: IF a set of conditions is true at sign-in, THEN enforce specific controls. All matching policies are applied together — if two policies both apply, the user must satisfy both. The outcome is always the most restrictive combination.

# CA Policy evaluation flow User authenticates (password / passwordless) ↓ Entra ID evaluates ALL enabled CA policies ↓ For each policy: Does the user match? (users/groups/roles assignment) Does the app match? (target resources) Do conditions match? (location, device, risk, client app) ↓ All matching policies → Grant controls combined (AND logic) Any policy says BLOCK → Access denied immediately No policies match → Access granted (no controls)

Common Mistake

Sign-in Risk vs User Risk — They Are Different Signals

Sign-in risk is evaluated in real time during the authentication attempt. Is this specific sign-in suspicious? Anonymous IP, impossible travel, malware-linked IP, unfamiliar sign-in properties.

User risk is calculated by Identity Protection in the background based on patterns over time. Is this user's account likely compromised? Leaked credentials, unusual activity patterns.

⚠️ A policy combining BOTH sign-in risk AND user risk in the same condition uses AND logic — both must be true simultaneously. This rarely happens in practice and makes the policy nearly useless. Create two separate policies: one for sign-in risk, one for user risk.

# WRONG: Combined risk condition (rarely triggers) Conditions: Sign-in risk = High AND User risk = High Result: Both must be elevated at the same moment = rare # RIGHT: Separate policies Policy 1: Sign-in risk = High → Block access Policy 2: User risk = High → Require password change + MFA

Critical Gap

What CA Does NOT Cover — The Blind Spots

Even a perfectly configured "All users, All apps" CA policy does not cover everything. These actions require dedicated policies or are outside CA scope entirely:

# Actions requiring dedicated CA policy (not covered by "All apps"): Security info registration → requires User Action policy Device registration/join → requires User Action policy Azure AD B2B guest sign-in → excluded unless explicitly included # Outside CA scope entirely: Legacy auth protocols → CA cannot enforce MFA (block them instead) App-level permissions → use App roles + RBAC Data access within an app → use DLP, sensitivity labels Device actions (wipe/lock) → use Intune

Licensing

What Requires P1 vs P2 vs No Licence

# No additional licence (included in all M365) Security Defaults (basic MFA + legacy auth block) — not CA # Entra ID P1 (M365 E3 / Business Premium) ✓ All Conditional Access policy creation ✓ Group, role, and location-based policies ✓ Device compliance and hybrid join requirements ✓ Authentication strength requirements ✓ Named locations (IP ranges, countries) ✓ Session controls (sign-in frequency, persistent browser) # Entra ID P2 (M365 E5) ✓ Sign-in risk conditions (Identity Protection) ✓ User risk conditions (Identity Protection) ✓ Token protection (preview) ✓ Insider risk conditions (Purview integration) ✓ GPS-based named locations

Enterprise Pattern

The 6-Policy Enterprise Baseline — Minimum Viable CA

These six policies represent the minimum enterprise CA baseline. Every policy has one job. Build them in this order — each one closes a specific attack surface.

Policy 1: BLOCK — Legacy Authentication Why: Legacy protocols bypass MFA entirely. Block first. Users: All | Apps: All | Client apps: EAS + Other clients | Grant: Block Policy 2: REQUIRE — MFA for All Users Why: Baseline identity verification for every sign-in. Users: All (excl. break-glass) | Apps: All | Grant: Require MFA Policy 3: REQUIRE — Phishing-Resistant MFA for Admins Why: Standard MFA is bypassable via AiTM. Admins need stronger auth. Users: Privileged roles | Apps: All | Grant: Auth strength = PR-MFA Session: Sign-in frequency = 1 hour Policy 4: REQUIRE — Compliant Device for Corporate Apps Why: Unmanaged devices have no security baseline. Users: All | Apps: Exchange, SharePoint, Teams | Grant: Compliant device Policy 5: BLOCK — High-Risk Sign-ins (requires P2) Why: Automated blocking of confirmed malicious sign-ins. Users: All | Apps: All | Conditions: Sign-in risk = High | Grant: Block Policy 6: REQUIRE — MFA for Security Info Registration Why: Prevents attackers registering their own MFA method. Users: All | User actions: Register security info | Location: Not trusted | Grant: MFA

💡 Load this baseline automatically in the Policy Builder tab using the Load Enterprise Baseline button. All policies start in Report-only mode so you can review before enforcing.

Governance

Policy Naming Convention — Enterprise Standard

A consistent naming convention means anyone troubleshooting at midnight can understand what a policy does without reading its full configuration. Microsoft recommends one policy = one job, with the action and scope in the name.

# Recommended format: ACTION — SCOPE — DETAIL BLOCK — Legacy Authentication BLOCK — High-Risk Sign-ins (P2) BLOCK — Unsupported Countries REQUIRE — MFA for All Users REQUIRE — Phishing-Resistant MFA for Admin Roles REQUIRE — Compliant Device for Corporate Apps REQUIRE — MFA for Security Info Registration SESSION — Short Sign-in Frequency for Admins SESSION — Browser-Only for Unmanaged Devices # Always add the policy purpose in the Description field: "Deployed 2026-05-20. Break-glass excluded. Reviewed quarterly." # This is visible in audit logs and the What If tool output

💡 This tool automatically applies the BLOCK/REQUIRE/SESSION naming pattern when you use the enterprise baseline. Edit policy names to match this convention when building your own.

2026 Updates

Key CA Changes in 2026 — What Changed and Why It Matters

March–June 2026: OIDC Scope Enforcement Fix What changed: CA policies targeting All Resources with exclusions previously skipped sign-ins requesting only OIDC scopes (openid, profile, email, User.Read). Impact: Apps using Azure CLI, custom OAuth apps, or developer tools that previously bypassed your policies will now be evaluated. Action: Run this KQL to find affected apps: SigninLogs | where ConditionalAccessStatus == "notApplied" | where AuthenticationRequirement == "singleFactorAuthentication" | summarize count() by AppDisplayName | order by count_ desc February 2026: Revoke Sessions — New Behaviour What changed: "Revoke sessions" now invalidates ALL tokens including MFA-satisfied sessions. Previously only revoked MFA state. Action: Update all IR playbooks and SOC runbooks. Correct action: Entra ID → User → Revoke sessions (not just password reset) 2026: Passkey-First Authentication (Preview) Microsoft is rolling out passkey (FIDO2 platform authenticator) as the default sign-in method for new accounts. CA policies using Authentication Strength = Phishing-resistant MFA automatically include passkeys — no policy change required. October 2025: Azure MFA Phase 2 Enforcement MFA is now mandatory for all Azure resource management actions. Any automation or script using password-only auth for Azure management APIs is non-compliant and will fail.

Token Security

Token Protection and AiTM Attacks — What Admins Need to Know

AiTM (Adversary-in-the-Middle) phishing uses a relay proxy (Evilginx, Modlishka) that sits between the user and the real Microsoft sign-in page. The user completes legitimate MFA through the proxy — the attacker captures the resulting session token and replays it from their own machine. MFA is already satisfied. CA policies are bypassed.

# AiTM Attack Flow User clicks phishing link → proxy relays real Microsoft sign-in User completes MFA (Authenticator push) → proxy captures token Attacker replays token from their IP → MFA already satisfied CA policies see: valid token, MFA completed → Access granted # Defences 1. Phishing-Resistant MFA (FIDO2/WHfB) Keys are bound to the legitimate site URL. Proxy cannot relay — the key challenge fails on the attacker's domain. 2. Token Protection (CA preview feature) Binds tokens to the specific device they were issued on. Replayed token from different device = rejected. Enable: CA policy → Session → Token protection: Enabled 3. Continuous Access Evaluation (CAE) Near-real-time revocation. When sessions are revoked, CAE-capable apps reject the token within minutes. Not instant — but dramatically reduces the replay window. 4. Sign-in frequency (1 hour for admins) Limits how long a stolen token remains useful.

Deployment

Safe Deployment Order — How to Roll Out Without Breaking Things

Week 1–2: Report-only mode Deploy ALL new policies in Report-only first. Review sign-in logs → identify impacted users, apps, service accounts. Use Entra ID → Monitoring → Sign-in logs → CA: Report-only results column. Week 3: Enforce Block Legacy Auth first Lowest disruption risk. Modern clients are unaffected. Identify any remaining legacy auth usage before enforcing. Week 4: Enforce MFA for All Users Communicate to users 1 week before enforcement. Ensure all users have Authenticator app registered. Have helpdesk ready for MFA registration queries. Week 5–6: Enforce Device Compliance Highest disruption risk — unmanaged devices lose access. Run Intune compliance report first: identify non-compliant devices. Grace period: set 3–5 days for devices to become compliant. Week 7+: Enforce remaining policies Admin phishing-resistant MFA, risk-based policies, session controls. Monitor for service account breakage — PA flows, scheduled tasks, SMTP relays. # ALWAYS keep 2 break-glass accounts excluded from ALL policies # Test every policy with the What If tool before enforcing