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

[For IT Pros]

Zero Trust went from buzzword to board-level mandate years ago. By 2026, most organisations claim they’re “doing Zero Trust” – but on the ground, it’s often just MFA and a few Conditional Access policies. The real work is making it strong enough to matter, but gentle enough that users don’t revolt.

This guide is how I’d approach a practical Zero Trust rollout as an IT lead: no grand frameworks, just concrete steps, example policies, and the order I’d tackle them in. You can start with what you have today (likely Microsoft 365 / Azure AD / Entra) and evolve without a big-bang project.

1. Get the Foundation Right: Identity is Your New Perimeter

1.1 Define what “trusted” actually means for your org

Zero Trust isn’t “trust nothing ever”; it’s “trust is earned, scoped, and re-verified”. You need a clear, written definition of what makes a sign-in or device acceptable risk for your environment.

At minimum, define these dimensions:

  • User type: employee, contractor, external partner, service account.
  • Device state: compliant corporate device, registered BYOD, unknown device.
  • Location: typical countries/regions, high-risk countries, TOR / anonymous.
  • Resource sensitivity: low, medium, high (e.g. mail vs. HR/payroll vs. admin consoles).

Pick a simple scale: Green / Amber / Red. If you can’t explain your model to your security lead in 3 minutes, it’s too complex.

1.2 Clean up the identity mess before locking doors

Zero Trust on top of a messy Entra ID (Azure AD) is like fitting new locks onto a broken door. Fix the basics first:

  • Disable legacy protocols (basic auth, IMAP, POP) for all but explicitly whitelisted service accounts.
  • Enforce security defaults or a baseline Conditional Access policy if you’ve outgrown defaults.
  • Audit and remove stale accounts (guest users, ex-contractors, test accounts that became production).
  • Move break-glass accounts off user email domains; use strong, hardware-key-protected cloud-only accounts.

A quick, practical step: run Microsoft’s Entra ID sign-in logs and filter for “Legacy authentication” over the last 30 days. If you still see a lot, your first Zero Trust milestone is to drive that to near-zero.

1.3 Baseline Conditional Access that actually helps

If you’re starting from scratch in 2026, here’s a simple but solid baseline set of Conditional Access policies (adjust names to your standards):

# Policy 1: Block legacy auth globally
Name: CA-001 Block Legacy Auth
Assignments: All users (exclude breakglass), All cloud apps
Conditions: Client apps = Legacy authentication clients
Access controls: Block

# Policy 2: Require MFA for all users
Name: CA-002 Require MFA All Users
Assignments: All users (exclude breakglass), All cloud apps
Conditions: None (or exclude known safe workload identities)
Access controls: Grant = Require multifactor authentication

# Policy 3: Require compliant device for admin roles
Name: CA-003 Admins Require Compliant Device + MFA
Assignments: Directory roles = Global admin, Security admin, etc.
Cloud apps: All cloud apps
Conditions: Device platform = Any
Access controls: Grant = Require device to be marked as compliant, Require MFA
Session: Sign-in frequency = 4 hours

Turn them on in Report-only mode first, watch impact for 1–2 weeks, then enforce. This avoids the classic “we just locked out a warehouse PC in another country” scenario.

2. Devices and Access: From “Can You Log In?” to “Should You?”

2.1 Intune (or equivalent) as the gatekeeper, not an afterthought

By 2026, Intune (Endpoint Manager) is mature enough that there’s no real excuse for unmanaged Windows/macOS endpoints in a Microsoft-centric shop. Zero Trust assumes you know the health of the device trying to access your data.

Core moves:

  • Enroll corporate Windows/macOS devices in Intune by default (standard Autopilot flows for Windows, ADE/DEP for macOS).
  • Use compliance policies as the actual security bar: PIN/biometric, disk encryption, OS version, AV/EDR running.
  • Connect Intune compliance to Conditional Access: only compliant devices can access sensitive apps.

Example Windows compliance policy baseline:

Name: CMP-WIN-Baseline-2026
- Require BitLocker = Yes
- Require Secure Boot = Yes
- Minimum OS version = 11.23.0 (your baseline)
- Antivirus = Required & Real-time protection on
- Firewall = Enabled for all profiles
- Jailbroken/rooted = Not applicable on Windows
- Mark device noncompliant after 7 days without check-in

