[For IT Pros]

If you’re managing identity in 2026, you’re juggling way more than usernames and passwords. You’ve got hybrid AD, contractors on BYOD, multiple SaaS apps, and security teams asking for “Zero Trust” while the business just wants things not to break.

This guide walks through practical cloud identity and Conditional Access (CA) patterns you can use today. No theory for its own sake — these are configurations and approaches I see working in real environments.

The 2026 Reality of Cloud Identity

Most organisations I work with now fall into one of three buckets:

  • Hybrid-joined everything: On-prem AD still exists, Entra ID (Azure AD) is the front door, and line-of-business apps are in weird places.
  • Cloud-first, not cloud-only: New apps in SaaS, legacy still on servers, identity is spread across Entra ID, a few vendor IdPs, and maybe some social logins for customer-facing portals.
  • M365-centric: Microsoft 365 is the backbone: mail, collaboration, devices, even telephony. Entra ID Conditional Access (CA) is the main policy engine.

The constant across all of them: Conditional Access is now your security perimeter. Firewalls still matter, but most attacks target identities and tokens first.

Pattern 1: Baseline Conditional Access for Any Org Size

If you inherit a messy tenant, or you’re starting to formalise security, this is the minimum CA baseline I recommend in 2026. The goal: strong protection, low user friction, and an easy escape hatch.

1.1. Protect Global and Privileged Admins First

Step one: stop admins from being the easiest target.

  • Create a dedicated “Break Glass” account:
    • Cloud-only, no MFA, long password (32+ chars), stored offline with dual control.
    • Exclude this account from all CA policies.
    • Add an alert rule for sign-ins from this account; it should be never used in normal ops.
  • Move all admins to PIM (Privileged Identity Management):
    • Assign permanent roles to Entra ID groups, not individuals.
    • Make those groups eligible, not active, via PIM.
    • Require justification and MFA to activate roles.
  • Create a strict CA policy for admins:
    • Assign to all admin roles (or an Admins group).
    • Require MFA on every admin sign-in (not just risky sign-ins).
    • Block legacy auth and require compliant or Entra-joined devices.

Example admin CA policy structure:

  • Assignments > Users: All users in “Privileged-Admins” group, exclude BreakGlass account.
  • Cloud apps: All cloud apps.
  • Conditions:
    • Client apps: Exclude legacy authentication (block separately).
    • Locations: No exclusions initially; tighten later if necessary.
  • Access controls > Grant: Require MFA + Require device to be marked as compliant.

1.2. MFA for Everyone, Without Destroying UX

By 2026, SMS MFA should be your absolute last resort. Push + phishing-resistant methods should be your default.

  • Enable modern auth only: Use security defaults or CA to fully block legacy auth.
  • Enforce MFA using CA, not legacy per-user MFA.
  • Strong methods first:
    • Entra ID passkeys (FIDO2/WebAuthn) where devices support it.
    • Microsoft Authenticator number matching + device binding.
    • Security keys (YubiKey, Feitian, etc.) for high-risk roles.

Typical CA policy for MFA for all users:

  • Assignments > Users: All users, exclude service accounts and BreakGlass.
  • Cloud apps: All cloud apps.
  • Conditions:
    • Sign-in risk: Low and above.
    • Device platform: All.
  • Access controls > Grant: Require MFA.

Combine this with Sign-in risk policies to challenge or block automatically when Entra ID marks a sign-in as medium or high risk.

Pattern 2: Location, Device, and Risk-Based Access

Static allow-lists of IPs and a single “require MFA” policy are no longer enough. You want policies that respond to the context of the user, device, and sign-in.

2.1. Split Policies by Sensitivity, Not Just App

Think in data sensitivity tiers instead of random app lists:

  • Tier 0: Identity admins, security admins, tenant-wide config.
  • Tier 1: Core business data: M365, ERP, CRM, finance systems.
  • Tier 2: Collaboration / low risk: intranet, HR portal, training tools.

Then design CA policies per tier:

  • Tier 0: Require compliant device, phishing-resistant MFA, no access from unknown countries, session limits, sign-in risk = block when high.
  • Tier 1: Require MFA when off corporate network or on unmanaged device; block legacy auth; sign-in risk = block high, require MFA for medium.
  • Tier 2: Allow browser-only access from unmanaged devices, with download restrictions via M365 session controls.

2.2. Device State: Compliant vs. Hybrid vs. Entra-Joined

By 2026, most orgs have a mix of:

  • Intune-managed devices (Windows, macOS, iOS, Android).
  • Non-managed but corporate-owned devices (e.g., some macOS fleets with JAMF, Linux workstations).
  • BYOD and contractor devices.

Use these to drive CA:

  • Require compliant device for higher tiers and admin roles.
  • Allow browser-only access from unmanaged/BYOD.
  • Use app protection policies on mobile devices, even if device is not fully enrolled.

Example CA policy for unmanaged devices:

  • Assignments: All users.
  • Cloud apps: Office 365, SharePoint, OneDrive.
  • Conditions > Device state: Exclude compliant devices.
  • Access controls > Session: Use Conditional Access App Control or “Use limited experience” to block downloads.

2.3. Named Locations and Country Controls

Location controls are easy to overdo and cause pain. Use them where they actually change risk:

  • Named locations:
    • Corporate ranges (including VPN IPs).
    • Trusted partner / outsourcer ranges (time-boxed if possible).
  • Countries/regions:
    • Block or strongly challenge sign-ins from regions where you never operate.
    • Use sign-in risk policies on top of country restrictions to avoid breaking travellers.

A lightweight pattern: no block by country for regular users, but block by country for admins and Tier 0 apps, except trusted countries/regions.

