Conditional Access in 2026: Practical Policies That Actually Protect Your Cloud

[For IT Pros]

If you own identity, you own security. In 2026, most attacks I see start with a single compromised account that didn’t have Conditional Access (CA) properly enforced. The good news: a small set of well-designed policies will stop most of the nonsense you’re firefighting today.

This guide walks through a practical Conditional Access setup for Azure AD / Entra ID that you can roll out in a real environment. Not the pretty diagram version – the version that survives sales, legacy apps, VIPs, and that one third-party vendor who still hates MFA.

1. Core Principles: How to Think About Conditional Access in 2026

Before we touch the portal, align on how we use CA. If you skip this, you’ll end up with 40+ conflicting policies and no one knows what breaks what.

1.1 The five design rules

  • Identity is your new perimeter. Treat every sign-in as untrusted until evaluated by CA. Networks, VPNs and firewalls help, but they’re supporting actors now.
  • Start with protect-then-exception. Create strict baseline policies, then carve out tightly controlled exceptions with explicit owners and review dates.
  • Use few broad policies. Aim for 6–10 well-scoped policies instead of 50 micro-policies. Fewer objects = easier troubleshooting.
  • Let risk systems do their job. Combine CA with Identity Protection (user risk, sign-in risk, device risk) instead of re-inventing risk logic with DIY conditions.
  • Everything is auditable. Every exclusion group, break-glass account, and bypass must be documented and time-bound.

1.2 Baseline building blocks to define early

Decide these up front:

  • Break-glass accounts: 2–3 cloud-only accounts, no CA, long random passwords, hardware token MFA disabled, stored offline in a physical safe, monitored 24/7 for any sign-in.
  • Tiered groups:
    • CA-Include-All-Users (excludes break-glass)
    • CA-Exclude-High-Risk-Apps (legacy / special handling)
    • CA-Admin-Roles (all privileged roles via PIM dynamic group)
  • Device posture sources: Intune compliance, Defender for Endpoint device risk, and your EDR if integrated via Entra ID.

2. Minimum Viable Conditional Access: 7 Policies That Matter

Here’s a realistic baseline that I deploy in most environments. Names are suggestions, but be consistent – your future self will be reading logs at 2am.

2.1 Require phishing-resistant MFA for admins

Policy name: CA-ADM-Require-PhishingResistant-MFA

Goal: Admins must use phishing-resistant methods (FIDO2, Windows Hello for Business, PIV/Smartcard, or Microsoft Authenticator number matching with device binding if FIDO isn’t yet feasible).

  • Assignments:
    • Users: CA-Admin-Roles group (or “Directory roles: All privileged roles”)
    • Cloud apps: All cloud apps
  • Conditions:
    • Locations: Include Any location; exclude “Trusted corporate locations” if you absolutely must (I don’t recommend it for admins).
  • Access controls:
    • Grant: Grant access > Require phishing-resistant MFA
    • Enable policy: On (after test in report-only)

Key point: In 2026, SMS and voice are basically “nice for your grandparents”, not for admins. Rip them out for privileged roles.

2.2 Require modern MFA for all users

Policy name: CA-ALL-Require-MFA

Goal: Every user, everywhere, must satisfy MFA – with adaptive friction so they’re not prompted every 5 minutes.

  • Assignments:
    • Users: CA-Include-All-Users
    • Cloud apps: Office 365, Azure management, and other core apps; you can roll out to “All cloud apps” once tested.
  • Conditions:
    • Locations: Include Any location; optionally exclude “Trusted locations” for low-risk apps, but avoid carving out for admins.
    • Sign-in risk: Low and above.
  • Access controls:
    • Grant: Grant access > Require multifactor authentication
    • Session: Enable sign-in frequency (e.g., 12 hours) and persistent browser session where device is compliant.

Tip: Pair this with Entra ID’s “Combined registration” and a short internal campaign: set people up with Authenticator app + at least one backup method.

2.3 Block legacy authentication

Policy name: CA-ALL-Block-Legacy-Auth

Goal: Stop basic auth and legacy protocols that can’t do modern MFA.

  • Assignments:
    • Users: CA-Include-All-Users
    • Cloud apps: All cloud apps
  • Conditions:
    • Client apps: Select Other clients and Legacy authentication clients.
  • Access controls:
    • Grant: Block access

Process: First, run this in Report-only for 2–4 weeks and export sign-in logs. Identify systems still on legacy auth, fix or isolate them, then enforce.

2.4 Require compliant or healthy devices for sensitive apps

Policy name: CA-HR-FIN-Require-Compliant-Or-LowRisk-Device

Goal: HR, finance, and other sensitive apps must only be reachable from Intune-compliant devices or machines with low device risk.

  • Assignments:
    • Users: Security groups for HR, Finance, Legal, etc.
    • Cloud apps: HRIS, payroll, ERP, DLP portals, finance systems, etc.
  • Conditions:
    • Device platforms: Windows, macOS, iOS, Android.
    • Device state: Include All.
    • Device filter: Optional, if you want corporate-owned only (e.g., tag-based filter from Intune).
    • Device risk (if using Defender): Require Low or None.
  • Access controls:
    • Grant: Require Compliant device OR Require device to be marked as secure (low risk) + MFA.

Example: A finance user on a personal, unmanaged laptop can still check email, but can’t open the finance SaaS. They see a friendly error telling them they need a managed device.

2.5 Block high-risk sign-ins

Policy name: CA-ALL-Block-HighSignInRisk

Goal: Anything flagged by Entra ID as High sign-in risk gets blocked, full stop.

  • Assignments:
    • Users: CA-Include-All-Users
    • Cloud apps: All cloud apps
  • Conditions:
    • Sign-in risk: High
  • Access controls:
    • Grant: Block access

