Real-World Conditional Access in 2026: Practical Policies That Actually Protect Your Users

[For IT Pros]

If you're responsible for Microsoft 365 or Azure AD (yes, Entra ID now), Conditional Access is probably the sharpest tool you have. Used well, it quietly blocks bad logins, reduces phish impact, and keeps auditors off your back. Used badly, it locks out executives on a Sunday and you spend the evening on a bridge call.

This guide is the version I wish I had years ago: opinionated, practical, and focused on what you can roll out this month. Less theory, more real policies, with examples you can copy, tweak, and ship.

1. Foundation: What Conditional Access Should Actually Do in 2026

By 2026, Conditional Access isn’t a “nice to have” – it’s your main guardrail for cloud identity. With token theft, session hijacking, and AI-powered phishing getting smarter, usernames and passwords are basically public information.

At a minimum, your Conditional Access strategy should:

  • Enforce phishing-resistant MFA for risky or sensitive access
  • Block obviously bad sessions (anonymous proxies, TOR, impossible travel)
  • Constrain where high-value data lives (compliant devices, controlled networks)
  • Give you visibility into who is bypassing controls and why

Think in layers: identity, device, session, and data. Every policy you create should clearly answer: “What risk am I reducing, and how will I know it’s working?”

2. A Baseline Policy Set You Can Build From

Here’s a pragmatic baseline set I implement in most environments, from 200 seats to 20,000+. Adjust names, groups, and scopes, but keep the intent.

2.1 Policy 0: Break-Glass Exclusions (Do This First)

Before any enforcement, create two cloud-only break-glass accounts with:

  • Global Administrator + Privileged Authentication Administrator
  • No Conditional Access, no MFA, extremely long passphrases
  • Stored in an offline password vault with clear access rules

Then define a filter group or direct exclusion to keep them out of every Conditional Access policy:

Monitor their usage with an alert rule in Entra ID or your SIEM: if they’re used, something’s already on fire.

2.2 Policy 1: Block Legacy Authentication Everywhere

Legacy protocols are still a top entry point in 2026 when someone enables POP/IMAP for “that one scanner”. Kill it globally, then carve explicit exceptions if you really must.

  • Assignments → Users: All users (exclude break-glass)
  • Cloud apps: All cloud apps
  • Conditions → Client apps: Select Other clients and legacy protocols only
  • Grant: Block access

In PowerShell (Entra ID preview module style):

Connect-Entra

$users = @{ "includeUsers" = @("All"); "excludeUsers" = @("[email protected]","[email protected]") }
$clientApps = @{ "includeClientApplications" = @("other") }
$grantControls = @{ "operator" = "OR"; "builtInControls" = @("block") }

New-EntraConditionalAccessPolicy `
  -DisplayName "CA01 - Block Legacy Auth" `
  -State "enabled" `
  -Conditions @{ users = $users; clientAppTypes = @("other") } `
  -GrantControls $grantControls

2.3 Policy 2: Require MFA for All Cloud Access (With Gradual Scope)

This is your workhorse policy. Don’t try to be clever initially, just make sure everyone hitting Microsoft 365 and Entra ID does so with MFA.

  • Assignments → Users: Start with a pilot group (e.g. GRP_CA_Pilot), expand to All users when ready
  • Cloud apps: Select All cloud apps
  • Conditions: No filters yet, keep it simple
  • Grant: Require multifactor authentication

Turn this on in Report-only mode first. After a week, check:

  • Sign-in logs → filter on the policy → see who would have been blocked
  • Identify service accounts / unattended processes still using user creds

2.4 Policy 3: Block High-Risk Sign-ins Automatically

If you have Microsoft Entra ID P2, you’re paying for risk-based access. Use it.

  • Assignments → Users: All users (exclude break-glass)
  • Cloud apps: All cloud apps
  • Conditions → Sign-in risk: High
  • Grant: Block access

This policy is your airbag. It catches things like impossible travel with token anomalies or confirmed leaked creds.

3. Device and Location Controls That Don’t Break Everything

This is where a lot of teams overreach and end up with chaos. The trick is to scope by data sensitivity and device reality, not by a theoretical Zero Trust diagram.

3.1 Require Compliant or Hybrid-Joined Devices for Admins

Admin sessions should never run from random BYOD laptops in 2026. Tie privileged roles to proper device posture.

Create a dynamic privileged group in Entra ID (or manage it in PIM):

