[For IT Pros]

If your security strategy in 2026 still relies on “inside the network = trusted”, you’re one compromised account away from a mess. Zero Trust isn’t a product you can buy, and it’s definitely not a checkbox in a portal. It’s a set of decisions you apply across identity, devices, networks, and data.

This guide walks through a practical Zero Trust implementation using Microsoft 365, Azure AD (Entra ID), Intune, and modern network controls. It’s written for real IT teams with real legacy systems, not greenfield unicorns.

1. Start with a Simple, Opinionated Zero Trust Blueprint

Zero Trust = always verify, least privilege, assume breach. To make this implementable, define a basic blueprint you can explain in one slide to your CIO and in one page to your admins.

1.1 A Minimal Zero Trust Target State

  • Identity is the new perimeter: All access decisions pivot on Entra ID (Azure AD) with strong auth and conditional access.
  • Devices are health-gated: Only compliant, managed devices get full access to sensitive apps.
  • Apps live behind modern auth: No legacy anonymous access; everything speaks modern auth (OIDC/SAML/WS-Fed) or is published via a broker (App Proxy/ZTNA).
  • Networks are thin transit layers: No flat LANs with wide lateral movement; segment east-west traffic and treat on-prem like an untrusted zone.
  • Data has context: Labels, DLP and logging to XDR/SIEM so you know who touched what, from where, and on which device.

Document this as a one-page Zero Trust Reference Model and get agreement before you dive into config. This saves you from configuration whiplash later.

2. Identity First: Conditional Access as Your Gatekeeper

If you only have capacity to do one thing well in 2026, make it strong identity controls. Everything else multiplies the value of this layer.

2.1 Baseline Conditional Access Policy Set (2026-ready)

In Entra ID, aim for a clean, layered policy set. A practical starting point:

  • CA-001: Block Legacy Auth
    • Assignments: All users, all cloud apps
    • Conditions: Client apps = Other clients (legacy protocols)
    • Access: Block
  • CA-002: Require MFA for Admin Roles
    • Assignments: Directory roles = Privileged roles (Global Admin, Security Admin, etc.)
    • Conditions: Any location, any device
    • Access: Grant access with Require MFA
    • Session: Sign-in frequency 4 hours, Token protection enabled
  • CA-003: Require Compliant or Protected Device for Sensitive Apps
    • Assignments: All users (exclude service accounts)
    • Cloud apps: Exchange Online, SharePoint, Teams, line-of-business apps
    • Conditions: Locations = Any (exclude named trusted locations if needed)
    • Access: Require device to be Hybrid joined or compliant OR use app-protection policy for mobile
  • CA-004: High-Risk Sign-ins = Step-Up or Block
    • Assignments: All users
    • Conditions: Sign-in risk = Medium and above
    • Access: Require password change + MFA, or block for highly sensitive roles

Roll these out in report-only mode first and watch the sign-in logs for a week. Fix breakages (service accounts, scanners, legacy apps) before enforcing.

2.2 Example: Conditional Access via PowerShell (for Consistency)

In larger environments, define policies as code. With the Microsoft Graph PowerShell SDK:

Connect-MgGraph -Scopes 'Policy.ReadWrite.ConditionalAccess'

$policy = @{ 
  displayName = 'CA-001 Block Legacy Auth'
  state       = 'enabled'
  conditions  = @{ 
    users = @{ includeUsers = @('All'); excludeUsers = @() }
    clientAppTypes = @('other')
  }
  grantControls = @{ 
    operator = 'OR'
    builtInControls = @('block')
  }
}

New-MgIdentityConditionalAccessPolicy -BodyParameter $policy

This lets you track policies in Git and push them repeatably between tenants (test, staging, production).

3. Device & App Trust: Intune + Compliance Before Access

Once identity is shaped, move quickly into device and app trust. You want a world where a random unmanaged laptop can’t quietly sync a 30GB SharePoint library.

3.1 Define Concrete Device Compliance Baselines

In Intune, create platform-specific compliance policies:

  • Windows 11/12 baseline (example):
    • Require BitLocker on OS and fixed data drives
    • Require Secure Boot and TPM 2.0
    • Minimum OS version = current – 1 feature release
    • Require Microsoft Defender for Endpoint onboarding
    • Block jailbreak/root detection equivalents on ARM-based devices
  • iOS/Android baseline:
    • Require device lock with strong PIN/biometrics
    • Block jailbroken/rooted devices
    • Minimum OS version aligned with your security policy (e.g. iOS 18+, Android 15+)
    • Require encryption at rest where supported

Tie these directly into the Conditional Access policies you defined earlier via Require device to be marked as compliant.

3.2 App Protection for BYOD

For bring-your-own devices, don’t fight the ownership battle; protect the data instead. Use Intune App Protection Policies (MAM) for mobile apps:

  • Only allow data transfer between managed apps (e.g. Outlook → Teams, not Outlook → personal Gmail).
  • Require PIN/biometrics to open work apps.
  • Encrypt app data at rest and wipe it on selective wipe or user leave.

In Conditional Access, add a policy like Require approved app & app protection policy for mobile devices accessing email or Teams.

4. Application & Network Layer: From Flat LAN to Micro-Segmented Access

Once identity and device posture are under control, move your focus to applications and the network paths they sit on. This is where you shrink your blast radius.

4.1 Publishing Legacy Apps Without Punching Big Holes

If you have on-prem web apps or older line-of-business systems, avoid broad VPN access. Options for 2026:

  • Azure AD Application Proxy for standard web apps.
  • ZTNA solutions (Defender for Cloud Apps private access, or equivalent) for TCP-based apps.
  • VDI/Cloud PC (Windows 365, AVD) as a sealed workspace for high-risk apps.

