[For IT Pros]

If you’re still talking about Zero Trust as a “project”, you’re already behind. In 2026 it’s the baseline expectation — from auditors, cyber insurance, and board-level risk committees. The problem is most organisations are stuck somewhere between PowerPoint diagrams and half-finished pilot policies.

This is a practical guide from someone who’s had to make this work in messy, hybrid, politically complex environments. No magic frameworks, just a clear path you can start using this week.

1. Start With What You Control: A Minimal, Realistic Zero Trust Core

Forget the vendor posters for a moment. In most Microsoft-centric environments, you can define a minimum Zero Trust core like this:

  • All identities protected with phishing-resistant MFA
  • All access evaluated continuously (Conditional Access, device posture, sign-in risk)
  • Devices are managed, compliant, and encrypted
  • Privileged access is just-in-time and isolated
  • SaaS and internal apps are published via an identity-aware access layer

Your job is to implement those pillars in small, defensible increments that don’t destroy user experience or operations.

1.1 Define your Zero Trust “MVP” in one page

Before you touch a portal, write a one-pager with:

  • Scope (Phase 1): Identities in Entra ID, M365 apps, corporate Windows/macOS devices
  • Non-goals (Phase 1): OT networks, legacy on-prem apps without modern auth, contractors on unmanaged devices
  • Measurable outcomes:
    • 100% of users on MFA by <date>
    • 90% of sign-ins evaluated by Conditional Access policies
    • 95% of corporate endpoints reporting compliant in Intune

This document becomes your shield when someone asks for “perfect” Zero Trust on day one.

2. Identity First: Entra ID, MFA, and Conditional Access That Won’t Blow Up Your Users

Identity is where you get the fastest risk reduction for the least infrastructure pain. In 2026, the combination of Entra ID P1/P2 + Conditional Access + Entra ID Protection is usually the backbone.

2.1 Clean up your identity landscape before enforcing anything

Do these basics first:

  • Identify stale accounts (no sign-in > 90 days). Export with:
Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes "AuditLog.Read.All","Directory.Read.All"

$threshold = (Get-Date).AddDays(-90)
Get-MgAuditLogSignIn -All | \
  Group-Object UserId | \
  ForEach-Object {
    $_.Group | Sort-Object CreatedDateTime -Descending | Select-Object -First 1
  } | Where-Object { $_.CreatedDateTime -lt $threshold } | \
  Select-Object UserDisplayName, UserPrincipalName, CreatedDateTime
  • Service accounts: Tag them (onPremisesExtensionAttributes or Entra ID directory extensions), catalogue owners, and migration plans.
  • Guest accounts: Find old B2B guests with:
Get-MgUser -Filter "userType eq 'Guest'" -All | \
  Select-Object DisplayName, UserPrincipalName, CreatedDateTime

For many orgs, 30–40% of accounts are unnecessary risk. Remove or disable before enforcing stricter policies.

2.2 Phishing-resistant MFA where possible, modern MFA everywhere else

In 2026, aim for:

  • FIDO2 security keys or platform authenticators for admins and high-risk users
  • Entra ID multi-factor with push number matching for everyone else

Create a basic MFA enforcement policy (pilot first):

  1. Create a test security group, e.g. CA-ZT-Pilot-Users.
  2. In Entra admin center > Protection > Conditional Access:
  • Assignments → Users: Include CA-ZT-Pilot-Users
  • Cloud apps: Select “All cloud apps” (for the pilot, that’s fine)
  • Conditions → Locations: Exclude trusted locations (office egress IPs) during test if needed
  • Grant: Require multi-factor authentication
  • Enable policy: Report-only for 1–2 weeks, then On

Tip: Always run policies in Report-only first and watch sign-in logs for breakage before enforcing.

2.3 Baseline Conditional Access pattern for 2026