Note: Combine this with a helpdesk process that can rapidly help a legitimate user recover access (ID verification + secure password reset + device health check).

2.6 Force password reset on high user risk

Policy name: CA-ALL-HighUserRisk-Require-PasswordReset

Goal: When Entra ID thinks an account is likely compromised, force a secure reset.

  • Assignments:
    • Users: CA-Include-All-Users
    • Cloud apps: All cloud apps
  • Conditions:
    • User risk: High
  • Access controls:
    • Grant: Require password change

Important: Make sure Self-Service Password Reset (SSPR) is configured properly, with strong authentication methods and clear user comms.

2.7 Protect privileged access to Azure management

Policy name: CA-ADM-AzureMgmt-Restrict-Locations-Devices

Goal: Access to Azure management endpoints is only allowed from known locations and healthy devices.

  • Assignments:
    • Users: CA-Admin-Roles
    • Cloud apps: Microsoft Azure Management, Azure Portal, CLI/PowerShell sign-ins where applicable.
  • Conditions:
    • Locations: Include Any location; exclude defined Trusted locations (e.g., office public IPs, secure VPN exit).
    • Device platform: All platforms.
    • Device state: Require managed devices for daily work; allow just-in-time admin workstation as exception if you use dedicated PAW devices.
  • Access controls:
    • Grant: Require Compliant device + MFA.

3. Practical Implementation Plan (Without Breaking Everything)

Rolling this out is where most teams get burnt. Here’s a pragmatic 4-phase plan that has worked repeatedly.

3.1 Phase 1 – Discovery and report-only

  • Turn on Report-only mode for all new policies first.
  • Monitor Sign-in logs and Report-only results for 2–4 weeks.
  • Tag apps and users that would be blocked or heavily impacted.
  • Meet with business owners of critical apps to agree on timelines and any justified exceptions.

Quick script to pull CA report-only impact (PowerShell):

Connect-MgGraph -Scopes 'AuditLog.Read.All','Directory.Read.All'

$start = (Get-Date).AddDays(-7).ToString('o')
$end   = (Get-Date).ToString('o')

$logs = Invoke-MgGraphRequest -Method GET `
  -Uri "/beta/auditLogs/signIns?`$filter=createdDateTime ge $start and createdDateTime le $end" -OutputType PSObject

$logs.value |
  Select-Object userPrincipalName, appDisplayName, conditionalAccessPolicies |
  Export-Csv .\CA-ReportOnly-Impact.csv -NoTypeInformation

3.2 Phase 2 – Pilot group rollout

  • Create a CA-Pilot user group with IT, security, and a few friendly business users.
  • Scope each policy to this group instead of CA-Include-All-Users initially.
  • Run 1–2 weeks of live enforcement for the pilot. Capture feedback daily.
  • Fix obvious friction points (e.g., app needing modern auth, device enrollment issues).

3.3 Phase 3 – Controlled global enablement

  • Switch policies from report-only to On in waves (e.g., department by department).
  • Use “Exclude” groups only as temporary crutches with expiry dates documented in your runbook.
  • Watch helpdesk tickets and sign-in logs closely after each wave.

Tip: For senior execs, pre-book 1:1 slots where IT helps them set up MFA on all their devices, including tablets and phones, before enforcement hits them.

3.4 Phase 4 – Tighten and maintain

  • Regularly review:
    • Sign-in logs for failures due to CA.
    • Users and apps in exclusion groups.
    • Admin sign-ins from unusual locations or devices.
  • Move from “require MFA” to “require phishing-resistant MFA” for more user groups as devices catch up.
  • Integrate CA decisions into your SIEM and incident response playbooks.

4. Governance: Keeping Conditional Access Sane Over Time

Most CA setups don’t fail technically, they fail in governance. Too many cooks, random exceptions, and zero documentation.

4.1 Ownership and change control

  • Owner: Assign a single accountable owner (typically Security or Identity team lead).
  • Change process: Any new CA policy or exclusion must go through a lightweight change review, not ad-hoc edits in production.
  • Documentation: Maintain a CA register with:
    • Policy name, purpose, owner
    • Included/excluded users, apps, conditions
    • Last reviewed date and next review date

4.2 Auditing and drift detection (PowerShell example)

Export your CA configuration regularly and store it in Git or another version control system.

Connect-MgGraph -Scopes 'Policy.Read.All'

$policies = Get-MgIdentityConditionalAccessPolicy

$policies | ConvertTo-Json -Depth 10 | `
  Out-File .\Export-ConditionalAccess-$(Get-Date -Format 'yyyyMMddHHmm').json -Encoding utf8

Commit the JSON files to a repo and set up a weekly diff check. That way, any surprise change to a policy is visible and traceable.

4.3 Handling exceptions the right way

  • Use dedicated groups like CA-Exception-MFA or CA-Exception-DeviceCompliance, never user-by-user exclusions in the policy.
  • All exceptions must have:
    • A clear business justification
    • An expiry date (30–90 days max)
    • A named approver (e.g., app owner + security)
  • Review exception groups monthly. Remove any member without active justification.

5. Your Next Step: Ship One High-Impact Policy This Week

You don’t need a six-month project plan to get value from Conditional Access. Pick one of these actions and schedule it for this week:

  • If you have no CA today: Create CA-ADM-Require-PhishingResistant-MFA in report-only, target admin roles, and start analysing the impact.
  • If you already have CA: Export your current policies and build a simple CA register. You’ll immediately see duplication and risky gaps.
  • If CA is a mess: Identify the top 10 most used policies by sign-in logs and map exactly what each does. Merge or retire where possible.

Once you’ve done that first step, tightening and expanding becomes much easier. Conditional Access isn’t about perfection – it’s about raising the floor so one compromised password doesn’t turn into a full company incident.