[For IT Pros]

I keep seeing the same pattern in 2026: leadership wants “Zero Trust everywhere”, vendors promise magic, and you’re left worrying about breaking Outlook, legacy apps, and the CEO’s iPad. This guide is the version I wish more teams had before they started clicking around in the portal.

We’ll keep it practical: what to protect first, how to phase it, example policies, and how to avoid the classic outages. Treat this as a field-tested rollout plan you can start using this week.

1. Start With a Clear Zero Trust Scope (Not Marketing Slides)

1.1 Translate Zero Trust Into Three Concrete Questions

Forget the buzzwords. For your environment, Zero Trust boils down to:

  • Who can access what?
  • From which devices/locations?
  • Under which conditions (risk, compliance, sign-in behaviour)?

Write one page that answers those three questions for: employees, privileged admins, external users, and high-risk apps (HR, finance, source code, admin portals).

1.2 Classify Apps Before You Touch Any Policies

Don’t start in the Conditional Access blade; start in Excel or a whiteboard.

  • Tier 0: Identity & control plane (AAD/Microsoft Entra ID, Azure portal, Intune, security portals, domain controllers, key vaults).
  • Tier 1: Business-critical apps (ERP, HR, payroll, CRM, core line-of-business, code repos, admin consoles for SaaS).
  • Tier 2: Productivity & low-risk apps (email, Teams, intranet, training, low-sensitivity SaaS).

This drives your rollout order and how strict you go. Tier 0 gets locked down first and hardest, but with a lot of testing.

2. Identity First: Conditional Access as Your Zero Trust Engine

2.1 Build a Baseline Policy Set (Tested in Report-Only)

In 2026, if your tenant doesn’t have a clean Conditional Access baseline, you’re already behind. Start with four core policies and run them in Report-only for 1–2 weeks before enforcing.

Baseline 1 – Block legacy authentication

  • Assignments: All users, all cloud apps.
  • Conditions: Client apps → select “Other clients” (legacy auth).
  • Access controls: Block access.
  • Mode: Report-only (for a week), then enforce.

Use the sign-in logs filter Client app = Other clients to find breakage candidates: old printers, scripts, legacy line-of-business apps.

Baseline 2 – Require MFA for risky sign-ins

  • Assignments: All users, all cloud apps (exclude break-glass accounts).
  • Conditions: User risk >= Medium or Sign-in risk >= Medium.
  • Access controls: Grant → Require multifactor authentication.

Baseline 3 – Require compliant or managed device for admin portals

  • Assignments: Role = administrative roles (or privileged groups).
  • Cloud apps: Azure management, Microsoft Entra admin center, Intune, security portals, privileged apps.
  • Grant: Require Hybrid joined or compliant device + MFA.

Baseline 4 – Block high-risk countries / impossible travel

  • Assignments: All users, all cloud apps (or at least Tier 0/1).
  • Conditions: Locations → Block “high-risk” regions you never operate from.
  • Grant: Block access (add explicit named locations for your offices and common travel countries).

2.2 Use Named Locations and Network Tags Properly

In 2026, relying solely on IP whitelisting is fragile, but named locations still help:

  • Define trusted corporate ranges for break-glass and service accounts.
  • Use GPS-based locations for mobile scenarios where appropriate.
  • Tag known VPN egress IPs as trusted to avoid confusing users on corporate VPN.

Combine this with “sign-in risk” instead of trying to predict every bad IP range yourself.

3. Device Trust: From ‘Any Device’ to Managed Endpoints

3.1 Phase 1 – Visibility: Get an Accurate Device Inventory

Before you enforce “compliant device only”, make sure you know what’s out there.

  • Ensure all corporate Windows/macOS/iOS/Android devices are onboarded to Intune.
  • Connect your EDR (Defender for Endpoint, CrowdStrike, etc.) to feed device risk signals into Conditional Access.
  • Clean up stale devices in Entra ID and Intune to avoid surprises.

Quick PowerShell snippet (using Microsoft Graph PowerShell) to list devices that haven’t checked in for 60+ days:

Connect-MgGraph -Scopes 'Device.Read.All'

$threshold = (Get-Date).AddDays(-60)

Get-MgDevice -All | Where-Object {
    $_.ApproximateLastSignInDateTime -lt $threshold
} | Select-Object DisplayName, Id, ApproximateLastSignInDateTime | \
    Export-Csv .\stale-devices.csv -NoTypeInformation

3.2 Phase 2 – Enforce Compliance on High-Value Apps First

Don’t flip “require compliant device” on all cloud apps overnight. Start with Tier 0/1 apps:

  • Create a Conditional Access policy targeting Tier 0 apps.
  • Grant: Require compliant device OR Hybrid joined device + MFA.
  • Run in Report-only for at least a week and monitor sign-in logs.

