[For IT Pros]

Cloud identity is now the front door to everything: SaaS, internal apps, contractor access, even smart office gear. By 2026, a messy Conditional Access setup is one mis-click away from either locking out half your users or leaving a big gap for attackers.

Let’s walk through real, opinionated Conditional Access patterns for Entra ID (formerly Azure AD) that I’ve seen work in live environments. You can lift these ideas straight into your tenant, adapt the details, and improve security without triggering a user revolt.

1. Baseline Principles: Before You Touch a Single Policy

If your Conditional Access rules grew organically, you probably have policy sprawl. Before adding more, set some simple ground rules.

1.1 The guardrails every tenant should have

  • Absolutely no permanent exclusions for user accounts. If you must exclude, use a temporary break-glass process with expiry and logging.
  • Minimum 2 break-glass accounts: cloud-only, strong unique passwords, no MFA, stored offline, and restricted by location and sign-in risk policies.
  • One CA policy per purpose: don’t mix “block legacy auth” with “require compliant device for admins” in the same rule.
  • Use named locations for corporate egress IPs and sensitive countries. Don’t hard-code raw IPs inside 20 different policies.
  • Document policies as you go (who, what, why). A simple table in your runbook beats reverse-engineering later.

1.2 Suggested base policy structure

Start by planning policies in these buckets:

  • Global hygiene: legacy auth, MFA baseline, sign-in risk, user risk.
  • Role-based: admins, privileged roles, helpdesk, external admins.
  • Device-based: corp-managed vs BYOD vs unmanaged.
  • App-based: high-risk apps (finance/HR), privileged APIs, management portals.

Keep these groupings in mind as we go through patterns.

2. Global Hygiene Policies: Non‑Negotiables in 2026

These policies give you a secure minimum baseline. Roll them out carefully but don’t skip them.

2.1 Block legacy authentication everywhere

Legacy auth remains a top entry point in 2026 because some random device or app still uses it. Kill it with a single, clear policy.

  • Assignments → Users: All users + service accounts (include). Exclude only break-glass accounts.
  • Cloud apps: All cloud apps.
  • Conditions → Client apps: Include legacy authentication clients only.
  • Access controls: Block access.

Practical rollout tip:

  • Start in Report-only for 2–4 weeks.
  • Use the sign-in logs to find legacy usage.
  • Fix or replace those clients, then switch to On.

2.2 Require MFA for all, tuned for sanity

By 2026, SMS MFA is increasingly frowned on. Use strong authentication methods (Authenticator, FIDO2 keys, or device-bound passkeys) wherever possible.

  • Assignments → Users: All users. Exclude break-glass only.
  • Cloud apps: Office 365 + critical LOB apps at minimum; ideally all apps except low-risk public sites.
  • Conditions:
    • Sign-in risk: Any; (we’ll add extra behavior later).
    • Locations: Exclude trusted corporate locations only if you have strong device controls on-site. I generally don’t recommend this anymore.
  • Access controls → Grant: Require multifactor authentication.

UX trick: Use sign-in frequency and persistent browser session to reduce MFA prompts for low‑risk sessions:

  • Sign-in frequency: 14 days (for standard users).
  • Persistent browser session: Always persistent or only on compliant devices.

2.3 Risk-based controls (use what you’re paying for)

If you have Entra ID P2, use risk signals properly instead of endlessly layering policies.

Policy: High sign-in risk → MFA or block

  • Users: All.
  • Cloud apps: All.
  • Sign-in risk: High.
  • Grant: Require MFA + require compliant device or hybrid joined. For very high security, consider block for standard users and allow only for high-priv groups.

Policy: High user risk → force secure password reset

  • Users: All, except break-glass.
  • User risk: High.
  • Grant: Require password change + MFA.

3. Role‑Based Policies: Don’t Treat Admins Like Normal Users

Privileged accounts deserve harsher treatment. Your attacker only needs one global admin session to ruin your week.

3.1 Create clean admin groups

