[For IT Pros]

Zero Trust stopped being a buzzword years ago. In 2026, regulators, cyber insurers, and your own leadership expect it. The challenge isn’t what Zero Trust is — it’s how to move from your current mess of legacy apps, hybrid identities, and half-documented firewalls to something structured and defensible.

This guide is for real-world environments: mixed Windows/macOS, Azure AD (Entra ID) plus some on‑prem AD, SaaS all over the place, and a security team that’s already overloaded. I’ll walk through how I’d implement Zero Trust step by step, with specific policies, example configs, and what to do first on Monday morning.

1. Start With a Minimum Viable Zero Trust (MVZT)

Don’t try to boil the ocean. Aim for a 90-day Minimum Viable Zero Trust that gives you meaningful protection and a story you can tell to auditors and leadership.

1.1 Define your Zero Trust MVP scope

Pick a scope that is high-risk but controllable:

  • Identities: All users in Entra ID (including guests).
  • Devices: Corporate Windows 11 and macOS devices enrolled in Intune.
  • Apps: M365, a few critical SaaS apps, and your VPN.
  • Data: M365 data (SharePoint, OneDrive, Teams) as a first target.

Write a one-page statement in plain English that you can show to management and auditors:

Zero Trust MVP (90 days):
- All access to M365 and key SaaS apps protected by Conditional Access.
- Only compliant or managed devices can access corporate data.
- High-risk sign-ins automatically challenged or blocked.
- Legacy protocols blocked for all users except a small, tracked exception list.

1.2 Map Zero Trust pillars to concrete controls

Use the classic pillars but tie them to real tech:

  • Identity: Entra ID, Conditional Access, PIM, identity protection.
  • Device: Intune compliance, Defender for Endpoint, macOS MDM baselines.
  • Network: VPN replacement (or hardening), app-based access, segmentation.
  • Applications: SSO everywhere possible, app protection policies.
  • Data: Sensitivity labels, DLP, restricted sharing.
  • Telemetry: Sentinel (or equivalent), Defender XDR, proper alert triage.

Your MVZT is simply: strong identity + strong device posture + context-aware access for your main apps.

2. Identity First: Conditional Access That Actually Works

If you try to do Zero Trust without strong identity, you’re just building fancy walls around a broken door. Start with Entra ID Conditional Access and protect everything people use daily.

2.1 Baseline Conditional Access policy set (2026-ready)

Here’s a typical production-ready baseline for most organisations >200 users. Adjust names, but keep the intent.

# Policy 1: Block legacy auth
Name: CA - Block legacy authentication
Assignments:
  Users: All users (exclude "Break-glass" accounts)
  Cloud apps: All cloud apps
  Conditions: Client apps - select "Other clients" and "Legacy authentication clients"
Access controls:
  Grant: Block access

# Policy 2: Require MFA for risky sign-ins
Name: CA - Require MFA for risky sign-ins
Assignments:
  Users: All users
  Conditions: Sign-in risk >= Medium
Access controls:
  Grant: Require multifactor authentication

# Policy 3: Require compliant or hybrid joined device for M365
Name: CA - Require compliant device for M365
Assignments:
  Users: All users (exclude break-glass + service accounts)
  Cloud apps: Office 365, Exchange Online, SharePoint Online, Teams
  Conditions: Device platform: Any device
Access controls:
  Grant: Require device to be marked as compliant OR hybrid Azure AD joined

# Policy 4: Block access from unsupported countries
Name: CA - Block high-risk geographies
Assignments:
  Users: All users
  Conditions: Locations - Include "Any location"; Exclude "Trusted locations" (office IPs, home country). Block specific regions.
Access controls:
  Grant: Block access

Deployment tip: Always deploy Conditional Access policies in report-only mode first, watch impact in the Entra sign-in logs for a week, then flip to “On”.

2.2 Protect admin accounts like they already got phished

Treat admin accounts as compromised by default. Fix it like this:

  • Create separate admin accounts (no email, no Teams, no OneDrive).
  • Use Privileged Identity Management (PIM) for all high-priv roles.
  • Force phishing-resistant MFA (FIDO2, Windows Hello for Business, or platform authenticators).
  • Restrict where admins can log in from (e.g., PAW devices or specific secured subnets).

Example admin-only Conditional Access policy:

Name: CA - Secure Admin Access
Users: All privileged roles (via Directory roles condition)
Cloud apps: All cloud apps
Conditions:
  Device platform: Any
  Locations: Include Any; Exclude "Admin PAW Subnet" named location
