Zero Trust in the Real World: A Practical Playbook for 2026 IT Teams

[For IT Pros]

Zero Trust in 2026 is no longer a buzzword you drop in steering meetings. It’s how you stop AI‑powered phishing, token theft, and lateral movement across a very messy mix of SaaS, on‑prem, and multiple clouds. This guide is the version I wish I’d had years ago: opinionated, implementation‑focused, and realistic about legacy and politics.

I’ll walk through how to move from “we should do Zero Trust” to a concrete, staged rollout you can actually ship: identity, endpoints, and access first, then network and data. You can start most of this with what you already own in Microsoft 365, Azure AD (Entra ID), Intune, and your existing firewall stack.

1. Start with a Zero Trust Baseline You Can Actually Explain

If you can’t explain Zero Trust to your CIO in one slide, you’ll never get the time or support to implement it. Here’s a simple working definition that maps to real controls:

  • Never trust by default: Every user, device, and session is treated as untrusted until verified.
  • Continuously verify: Identity, device health, location, risk, and behavior are evaluated all the time, not just at login.
  • Least privilege everywhere: Users and services only get just‑enough access, for just‑enough time.

From that, you can derive a minimal scope for phase 1:

  • All external access to corporate apps is behind SSO + Conditional Access.
  • All corporate devices are enrolled, compliant, and encrypted.
  • High‑risk actions (admin changes, finance systems) require step‑up auth and approvals.

Write this as a one‑page Zero Trust Charter and get sign‑off from security, infra, and at least one business sponsor. This becomes your north star when you’re negotiating exceptions later.

2. Identity First: Strong Auth, Strong Governance, No Exceptions

2.1 Enforce phishing‑resistant MFA for everyone

By 2026, SMS/voice MFA is basically an incident waiting to happen. Prioritise FIDO2, Passkeys, and platform authenticators.

Priority order:

  • Admins and privileged accounts
  • Remote workers and third parties
  • Everyone else

Example Entra ID Conditional Access policy (conceptual):

  • Assignments: All cloud apps; Include all users; Exclude break-glass accounts
  • Conditions: Sign-in risk >= Medium OR Location = Outside Trusted
  • Access controls: Grant access > Require authentication strength = “Phishing-resistant MFA”

Use authentication strengths in Entra ID rather than a generic “require MFA” so you can differentiate between legacy TOTP and FIDO2/passkeys.

2.2 Clean up the identity blast radius

Zero Trust falls over if you have god‑mode accounts and zombie access everywhere. Focus on three quick wins:

  • Kill standing Global Admins: Move to Privileged Identity Management (PIM) with just‑in‑time elevation and approval workflows.
  • Standardise group‑based access: RBAC via security groups/Entra roles, not individual assignments.
  • Close stale entry points: Review enterprise apps and service principals; remove unused apps and legacy auth flows.

Example: Enforcing PIM for Global Admins via Entra ID (high level):

  • Enable PIM for Azure AD roles.
  • Set Global Administrator as Eligible, not Active.
  • Require: justification, MFA, and approval from security for activation, with a max duration of 2 hours.

3. Device & Endpoint: You Can’t Trust What You Don’t Manage

3.1 Define “trusted device” in technical terms

Marketing loves the phrase “trusted device”. Make it concrete and machine‑checkable. For example, in Intune:

  • OS = Windows 11 Enterprise / macOS 14+ / iOS 17+ / Android 15+
  • Disk encryption enabled (BitLocker/FileVault)
  • Defender or approved EDR healthy and active
  • No high‑severity vulnerabilities in the last scan

Turn that into a Device Compliance Policy per platform in Intune, then use Conditional Access to restrict sensitive apps to compliant or hybrid‑joined devices only.

Example CA logic (pseudocode):

IF app IN {Exchange Online, SharePoint, FinanceApp, AdminPortal}
AND user NOT IN {BreakGlass}
THEN require device to be:
    - marked compliant OR
    - hybrid Azure AD joined
ELSE block

3.2 Block or cage unmanaged devices

You won’t get to 100% managed devices overnight, especially for contractors and BYOD. For those cases:

  • Use app protection policies for mobile (no local save, no copy/paste to personal apps).
  • Force browser access through a secured, isolated browser or M365 Defender’s web isolation for unmanaged endpoints.
  • Block client apps like Outlook desktop for unmanaged devices; allow only web with limited session controls.

That gives you a pragmatic spectrum instead of a binary yes/no: fully trusted, semi‑trusted (isolated), and blocked.

4. Access Decisions: Conditional Access as Your Policy Engine

4.1 Replace legacy “inside/outside” with signals

Firewalls and VPNs alone don’t cut it; modern attacks ride SSO and OAuth. Your default should be: all apps behind SSO, all access policy‑driven.

In Entra ID Conditional Access, think in layers:

  • User & role: Who are they? Do they hold a privileged role?
  • Device & compliance: Is this a managed, compliant device?
  • Location & network: Known corporate egress, country, TOR/VPN detection.
  • Risk & behavior: Entra ID risk signals, impossible travel, sign‑in anomalies.

Use these to define 3–4 reusable “access patterns” instead of one‑off policies per app.

4.2 Example: Three reusable Conditional Access patterns

Pattern 1: Standard productivity apps (Teams, Exchange, SharePoint)

  • Require MFA if risk >= Medium or outside trusted locations.
  • Allow from unmanaged devices, but enforce session controls (limited download, no sync).

