Cloud Identity in 2026: Practical Conditional Access Patterns That Actually Work

[For IT Pros]

If you're running Microsoft 365 or Azure AD (Entra ID) in 2026, your real security perimeter is no longer the office network – it's your identity layer plus Conditional Access. The problem is, most organisations either go way too permissive (“just MFA everything”) or way too aggressive and lock out half the business.

In this guide, I’ll walk through practical, battle-tested Conditional Access patterns you can deploy without breaking your users. Think of this as a baseline playbook you can adapt to almost any organisation using Entra ID, Intune, and modern endpoints.

1. Foundations: Design Principles Before You Touch a Policy

Before you add yet another CA policy, you need a mental model. Otherwise you end up with 40 overlapping rules and no one knows which one is doing what.

1.1 Identity & device: treat them as one control surface

In 2026, "user + password + MFA" is not enough. You need to think in terms of:

  • User risk – sign-ins from abnormal locations, impossible travel, leaked credentials.
  • Session risk – token theft, unusual session behaviour (Entra ID Protection / Defender for Cloud Apps).
  • Device trust – compliant Intune devices vs unknown / unmanaged vs BYOD.
  • App sensitivity – Teams vs Exchange vs your finance or HR apps.

Your Conditional Access design should reflect that: different controls for different combinations of user, device, and app.

1.2 Policy layering strategy

Stop building monolithic “do everything” policies. Instead:

  • Baseline layer – Global rules every user hits (MFA, basic protections).
  • Risk layer – User risk, sign-in risk, risky sessions.
  • Device posture layer – Require compliant / hybrid-joined for sensitive apps.
  • App sensitivity layer – Stricter for admin portals, HR, finance, customer data.
  • Exception layer – Only for genuine edge cases (break-glass, service accounts, legacy).

Keep policies small and purpose-built. It makes debugging and audits far easier.

2. Baseline Conditional Access: The 80% You Should Have Everywhere

This section is the “if you have nothing, start here” part. The intent is to get you to a sane, modern baseline without killing productivity.

2.1 Policy: Require phishing-resistant MFA for all users (where supported)

Goal: Stop basic credential theft and MFA fatigue attacks.

Pattern:

  • Assignments
    • Users: All users (exclude break-glass accounts).
    • Cloud apps: All cloud apps.
  • Conditions
    • Locations: Any location (don’t carve out “trusted” networks – those get abused).
    • Device platforms: Any device.
  • Access controls
    • Grant: Require multifactor authentication.
    • Authentication strengths: Prefer “Phishing-resistant MFA” (FIDO2, Windows Hello for Business, platform authenticators). Fall back only where absolutely necessary.

Why: In 2026, push-based MFA alone is no longer acceptable for internet-exposed identities. Use authentication strengths to enforce better factors for admins and high-value roles first, then scale to all.

2.2 Policy: Block legacy authentication globally

Goal: Kill basic auth and remove the biggest bypass path.

  • Assignments
    • Users: All users (no exceptions unless you truly have a legacy app and a plan to retire it).
    • Client apps: Other clients (legacy authentication).
    • Cloud apps: All cloud apps.
  • Access controls
    • Grant: Block access.

Tip: Run it in Report-only for 2–4 weeks, export the sign-in logs to a workbook and hammer down the last legit legacy clients before enforcing.

2.3 Policy: Administrators must use compliant or privileged workstations

Goal: Stop admin work from personal / unknown devices.

  • Assignments
    • Users: Admin roles (use a dynamic group based on directory roles).
    • Cloud apps: Azure Management, Microsoft 365 admin centers, privileged business apps.
  • Conditions
    • Client apps: Browser + Modern auth clients.
  • Access controls
    • Grant: Require compliant device OR require Hybrid Azure AD joined device.
    • Session: Use sign-in frequency = 8 hours or less, persistent browser session = disabled.

Real-world note: Pair this with a privileged access workstation (PAW) policy in Intune and a separate device group for admin machines.

3. Risk-Based Controls: Let Entra ID & Defender Do the Heavy Lifting

Static rules will never keep up with today’s phishing kits and token theft. Risk-based Conditional Access helps you respond faster without manual intervention.

3.1 Policy: User risk-based step-up

Goal: When Entra ID thinks an identity is risky, force the user through a higher bar.

  • Assignments
    • Users: All users (excl. break-glass).
    • Cloud apps: All cloud apps.
  • Conditions
    • User risk: High.
  • Access controls
    • Grant: Require password change + require MFA (or phishing-resistant MFA strength where licensed).

Why: This gives you automated containment when creds are leaked, without relying on a human analyst to react at 2 a.m.

3.2 Policy: Sign-in risk-based blocking for sensitive apps

Goal: Don’t let risky sign-ins touch finance, HR, or production admin tools.

  • Assignments
    • Users: All users with access to sensitive apps (use app-based dynamic groups if possible).
    • Cloud apps: Finance systems, HR, admin portals, customer data apps.
  • Conditions
    • Sign-in risk: Medium and above (tune to your appetite).
  • Access controls
    • Grant: Block access.

Practical tip: Run this in Report-only first. You’ll quickly see if travel users or VIPs get hit a lot and can tune exclusions if necessary.

3.3 Policy: High-risk sessions go through continuous access evaluation

Goal: Cut off compromised sessions instead of letting them live for days.

  • Assignments
    • Cloud apps: Exchange, SharePoint, Teams, and any app that supports Continuous Access Evaluation (CAE).
  • Access controls
    • Session: Enforce Cloud Apps (Defender for Cloud Apps) session controls where licensing allows, and ensure CAE is enabled tenant-wide.

