[For IT Pros]

Most organisations I work with in 2026 will say, “We’re doing Zero Trust.” Then we open the tenant and find: flat networks, legacy VPN tunnels still wide open, and a single catch‑all Conditional Access rule.
You don’t need a perfect NIST diagram; you need a realistic, staged plan that works with the tools and people you already have.

This guide is a practical Zero Trust implementation roadmap you can start from tomorrow morning. It assumes you’re in a Microsoft-centric environment (Entra ID, Intune, Defender), but the mindset applies anywhere.

1. Start with a Simple Zero Trust Blueprint (Not a Big Bang)

Forget buzzwords for a moment. At its core, Zero Trust means:

  • Never trust by default – every access is evaluated in context.
  • Verify explicitly – user, device, location, risk, sensitivity.
  • Assume breach – limit blast radius; detect fast.

To keep this practical, break your implementation into four tracks:

  • Identity – authentication, MFA, Conditional Access, privileged access.
  • Device – compliance, health, patching, and registration.
  • Access – network segmentation, app publishing, and data boundaries.
  • Visibility & Response – logging, alerting, and playbooks.

Your first deliverable: a one‑page Zero Trust roadmap with milestones over 6–12 months. If it doesn’t fit on one page, it won’t land with leadership.

1.1. Define a Minimal Zero Trust Policy Statement

Write a short internal policy you can point to when people resist change:

Our organisation will:
- Require strong, phishing-resistant authentication for all users.
- Only allow access from healthy, managed, or explicitly approved devices.
- Restrict access based on user role, data sensitivity, and risk level.
- Log and review privileged activity and high-risk access.
- Regularly test and improve these controls.

Get this blessed by security governance or your CISO. This is your shield when you start tightening controls.

2. Identity First: Conditional Access and MFA That Actually Work

If you try to fix network and endpoints before identity, you’ll spend twice the effort. In 2026, Entra ID (Azure AD) + Conditional Access is the backbone of Zero Trust for most orgs.

2.1. Baseline Conditional Access Policy Set

Build a small set of layered policies instead of one monstrous rule. Example baseline (adjust names to your tenant):

Policy 1: Block legacy authentication
- Assignments: All users, all cloud apps
- Conditions: Client apps - Other clients (POP, IMAP, SMTP, legacy)
- Access: Block

Policy 2: Require MFA for risky sign-in
- Assignments: All users, all apps
- Conditions: User risk: Low+ OR Sign-in risk: Medium+
- Grant: Require MFA

Policy 3: Require compliant or approved device for admins
- Assignments: Privileged roles (Global Admin, Intune Admin, etc.)
- Conditions: All locations
- Grant: Require compliant device OR require approved app, and require MFA

Policy 4: Block access from high-risk countries
- Assignments: All users, all apps
- Conditions: Locations: Named location group "High-Risk Countries"
- Access: Block

Policy 5: Require MFA outside trusted locations
- Assignments: All users, key business apps
- Conditions: Exclude: Trusted locations (offices, fixed VPN egress)
- Grant: Require MFA

Create these in report-only mode first. Let them run for at least a week. Review the impact in the Entra sign-in logs before enforcing.

2.2. Phishing-Resistant Authentication Strategy

By 2026, if you’re still mainly on SMS or phone call MFA, you have a problem. Trend toward:

  • Passwordless with Microsoft Authenticator number matching & biometric.
  • FIDO2 security keys for admins and high-risk users.
  • Passkeys where your SaaS apps support them.

Example priority order:

  1. Mandate number matching and push notification context (already default for new tenants).
  2. Roll out FIDO2 keys to admins, finance, HR, and executives.
  3. Pilot passwordless sign-in for a willing department, then expand.

2.3. Privileged Access: No More Everyday Global Admins

Zero Trust without Privileged Access Management is half-done. Use Entra Privileged Identity Management (PIM) or an equivalent solution.

Baseline PIM configuration for 2026:

  • Convert all permanent high-privilege roles (Global Admin, Security Admin, Cloud App Admin, Intune Admin, etc.) to eligible.
  • Require MFA and justification on activation.
  • Limit activation duration (e.g., 1–4 hours).
  • Set alerts for unusual activations – out of hours, long duration, or rarely used roles.

If you can’t deploy PIM yet, at minimum enforce:

  • A dedicated admin account per admin, no mailbox.
  • Zero Global Admins used for day-to-day. Use specific roles instead.
  • Admin accounts restricted to compliant devices only.

3. Device Trust: Intune, Compliance, and Practical Baselines

Once identity is under control, move to device trust. The practical goal: critical apps and data should only be reachable from devices you trust or explicitly approve.

