Zero Trust in the Real World: How to Roll It Out Without Breaking Everything

[For IT Pros]

Zero Trust has been on every slide deck since 2020, but in 2026 most organisations are still somewhere between "we turned on a few policies" and "nobody can work remotely without swearing." This guide is the practical middle ground: how to implement Zero Trust in a way that actually improves security and keeps people productive.

I’ll walk through a realistic rollout using Microsoft 365 / Azure AD (now Entra ID), with patterns you can adapt to other stacks. The aim: concrete steps, example policies, and what to watch out for if you don’t want a 2 a.m. outage because of an over‑enthusiastic conditional access rule.

Zero Trust, Without the Marketing: What It Really Means in 2026

Ignore the buzzwords. In practice, Zero Trust in 2026 boils down to five habits:

  • Never trust a connection just because it’s "inside" the network — every access is evaluated, every time.
  • Explicitly verify user, device, and context — identity, health, location, and risk signals.
  • Least privilege everywhere — people and apps get the minimum they need, just in time, not forever.
  • Assume breach — design so that a single compromised account or device doesn’t spread like wildfire.
  • Continuous monitoring and policy tuning — this is not a one‑and‑done project.

The good news: if you’re on Microsoft 365 E3/E5 or Business Premium, you already own 70% of the tech you need (Entra ID Conditional Access, Defender, Intune, Privileged Identity Management). The challenge is turning features into a coherent strategy.

Step 1: Establish a Simple Zero Trust Baseline

1.1 Define Your First Guardrails (Don’t Start With Everything)

Before you touch a portal, write down a minimal baseline you can communicate to the business. For example:

  • All external access requires MFA.
  • Only compliant or managed devices can access corporate data.
  • Admins use just‑in‑time roles and separate admin accounts.
  • High‑risk sign‑ins are blocked or require step‑up verification.

Translate that into four pillars for phase 1:

  • Strong auth: modern auth + MFA everywhere it makes sense.
  • Device trust: Intune or equivalent to differentiate trusted from unknown devices.
  • Access policies: a small number of Conditional Access policies.
  • Privileged access: PIM and admin segmentation.

1.2 Inventory: Know What You’re Protecting

Run a quick inventory so you don’t accidentally lock out critical stuff:

  • Apps: In Entra admin center > Applications > Enterprise applications, export a list of apps with SSO / SAML / OAuth.
  • Protocols: Identify legacy auth usage (IMAP/POP/SMTP basic, older Office clients) via sign‑in logs or the Sign-in reports workbook.
  • Admin roles: List who has Global Admin and other high‑impact roles. Expect this to be worse than you think.
  • Devices: Count Entra joined, hybrid joined, and unmanaged devices hitting M365.

This doesn’t need to be perfect. You just need enough to avoid killing an old line‑of‑business app or shared mailbox scanner during rollout.

Step 2: Identity & MFA – Your First Real Win

2.1 Standardise Authentication Methods

By 2026, SMS MFA should be your absolute last resort. Move users to phishing‑resistant methods:

  • Microsoft Authenticator with number matching
  • FIDO2 security keys for admins and high‑risk roles
  • Platform authenticators (Windows Hello, Passkeys on mobile)

In Entra admin center:

  • Go to Protection > Authentication methods.
  • Disable phone call and SMS for most users; keep them only for break‑glass scenarios.
  • Enable Authenticator app, FIDO2, and Windows Hello for Business.

2.2 Baseline Conditional Access for MFA

Create a small set of policies instead of dozens of overlapping rules.

Policy 1 – Require MFA for all cloud apps (with safe exclusions)

  • Assignments > Users: All users excluding break‑glass accounts and maybe one emergency group.
  • Cloud apps: All cloud apps.
  • Conditions:
    • Locations: Exclude trusted locations if your business insists, but plan to remove this later.
    • Client apps: Include browser + modern clients; consider excluding legacy for now but flag as tech debt.
  • Access controls: Grant access > Require multi-factor authentication.
  • Enable: Start in Report-only for at least 1–2 weeks.