Once the pilot is stable, build towards this pattern:

  • Block legacy auth globally (Exchange Online, SMTP AUTH, POP/IMAP unless explicitly required)
  • Require MFA for all users except break-glass accounts
  • Require compliant or hybrid-joined device for high-value apps (admin portals, finance apps, HR)
  • Block access from high-risk sign-ins using Entra ID Protection risk signals
  • Restrict privileged roles to privileged workstations only

Use Named Locations, User Risk, and Sign-in Risk to tighten gradually instead of flipping a single “paranoid” switch overnight.

3. Devices: Turning Intune Into an Actual Trust Signal, Not a Checkbox

The Zero Trust line of “never trust, always verify” only works if your device posture data is honest. In 2026, that usually means Intune (Endpoint Management) + Defender for Endpoint + compliance policies that reflect your real standards.

3.1 Build meaningful compliance, not “device is enrolled” nonsense

Define at least these compliance policies per platform:

  • Windows 11
    • Disk encryption with BitLocker required
    • Secure boot enabled
    • Minimum OS version (align with your patch cadence)
    • Defender for Endpoint active and healthy
  • macOS
    • FileVault enabled
    • Minimum macOS version
    • EDR sensor installed and reporting
  • Mobile (iOS/Android)
    • Device not jailbroken/rooted
    • Screen lock required
    • Minimum OS version

Then use Conditional Access to require compliant device for any app dealing with company data at rest (SharePoint, OneDrive, Teams, key SaaS apps).

3.2 Practical rollout sequence that won’t cause a revolt

Roll in this order:

  1. Visibility phase: Enrol existing devices into Intune / MDE, but don’t enforce compliance. Use reports to understand how far you are from your ideal state.
  2. Soft enforcement: Mark non-compliant devices but only warn users via email/Teams and IT dashboards.
  3. Hard enforcement: For a defined app set (e.g. Exchange, SharePoint), block non-compliant devices after <date> with plenty of comms.

Create a simple PowerShell/Graph script to monitor compliance drift daily and send to your team channel:

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

$devices = Get-MgDeviceManagementManagedDevice -All
$summary = $devices | Group-Object complianceState | \
  Select-Object Name, @{n='Count'; e={ $_.Count }}

$summary | Format-Table

4. Privileged Access: Just-in-Time, Not Just-in-Case

Most “Zero Trust” programmes fail quietly because admin accounts remain over-privileged and always-on. Entra Privileged Identity Management (PIM) is now mature enough that there’s no excuse not to use it.

4.1 Basic PIM pattern to implement in every tenant

For critical roles (Global Admin, Privileged Role Admin, Security Admin, Exchange Admin, etc.):

  • Make them eligible, not permanently active
  • Require MFA at activation
  • Set max duration (e.g. 2–4 hours)
  • Require justification text for activations
  • Optionally require approval for the highest-risk roles

Also, ban shared admin accounts by policy. If your MSP insists on a shared GA, that’s a conversation, not a configuration issue.

4.2 Use privileged access workstations (PAWs) without going full sci-fi

You don’t need a separate physical laptop for every admin. A pragmatic 2026 approach:

  • Define a PAW device group in Intune with stricter policies (no local admin, hardened browser, limited app set).
  • Use Conditional Access to only allow PIM role activation from devices in that group.
  • Consider Cloud PCs (Windows 365) as PAWs for small admin teams or MSPs.

This gives you a strong story for auditors: privileged work happens in a constrained, monitored environment.

5. App Access: From “Flat” Access to Context-Aware Controls

Zero Trust access to apps means who you are, what you’re using, where you are, and how risky things look all influence the decision.

5.1 Categorise apps by blast radius, then protect accordingly

List your apps and tag them:

  • Tier 0: Identity, directory, PKI, domain controllers, core security tooling
  • Tier 1: Email, collaboration, ERP, finance, HR systems
  • Tier 2: Departmental apps, line-of-business tools