3.1. Define “Trusted Device” for Your Organisation

Agree internally on a clear definition for at least three categories:

  • Corporate device: Entra-joined or Hybrid-joined, Intune-managed, compliant.
  • Partner device: Not yours, but partially onboarded (e.g., Intune app protection, MAM, or third-party MDM signal).
  • Unmanaged device: Browser-only access with strict session controls, ideally to low-risk apps only.

Use this to drive Conditional Access decisions rather than arguing case-by-case.

3.2. Intune Compliance Policy Template (Windows 11/12)

For Windows fleets, a solid 2026 baseline compliance policy in Intune could include:

  • OS version >= latest – 1 (e.g., Windows 11 24H2 or later).
  • BitLocker enabled on system drive.
  • Secure Boot enabled.
  • Defender for Endpoint onboarded and healthy.
  • No high-severity security center alerts.
  • Defender AV enabled with real-time protection, cloud protection.

Combine this with Conditional Access:

Policy: Require compliant device for 365 core apps
- Users: All employees (exclude break-glass accounts)
- Apps: Office 365, Exchange Online, SharePoint, Teams
- Conditions: All cloud apps; device platforms: Windows, macOS
- Grant: Require device to be marked as compliant

Roll it out by department with staged enforcement. Use sign-in logs and Intune device reports to track who will be blocked before you flip the switch.

3.3. Mobile: App Protection Policies (MAM) for BYOD

Not every phone will be fully enrolled. App Protection Policies (MAM) give you a useful middle ground without a full MDM fight.

Core settings for M365 apps on BYOD (iOS/Android):

  • Require app PIN or biometric.
  • Block saving corporate data to personal storage (e.g., local device storage, personal OneDrive, Google Drive).
  • Encrypt app data at rest.
  • Prevent copy/paste from business apps to personal apps (or make it one-way only).
  • Wipe corporate data if the device is inactive or offline for X days.

Then add a Conditional Access rule: allow access from non-compliant devices only via approved apps. That keeps sensitive data in the container.

4. Network & App Access: Shrink the Attack Surface

Traditional VPNs with full-tunnel, flat access are still a huge risk. Modern Zero Trust prefers application-level access over full network access.

4.1. Segment the Network with Identity-Aware Rules

If you still have on-prem workloads, combine network segmentation with identity:

  • Use VLANs or microsegmentation (e.g., NSX, Azure Firewall, or NAC) to split out:
    • User segments (by department or risk).
    • Server segments (by application or data sensitivity).
    • Management segments (for admin tools and monitoring).
  • Restrict east-west traffic; default deny between segments unless explicitly required.
  • Use service accounts with tightly scoped permissions, never domain admin for services.

Where possible, front internal apps with reverse proxies or application gateways that terminate identity: Entra Application Proxy, Azure Front Door with Web Application Firewall, or a Zero Trust Network Access (ZTNA) product.

4.2. Replace or Contain Legacy VPN

Full VPN will survive longer than we like, but you can harden it:

  • Require MFA for all VPN logons; federate auth with Entra ID if possible.
  • Limit VPN access to specific internal resources rather than full LAN.
  • Use split-tunnel where possible to keep SaaS traffic out of the corporate network.
  • Tag VPN clients as a distinct location or device category and treat them as higher risk in Conditional Access.

In parallel, pilot a ZTNA solution (could be Microsoft Entra Private Access, Defender for Cloud Apps, or third-party) for a small internal web app. Prove the value, then grow.

4.3. Application-Level Policies (M365 and SaaS)

Use Defender for Cloud Apps or your CASB to add data-aware controls:

  • Block downloading sensitive SharePoint/OneDrive files to unmanaged devices.
  • Use session controls to restrict risky sessions (view-only mode for risky logins).
  • Set DLP policies for labels like “Confidential” or “Highly Confidential”.

If you’re not ready for full DLP, at least:

  • Label HR, Finance, and Legal data with a basic “Internal Only” label.
  • Restrict external sharing for sites with that label.

5. Visibility, Detection, and Playbooks: Assume Breach

Zero Trust doesn’t mean “we won’t be breached”; it means “when we are, we’ll catch it early and limit damage.” Logging and repeatable response are non-negotiable.

5.1. Logging Minimums for 2026

At a minimum, centralise into your SIEM (Defender XDR, Sentinel, or equivalent):

  • Entra ID sign-in and audit logs.
  • Defender for Endpoint alerts and device inventories.
  • Defender for Office 365 alerts (phishing, malware, BEC attempts).
  • Conditional Access insights and sign-in risk events.
  • Key firewall, VPN, and proxy logs.

