Cloud Identity & Conditional Access in 2026: Practical Guardrails That Actually Work

[For IT Pros]

Most breaches I see in 2026 don’t start with a 0‑day. They start with a stolen token, an over‑permissive app, or a Conditional Access policy that someone meant to tidy up “later”. If you own Azure AD / Entra ID, you are the security perimeter now.

This guide is about building a cloud identity and Conditional Access setup that’s boring, predictable, and hard to mess up. Not perfect, not academic — something you can roll out in a real organisation with politics, legacy apps, and users who reuse their dog’s name.

1. Start With an Opinionated Identity Baseline

Before you touch Conditional Access, decide what “good” looks like for identity in your tenant. If you don’t, policies become one‑off exceptions instead of guardrails.

1.1. Core identity principles for 2026

• One person, one account: No shared cloud identities. Use PIM or access packages instead.
• Cloud is the authority: Entra ID (Azure AD) is the source of truth; sync from HR, not from random CSVs.
• MFA for everyone, phishing-resistant for admins: FIDO2 / passkeys or platform authenticators for high‑risk roles.
• Least privilege by design: No permanent Global Admins. Zero.

1.2. Concrete baseline tasks

• Clean up tenant admins:
  • Target list: Global Administrator, Privileged Role Administrator, Security Administrator, Exchange Administrator, SharePoint Administrator.
  • Limit each to 2–4 named people, all through PIM.
• Turn off legacy auth for all users and protocols unless explicitly justified.
• Standardise identities:
  • UserPrincipalName must match email (simplifies user support and sign‑in logs).
  • Use security groups for app access; stop assigning apps to individual users.

# List permanent directory roles with members
Connect-MgGraph -Scopes "Directory.Read.All","RoleManagement.Read.Directory"
Select-MgProfile -Name beta

Get-MgRoleManagementDirectoryRoleAssignmentScheduleInstance -All |
  Where-Object { $_.AssignmentType -eq "Assigned" } |
  Select-Object PrincipalId, RoleDefinitionId | Ft

Use this to spot who still has standing admin rights and move them to PIM.

2. Design Conditional Access Like an Architecture, Not a To-Do List

Most messy Conditional Access deployments grew organically from “we need MFA now”. In 2026, you need a simple, layered model you can explain to security, auditors, and your successor.

2.1. A practical CA policy framework

Think in layers:

• Foundation: Applies to everyone, all the time.
• Protection: Adds controls for higher‑risk conditions.
• Privileged: Extra walls around admin accounts and high‑value apps.
• Exception: Carefully documented, time‑bound gaps.

A minimal but strong set for most organisations:

• CA-001 – Block Legacy Authentication
• CA-010 – Require MFA for All Users
• CA-020 – Require Compliant or Entra-Hybrid Joined Device for M365
• CA-030 – High-Risk Sign-In: Require Password Change & Strong Auth
• CA-040 – Admin Roles: Require Phishing-Resistant MFA & Compliant Device
• CA-050 – External Users: Limit to Low-Risk Apps & Block Download

2.2. Implementing the core policies (Entra ID portal)

Policy: Block legacy authentication (CA-001)

• Assignments:
  • Users: All users
  • Cloud apps: All cloud apps
  • Conditions → Client apps: tick only Other clients and Legacy authentication clients
• Access controls: Grant → Block access
• Enable: Start in Report-only for 1–2 weeks, then enforce.

Policy: Require MFA for all users (CA-010)

• Assignments:
  • Users: All users (exclude break-glass & emergency accounts)
  • Cloud apps: All cloud apps
• Conditions:
  • Device platform: Any
  • Locations: Optionally exclude trusted named locations during migration only.
• Grant: Require Multi-factor authentication

2.3. Keep the CA surface area small

• Stay under ~25 active CA policies in mid-sized tenants; more than that is usually a design smell.
• Use named locations and security groups, not one‑off user exclusions.
• Prefix policies with numbers (CA-010, CA-020) so you can track them in documentation and scripts.

3. Strong Sign-In: From MFA Basics to Phishing-Resistant Auth

MFA fatigue attacks, token theft, and AiTM proxies are normal now. If your “MFA” is just SMS, assume it’s bypassable. For admins and high‑risk apps, move to phishing‑resistant methods.

3.1. Decide your MFA matrix by role

In Conditional Access, use Authentication strength instead of just “Require MFA”.

3.2. Admin protection policy (CA-040)

• Assignments:
  • Users: + Select → Directory roles → choose admin roles you care about.
  • Apps: All cloud apps.
• Conditions:
  • Locations: Exclude only trusted admin networks if you absolutely must.
• Access controls:
  • Grant: Require Authentication strength = Phishing-resistant MFA.
  • Require compliant device or hybrid joined device.

3.3. Registering and enforcing FIDO2 / passkeys

1. In the Entra ID portal, go to Security → Authentication methods → Policies.
2. Enable FIDO2 Security Key for your admin group(s) first.
3. Default key restrictions: allow only keys you support (e.g., YubiKey, Feitian) using AAGUIDs.
4. Communicate a simple rollout:
   • Week 1: Optional registration for admins.
   • Week 2: Enforce CA-040 in Report-only.
   • Week 3: Enforce CA-040.