2.2 Differentiating corp vs. BYOD without killing productivity

Blanket-blocking BYOD is usually not realistic. Instead, give BYOD a reduced trust lane with limited access and strong session controls.

Pattern I use a lot:

  • Corporate devices: full access to M365, line-of-business apps, and internal web apps; can download/sync data.
  • BYOD / unmanaged: browser-only access via Conditional Access session controls with download restrictions and watermarking.

Example CA policy for BYOD M365 web access:

Name: CA-010 M365 Web – BYOD Limited
Users: All employees
Cloud apps: Office 365, SharePoint, Exchange Online
Conditions:
  - Device state = Unmanaged or not compliant
Access controls:
  - Grant = Require MFA
Session controls:
  - Use Conditional Access App Control (Defender for Cloud Apps)
  - Block download of sensitive labeled docs
  - Apply watermark to web sessions

2.3 Admin access: treat it like production, not convenience

Admin accounts are where Zero Trust pays off fastest. If you do nothing else, implement tighter policies here.

Steps:

  • Create dedicated admin accounts (no email, no normal browsing) for privileged roles.
  • Introduce Privileged Access Workstations (PAW) – Intune-managed devices or hardened VDI for admin tasks.
  • Use Conditional Access to restrict admin-role sign-ins to PAWs only.

Example admin CA policy:

Name: CA-020 Admin Roles – PAW Only
Users: Directory roles in [Global Admin, Privileged Role Admin, Security Admin, Exchange Admin]
Cloud apps: All cloud apps
Conditions:
  - Device state = Require compliant
  - Locations = Named location 'Admin-PAW-Networks' only (optional)
Access controls:
  - Grant = Require compliant device, Require MFA, Require phishing-resistant auth (FIDO2 / Windows Hello)

3. Applications and Data: Reduce Implicit Trust, Not Productivity

3.1 Classify apps: not every app deserves the same trust

In many environments, every SaaS app is treated the same in SSO. Zero Trust means grouping and protecting by risk, not just convenience.

Create 3 tiers:

  • Tier 0 (Critical) – Identity provider, admin portals, HR/payroll, finance, security tools.
  • Tier 1 (Important) – Core business apps, CRM, ERP, major line-of-business systems.
  • Tier 2 (Routine) – Low-risk SaaS (training platforms, surveys, minor tools).

Enforce progressively stricter policies:

  • Tier 0 – strong auth (FIDO2/biometric), admin-only from PAWs, very short session times.
  • Tier 1 – MFA plus compliant device, moderate session length.
  • Tier 2 – MFA only, maybe allow more flexible device states.

3.2 Micro-segmenting access to internal apps (without boiling the ocean)

If you still have on-prem or IaaS workloads, Zero Trust means stopping the “flat network + VPN” pattern. Use modern access brokers instead of full-tunnel VPN as the default.

For Microsoft-heavy shops, that often means:

  • Publishing internal web apps via Entra Application Proxy or a modern ZTNA product.
  • Locking access behind identity-aware policies (user, device, risk, location).
  • Reserving traditional VPN for a shrinking set of edge use cases, with tight subnet ACLs.

Minimal first step: list every app that currently requires “full VPN” and mark which are just web apps. Those should move to identity-based publishing first; leave the weird legacy TCP apps for phase two.

3.3 Data-centric Zero Trust with sensitivity labels

By 2026, Purview sensitivity labels are stable enough that they should form the data layer of your Zero Trust approach. Instead of trusting location (SharePoint vs. local disk), trust classification.

Baseline you can implement this quarter:

  • Create 3–4 labels: Public, Internal, Confidential, Highly Confidential.
  • For “Confidential+”, enforce encryption + restricted sharing + download limits on unmanaged devices.
  • Add a simple auto-labeling rule (e.g., anything with NI numbers, credit card numbers → Confidential).

Then wire Conditional Access to respect those labels via session controls (block download for high labels on unmanaged/BYOD).

4. Risk, Signals, and Continuous Evaluation (What Makes it *Zero*)

4.1 Turn on risk-based controls (and tune them)

Static rules are fine, but Zero Trust really starts when signals from identity protection, endpoint, and SaaS risk feed into access decisions.