Controls:
  Grant: Require compliant device + Require phishing-resistant MFA
  Session: Sign-in frequency = 4 hours

3. Device Trust: Intune and Endpoint Security Baselines

In Zero Trust, the device is not automatically trusted just because it’s “corporate”. You trust it because it meets a set of measurable standards and stays compliant over time.

3.1 Define what a “trusted” device means for you

Write this down as a short list your team can understand. For example, for Windows 11 devices in 2026:

  • Enrolled in Intune (MDM) and present in Entra ID.
  • BitLocker enabled with recovery keys escrowed to Entra/Intune.
  • Defender for Endpoint active with real-time protection and EDR in block mode.
  • OS on latest feature release – 1 or 2 behind maximum, no more.
  • Disk encryption, firewall, and core isolation enabled.

Translate that into an Intune Device Compliance policy and a set of Endpoint Security baselines.

3.2 Sample Intune compliance policy (Windows 11)

Pseudo-config you can mirror in the Intune portal or via Graph:

Platform: Windows 10 and later
Settings:
- Require BitLocker: Yes
- Require secure boot to be enabled on the device: Yes
- Require code integrity: Enabled
- Require antivirus: Microsoft Defender Antivirus active
- Minimum OS version: 10.0.22631.0 (adjust for your org)
- Mark device noncompliant if there is no compliance data: After 30 days

Then link this to Conditional Access (as above) so devices that fall behind patching or lose Defender go non-compliant and lose access until fixed.

3.3 macOS and BYOD reality check

By 2026, you probably have a lot of macOS and employee-owned devices in the mix. Two practical patterns:

  • Corporate macOS: Full MDM via Intune, FileVault mandatory, Defender for Endpoint, compliance policy similar to Windows (but macOS-specific).
  • BYOD: Use App Protection Policies (MAM) for M365 apps; limit access to browser and app-only, no full device compliance required, but block download of company data to unmanaged storage.

Example policy choice: “Users on unmanaged devices can only access M365 via web, and cannot download or sync files to local storage; they can use Office mobile apps with App Protection enforcing PIN and no data export.”

4. Network & App Access: Move Away From “VPN = Trusted”

Zero Trust means your internal network is just another location, not a safe zone. The aim isn’t to kill VPN overnight, but to stop using it as a blanket trust decision.

4.1 Segment internal networks around apps, not floors

If your VLANs are named after physical floors or departments, you’re playing on hard mode. Move towards:

  • User VLANs: Office WiFi, wired users, guest.
  • App VLANs/segments: Shared services, line-of-business apps, databases.
  • Management networks: Infrastructure only: switches, firewalls, hypervisors.
  • OT/IoT segments: Printers, cameras, building systems, etc.

Use NAC (or at least DHCP reservations and ACLs) to control which devices can talk to what. Start small: isolate domain controllers and critical databases first.

4.2 App-based access and modern “VPN” patterns

Several real-world patterns work in 2026:

  • Reverse proxy / application gateway: Publish internal web apps via Azure Application Proxy or similar, protected by Conditional Access.
  • ZTNA client: ZTNA agents (GlobalProtect ZTNA, Prisma, Zscaler, Defender for Cloud Apps inline, etc.) that authenticate devices and users per app.
  • API-first access: For in-house apps, expose APIs via API gateways with OAuth2 / OpenID Connect, treat the API as an app in Entra.

Quick win: move your top 3 internal web apps off raw VPN and publish them via a reverse proxy integrated with Entra ID and Conditional Access. That alone usually kills a big chunk of lateral movement risk.

4.3 Example: Azure Application Proxy for a legacy intranet

  1. Install the Azure Application Proxy connector on a Windows Server in your DMZ (or anywhere that can reach the intranet URL).
  2. In Entra ID > Enterprise applications > New application > On-premises application.
  3. Set internal URL, external URL, and assign user groups.
  4. Enable “Pre-authentication: Azure Active Directory”.
  5. Apply a Conditional Access policy: require compliant device + MFA + block high-risk sign-ins.

Result: a legacy app now sits behind modern auth, Conditional Access, and no longer relies solely on VPN.

5. Data & Telemetry: See, Label, and React

Identity and device controls are only half the story. Zero Trust means assuming breach and having enough visibility and control to respond quickly.

5.1 Sensitivity labels as your data language