4. Bring Devices and Apps Into the Identity Story

Conditional Access that ignores device state is only doing half the job. In 2026, device compliance and app context are first‑class signals. If the device is unknown or unhealthy, your policy should say “no” or “limited”.

4.1. Device-based access for Microsoft 365 (CA-020)

• Assignments:
  • Users: All internal users, exclude service accounts.
  • Cloud apps: Office 365, Exchange Online, SharePoint Online, Teams.
• Conditions:
  • Device platforms: Any.
• Grant:
  • Require Hybrid Azure AD joined or Compliant device.

Then in Intune / Endpoint Manager, define a minimal compliance baseline:

• OS supported & up to date (e.g. Windows 11 24H2+).
• Disk encryption (BitLocker / FileVault) required.
• Endpoint protection running (Defender / EDR agent).

4.2. Manage “BYOD reality” without giving up

• For personal devices, use app protection policies (MAM) instead of full device compliance.
• Create a CA policy for Browser / Mobile apps that:
  • Allows access only via approved client apps (e.g. Outlook, Teams, Edge with App Protection).
  • Blocks download of files to unmanaged devices; allow web-only.

4.3. High-value apps: extra walls

Finance, HR, source code, and admin portals deserve more protection than lunch menus.

• Tag apps as business critical in your CMDB / inventory.
• Create a CA-060 – High-Value Apps policy:
  • Apps: select those critical SaaS / custom apps.
  • Grant: Require strong auth + compliant device + sign-in risk < medium.
  • Session: Use Continuous Access Evaluation and sign-in frequency of 4–8 hours.

5. Governance: Keep It Auditable, Predictable, and Boring

A good cloud identity setup is one your auditor, CISO, and future you can understand in 30 minutes. That means naming, documentation, and automated checks.

5.1. Naming and documentation standards

• Policy naming: CA-0XX – Short description – Scope
  Example: CA-020 – Require Compliant/Hybrid Device – M365
• Group naming: GRP-CONDACC-Admins-PhishResistant, GRP-CONDACC-Bypass-Temporary
• Create a one‑page summary per policy:
  • Purpose
  • Scope (users, apps, locations)
  • Controls (grant/session)
  • Owner
  • Last reviewed / next review

5.2. Monitor and test continuously

• Use Sign-in logs → Insights & workbooks to watch:
  • Top CA policies by failure count.
  • Legacy auth attempts (they should trend to zero).
  • Risky sign-ins and unfamiliar sign-in properties.
• Set up scheduled reviews of:
  • Admin role assignments and PIM activations.
  • CA policies in Report-only (either delete, or ship them).
  • Exclusions and GRP-CONDACC-Bypass-* groups.

# Simple check for report-only policies and bypass groups
Connect-MgGraph -Scopes "Policy.Read.All","Group.Read.All"

$caPolicies = Invoke-MgGraphRequest -Method GET -Uri "/beta/identity/conditionalAccess/policies" | select -ExpandProperty value
$reportOnly = $caPolicies | Where-Object { $_.state -eq "reportOnly" }

Write-Host "Report-only policies:" -ForegroundColor Cyan
$reportOnly | Select-Object displayName, id | Ft

$bypassGroups = Get-MgGroup -Filter "startswith(displayName,'GRP-CONDACC-Bypass')" -All
Write-Host "Bypass groups:" -ForegroundColor Yellow
$bypassGroups | Select-Object DisplayName, Id | Ft

5.3. Break-glass: design it, then pretend it doesn’t exist

• Create two break-glass accounts:
  • UPNs like [email protected].
  • Cloud-only, no sync, long random passwords stored in an offline safe.
• Exclude them from all CA policies, but:
  • Apply alerting on sign-in (Log Analytics / Sentinel rule).
  • Test them monthly and log the test.

6. A 30-Day Action Plan You Can Actually Execute

To avoid boiling the ocean, here’s a pragmatic 30‑day plan.

Days 1–7: Discover and tidy

• Inventory all Conditional Access policies and admin roles.
• Document your existing auth methods usage (who’s still on SMS?).
• Create two break-glass accounts and test them.

Days 8–15: Baseline enforcement

• Implement CA-001 Block Legacy Auth and CA-010 MFA for All in Report-only.
• Enable modern auth methods: Authenticator app, FIDO2 for pilot users.
• Start cleaning permanent admin assignments; move to PIM where possible.

Days 16–23: Device and privileged hardening

• Define minimal compliance policies in Intune and assign to a pilot.
• Implement CA-020 Require Compliant/Hybrid Device for M365 for pilot groups.
• Deploy CA-040 Admin Protection in Report-only, begin FIDO2 rollout for admins.

Days 24–30: Turn the corner

• Move CA-001, CA-010, and CA-040 to On after validating logs.
• Expand CA-020 device requirements beyond pilot, with clear comms.
• Document the final CA framework and ownership, and book a quarterly review.

One Concrete Next Step

Today, before you get dragged into another meeting, log into the Entra ID portal and export your Conditional Access policies and admin roles. If you can’t explain in 10 minutes who can access what, from where, and how strongly they’re authenticated, you’ve just found your roadmap.

From there, pick the first three policies from this guide, run them in report‑only, and turn your identity layer from “best effort” into an intentional security boundary.