Every access path should flow through your identity plane, with Conditional Access applied. If an app can’t be tied to identity-based controls, flag it as a modernisation candidate.

4.2 Network Segmentation & VLAN Strategy That Actually Gets Implemented

You don’t need 50 VLANs to do Zero Trust. You do need meaningful zones:

  • User Zone: End-user devices; internet and app-proxy outbound only; no server-to-server access.
  • Server / App Zone: On-prem apps; strict east-west rules; no direct internet unless required.
  • OT / IoT Zone: Printers, cameras, building systems; very limited north-south traffic; no direct access from User Zone.
  • Management Zone: Jump hosts, management tools; access restricted to admins with just-in-time elevation.

On your core switches/firewalls, define ACLs or security policies that implement explicit allow only between these zones. Example using a Fortinet-style approach:

config firewall policy
  edit 10
    set name "User-to-Internet"
    set srcintf "VLAN_USER"
    set dstintf "WAN"
    set srcaddr "all"
    set dstaddr "all"
    set action accept
    set service "HTTPS" "DNS"
  next
  edit 20
    set name "User-to-Server-Restricted"
    set srcintf "VLAN_USER"
    set dstintf "VLAN_SERVER"
    set srcaddr "all"
    set dstaddr "AppServers"
    set action accept
    set service "HTTPS" "RDP"
  next
end

The important thing: no implicit any-any between user and server networks.

5. Privileged Access & Just-in-Time (JIT) Admin

Compromised admin accounts are still the fastest way to lose a weekend. Zero Trust assumes an attacker will eventually get some credentials; your job is to reduce what those credentials can do and for how long.

5.1 Clean Separation of Admin Identity

  • Give admins separate admin accounts (e.g. firstname.lastname and firstname.lastname-admin).
  • Block admin accounts from email and daily browsing.
  • Require compliant device + MFA + strong Conditional Access for all admin sign-ins.

Use Entra Privileged Identity Management (PIM) for role elevation:

  • Make roles eligible, not permanent.
  • Require justification and approval for high-privilege roles.
  • Set activation durations to hours, not days.

5.2 Admin Workstations

Build a dedicated admin workstation configuration profile in Intune:

  • Hardened browser and OS policies (no local admin, ASR rules, Credential Guard).
  • Limited allowed apps; no Office macros from the internet.
  • Force all admin actions through these devices using Conditional Access (e.g. Require device in AdminDevices group for portal access).

6. Visibility, Logging, and Practical Automation

Zero Trust without visibility is just guesswork with extra steps. Wire in logging and automation early, even if it’s basic at first.

6.1 Log the Things That Actually Matter

At a minimum, send the following to your SIEM/XDR (e.g. Sentinel):

  • Entra ID sign-in logs and audit logs
  • Defender for Endpoint alerts and device timelines
  • Firewall logs for inter-zone traffic
  • Key SaaS audit logs (M365, major line-of-business apps)

Create a small set of high-signal alerts instead of dozens you’ll ignore:

  • Impossible travel or unfamiliar sign-in + sensitive app access.
  • New Global Admin or high-privilege role assignment.
  • Mass file download or unusual DLP events from a single user.

6.2 Automate the First Response Step

Use Logic Apps or Power Automate with Sentinel/MDE to handle easy decisions:

  • High sign-in risk user → automatically force password reset + send service desk ticket.
  • Device with critical alert → automatically mark non-compliant in Intune and block Conditional Access.
  • New external forwarding rule in Exchange → auto-disable and notify security.
// Example Sentinel analytics rule query
SigninLogs
| where RiskLevelDuringSignIn in ('high', 'medium')
| where ResultType == 0
| project TimeGenerated, UserPrincipalName, IPAddress, RiskLevelDuringSignIn, AppDisplayName

Trigger a playbook from this rule to send details to Teams and, if conditions match, lock the account via Graph.

7. A Pragmatic 90-Day Zero Trust Roadmap

This doesn’t need to be a 2-year transformation project. Here’s a realistic 90-day plan for most mid-size environments.

Days 1–30: Identity & Quick Wins

  • Document your Zero Trust blueprint and get stakeholder sign-off.
  • Enable MFA for all users (using modern methods, phishing-resistant where possible).
  • Deploy CA-001–004 in report-only, tune, then enforce.
  • Turn on basic Defender for Office 365 phishing and safe links policies.

Days 31–60: Device & App Trust

  • Roll out Intune device compliance for Windows and mobile devices.
  • Configure App Protection Policies for mobile (Outlook, Teams, OneDrive).
  • Start publishing 1–2 key on-prem apps via App Proxy or your ZTNA of choice.
  • Define VLAN zones and adjust firewall rules where feasible (start with User vs Server).

Days 61–90: Privileged Access & Automation

  • Implement PIM for high-privilege roles and remove permanent Global Admins.
  • Deploy hardened admin workstations and Conditional Access for admin portals.
  • Onboard logs to Sentinel/XDR and set up 3–5 high-signal incident rules.
  • Build at least one end-to-end automation (e.g. high-risk sign-in → auto-contain).

One Thing to Do This Week

If this feels like a lot, start with the highest leverage move: audit and fix your Conditional Access strategy. Export your current policies, map them against the identity baseline in this article, and decide what you can safely enable in report-only mode tomorrow.

Once the identity layer is solid and measured, every other Zero Trust change you roll out will be faster, safer, and easier to justify to the business.