In a Microsoft stack, that means:

  • Enable Entra ID Protection (user risk, sign-in risk).
  • Connect your EDR (Defender for Endpoint, CrowdStrike, etc.) as a device compliance signal.
  • Use Defender for Cloud Apps for anomalous session and impossible travel detection.

Example risk-based CA policies:

Name: CA-030 High Sign-in Risk – Block
Users: All users
Conditions: Sign-in risk = High
Access controls: Block access

Name: CA-031 Medium Sign-in Risk – Step-Up MFA
Users: All users
Conditions: Sign-in risk = Medium
Access controls: Require MFA, Sign-in frequency = every sign-in

4.2 Session revocation and token lifetime

A lot of Zero Trust projects forget that long-lived sessions completely bypass the fancy access rules you just built. Review token lifetimes and session behaviour.

Practically:

  • Shorten sign-in frequency for high-risk apps (Tier 0) to a few hours.
  • Enable Continuous Access Evaluation (CAE) so risky events (password change, revoke, device non-compliant) cut tokens early.
  • Use revocation workflows in incident response runbooks (one click: revoke sessions for user/device + reset creds + disable refresh tokens).

Example: in an incident, your step 1 should not be “reset password”; it should be “revoke sessions + require re-auth with strong MFA”. Build this into your IR automation (Power Automate / Logic Apps) so the SOC can do it quickly.

4.3 Telemetry and a simple dashboard that leadership understands

Zero Trust is as much a communication exercise as a technical one. Non-technical leaders will ask: “Is it working?” You need 5–7 KPIs you can track and show.

Good candidates:

  • % of users with MFA enforced.
  • % of interactive sign-ins from compliant devices.
  • Number of successful legacy-auth sign-ins (target: 0).
  • Number of blocked high-risk sign-ins per month.
  • % of privileged roles using PAWs.
  • Share of data labeled Confidential+.

Build a simple Power BI / Defender / Entra workbook view and review it monthly. That keeps Zero Trust from becoming a one-off project that silently degrades.

5. Rollout Strategy: Order of Operations to Avoid Chaos

5.1 A realistic 6–12 month Zero Trust roadmap

Here’s how I’d structure a practical roadmap that fits around BAU:

Phase 0 – 2 weeks: Baseline and quick wins

  • Audit legacy auth; plan its removal.
  • Create break-glass accounts and verify they work.
  • Enable security defaults if you’re very small, or design baseline CA policies if you’re not.

Phase 1 – 2–3 months: Identity hardening

  • Roll out baseline CA (MFA for all, block legacy auth, admin CA).
  • Introduce risk-based policies in report-only and then enforce.
  • Clean up stale accounts and overly-permissive admin roles.

Phase 2 – 3–6 months: Device and BYOD model

  • Enroll corporate devices into Intune; define compliance baselines.
  • Enforce “compliant-only” access to Tier 0 and Tier 1 apps.
  • Implement BYOD web-only access with session controls.

Phase 3 – 6–12 months: Apps, data, and internal access

  • Classify apps by tier; apply differential CA policies.
  • Start publishing internal web apps via identity-aware proxies instead of VPN.
  • Roll out sensitivity labels with at least one auto-label rule.

5.2 Change management: communicating Zero Trust without scaring people

If users hear “Zero Trust” they often think “We don’t trust you”. Phrase it as protecting people and work, not policing them.

Tactics that help:

  • Announce changes before turning on strict policies, with clear dates and reasons.
  • Give simple “what you’ll notice” examples: extra MFA prompt on certain apps, a banner when using personal devices, etc.
  • Offer a short self-service guide for common issues: new device enrollment, lost phone with authenticator, switching from SMS to app or FIDO2 key.

You’ll get far less pushback if people feel like the project is for them, not just auditors.

One Concrete Next Step: Turn on Report-Only CA and See Your Real Risk

If you do just one thing after reading this, do this: create 2–3 report-only Conditional Access policies that reflect where you want to be – for example, “MFA for all users” and “Compliant device required for admin roles”.

Let them run for 1–2 weeks, then analyse the sign-in logs. You’ll see exactly who and what would break if you enforced Zero Trust rules today. That report becomes your negotiation card with the business and your realistic implementation plan.

From there, you can iterate safely: tighten, enforce, then move on to the next slice. Zero Trust becomes a series of small, controlled improvements – not a painful, one-time Big Bang.