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

[For IT Pros]

By 2026, most organisations are “cloud-first” on paper, but in reality you’ve got a messy mix of Azure AD (Entra ID), on-prem AD, legacy VPNs, random SaaS, and a security team asking why conditional access still isn’t “fully rolled out”.

This guide is the version I give to teams when we sit down and clean up their cloud identity and conditional access from the ground up. It’s opinionated, practical, and focused on policies you can actually deploy this month without breaking the business.

1. Start With an Opinionated Identity Baseline

Before you touch conditional access, decide what “good” looks like for identity in your org. Otherwise you’ll end up with a pile of exception rules and angry executives locked out of email.

1.1 Core identity principles for 2026

These are the non‑negotiables I recommend to most mid-size and enterprise environments:

  • Single source of truth: Entra ID is the primary identity plane for cloud apps. On-prem AD exists, but it’s not the long-term owner of identities.
  • Phish-resistant MFA by default: Security keys / Windows Hello for Business / platform FIDO2 where possible. App-based push as a fallback, but with strong controls.
  • No direct passwords for admins: All privileged roles go through PIM + just-in-time + MFA + device compliance checks.
  • External access is explicit: B2B/B2C with clear policies, not random guest accounts with full rights.

1.2 Baseline configuration checklist

Before you build policies, stabilise the basics:

  • Entra Connect / Cloud Sync: Ensure only the OUs you really need are synced. Stop syncing stale accounts and disabled users.
  • UPN alignment: Users’ UPNs should match primary email; fix legacy .local UPNs to avoid sign-in confusion and SaaS issues.
  • License mapping: Define a simple group-based licensing scheme (e.g. M365_E3, M365_E5_SecurityAddOn) and apply via dynamic groups or HR-driven provisioning.
  • Admin roles rationalised: Review who actually needs Global Admin. Any more than 4–6 in a large org is usually a smell.

1.3 Example: HR-driven provisioning with dynamic groups

If you’re using something like Workday / SAP SuccessFactors or an HR connector into Entra:

// Example dynamic group rule for "EMEA-Employees"
(user.department -contains "EMEA") -and (user.accountEnabled -eq true)

Map HR attributes to Entra attributes, then:

  • Assign licenses to role-based dynamic groups.
  • Target conditional access using those same groups.

This keeps CA policies aligned with actual HR data instead of one-off security groups someone created in 2019.

2. Build a Layered Conditional Access Strategy (Not a Policy Zoo)

Conditional Access in 2026 is powerful enough to secure you or lock out the entire business. The trick is to design in layers: who, what, where, how risky.

2.1 The 6 foundational policies every tenant should have

Start with a standardised set and adapt. For a typical mid-size tenant, I apply something like this:

  1. Global: Block legacy authentication
    Use sign-in logs to find remaining legacy dependencies first (scan for IMAP/POP/SMTP/older Office clients). Plan migration or carve out very narrow temporary exception groups.
    • Assignments: All users, all cloud apps.
    • Conditions: Client apps = Other clients (legacy protocols).
    • Grant: Block access.
  2. Global: Require MFA for all users (with exclusions)
    Deploy in Report-only first; watch sign-in logs for breakage (devices, scripts, old apps) then formally document any exceptions.
    • Assignments: All users, exclude break-glass accounts + specific service accounts.
    • Cloud apps: All cloud apps.
    • Conditions: None initially.
    • Grant: Require MFA.
  3. Admins: Require compliant device + MFA + PIM
    Pair this with Entra PIM policies that force MFA at activation and restrict activation time windows.
    • Assignments: Role-based security group containing all admin accounts.
    • Cloud apps: Microsoft Azure Management, Microsoft Graph, Office 365, and any privileged app.
    • Conditions: Device platform = all; sign-in risk >= medium = block if not compliant.
    • Grant: Require MFA + Require device to be marked compliant.
  4. Unmanaged devices: Restrict to web + limited actions
    This protects data when users insist on using BYOD laptops or random machines on the road.
    • Assignments: All users for productivity apps (Exchange, SharePoint, Teams).
    • Conditions: Device state = Not compliant / Not hybrid-joined.
    • Grant: Require Terms of Use + Restrict to web-only or use session controls (e.g. limited download in SharePoint).
  5. High-risk sign-ins: Force re-auth or block
    This catches token theft, impossible travel, and other anomalies without forcing friction on every low-risk sign-in.
    • Assignments: All users.
    • Conditions: Sign-in risk >= high (via Entra ID Protection).
    • Grant: Require password change + MFA or block completely for sensitive roles.
  6. External users: Separate policy set
    • Assignments: All guest and external users.
    • Cloud apps: SharePoint/Teams/any external-facing services.
    • Conditions: Countries, device state, or a specific partner group.
    • Grant: Require MFA (if not enforced by their home tenant) + restrict to web-only for highly sensitive resources.

2.2 Naming and documentation pattern

Don’t underestimate naming. Your future self will have to debug these at 2am during an incident.

