Substantive Overview
Conditional Access (CA) is the heartbeat of a Zero Trust architecture. It is the policy engine that intercepts every access request to Entra ID-connected resources and makes a dynamic decision: Grant, Block, or Challenge.
In the old world, security was binary: you were on the network (trusted) or off (untrusted). In the modern world, identity is the perimeter. Every request must be explicitly verified. Conditional Access orchestrates this verification by synthesizing signals (User, Device, Location, Application, Risk) to enforce organizational policy.
A "good" implementation moves beyond simple "Enable MFA" checkboxes. It implements a tiered access model, distinguishes between managed and unmanaged devices, and incorporates real-time risk signals (Identity Protection). It fails safe (default deny) but minimizes friction for low-risk, high-trust scenarios.
Architecture & Patterns
Pattern 1: The "Zero Trust" Evaluation Loop
The conceptual model for how CA acts as the policy decision point (PDP) and policy enforcement point (PEP).
Diagram
Pattern 2: Personas and Tiers Strategy
Organizing policies not by random rules, but by user personas and resource sensitivity.
Diagram
Key Design Decisions
| Decision | Options | Recommendation | Context |
|---|---|---|---|
| MFA Strategy | All Users vs. Conditional | All Users (Conditional) | Enforce MFA for everyone, but use "Trusted Location" or "Compliant Device" to suppress prompts (reduce fatigue) where safe. |
| Device Trust | Domain Joined vs. Compliant (Intune) | Compliant | "Domain Joined" only proves ownership. "Compliant" proves health (AV updated, BitLocker on). |
| Risk Integration | Block High Risk vs. Allow with Remediation | Remediation | "Require Password Change" for High Risk Users is self-healing. Blocking creates helpdesk tickets. |
| Session Control | Persistent vs. Non-Persistent | Context-Aware | Use "Sign-in Frequency" controls. reduce session lengths for unmanaged devices or sensitive apps. |
| Legacy Auth | Allow vs. Block | Block Globally | Legacy Auth (POP/IMAP) bypasses MFA. It must be killed. |
Implementation Strategy
Phase 0: Baseline & Report-Only
- Emergency Access: Create 2x "Break Glass" accounts (cloud-only) and exclude them from all CA policies.
- Legacy Auth Discovery: Use Sign-in Logs to identify who is still using legacy protocols.
- Report-Only Mode: Create proposed policies in "Report-Only" mode. Do not enforce yet.
Phase 1: Foundation (The "Fence")
- Block Legacy Auth: Enforce blocking of legacy protocols.
- Admin MFA: Require MFA for all Privileged Roles (no exceptions).
- MFA for All: Enable MFA for all users, perhaps with trusted location exceptions.
Phase 2: Device & Risk (The "Filter")
- Hybrid Join/Compliant: Create policies requiring "Hybrid Joined" OR "Compliant" device for core Office 365 apps.
- Risk-Based CA: Implement "User Risk" (require password change) and "Sign-in Risk" (require MFA) policies.
- Browser Protection: Enforce "App Enforced Restrictions" (limit downloads) for unmanaged devices accessing SharePoint/Exchange.
Phase 3: Guest & External
- Guest Baseline: Enforce MFA for guest users (trust their home tenant MFA if possible).
- Terms of Use: Require Guest acceptance of ToU.
- Frequency: Set aggressive sign-in frequency (e.g., 24h) for guests.
Phase 4: Operationalize
- Insights: Use the "Insights and Reporting" workbook to monitor policy impact.
- Review: Quarterly review of "Excluded" users/groups.
Risks & Anti-Patterns
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Locking Out Admins | Medium | Critical | Always, always have a Break Glass account excluded from ALL policies. |
| MFA Fatigue | High | Medium | Don't prompt for MFA on every sign-in. Use "Remember this device" or "Compliant Device" as a satisfied factor. |
| Circular Dependencies | Low | High | Don't require a compliant device to register a device. Don't require MFA to register MFA (unless using Temporary Access Pass). |
| Service Account Blocks | Medium | High | Exclude non-interactive service accounts from MFA policies; restrict them by IP instead. |
| "Block All" Misconfiguration | Low | Critical | Be very careful with "Block" policies. Ensure they target specific conditions and have exclusions. |
KPIs & Outcomes
- MFA Coverage: 100% of user accounts.
- Legacy Auth: 0 active connections.
- Managed Device Access: >80% of access to sensitive data comes from Managed/Compliant devices.
- Risk Remediation: under 1 hour mean time to remediate "High Risk" user flags (automated).
Workshop Questions
- Who needs access to data from non-corporate devices (BYOD)?
- Are there specific countries/regions you absolutely never do business with? (Geo-blocking)
- What is the definition of a "Privileged User" in your org beyond Global Admin?
- Do you have "Service Accounts" logging in interactively?
- What is the tolerance for MFA prompts? (Every day? Every 30 days? Only on new device?)
- Are you using Intune for device compliance? If not, what validates device health?
- How do you handle "Emergency Access" today?
- Do you have existing MFA solutions (Duo, RSA) you need to integrate or replace?
- What are the "Crown Jewel" applications that require stricter policy?
- Do you want to block downloads on unmanaged devices or block access entirely?
- How do you handle contractors? (Guests vs. Member accounts)
- Is "Impossible Travel" a valid signal for your workforce, or do they use VPNs that hop regions?
- Do you trust the MFA performed by external partners (B2B Direct Connect)?
- What is the process for onboarding a new policy?
- Do you use "Named Locations" for branch offices?
Checklist
- Break Glass Accounts: Created and verified login.
- Named Locations: Define Trusted IPs (Offices, VPN Egress).
- MFA Registration: Campaign to get users registered for Auth App (push).
- Legacy Auth: Confirm usage is effectively zero or identified.
- Policy Naming Convention: Standardize (e.g.,
[Scope] - [Target] - [Control]). - Report-Only: Verify logs for at least 2 weeks before enforcement.
- User Communication: Draft comms explaining why they are seeing prompts.