Why: CAE is now mature; there’s no good reason to allow long-lived sessions for critical data.

4. Device-Centric Conditional Access: Compliant vs BYOD vs Unknown

This is where a lot of tenants get messy. You want strong controls for managed devices but still allow sane access from BYOD and partner machines.

4.1 Policy: Require compliant devices for “tier 1” apps

Goal: Mail and Teams can be accessed from almost anywhere, but your core business apps should live behind stronger gates.

  • Assignments
    • Users: All employees (or specific departments like Finance, HR, Engineering).
    • Cloud apps: ERP, CRM, internal admin portals, production management tools.
  • Conditions
    • Device platforms: All.
  • Access controls
    • Grant: Require device to be marked as compliant.
    • Session: Optionally apply sign-in frequency (e.g., 12 hours) for these apps only.

Dependency: This assumes you have Intune compliance policies that mean something (disk encryption, AV, OS version, secure boot, etc.). Don’t mark everything compliant by default.

4.2 Policy: BYOD / personal devices get web-only, read-only where possible

Goal: Users can still work from personal devices, but data doesn’t live there indefinitely.

  • Assignments
    • Users: All standard users.
    • Cloud apps: Exchange, SharePoint, OneDrive, Teams, lightweight internal portals.
  • Conditions
    • Device state: Not marked as compliant AND not Hybrid Azure AD joined.
  • Access controls
    • Grant: Require MFA.
    • Session: Use conditional app access (Defender for Cloud Apps) to limit download, enforce web-only for Office online, and add watermarking as needed.

Scenario: User on a hotel PC can still check email via web, but can’t sync OneDrive or download your whole customer list.

4.3 Policy: Block unmanaged devices for admin endpoints

Goal: Absolutely no admin activity from unknown endpoints.

  • Assignments
    • Users: Admins, DevOps, anyone with production access.
    • Cloud apps: Azure Management, Entra ID, Defender portals, CI/CD systems, privileged business apps.
  • Conditions
    • Device state: All devices.
  • Access controls
    • Grant: Require compliant device AND require phishing-resistant MFA.

Extra hardening: Combine with privileged identity management (PIM) so elevated roles can only be activated from those compliant devices.

5. Governance, Exceptions, and Documentation That Won’t Rot in 6 Months

Good Conditional Access is as much about governance as it is about checkboxes in the portal. Without guardrails, policies sprawl fast.

5.1 Naming and tagging standards

Adopt a simple, consistent naming pattern:

  • CA-[Layer]-[Target]-[Condition]-[Action]

Examples:

  • CA-Base-AllUsers-AllApps-RequireMFA
  • CA-Device-Finance-RequireCompliant
  • CA-Risk-AllUsers-HighUserRisk-ForcePwdReset

Use policy descriptions to document:

  • Owner / team.
  • Business justification.
  • Date created and last reviewed.

5.2 Exception handling without chaos

Resist one-off policy exclusions where possible. Instead:

  • Create an “Exception – Temporary” group with an approval process and expiry dates.
  • Document each member with a ticket ID and business owner.
  • Review membership monthly and remove stale exceptions.

For genuine legacy systems, create dedicated policies that are narrow (specific users, specific apps, specific networks) and have a clear retirement date.

5.3 Exporting and version-controlling policies

Don’t rely on “we’ll remember what we changed”. Use automation.

Basic pattern with PowerShell (using the Microsoft Graph PowerShell SDK):

Connect-MgGraph -Scopes "Policy.Read.All"
Select-MgProfile -Name "beta"  # or v1.0 where supported

$timestamp = (Get-Date).ToString("yyyyMMdd-HHmmss")
$path = "./Exports/ConditionalAccess-$timestamp.json"

$policies = Get-MgIdentityConditionalAccessPolicy
$policies | ConvertTo-Json -Depth 10 | Out-File $path -Encoding utf8

Check these JSON exports into Git (private repo) so you can:

  • Compare changes over time.
  • Roll back if a policy breaks sign-ins.
  • Share review diffs with security and compliance teams.

6. A Concrete 30-Day Plan to Improve Your Conditional Access

If your current setup is a mix of old policies, ad-hoc rules, and legacy exceptions, here’s a realistic sequence you can actually follow this month.

Week 1: Visibility & groundwork

  • Export your current CA policies using the script above.
  • Map each policy to one of the layers: baseline, risk, device, app, exception.
  • Enable sign-in log export to Log Analytics (if not already) and build a simple workbook: top apps, legacy auth usage, failed sign-ins by reason.

Week 2: Baseline cleanup and legacy auth removal

  • Create a single baseline MFA policy if you currently have three or four conflicting ones.
  • Enable the block legacy auth policy in Report-only and identify remaining dependencies.
  • Start pilot of phishing-resistant MFA for a small group of IT and security staff.

Week 3: Device & app sensitivity

  • Define your tier 1 apps (finance, HR, admin, IP-heavy systems).
  • Implement the require compliant device policy for those apps in Report-only.
  • Set up BYOD web-only access for Exchange / SharePoint / OneDrive with MCAS/Defender for Cloud Apps if licensed.

Week 4: Risk-based automation and governance

  • Turn on user risk and sign-in risk policies, starting with medium+ risk on less critical apps.
  • Standardise naming and documentation for all policies created in the last three weeks.
  • Present the new model to your security / compliance stakeholders: show before vs after diagrams and sign-in impact.

One Clear Next Step

Pick one of the patterns above and put it into Report-only mode today – ideally, the global legacy auth block or a clean baseline MFA policy. Let the data show you where the gaps are, then iterate. Conditional Access becomes powerful when it’s treated as a living control system, not a one-off project you set and forget.