// Suggested naming pattern
CA-ADM-Require-CA-Device-MFA
CA-GLB-Block-LegacyAuth
CA-EXT-Guest-MFA-WebOnly
CA-USR-Require-MFA-AllApps

Create a simple wiki page per policy group with:

  • Business goal
  • Scope (who/what/where)
  • Change history
  • Known exceptions and why they exist

2.3 Rolling out safely: use Report-only and staged groups

In 2026, the Report-only mode and simulation tools are finally good enough to use seriously:

  • Start with Report-only and analyse sign-in logs for a week.
  • Use a pilot group (IT + security + a few friendly power users).
  • Flip to On for the pilot before going tenant-wide.

Track metrics: percentage of sign-ins requiring MFA, number of legacy auth sign-ins over time, and failed sign-ins by policy.

3. Integrating Device Compliance, Apps and Network Signals

Cloud identity isn’t just usernames and passwords anymore. In 2026, the signal from devices, apps, and networks is critical to reduce prompts while still staying secure.

3.1 Device compliance as a core condition, not an afterthought

Intune (and third-party MDMs via integration) should be the system of record for device health.

  • Define OS baselines (e.g. Windows 11 24H2+, macOS 15+, Android 14+, iOS 18+).
  • Require disk encryption, secure boot, antivirus/EDR, and up-to-date patches.
  • Expose compliance to Entra and use Require device to be marked compliant in key CA policies.

For example, admins connecting to Azure Portal must be on an Intune-compliant device and pass MFA.

3.2 App-enforced restrictions and session controls

Use the Microsoft 365 app control and Conditional Access App Control (Defender for Cloud Apps) for granular data controls.

  • On unmanaged devices, allow web access to SharePoint but block download, sync, and print.
  • Enable sign-in frequency rules (e.g. re-auth every 12 hours for financial systems).
  • Use persistent browser sessions for low-risk apps to reduce MFA fatigure while still using device compliance and risk signals.

3.3 Network and location: still useful, but don’t over-trust

Location-based policies are less meaningful in 2026 with remote work everywhere, but they still help:

  • Tag your trusted corporate egress IPs in Entra.
  • For non-critical apps, relax MFA slightly when coming from trusted networks + compliant devices.
  • Avoid fully trusting any location for admin roles; still enforce MFA and device compliance.

For high-risk countries or TOR/VPN exit nodes, consider an explicit block policy or additional controls.

4. Handling Service Accounts, Legacy Apps, and Edge Cases

Most identity and CA deployments fail not at the design level, but in the messy details: service accounts, old apps, and third-party integrations.

4.1 Modernise service accounts where possible

General approach:

  • Prefer managed identities for Azure workloads.
  • Use workload identities and OAuth2/OIDC for SaaS/app integrations.
  • Only fall back to password-based accounts if absolutely necessary, and wrap them with process and monitoring.

For remaining password-based service accounts:

  • Put them in a dedicated Service-Accounts group.
  • Exclude only that group from specific CA policies where needed.
  • Rotate credentials with something like Azure Key Vault + automation (PowerShell / Logic Apps / n8n).

4.2 Example PowerShell to audit conditional access impact

Use the Microsoft Graph PowerShell SDK to understand what’s happening before and after changes.

Connect-MgGraph -Scopes "Policy.Read.All","AuditLog.Read.All" -NoWelcome

# List conditional access policies with state
Get-MgIdentityConditionalAccessPolicy | \
  Select-Object DisplayName,State,CreatedDateTime | \
  Sort-Object DisplayName

# Check failed sign-ins by conditional access policy
Get-MgAuditLogSignIn -Filter "status/errorCode ne 0" -Top 1000 | \
  Select-Object userDisplayName,appDisplayName,ipAddress,conditionalAccessStatus,status

Export sign-in logs regularly and feed them into your SIEM to track trends over time.

4.3 Document and time-box exceptions

Exception creep will quietly kill your identity strategy.

  • Every exception group must have: owner, business justification, expiry date.
  • Use access reviews in Entra to periodically validate exceptions and guest access.
  • Set calendar reminders or automated workflows to alert when exception groups are about to expire.

5. What You Can Do This Week

Don’t try to “fix identity” in one project. Move in small, high-impact steps and show progress.

  • Day 1–2: Review current conditional access policies. Rename and document them using a clear pattern. Identify any policies with overly broad exclusions (e.g. excluding “All users”).
  • Day 3: Turn on Report-only policies to (a) block legacy auth and (b) require MFA for all users. Analyse logs for apps and accounts that would break.
  • Day 4–5: Design and deploy a hardened admin-only policy set: compliant device + MFA + PIM. Start with a small pilot group of admins.
  • Next 2–4 weeks: Roll out unmanaged-device web-only access for M365, tighten high-risk sign-in policies, and start migrating service accounts to modern auth / managed identities.

If you do just those steps, you’ll go from “we have some policies somewhere” to a clear, auditable cloud identity posture that security, auditors, and users can live with. From there, iterating is easy; digging out of chaos later is not.