Once you’re comfortable, expand to Tier 1, then later to email and collaboration if your user base is ready.

3.3 Phase 3 – Make BYOD Not Horrible

People will use personal devices regardless. Zero Trust in 2026 means giving them a safe, limited way to do that.

  • Use App Protection Policies for Office mobile apps instead of forcing full device enrollment for all staff.
  • Expose sensitive apps only via VDI / AVD / published apps for contractors and high-risk BYOD users.
  • Use Conditional Access filters for devices to differentiate corporate devices vs personal.

4. Micro-Segmentation for Identities and Apps, Not Just Networks

4.1 Role-Based and Attribute-Based Access

Don’t keep adding people to giant “All Staff” access groups. Move toward role-/attribute-based access control:

  • Sync HR attributes (department, jobTitle, office, employmentType) into Entra ID.
  • Use dynamic groups in Entra ID: e.g. (user.department -eq "Finance").
  • Scope app access to these dynamic groups instead of static, manually maintained ones.

Example: Dynamic group for UK-based HR staff:

(user.department -eq "HR") -and (user.country -eq "GB")

4.2 Segment Admin Roles and Paths

Zero Trust means your admins are most locked down, not least.

  • Use PIM (Privileged Identity Management) for all high-privilege roles; no standing global admins.
  • Enforce separate admin accounts with stricter Conditional Access (no sign-ins from unmanaged devices, no legacy auth, stronger MFA).
  • Restrict Azure management and security portals to a small, controlled IP range or compliant devices only.

Example Conditional Access idea for admins:

  • Users: privileged admin roles only.
  • Apps: Azure management, Entra, Intune, Defender, M365 admin portals.
  • Conditions: Device = compliant or hybrid joined; Sign-in risk >= Low; Locations = named trusted locations.
  • Grant: Require MFA + device compliance + phishing-resistant credential (FIDO2 / Windows Hello for Business).

5. Don’t Break the Business: Safe Rollout Patterns

5.1 Always Use Exclusion Groups (But Protect Them)

For every major policy, create an exclusion group (e.g. CA-Exclusions-HighRiskApps) and:

  • Limit owners to senior IT only.
  • Require ticket/approval to add someone.
  • Audit membership changes (ideally via SIEM alerting).

This gives you a quick safety valve for execs, breakage cases, and critical third parties without completely disabling a policy.

5.2 Use Staged Rollouts: Pilots, High-Risk, Then Everyone

For each Zero Trust control (MFA, compliant devices, app protections):

  • Phase 1: IT + Security only.
  • Phase 2: High-risk groups (finance, HR, access to customer data, admins).
  • Phase 3: The rest of the org.

Communicate clearly: what’s changing, what users will see, and how to get help. Include screenshots and a short FAQ page for each rollout.

5.3 Monitor Like Crazy in the First 72 Hours

After enabling a new policy, live in the logs for a few days:

  • Entra ID sign-in logs: failures by app/user/location.
  • Conditional Access insights & reporting: impact of each policy.
  • Helpdesk ticket trends: spikes in MFA/device issues.

Have a pre-agreed rollback path: either switch to Report-only, temporarily expand exclusions, or narrow the app scope while you fix the issue.

6. Measuring If Your Zero Trust Strategy Is Actually Working

6.1 Practical Metrics to Track Monthly

Pick a handful of KPIs that show progress, not perfection:

  • MFA coverage: % of active accounts with strong MFA enabled (aim > 98%).
  • Legacy auth volume: should trend to near-zero.
  • Compliant devices: % of active devices that are compliant.
  • Risky sign-ins: count and resolution time.
  • Number of standing admin accounts: should be zero for high-privilege roles.

6.2 Build a Lightweight Zero Trust Scorecard

You don’t need a full GRC suite; a simple monthly scorecard that you share with leadership works:

  • Top 3 improvements this month (e.g. all finance apps now require compliant devices).
  • Top 3 remaining risks (e.g. legacy app still needs basic auth, certain partners on unmanaged devices).
  • Planned changes next month (e.g. enforcing MFA for all external users).

This keeps Zero Trust from being “an IT project” and turns it into an ongoing security posture conversation.

Next Step: Pick One High-Impact Change and Move It to Report-Only Today

Zero Trust is not something you “switch on”; it’s a series of controlled, reversible steps. The fastest way to start is to pick one concrete change and get visibility on it.

Today, go into Conditional Access and create one new policy in Report-only for a Tier 0 or Tier 1 app: for example, “require MFA and compliant device for all admins”. Watch the logs for a week. Once you’re comfortable, enforce it, then repeat for the next control. Step by step, you’ll get to a real, working Zero Trust posture without taking the business down.