Use the Sign-in logs > Conditional Access tab to see what would break. Fix pain points (service accounts, scanners, automation accounts) before enforcing.

2.3 Kill Legacy Authentication in a Controlled Way

Legacy auth is still one of the top ways accounts get popped. To phase it out:

  1. In Entra admin center, under Protection > Legacy authentication, review the dashboard and export who still uses it.
  2. Create a Conditional Access policy:
    • Users: All users
    • Client apps: Only legacy authentication clients
    • Grant: Block access
    • Mode: Report-only for a week
  3. Work with app owners to upgrade or replace legacy dependencies (e.g., MAPI over HTTP, modern SMTP with OAuth).
  4. Switch the policy from report-only to On, ideally by department or region.

Step 3: Device Trust – Stop Treating Every Laptop as Equal

3.1 Establish Device Compliance in Intune

Your Zero Trust story collapses if you can’t distinguish a managed, encrypted device from a random home PC. In Intune:

  • Create compliance policies per platform (Windows, macOS, iOS/Android).
  • At minimum, enforce:
    • Disk encryption (BitLocker/FileVault)
    • OS version ≥ your support baseline
    • Secure boot / TPM where supported
    • Defender/AV enabled and up to date
    • Device lock + password/biometrics
  • Set Actions for noncompliance to allow a short grace period (e.g., 3 days) before marking the device noncompliant.

For Windows, a minimal compliance rule might look like:

// Example: Key requirements
- Require BitLocker = Yes
- Require Secure Boot = Yes
- Minimum OS version = 10.0.19045
- Microsoft Defender for Endpoint risk level <= Medium

3.2 Conditional Access: Only Compliant Devices Get Full Access

Policy 2 – Require compliant or hybrid joined devices for key apps

  • Users: Start with a pilot group (IT + a friendly business unit).
  • Cloud apps: Exchange Online, SharePoint, Teams, key line‑of‑business apps.
  • Conditions > Device platforms: Include Windows, macOS, iOS, Android.
  • Grant:
    • Require device to be marked as compliant OR
    • Require hybrid Azure AD joined device
  • Mode: Start in Report-only, monitor, then roll out by department.

Combine this with App Protection Policies on mobile so that corporate data stays inside managed apps (Outlook, Teams, Office) even on BYOD.

3.3 Use Defender Signals for Risk-Based Access

If you have Defender for Endpoint and Cloud Apps (Defender for Cloud Apps), feed risk into Conditional Access:

  • In Entra, go to Protection > Conditional Access > Named locations & Risk policies.
  • Enable user risk and sign‑in risk policies to:
    • Block access for high-risk sign‑ins
    • Require password change + MFA for high user risk

Example risk policy idea:

  • If Sign-in risk = High → Block access.
  • If User risk = Medium/High → Require password change and MFA.

Step 4: Privileged Access – Stop Letting Global Admins Live Forever

4.1 Separate Admin Identities

Zero Trust for admins is non‑negotiable. At minimum:

  • Give each admin a dedicated admin account (e.g., [email protected]).
  • Block those accounts from email and regular productivity apps.
  • Require phishing‑resistant MFA (FIDO2 or Windows Hello) for all privileged roles.

Enforce via Conditional Access:

  • Policy 3 – Require strong MFA + compliant device for admins
    • Users: All privileged roles (Global Admin, Security Admin, etc.) using role filters.
    • Grant: Require MFA + compliant device; block from untrusted locations.

4.2 Just-in-Time Access with PIM

Use Entra Privileged Identity Management (PIM) to remove standing access:

  1. In Entra admin center, go to Identity Governance > PIM.
  2. Convert permanent assignments to Eligible for all high‑impact roles.
  3. Require:
    • MFA on activation
    • Approval workflow for the most sensitive roles
    • Justifications and ticket references
  4. Enable alerts for:
    • Roles active 24/7
    • Too many role activations
    • Old unused assignments

