21 KiB
Assignment: Conditional Access Architecture
CA policies are enforcement points, not audit tools. A policy in report-only mode is a sensor. A policy in enabled mode is a wall. Know which you're building before you start.
This is a scoped assignment package — a complete, principled delivery guide for one specific client brief. It can be delivered standalone or immediately after Assignment: Identity Baseline. If identity baseline has not been completed, the prerequisites section below applies first.
The Brief
Client requests that fall within this scope:
- "Review our Conditional Access policies — we're not sure they're right"
- "We need to enforce MFA properly, not just per-user MFA"
- "Our auditor wants evidence of access controls"
- "We got a new employee and nobody knows how access actually works"
- "We bought E5 and want to use the CA features"
- "We need compliant devices to be required for access" (if Intune baseline is already deployed)
This assignment does not require executive sponsorship. It requires one named IT lead with Global Administrator access, tolerance for a 72-hour report-only period per policy before enforcement, and awareness that policy changes affect all users.
Scope Boundary
In scope:
- Audit of all existing CA policies (coverage, gaps, naming, exclusions, mode)
- Design and documentation of a complete CA policy set
- Staged deployment of the baseline policy set (identity-level controls)
- Device compliance integration if Intune compliance policies are already active
- Named locations configuration
- Authentication strengths configuration (phishing-resistant MFA for admins)
Out of scope:
- Intune compliance policy configuration → Assignment: Intune Security Baseline
- Microsoft Defender for Cloud Apps session controls (app-enforced restrictions are in scope; MDCA-dependent session policies are not)
- Privileged Identity Management configuration → privileged access engagement
- Identity Baseline (MFA registration, legacy auth, admin account hygiene) → Assignment: Identity Baseline
Dependency: This assignment can configure device compliance as a CA signal, but only if Intune compliance policies are already active and returning compliance state for enrolled devices. If Intune is not deployed, the device-compliance policies in this assignment are designed in report-only mode and left for activation when Intune is ready. Do not activate device-compliance CA policies against an environment where device enrollment is incomplete — the result is a broad lockout.
Before You Touch Anything
1. Break-glass confirmation. Before touching any CA policy, confirm that two cloud-only break-glass Global Admin accounts exist and are excluded from all CA policies. If they do not exist, create them and configure sign-in alerts before proceeding. See Assignment: Identity Baseline for the break-glass standard. This step is non-negotiable — a misconfigured CA policy with no break-glass is a full tenant lockout.
2. CAExporter baseline. Export all existing CA policies using CAExporter. Store the JSON export as the before-state. Every change is measurable against it. This is also the rollback reference.
3. Per-user MFA audit. Run the per-user MFA state report (Entra admin center → Users → Per-user MFA). If per-user MFA is enabled for any accounts, document it. Per-user MFA and CA-enforced MFA operate on separate control planes and interact unpredictably: a user with per-user MFA enforced may bypass some CA policies. Resolution is part of Step 3 below.
4. Sign-in log baseline. Export 30 days of sign-in logs. Note the distribution of authentication methods in use, client application types (modern vs. legacy), and any conditional access results (success, failure, report-only). This is the baseline against which policy impact is measured.
Principles Applied
Automation over procedure. A CA policy enforces MFA whether or not anyone remembers to ask for it. A checklist does not. Every identity control in this assignment is implemented as a CA policy — self-enforcing, continuous, requiring no human decision to operate after deployment.
Kill chain first. The policy set in this assignment is sequenced by structural impact. Legacy auth block and universal MFA enforcement come first because they close the widest attack path. Device compliance, location controls, and session policies come after. If the engagement ends early, the first two policies are the ones that matter.
Explicit design, documented intent. Every policy deployed in this assignment has a documented name, purpose, conditions, grant controls, exclusions, and the date it was set to enabled. A CA policy with no documented intent is a liability: nobody can safely modify it, nobody knows if it can be removed, and future administrators work around it rather than through it. The leave-behind package for this assignment is the policy design document — not just the JSON export.
Report-only before enforcement. Every new policy goes to report-only mode for a minimum of 48–72 hours. Sign-in logs are reviewed during that window to confirm expected behavior before enforcement. This is not optional. The cost of a production lockout — even for 30 minutes — is higher than the cost of 72 hours' delay.
Delivery Architecture
Step 1 — Audit (no changes)
Document the current state honestly. The finding is not a criticism of the IT team — it is the starting point.
| Action | Output |
|---|---|
| CAExporter export | CA policy baseline JSON and human-readable summary |
| Per-user MFA state export | Accounts with per-user MFA enforced vs. disabled vs. not configured |
| Policy coverage matrix | Every policy: name, state (enabled/report-only/disabled), conditions, grant, exclusions, last modified, named owner |
| Gap analysis | Conditions with no coverage; duplicate coverage; exclusion lists with individual accounts |
| Sign-in log review | Authentication methods in use; legacy auth clients; CA policy results |
| Named locations inventory | Trusted IPs and named locations configured, if any |
Deliver the audit findings to the named client lead before writing any policies. The coverage matrix should be readable without technical background — each row is one policy, each column answers one question. Include a plain-language summary: "You have 14 policies. Three are disabled and appear forgotten. Two overlap in ways that may create gaps. Five have no named owner and no documented purpose. Legacy authentication is not blocked at the CA level."
Step 2 — Design
Before deploying anything, produce the complete policy set design on paper (or in a document). Every policy defined, every exclusion justified, every interaction between policies mapped. Review with the named client lead before deployment begins.
The policy set is designed in three layers. Deploy them in order.
Layer 1 — Identity controls (no device dependency) These work immediately, without Intune or any device management. Deploy first.
Layer 2 — Admin controls (elevated requirements for privileged roles) Stricter controls applied specifically to accounts holding privileged roles. Deploy after Layer 1 is stable.
Layer 3 — Device and session controls (Intune dependency) Require device compliance as a CA signal. Deploy only when Intune compliance policies are active and returning results. Design these policies now; activate them when the Intune assignment is complete.
Step 3 — Deploy Layer 1 (staged)
Each policy follows the same deployment sequence:
- Create policy in report-only mode
- Wait 48–72 hours; review sign-in logs for the policy's report-only results
- Identify any legitimate traffic that would be blocked; create exclusion groups or refine conditions
- Switch to enabled
- Monitor sign-in logs for 24 hours
- Only then move to the next policy
Do not deploy multiple policies simultaneously. Each policy change has independent blast radius; sequential deployment makes causality clear when something breaks.
Legacy authentication block first. This is the one control that cannot afford to be partially deployed. If legacy auth is blocked via CA but not via Entra authentication policies, a policy gap in CA can allow legacy auth through. Confirm after deployment that the sign-in log shows zero legacy auth sign-ins. Zero is the only acceptable result.
Per-user MFA resolution. After CA-enforced MFA is active for all users, disable per-user MFA for all accounts except break-glass. Leaving both active creates a split control plane. The CA policy is the authoritative control; per-user MFA is the legacy mechanism. They should not coexist once CA is stable.
The Baseline Policy Set
This is the policy set to deploy on every engagement. Adapt scope and exclusions to the client's environment; do not adapt the design principles.
Naming convention:
CA-[Audience]-[Condition or Trigger]-[Grant or Block]
Examples: CA-AllUsers-LegacyAuth-Block, CA-Admins-AllApps-RequirePhishingResistantMFA
Consistent naming is not aesthetic preference — it is the difference between a policy set that can be maintained and one that accumulates technical debt.
Exclusion groups:
All exclusions use Entra ID security groups, never individual accounts (except break-glass, which is excluded by account). Group membership is reviewed as part of the leave-behind. A group named CA-Exclusion-BreakGlass is named and owned; an individual account exclusion is invisible in aggregate policy review.
Layer 1 — Identity Controls
| Policy | Conditions | Grant / Block | Notes |
|---|---|---|---|
CA-AllUsers-LegacyAuth-Block |
All users / All cloud apps / Legacy auth clients (Exchange ActiveSync + Other clients) | Block | Deploy first. Confirm zero legacy auth in sign-in logs post-enforce. |
CA-AllUsers-AllApps-RequireMFA |
All users / All cloud apps / All platforms / Exclude break-glass group | Require MFA | Core enforcement. Deploy second. Resolve per-user MFA conflict after this is stable. |
CA-GuestUsers-AllApps-RequireMFA |
Guest and external users / All cloud apps | Require MFA | Separate policy: guests often require different exclusion handling. |
E3 stops here for identity-layer controls. Risk-based policies (sign-in risk, user risk) require Entra ID P2. If the client has P2 licensing, add:
| Policy | Conditions | Grant / Block | Notes |
|---|---|---|---|
CA-AllUsers-HighUserRisk-RequirePasswordChange |
All users / High user risk | Require MFA + password change | P2 required. Requires Identity Protection enabled. |
CA-AllUsers-MedHighSignInRisk-RequireMFA |
All users / Medium and High sign-in risk | Require MFA | P2 required. Step-up for risky sign-ins. |
Layer 2 — Admin Controls
| Policy | Conditions | Grant / Block | Notes |
|---|---|---|---|
CA-Admins-AllApps-RequirePhishingResistantMFA |
Directory roles (Global Admin, Privileged Role Admin, Security Admin, Exchange Admin, SharePoint Admin, User Admin, Conditional Access Admin, Application Admin) / All cloud apps | Require authentication strength: Phishing-resistant MFA | Phishing-resistant = FIDO2 security key, Windows Hello for Business, or certificate-based auth. Requires auth strength configured in Entra. Standard Authenticator push is not phishing-resistant. |
CA-Admins-AllApps-RequireCompliantOrHybridDevice |
Same role scope / All cloud apps | Require compliant device OR hybrid Azure AD joined | Layer 3 control applied early to admins specifically. Activate this even before broad device compliance enforcement if Intune covers admin workstations. |
Why admins get a separate, stricter policy set: Admin credentials are the highest-value target in the tenant. An attacker who can bypass MFA on an admin account owns the tenant. Standard Authenticator push MFA is bypassed by MFA fatigue attacks (request flooding until the user approves). Phishing-resistant MFA is not. The separation in the policy set makes it explicit that admin accounts have a different requirement — and makes it auditable.
Layer 3 — Device Controls (activate when Intune is ready)
Design these policies now. Activate them after Assignment: Intune Security Baseline is complete and device compliance results are stable.
| Policy | Conditions | Grant / Block | Notes |
|---|---|---|---|
CA-AllUsers-AllApps-RequireCompliantDevice |
All users / All cloud apps / All platforms | Require compliant device OR require MFA | Start with OR (compliant device OR MFA) — gives unmanaged-device users a path via MFA. Once enrollment is high enough, switch to AND or compliant-only. |
CA-AllUsers-SensitiveApps-RequireCompliantDevice |
All users / Exchange Online + SharePoint Online / All platforms | Require compliant device | Strict. Apply to sensitive apps first before all apps. |
CA-AllUsers-UnmanagedDevice-AppEnforcedRestrictions |
All users / Exchange Online + SharePoint Online / Any platform / Filter: not compliant, not hybrid-joined | Session: app-enforced restrictions (use limited web access) | Limits download and sync on unmanaged devices accessing mail and documents. Requires Exchange Online and SharePoint to be configured for app-enforced restrictions. E3-compatible. |
The CA-AllUsers-UnmanagedDevice-AppEnforcedRestrictions policy is the most immediately valuable Layer 3 control for E3 clients without full Intune enrollment — it degrades access rather than blocks it, which is easier to deploy without user disruption.
Named Locations (supporting the policy set)
Configure named locations before deploying any location-based policies.
| Location | Purpose |
|---|---|
| Trusted corporate networks | Office IP ranges. Used to relax MFA requirements on trusted networks if the client explicitly requests it. Default recommendation: do not relax MFA on any network — trusted location is less durable than device compliance. |
| High-risk countries (optional) | Countries from which the client has no operations and no expected sign-ins. Can be used to block access or require MFA as a step-up. Use carefully: VPN exit nodes and mobile roaming will trigger this. Document the decision. |
Named locations are often requested but rarely worth the operational overhead unless the client has a specific use case (blocking sign-ins from a defined list of countries, or relaxing physical office controls). Include in the design document; deploy only if the client has a clear requirement.
Structural Resilience Checklist
Controls that hold without ongoing human willingness after this engagement closes.
CA-AllUsers-LegacyAuth-Blockis enabled — not report-only — and sign-in logs confirm zero legacy auth clientsCA-AllUsers-AllApps-RequireMFAis enabled and covers all users including guests (separate guest policy)CA-Admins-AllApps-RequirePhishingResistantMFAis enabled and authentication strength is configured- Per-user MFA has been disabled for all accounts after CA-enforced MFA is stable (except break-glass)
- All exclusions use named Entra ID groups — no individual account exclusions except break-glass
- Every policy has a documented name, intent, owner, and date of last review
- CAExporter export (before and after) stored in client documentation
- Layer 3 policies exist in report-only mode, ready for activation when Intune is complete
Kill Chain Contribution
What this assignment closes:
| Attack vector | Control deployed |
|---|---|
| Password spray with no MFA prompt | CA-AllUsers-AllApps-RequireMFA |
| MFA fatigue attack against admin accounts (push flooding) | CA-Admins-AllApps-RequirePhishingResistantMFA |
| Legacy protocol abuse (SMTP AUTH, IMAP, Basic Auth REST) | CA-AllUsers-LegacyAuth-Block |
| Credential stuffing from breached credential lists | MFA enforcement |
| Guest account lateral movement through weakly controlled external access | CA-GuestUsers-AllApps-RequireMFA |
| Unmanaged device access to sensitive apps (if Layer 3 activated) | CA-AllUsers-UnmanagedDevice-AppEnforcedRestrictions |
What this assignment does not close:
| Remaining gap | Addressed by |
|---|---|
| Adversary-in-the-middle / session token theft post-MFA | Device compliance in CA + Entra token protection (P2) |
| Unmanaged device as unrestricted access vector | Assignment: Intune Security Baseline + Layer 3 activation |
| Standing admin privilege (long-lived sessions, no JIT) | Privileged access engagement (PIM) |
| Sign-in risk and impossible travel detection | Entra ID P2 Layer 1 additions |
| App permission abuse (OAuth consent phishing) | Service identity engagement |
The residual gap the client is most likely to feel: a stolen session token (from phishing with AiTM proxy) bypasses MFA because it captures the token after MFA completes. This is the next-generation phishing technique. Mitigating it requires token binding to device compliance — a Layer 3 control — plus Entra token protection (P2 feature). Document this in the residual risk statement.
Leave-Behind Package
| Artifact | Description |
|---|---|
| CAExporter JSON (before) | CA policy state at engagement start |
| CAExporter JSON (after) | CA policy state at engagement close |
| Policy design document | Every deployed policy: name, intent, conditions, grant/block, exclusion groups, owner, date enabled |
| Policy coverage matrix | Human-readable: which users are covered by which policies, which apps, which platforms |
| Per-user MFA resolution record | Confirmation that per-user MFA has been disabled post-CA deployment |
| Layer 3 design document | Device compliance policies designed but not yet activated; activation prerequisites and checklist |
| Exclusion group inventory | Every CA exclusion group: name, members, review cadence |
| Sign-in log confirmation | Legacy auth: zero clients post-block. MFA: applied to >99% of sign-ins. |
| Named locations documentation | Any configured named locations with business justification |
| Scope boundary log | Every finding outside this scope, named and prioritized |
| Residual risk statement | What this assignment did not close, specifically including AiTM/token theft risk |
The Layer 3 design document is the explicit handoff to the Intune assignment. A CISO reading the leave-behind package can see exactly what was built, why, what it prevents, and what comes next — without needing to ask.
Scope Boundary Signals
| Signal | Points toward |
|---|---|
| No Intune enrollment or compliance policies active | Intune Security Baseline assignment — activate Layer 3 after |
| Global Admins have no phishing-resistant MFA method registered | Auth method enrollment drive; may need hardware key procurement |
| Entra ID P2 not licensed; client has credential-stuffing exposure | Licensing recommendation: P2 for Identity Protection (cheaper than full E5) |
| App registrations with broad Graph permissions visible in sign-in logs | Service identity engagement |
| Service accounts authenticating with CA policies applied | Service account remediation — service accounts should use managed identities or workload identity federation, not user-like credential flows through CA |
| Defender for Cloud Apps not licensed; session control requests needed | MDCA engagement for full session control |
| Sign-in logs show access from unexpected geographies | Named location policy review; may warrant country block |
| Audit log retention < 90 days | Detection baseline assignment |
Buildable-On: What the Next Assignment Depends On
The Intune Security Baseline assignment builds directly on the CA architecture deployed here. Specifically, it depends on:
CA-AllUsers-AllApps-RequireCompliantDeviceexists in report-only mode. The Intune assignment activates this policy as its final step — the point where device compliance becomes an access control, not just a reporting tool.- CA exclusion groups are using the right naming convention. Device compliance policies deployed in Intune reference the same user groups used in CA. Consistent group naming prevents the Intune assignment from having to clean up CA policy exclusions mid-deployment.
- Sign-in logs show MFA is enforced. The Intune assignment cannot safely activate device-compliance CA policies if MFA enforcement is incomplete — an unmanaged device could otherwise use the compliance check as a bypass path.
If all three conditions are true at handover, the Intune assignment can activate Layer 3 without revisiting the CA work. If any condition is false, the scope boundary log documents what needs to be resolved first.
For the identity foundation this builds on, see Assignment: Identity Baseline. For the device compliance integration that activates Layer 3, see Assignment: Intune Security Baseline. For the technical depth on privileged access architecture that informs admin CA requirements, see Book III — Privileged Access.