Create these Entra groups and use them across CA and PIM:

  • GRP-CLOUD-ADMINS – global admin, security, exchange, sharepoint, etc.
  • GRP-HELPDESK-ADMINS – helpdesk and 1st line.
  • GRP-EXT-ADMINS – external partner admins.

Assign roles via PIM, with eligibility in these groups only. Don’t assign roles directly to users.

3.2 Policy: Admins must be on secure devices, always

  • Users: GRP-CLOUD-ADMINS.
  • Cloud apps: All cloud apps.
  • Conditions:
    • Client apps: Browser + modern auth only (legacy already blocked globally).
  • Grant: Require MFA and require device to be marked compliant or require hybrid Entra join.
  • Session:
    • Sign-in frequency: 4 hours.
    • Persistent session: Disabled.

Goal: admin sessions should be short-lived and tied to healthy managed devices.

3.3 Policy: External admins locked to known locations and devices

For partner admins, you usually have less control over their devices. Reduce the blast radius.

  • Users: GRP-EXT-ADMINS.
  • Cloud apps: Azure Management, Microsoft 365 admin portals, Entra ID, any custom admin app.
  • Locations: Include all; exclude a named location with their office IP ranges if they have a known office.
  • Grant: Require MFA; require device to be marked compliant or app protection policy (if using MAM for them).

If you can’t enforce device compliance for partners, at minimum restrict them to browser-only and a very tight set of apps.

4. Device‑Aware Access: Managed vs BYOD vs Unmanaged

By 2026, most orgs are hybrid: some Intune-managed devices, some co-managed, plus a bunch of unmanaged/BYOD. Conditional Access is where you decide who gets what from where.

4.1 Classify your device states

At minimum, know which user groups should use:

  • Fully managed devices (Intune-compliant or hybrid joined) – internal staff, high‑risk roles.
  • App‑protected devices (MAM only) – BYOD mobile.
  • Unmanaged devices – browsers on random machines; should get limited access.

4.2 Policy pattern: Full access from compliant devices only

For core apps (Teams, OneDrive, SharePoint, core LOB), require compliant or hybrid joined devices for full-fat client access.

  • Users: Internal staff groups (exclude contractors and externals).
  • Cloud apps: Office 365 + key LOB apps.
  • Grant: Require device to be marked compliant or require hybrid joined device.

Pair this with an App enforced restrictions policy to give web-only, limited access from unmanaged devices.

4.3 Policy pattern: Limited, web-only access from unmanaged devices

This keeps users productive when they’re on a personal laptop but protects data.

  • Users: Same internal groups.
  • Cloud apps: SharePoint Online, OneDrive for Business, Exchange Online.
  • Conditions:
    • Device platform: All.
    • Filter for devices: Exclude compliant and hybrid joined devices (so this hits only unmanaged).
  • Access controls → Session: Use Use app enforced restrictions (SharePoint/Exchange limited experience: no download, no sync, no open in unmanaged apps).

In practice, this means: on personal laptops, users get browser‑only, view‑only for sensitive data.

4.4 Policy pattern: BYOD mobile with App Protection

For mobile BYOD, pair Conditional Access with Intune App Protection Policies.

  • Users: BYOD/Bulk staff, field workers, contractors.
  • Cloud apps: Office mobile apps, Outlook, Teams, OneDrive, and your mobile LOB apps.
  • Conditions:
    • Device platforms: iOS, Android.
  • Grant: Require approved client app and require app protection policy.

This forces corporate data into managed containers on personal phones, while letting you keep the device itself out of full MDM if that’s your policy.

5. App‑Specific Rules: Protecting the Crown Jewels

Not all apps are equal. Finance, HR, and core line‑of‑business portals usually deserve stricter conditions than basic productivity tools.

5.1 Identify your “tier‑0” and “tier‑1” apps