This alone can massively reduce the blast radius of a compromised admin account.

Step 5: Data & Apps – Go Beyond “Can You Log In?”

5.1 Constrain Access by App Sensitivity

Not all apps are equal. Group them and apply different policies:

  • Tier 0: Identity and security admin portals (Entra, Defender, Azure portal).
  • Tier 1: Finance, HR, customer data, core line‑of‑business.
  • Tier 2: Low‑risk SaaS (training portals, surveys).

Apply stricter Conditional Access policies to Tier 0 and Tier 1:

  • Tier 0: Require compliant device, strong MFA, trusted network, and PIM activation.
  • Tier 1: Require compliant device + MFA; block from high‑risk countries.
  • Tier 2: MFA only; allow from more locations depending on business need.

5.2 Use App Protection and Session Controls

For browser access from non‑compliant devices, use Defender for Cloud Apps session controls:

  • Create a Conditional Access policy:
    • If device is not compliant, but user is allowed access…
    • Then use Conditional Access App ControlUse custom policy.
  • In Defender for Cloud Apps, configure a session policy to:
    • Block downloads for sensitive SharePoint sites.
    • Monitor or block uploads to unknown storage apps.
    • Mask sensitive fields in web apps.

This is how you balance flexibility (users can log in from home laptops) with control (data doesn’t leak to random devices).

5.3 Label and Protect the Data Itself

Zero Trust isn’t just about sessions; it’s also about the data. Use Purview sensitivity labels:

  • Create 3–5 clear labels: Public, Internal, Confidential, Restricted.
  • Attach policies:
    • Confidential: Encrypt, restrict sharing to internal + approved external domains.
    • Restricted: Encrypt, internal‑only, prevent printing/downloading where possible.
  • Enable auto‑labelling for obvious patterns (financial data, customer IDs, national IDs).

Even if accounts or sessions are compromised, encryption and usage rights slow attackers down and improve your incident response story.

Step 6: Operationalising Zero Trust – Don’t Fly Blind

6.1 Build a Simple Monitoring Routine

Zero Trust without monitoring is just chaos in a blazer. Set up a weekly or daily review:

  • Dashboards: Use Entra Workbooks for sign‑in risk, Conditional Access impact, and legacy auth attempts.
  • SIEM: Send critical logs to Sentinel or your SIEM: sign‑ins, Conditional Access, PIM events, risky users.
  • Alerts: Configure alerts for spikes in blocked sign‑ins, high‑risk users, and admin role activations.

Example KQL query in Sentinel to watch for blocked high‑risk sign‑ins:

SigninLogs
| where ResultType != 0
| where RiskLevelDuringSignIn == "high"
| summarize count() by UserPrincipalName, bin(TimeGenerated, 1h)
| order by TimeGenerated desc

6.2 Change Management and Communication

The biggest Zero Trust failures I see in 2026 are communication failures, not tech failures. Make it boringly clear:

  • Publish a Zero Trust playbook or FAQ on your intranet: what changes, why, and how to get help.
  • Use phased rollouts: IT → champions → departments → entire org.
  • Have a clear rollback plan for each major Conditional Access change.

If your helpdesk and business stakeholders understand the plan, the politics around "this is blocking my work" becomes much easier to manage.

Your Next Step: Ship a Real Zero Trust Change This Month

Zero Trust is not a single project; it’s a series of small, deliberate upgrades to how your organisation trusts users, devices, and apps. The worst thing you can do is leave it as a buzzword on your roadmap.

Pick one concrete action you can implement in the next 30 days:

  • Turn on a report‑only MFA Conditional Access policy and analyse the impact.
  • Roll out Intune compliance for a pilot group and tie it to app access.
  • Move your Global Admins to PIM just‑in‑time roles with strong MFA.

Ship one of these, learn from it, then move to the next. That’s how you go from slideware to a working Zero Trust implementation that actually protects your organisation without grinding it to a halt.