New-EntraGroup `
  -DisplayName "GRP_Admins_CA_Scope" `
  -MailEnabled:$false `
  -SecurityEnabled:$true

Then Conditional Access policy:

  • Users: GRP_Admins_CA_Scope
  • Cloud apps: Microsoft Admin Portals (Entra ID, Exchange, Teams, SharePoint, Azure Portal)
  • Conditions → Device platforms: All supported
  • Grant: Require Compliant OR Hybrid Azure AD joined device + MFA

That way even if an admin’s non-corporate laptop is compromised, the attacker doesn’t get straight into your portals.

3.2 Restrict Sensitive Apps to Trusted Locations

For finance, HR, or regulated workloads, it’s still useful to say: “You can’t get to this from an internet café in another country.” But do it with precision.

  1. Define trusted locations in Entra ID:
    Entra admin center → Protection → Conditional Access → Named locations
    Add your office public IP ranges and major VPN egress points.
  2. Create a policy for sensitive apps:
  • Users: Finance / HR groups
  • Cloud apps: Specific SaaS apps and SharePoint sites hosting sensitive data (via app filters)
  • Conditions → Locations: Include All locations, exclude trusted locations
  • Grant: Block access

This doesn’t affect day-to-day Office usage, just the high-value crown jewels.

3.3 Handle BYOD without Stopping Work

Most orgs in 2026 are hybrid: mix of enrolled corporate devices and unmanaged BYOD mobiles/laptops. Don’t fight it; shape it.

Pattern that works well:

  • Corporate / compliant devices: Full access, including downloadable content
  • Unmanaged devices: Browser-only, limited download, or use MAM-WE (app protection without enrollment)

Example CA policy for unmanaged devices:

  • Users: All users
  • Cloud apps: Office 365 and SharePoint Online
  • Conditions → Device filter: Exclude devices where isCompliant -eq true OR deviceTrustType -in ["ServerAD","AzureAD"]
  • Session: Use Conditional Access App Control or "Use app enforced restrictions"

Result: From home PCs, users can still work via the browser, but bulk downloads or syncing entire libraries can be blocked or monitored.

4. Risk-Based and Sign-in Context: Where the Real Power Is

Static rules are blunt. In 2026, the value is in context-aware policies – risk, sign-in behavior, and device posture.

4.1 Azure AD / Entra Risk Levels that Actually Matter

If you have P2, design around three levers:

  • User risk – High: Force password reset before next sign-in
  • Sign-in risk – Medium/High: Require MFA, block if high + sensitive apps
  • Risky sign-ins & risky users reports: Feed into SOC workflows

Example: Policy – "CA-Risk-02: Medium Sign-in Risk Requires MFA"

  • Users: All users
  • Sign-in risk: Medium and above
  • Grant: Require MFA

This stacks on top of your base MFA policy, catching those edge cases where device or location is weird.

4.2 Token Theft and Session Protection

Token theft has been a key trend since 2024. By 2026, you should be using Continuous Access Evaluation (CAE) and Conditional Access session controls as standard.

Practical actions:

  • Ensure CAE is enabled for Microsoft 365 and other supported apps
  • Set sign-in frequency for admins (e.g. 4–8 hours) and regular staff (e.g. 12–24 hours)
  • Use persistent browser session carefully; avoid it for privileged roles

Example session settings for admins:

  • Sign-in frequency: 4 hours
  • Persistent browser session: Never persistent

This doesn’t eliminate token theft, but it shortens the window where a stolen token is useful.

5. How to Roll Out Conditional Access Without a User Revolt

Technically, you can flip all of this on in a day. Operationally, that’s how you end up on a war room call with the CIO. Rollout matters as much as design.

5.1 Always Use Report-Only First

Every new policy should live in Report-only mode for at least a week, ideally two, except emergency blocks.

During that time:

  • Use the What If tool on a few typical and edge-case accounts (external, VIP, service)
  • Check sign-in logs filtered by the policy name for unintended hits
  • Document known exceptions before go-live

5.2 Tag and Group Policies by Purpose

Once you hit 10–15 policies, chaos creeps in. Name them like you’ll live with them for years:

  • CA01 - Block Legacy Auth
  • CA10 - Baseline MFA - All Users
  • CA20 - Admin Portal - Compliant Devices Only
  • CA30 - HR Apps - Trusted Locations Only
  • CA40 - Risk - Block High Sign-in Risk

That way someone new to the team can read the list and understand your intent in five minutes.

5.3 Build Exception Workflows from Day One

There will be edge cases: legacy apps, field workers with patchy connectivity, third-party vendors.

Don’t hardcode user exceptions in policies. Instead:

  • Create azure-only security groups like GRP_CA_LegacyAuthException
  • Use them in policy exclusions
  • Wrap access to those groups in a documented approval workflow (ServiceNow, Jira, Power Apps + Power Automate)
  • Timebox membership where possible (e.g. PIM for groups or expiring access)

This avoids the slow creep of “just this one user” turning into 400 untracked exceptions.

6. One Concrete Next Step: Build and Test Your Baseline Set

If you do nothing else, implement and test this backbone of Conditional Access policies:

  1. CA01 – Block Legacy Authentication (enforced)
  2. CA10 – Require MFA for All Users (start report-only → enforce)
  3. CA20 – High-Risk Sign-ins Blocked (if you have P2)
  4. CA30 – Admin Portals on Compliant / Hybrid-Joined Devices Only
  5. CA40 – Sensitive Apps Restricted to Trusted Locations

Document them, run them in report-only, tune exceptions, then turn the key. Once these are stable, you can start layering in more advanced scenarios—like granular data controls with Purview and Defender for Cloud Apps—without standing on shaky ground.

If you want to sanity-check a design, take screenshots of your current CA policies and sign-in logs and review them as if you were an attacker. Anywhere you see a path to mail, SharePoint, or admin portals without MFA, device posture, or risk evaluation, that’s where to focus next.