Create a simple classification:

  • Tier 0: Entra ID, Azure portal, security tools, identity providers, privileged access management.
  • Tier 1: Finance/ERP, HRIS, payroll, patient records, intellectual property systems.
  • Tier 2: Email, Teams, SharePoint (general), basic LOB apps.

Tier 0 and Tier 1 should never be wide open from unmanaged devices in random locations.

5.2 Policy: Tier 1 apps from trusted locations only (or locked down)

  • Users: Finance, HR, legal, R&D groups; admins with access to these apps.
  • Cloud apps: Your tagged Tier 1 apps (include enterprise apps and service principals).
  • Conditions:
    • Locations: Block unknown risky countries; optionally allow only your country/region and corporate offices.
    • Device filter: If possible, require compliant/hybrid joined device.
  • Grant: Require MFA and compliant/hybrid joined device.

For senior execs constantly traveling, you may need a parallel policy that allows secure access from known hotel chains/roaming IPs but with extra step‑up MFA or limited access.

5.3 Policy: Protect service principals and app-only access

By 2026, a lot of damage is done via compromised service principals or mis‑scoped app permissions. Use CA where supported:

  • Use workload identities Conditional Access for service principals where available.
  • Restrict sensitive APIs to managed identities running in approved environments (e.g. particular Azure subscriptions, resource groups, or IP ranges).
  • Log all app‑only consent and review quarterly.

Where CA cannot directly touch the app, wrap it behind a published application (e.g., Application Proxy or a modern reverse proxy) that is controlled by CA.

6. Governance: Keeping Conditional Access Sane Over Time

The best CA design will rot if nobody owns it. Treat Conditional Access as a living product, not a one‑time project.

6.1 Naming standards that save your future self

Use a consistent naming convention so people can see intent at a glance. One option:

CA-[Scope]-[Condition]-[Control]-[State]

Examples:
CA-ALL-BlockLegacyAuth-Block-ENABLED
CA-ADMINS-AllApps-RequireCompliantDevice-ENABLED
CA-BYOD-Mobile-RequireAppProtection-ENABLED
CA-TIER1-FinanceApps-ReqMFA-ReportOnly

Document this standard once and insist new policies follow it.

6.2 Change management pattern

  • Always create new policies in Report-only first.
  • Monitor impact via Sign-in logs → Insights and Conditional Access insights workbook.
  • For risky changes, stage rollout with an include group (pilot users) before flipping to “All users”.
  • Keep a rollback plan: which policy to disable if something breaks.

6.3 Don’t forget break‑glass accounts

Break-glass accounts are your last safety net when CA goes wrong.

  • Create at least two accounts: e.g. emergency-admin-01@, emergency-admin-02@.
  • Cloud-only, never synced. Long, random passwords stored offline (safe, sealed envelope, or enterprise password vault).
  • Exclude them from all CA except one policy: restrict to specific trusted locations.
  • Monitor sign-ins and alert on any use.

7. Quick Wins You Can Implement This Week

If you don’t have time for a full redesign, here’s a practical sequence you can run this week to materially improve your tenant:

  • Day 1: Create proper admin groups and move existing privileged accounts into them. Set up or review your break-glass accounts.
  • Day 2: Deploy Block legacy authentication in Report-only. Start reviewing activity. Implement basic MFA for all users if you haven’t, with sane sign-in frequency.
  • Day 3: Add an admin‑only CA policy requiring compliant/hybrid devices, short sign-in frequency, and no persistent sessions.
  • Day 4–5: Identify your Tier 1 apps and protect them with stricter conditions: MFA + compliant devices + location filtering.
  • Next week: Split internal users into managed vs BYOD vs unmanaged, and start applying the device-aware patterns for SharePoint, OneDrive, and Exchange.

One clear next step: open the Entra portal today, list your existing Conditional Access policies, and classify each into Global hygiene, Role-based, Device-based, or App-based. Anything that doesn’t clearly fit one of those buckets is a candidate to refactor or retire. Do that first, and every new policy you add will be clearer, safer, and easier to operate.