Pattern 2: Sensitive line‑of‑business apps (Finance, HR, R&D)

  • Require compliant or hybrid‑joined device.
  • Block access from high‑risk sign‑ins outright.
  • Require phishing‑resistant MFA on every new device or every 24 hours.

Pattern 3: Admin and security portals (Azure, Entra ID, Defender, security tooling)

  • Access only from admin workstations or PAWs (Privileged Access Workstations).
  • Session time‑boxed (e.g., token lifetime controls, sign‑in frequency set to 8 hours or less).
  • Mandatory PIM elevation; no direct standing assignment.

Document these as standard patterns and align new app onboardings to them instead of reinventing policy every time.

5. Network & Micro‑Segmentation: Contain the Blast Radius

5.1 Stop treating the internal network as safe

Zero Trust doesn’t mean throwing your firewall away, it means stop trusting everything behind it. Move towards:

  • Micro‑segments/VLANs per function: User, server, OT/IoT, management, guest.
  • Default‑deny between segments: Only open the specific ports/services required.
  • User‑to‑app access: Prefer app‑level gateways (App Proxy, reverse proxies, ZTNA) over full network tunnels.

Example: Simple on‑prem segmentation model

  • VLAN 10 – User Workstations
  • VLAN 20 – Application Servers
  • VLAN 30 – Database Servers
  • VLAN 40 – Management/Backup
  • VLAN 50 – IoT/Building Systems
  • VLAN 60 – Guest Wi‑Fi (Internet only)

On the core firewall, implement rules that, for example, only allow:

  • VLAN 10 → VLAN 20: app‑specific ports
  • VLAN 20 → VLAN 30: DB ports from app servers only
  • VLAN 10 → VLAN 30: blocked
  • VLAN 50 → internal networks: blocked (allow only outbound to specific cloud endpoints)

5.2 Extend Zero Trust to hybrid and multi‑cloud

Many orgs now have workloads in Azure, AWS, and maybe GCP, plus SaaS. Don’t try to build one giant flat WAN around all of it. Instead:

  • Expose internal apps via app proxies or ZTNA rather than site‑to‑site VPNs to everyone.
  • Use identity‑aware access for admin (Azure Bastion, AWS Systems Manager, just‑in‑time jump hosts).
  • Standardise on a single identity plane (Entra ID as primary) wherever possible.

6. Data & SaaS: Classify, Protect, and Monitor

6.1 Make data classification actually usable

Classification that nobody uses is useless. Create 3–4 labels in Purview or your chosen DLP platform that map to real business impact:

  • Public
  • Internal
  • Confidential
  • Restricted (regulatory/secret)

Then attach automatic protections to the top two levels:

  • Restricted: encryption, no external sharing, watermarking, strict DLP.
  • Confidential: conditional external sharing (whitelisted domains, approval), soft DLP with user justification.

6.2 Bring shadow SaaS under control

By 2026, almost every team uses AI‑SaaS tools that can leak data quickly. Use your CASB/SSE (Defender for Cloud Apps, Netskope, Zscaler, etc.) to:

  • Discover SaaS usage from proxy and endpoint telemetry.
  • Block or coach on “high‑risk” AI tools and file‑sharing apps.
  • Enforce session controls (no download, no copy/paste) for sensitive labels when accessed via the browser.

Start with a read‑only discovery phase for 30 days, then present a list of top apps and associated risks to the business to agree on sanctioned vs unsanctioned services.

7. Implementation Strategy: 90‑Day, 6‑Month, 12‑Month Plan

7.1 First 90 days: Lay the foundations

  • Publish your 1‑page Zero Trust Charter.
  • Turn on sign‑in and risk‑based policies in Entra ID in report‑only mode.
  • Roll out phishing‑resistant MFA to all admins and high‑risk roles.
  • Define Intune compliance policies and pilot on one business unit.
  • Create your three standard Conditional Access patterns and pilot on test users.

7.2 By 6 months: Critical coverage

  • Move CA policies out of report‑only for all users.
  • Onboard top 10 SaaS and internal apps to SSO and CA patterns.
  • Segment at least your DCs, databases, and IoT into separate VLANs.
  • Enable PIM for all privileged roles and Azure subscriptions.
  • Deploy basic DLP and 3–4 Purview labels with enforcement for email and SharePoint.

7.3 By 12 months: Maturity and tuning

  • Extend device compliance & app protection to all corporate devices.
  • Implement PAWs for admins and require them via Conditional Access.
  • Tune risk‑based policies based on real incidents and telemetry.
  • Integrate Zero Trust signals into your SIEM/SOAR for automated response (e.g., disable account, block device, revoke tokens).

8. One Concrete Next Step: Map What You Have Against Five Questions

Before you draft another strategy slide, open a spreadsheet and map your current state against these five questions for your top 10 apps:

  1. Identity: Is access going through SSO with Conditional Access?
  2. Device: Can we distinguish between compliant and unmanaged devices?
  3. Access: Do we enforce MFA and step‑up for risky actions and admins?
  4. Network: If this app is compromised, how far can the attacker move laterally?
  5. Data: Is the data classified and protected if it leaves the app?

The gaps you find there are your Zero Trust backlog. Prioritise the apps with the worst answers and the biggest business impact, then plug them into the 90‑day/6‑month plan above. That’s how you turn Zero Trust from a concept into working guardrails your organisation can feel.