Pattern 3: Cloud Identity Architecture That Scales

Conditional Access is only as good as your identity architecture. If you’re still doing point-to-point SSO configs everywhere, you’ll hit a wall.

3.1. Use Entra ID as the Primary Identity Provider

Nearly every SaaS tool worth using in 2026 supports OpenID Connect or SAML. Your default stance should be:

  • All SaaS apps authenticate via Entra ID, not local accounts.
  • Use SCIM/Provisioning from Entra ID to push users and groups.
  • Use Entra ID groups for app assignment instead of app-native roles where possible.

This lets your CA policies automatically apply to new apps without new firewall rules or one-off configs.

3.2. Group Strategy: Dynamic, Role-Based, and Clean

Stop giving apps to individuals. Build a group strategy that mirrors business roles and device posture.

  • Dynamic user groups for job functions (e.g., Finance-Users, Sales-Field) using attributes like department, job title, or custom attributes.
  • Dynamic device groups for CA targeting (e.g., Windows-Corp-Managed, Mac-Engineering, BYOD-iOS).
  • App-specific access groups assigned from those role groups using access packages or manual mapping.

Example: Dynamic group for Finance in London

// Entra ID dynamic rule (GUI expression)
(user.department -eq "Finance") and (user.city -eq "London")

Use these groups in CA, PIM, and app assignments so a change in HR or attribute update automatically flows to access.

3.3. Hybrid Identity: What Still Makes Sense in 2026

Many orgs still run AD Connect or Cloud Sync. Key decisions:

  • Prefer Entra Cloud Sync over legacy AD Connect where possible for simpler, more resilient sync.
  • Avoid password hash sync plus PTA plus federation. Choose one mainstream auth strategy and simplify.
  • Minimise forest complexity: as you consolidate, rationalise UPNs and namespaces to reduce CA exceptions.

For new apps, don’t bind them to on-prem AD if you can help it. Use Entra ID for auth and keep CA in play.

Operationalising Conditional Access: Don’t Fly Blind

Most CA incidents I see are self-inflicted: someone flips a policy to “On” Friday afternoon and locks out a site or a whole region. Avoidable.

4.1. Policy Lifecycle: Report-Only, Then Gradual Enforce

  • Step 1 – Report-only: Create new policies in Report-only mode. Let them run at least 1–2 weeks.
  • Step 2 – Review logs:
    • Use Entra ID sign-in logs > Conditional Access tab.
    • Export to Log Analytics and build KQL queries to see what would have been blocked.
  • Step 3 – Target a pilot group: Switch to “On” for IT, security, and friendly users first.
  • Step 4 – Full rollout: Expand groups or move to “All users” once you’re comfortable.

Sample KQL to see impacted users for a report-only policy (Log Analytics):

SigninLogs
| where TimeGenerated > ago(7d)
| where ConditionalAccessStatus == "reportOnlySuccess"
   or ConditionalAccessStatus == "reportOnlyFailure"
| summarize count() by UserPrincipalName, ConditionalAccessPolicyName
| order by count_ desc

4.2. Document the Intent of Each Policy

A tenant with 40+ CA policies and no documentation is a nightmare. Adopt a simple naming and documentation pattern:

  • Policy name structure: [Scope] - [Control] - [Target]
    • Example: BASE - MFA Required - All Users
    • Example: TIER0 - Compliant + FIDO2 - Admin Roles
  • Record in your CMDB or a simple wiki:
    • What risk the policy addresses.
    • What groups/apps it affects.
    • Who approved it and when it was last reviewed.

4.3. Handle Break Glass and Emergency Changes Safely

When something breaks, people panic and start editing CA. Put guardrails in place:

  • Require change tickets for any CA policy modifications in production tenants.
  • Limit who can edit CA policies to a small, auditable group (via PIM).
  • Have a known, tested runbook for lockout scenarios, including using the Break Glass account to disable problematic policies.

Identity Protection and Step-Up Access

Conditional Access should work with Entra ID Protection, not instead of it. In 2026, risk signals from Entra, endpoint platforms, and even third-party EDR tools can feed access decisions.

5.1. Use Risk-Based Policies, Not Only Static Rules

At a minimum, enable and tune:

  • User risk policy:
    • Medium or High user risk → require password change + MFA.
    • High risk service accounts → often better to auto-disable and handle via IR playbook.
  • Sign-in risk policy:
    • High sign-in risk → block access.
    • Medium sign-in risk → require MFA, even if normally satisfied.

5.2. Step-Up for Sensitive Actions

Don’t just gate sign-in; gate actions. Many SaaS apps and custom apps now support step-up authentication via Entra ID.

  • Examples:
    • Accessing payroll data or exporting >1,000 records from CRM.
    • Changing security settings, email forwarding rules, or public sharing.
    • Approving high-value payments or vendor changes.

Implement this with separate app registrations or scopes that have stricter CA applied (e.g., require phishing-resistant MFA for the “payment-approval” scope).

What You Can Do This Week

If you’re reading this and thinking “OK, where do I start?”, here’s a concrete one-week plan:

  • Day 1–2:
    • Inventory existing CA policies and document intent, scope, and conflicts.
    • Create or validate a Break Glass account and alerting.
  • Day 3–4:
    • Enable admin-focused CA policies (MFA + compliant device) in report-only mode.
    • Move at least Global Admins and Security Admins into PIM.
  • Day 5:
    • Turn on sign-in risk policies at conservative levels.
    • Design your three-tier app sensitivity model and map key apps.

Once that’s done, you’ve got a solid footing. From there, you can iterate into device-based access, step-up policies, and deeper SaaS integrations — with far less chaos.