In M365 Purview, define 3–5 labels that humans can understand:

  • Public – okay to share outside.
  • Internal – default, no external sharing.
  • Confidential – limited sharing, encryption at rest, watermarks.
  • Restricted – strictest, only specific groups, strong controls.

Then tie DLP policies to these labels, not just to keywords. Example: “Confidential” documents cannot be shared with personal email domains and can’t be downloaded on unmanaged devices.

5.2 Minimum viable logging and detection

Zero Trust without logs is blind trust. You don’t need a full-blown SOC on day one, but you do need:

  • Entra ID sign-in & audit logs streamed to Sentinel (or your SIEM of choice).
  • Defender for Endpoint alerts integrated to the same SIEM.
  • M365 Defender alerts (Exchange, SharePoint, Teams) in one queue.

Start with a small set of high-signal detection rules:

  • Impossible travel or atypical travel with successful sign-in.
  • Mass download from SharePoint/OneDrive followed by external sharing.
  • New OAuth app consented with high privileges.
  • Multiple device non-compliance events for the same user in short time.

5.3 Simple incident response playbook

Write a 1–2 page playbook per common scenario. For example, “Suspicious user sign-in”:

  1. Review sign-in log: locations, device, risk level, sign-in pattern.
  2. Use Entra Identity Protection to confirm user risk score.
  3. Immediately require password reset and re-register MFA if risk is high.
  4. Set user risk to High and trigger automatic blocking policy until confirmed.
  5. Review recent activity: inbox rules, app consents, file sharing.

Attach these playbooks directly to Sentinel incidents or your ticketing system so they’re one click away when things go wrong.

6. Governance: Keep It From Turning Into a Spaghetti of Exceptions

Zero Trust often dies in the gap between good intentions and uncontrolled exceptions. You need lightweight governance that doesn’t smother delivery.

6.1 Create simple, opinionated standards

Three short documents are usually enough to start:

  • Identity & Access Standard – how accounts are created, MFA, PIM, Conditional Access baseline.
  • Device Standard – what “managed” means per platform, patching timelines, EDR requirements.
  • App Onboarding Checklist – every new SaaS or internal app must pass this before going live.

Example App Onboarding items:

  • Supports SSO via SAML/OIDC? If not, exception required.
  • Entra enterprise app created? Owner set? Lifecycle defined?
  • Data classification: what labels will be stored/used?
  • Conditional Access group or policy mapped?

6.2 Control exceptions like changes, not favours

Every exception (e.g., “allow POP for this scanning device”, “permit IMAP for this app”) should:

  • Be recorded in a ticket with business owner and end date.
  • Have a risk statement and a sign-off from someone accountable.
  • Be periodically reviewed (at least quarterly).

Automate reporting on these where possible (e.g., PowerShell scripts pulling Conditional Access exclusions, legacy auth allowed users, etc.).

7. A 90-Day Zero Trust Action Plan You Can Start This Week

To avoid analysis paralysis, here’s a concrete 90-day roadmap you can adapt.

Days 1–30: Foundations

  • Write and agree your Zero Trust MVP scope.
  • Deploy Conditional Access baseline in report-only.
  • Create and pilot Intune device compliance for Windows and macOS.
  • Turn on Entra ID Protection (even in evaluation if needed) and review risky sign-ins weekly.

Days 31–60: Enforce and Segment

  • Flip Conditional Access baseline from report-only to on (staged by group if needed).
  • Require MFA for all external access and all admins with phishing-resistant methods for high-priv.
  • Isolate domain controllers and core databases into separate network segments.
  • Publish at least one internal app via Azure Application Proxy or your chosen ZTNA.

Days 61–90: Data and Ops

  • Roll out basic sensitivity labels and DLP for M365.
  • Centralise logs from Entra, M365, and Defender to Sentinel or your SIEM.
  • Document 2–3 incident response playbooks and test them in a tabletop.
  • Publish your Identity & Device standards and add them to your change process and new project templates.

One Clear Next Step

This week, pick one area — identity, device, or app access — and write down exactly what “Zero Trust” means for that pillar in your environment, in one page or less. Then create a small, measurable change (like blocking legacy auth for 10 pilot users or enforcing a new Intune compliance rule on one device group) and ship it.

Zero Trust isn’t a project you finish; it’s a direction. The value comes from steady, concrete improvements that make it harder to get in, harder to move laterally, and easier for you to see and respond when something breaks.