Now apply a simple policy stack:

  • Tier 0: Only from PAWs, PIM, compliant devices, no external locations
  • Tier 1: Require MFA + compliant device, restrict download on unmanaged devices using M365 app protection policies
  • Tier 2: MFA + basic device checks, maybe allow browser-only access for contractors

5.2 Use modern publishing for internal apps

For internal web apps still hiding behind VPNs:

  • Use Entra Application Proxy or equivalent to publish them externally with SSO and Conditional Access.
  • Wrap access in device and user risk conditions instead of a flat network tunnel.
  • Over time, retire VPN access for anything that can be fronted by identity-aware access.

The strategic goal: VPN becomes the exception, not the default.

6. Monitoring, Telemetry, and Proving You’re Not Just Doing Security Theatre

Zero Trust without evidence is just a nicer poster. You need telemetry to detect abuse and show progress to leadership.

6.1 Essential signals to wire up

Make sure these are flowing into a SIEM (Defender XDR, Sentinel, Splunk, etc.):

  • Entra ID sign-ins + audit logs
  • Conditional Access policy decisions
  • Defender for Endpoint alerts + device risk scores
  • Intune compliance state changes
  • PIM activations and role assignments

Define a small set of Zero Trust KPIs you track monthly, for example:

  • % of users with MFA enrolled
  • % of sign-ins evaluated by Conditional Access
  • % of devices compliant
  • Number of risky sign-ins blocked vs. allowed with remediation

6.2 Practical KQL examples you’ll actually use

Blocked sign-ins due to Conditional Access:

SigninLogs
| where ResultType != 0
| where ConditionalAccessStatus == "failure"
| summarize count() by ResultDescription, bin(TimeGenerated, 1d)
| order by TimeGenerated desc

High-risk sign-ins allowed (to tune risk policies):

SigninLogs
| where RiskDetail == "ai_detected_risk" or RiskLevelDuringSignIn in ("high","medium")
| where ResultType == 0
| project TimeGenerated, UserPrincipalName, AppDisplayName, RiskLevelDuringSignIn, IPAddress
| order by TimeGenerated desc

Devices dropping out of compliance:

IntuneDevices
| where isnotempty(Compliant)
| summarize dcount(DeviceId) by Compliant, bin(TimeGenerated, 1d)

7. A Concrete 90-Day Zero Trust Action Plan

If you do nothing else, use this as your 90-day roadmap.

Days 1–30: Foundations and visibility

  • Produce your 1-page Zero Trust MVP scope.
  • Inventory identities, stale accounts, service accounts, and guest users.
  • Onboard endpoints to Intune and Defender for Endpoint (visibility only).
  • Implement MFA pilot via Conditional Access in report-only mode.
  • Enable logging to your SIEM for Entra ID, Intune, and Defender.

Days 31–60: Enforce core controls in low-risk slices

  • Enforce MFA for pilot users, expand to all staff except break-glass accounts.
  • Block legacy authentication for everyone except explicitly documented exceptions.
  • Create and apply meaningful device compliance policies in report-only, then enforce for IT and security teams first.
  • Enable PIM for a subset of admin roles and switch those admins off permanent assignment.

Days 61–90: Extend & prove value

  • Require compliant devices for access to M365 and high-value SaaS apps for all employees.
  • Start publishing 1–2 internal web apps via Entra Application Proxy to reduce VPN dependency.
  • Implement PAW pattern (physical or Cloud PC) for Tier 0 admins.
  • Build a simple Zero Trust KPI dashboard and share monthly with leadership.

The One Next Step: Pick One Pillar and Move It Forward This Week

Zero Trust fails when you try to boil the ocean. It works when you pick a pillar, define a narrow outcome, and actually ship it.

This week, choose one of these and schedule it: enforce MFA for a pilot group, enable PIM for a single admin role, or turn on a real Intune compliance policy in report-only. Once that’s live, build from there — one practical, defensible step at a time.