Set retention in line with your regulatory requirements, but aim for at least 6–12 months for identity and endpoint logs.

5.2. Simple KQL Queries You Should Actually Use

In Microsoft Sentinel or Defender XDR, you don’t need fancy ML for the basics. A few bread‑and‑butter queries help you spot Zero Trust gaps.

1. MFA fatigue or push-bombing attempts:

SigninLogs
| where ResultType == 500121  // MFA denied or misconfigured
| summarize Attempts = count() by UserPrincipalName, bin(TimeGenerated, 1h)
| where Attempts > 10

2. Legacy auth still in use (after you thought you blocked it):

SigninLogs
| where ClientAppUsed in ("Other clients", "IMAP4", "POP3", "SMTP")
| summarize count() by UserPrincipalName, ClientAppUsed

3. Admin role activations outside business hours (if using PIM):

AuditLogs
| where Category == "RoleManagement"
| where OperationName startswith "Add member to role" or OperationName startswith "Activate role"
| extend Hour = datetime_part("hour", TimeGenerated)
| where Hour < 7 or Hour > 19
| project TimeGenerated, InitiatedBy, TargetResources

5.3. Minimum Incident Playbooks You Need

Document at least three short playbooks (one page each is fine):

  • Suspected account compromise – steps such as:
    • Force sign-out and revoke tokens.
    • Reset password, require MFA re-registration.
    • Review sign-in history and risky sessions.
    • Check forwarding rules and mailbox permissions.
  • Suspected device compromise – isolate device in Defender, collect timeline, re-image if needed, investigate lateral movement.
  • Data exfiltration – locate data, revoke shared links, invalidate sessions, brief legal/HR if personal data involved.

Automate what you can with Logic Apps, Power Automate, or XDR automation rules, but start with the manual checklist first.

6. Governance, Exceptions, and Getting People On Side

Most Zero Trust projects fail not on tech, but on people and process. You need a simple way to manage exceptions and communicate changes.

6.1. Exception Process That Doesn’t Become the Default

When someone says “we can’t work like this, turn it off,” your answer should be: “We’ll review an exception.” Make it structured:

  • Short form: who, what system, why they can’t meet the control.
  • Risk rating: low/medium/high, with sign-off level matching the risk.
  • Expiry date: exceptions auto-expire unless renewed.
  • Compensating controls: extra logging, restricted access, or temporary measures.

Track exceptions in a simple register (SharePoint list, Jira project, or your GRC tool). Report how many exist and how many closed each quarter.

6.2. Communicating Zero Trust Changes Without Drama

Before you enforce a new control, send a short, plain-language heads-up:

  • What’s changing – “From next Monday, you’ll be asked for an extra step when logging in from home.”
  • Why – “We’ve seen a rise in attacks that guess passwords and steal SMS codes.”
  • What you need to do – “Install the Microsoft Authenticator app and register it here.”
  • Where to get help – “Contact the Service Desk; this is a priority.”

Use champions in each department to pilot changes and give honest feedback before you go broad.

7. A Concrete 90-Day Zero Trust Action Plan

If you want something you can start this quarter, here’s a realistic plan I use with mid-sized organisations:

Days 1–30: Identity Foundations

  • Enable and tune Conditional Access baselines in report-only mode.
  • Block legacy authentication for a small pilot group, then expand.
  • Deploy number-matching MFA and start planning FIDO2 for admins.
  • Onboard admin roles into PIM or at least reduce permanent Global Admins.

Days 31–60: Device and Access Controls

  • Roll out Intune compliance policies for Windows/macOS.
  • Gate M365 core apps behind compliant devices for a pilot department.
  • Implement mobile App Protection Policies for BYOD with approved apps only.
  • Harden VPN: enforce MFA, narrow access, and log everything.

Days 61–90: Visibility and Hardening

  • Integrate Entra, Defender, and VPN logs into your SIEM.
  • Create three key KQL queries and at least two automated alerts.
  • Document the three core incident response playbooks.
  • Stand up a pilot Zero Trust access path for one internal web app (Entra App Proxy or ZTNA).

Your Next Step: Pick One Track and Move It Forward This Week

Don’t try to “do Zero Trust” as one giant project. Pick just one of these to move forward in the next seven days:

  • Turn on a Conditional Access policy in report-only mode and review its impact.
  • Convert one high-privilege role to PIM with just-in-time access.
  • Define your trusted device categories and draft the matching access rules.
  • Write a one-page playbook for suspected account compromise.

Zero Trust is less about a perfect architecture slide and more about consistently tightening the screws in the right places. Start small, ship something, and iterate.