[For IT Pros]

Zero Trust has gone from buzzword to baseline. In 2026, if your organisation still relies on a “secure internal network” and a VPN, you’re carrying unnecessary risk. But the problem isn’t knowing what Zero Trust is — it’s turning it into something you can actually implement without breaking everything.

This guide is written from the perspective of getting it done in the real world: hybrid environments, legacy apps, politics, and limited time. You’ll see practical steps, example policies, and a starter roadmap you can adapt to your environment.

1. Ground Rules: What Zero Trust Really Means in 2026

Forget the marketing slides. In practice, Zero Trust boils down to three things:

  • Never trust by default – identity, device, location, and risk are evaluated on every access.
  • Enforce least privilege – users, apps, and devices get only what they need, when they need it.
  • Assume breach – design as if an attacker is already inside your network or tenant.

For most enterprises using Microsoft 365, Azure, and some on‑prem, the centre of gravity for Zero Trust is identity and access: Entra ID (formerly Azure AD), Conditional Access, device compliance, and micro-segmentation around critical apps and data.

Zero Trust pillars you can actually influence quickly

  • Identity – Entra ID, SSO, MFA, Conditional Access, Privileged Identity Management (PIM).
  • Device – Intune compliance, Defender for Endpoint, OS hardening, managed vs unmanaged.
  • Access – app-based rules, network segmentation, just-in-time (JIT) admin, granular RBAC.

Data, apps, infrastructure, and observability matter too, but if you’re trying to make impact in 6–12 months, start with identity + device + access. The rest builds on that foundation.

2. Start with a Zero Trust Baseline: Identity & MFA That Don’t Suck

If you try to “do Zero Trust” with a 60-page strategy document and no changes to sign-in, you’ll fail quietly. Your first visible win should be cleaning up how people log in — securely and (almost) painlessly.

Step 1: Enforce strong MFA for all, with reasonable exclusions

By 2026, SMS MFA is legacy. Your default should be phishing-resistant methods:

  • Microsoft Authenticator number matching + app context.
  • Passkeys / FIDO2 security keys for admins and high-risk roles.
  • Platform authenticators (Windows Hello for Business, Face ID/Touch ID on mobile).

Example Entra ID Conditional Access baseline for MFA:

// Pseudo-definition of a baseline CA policy
Name: "Baseline - Require MFA for all cloud apps"
Assignments:
  Users: All users
  Exclude: Break-glass accounts (max 2), service principals
  Cloud apps: All cloud apps
Conditions:
  Locations: All (exclude trusted break-glass locations if required)
  Client apps: Browser, modern auth clients, mobile & desktop
Access controls:
  Grant: Require multi-factor authentication
  Session: Persistent browser session = disabled for admin roles

Roll it out in stages: IT + security, then high-risk departments (finance, execs), then everyone. Use report-only mode for 1–2 weeks so you can see impact before flipping it to enforce.

Step 2: Kill legacy authentication properly

Legacy auth (basic auth, IMAP, POP, older Office clients) ignores Conditional Access and is still a common attack path, especially for scripted password spraying.

Use Authentication Methods policy + Sign-in logs to identify what’s still using legacy auth. Then:

  • Block legacy auth at the tenant level (Entra ID > Security > Authentication methods > Policies).
  • Create time-bound exception CA policies for the few apps that can’t be upgraded, with an explicit decommission date.

For example, a restrictive exception policy:

Name: "Exception - Legacy app SMTP relay (time-limited)"
Assignments:
  Users: Specific service account only
  Cloud apps: Office 365 Exchange Online
Conditions:
  Locations: Named on-prem IP range only
  Client apps: Other clients (legacy auth)
Access controls:
  Grant: Require password + compliant network location
  Session: Sign-in frequency = 8 hours

3. Device & Endpoint: Trust the Device, Not the Network

Once MFA is in place, the next big win is treating unmanaged devices as second-class citizens. If your finance data is accessible from a random personal laptop with outdated antivirus, Zero Trust is a myth in your environment.

Step 3: Intune compliance as your gatekeeper

Use Intune device compliance policies as a hard requirement for accessing sensitive apps. At minimum for corporate devices:

  • OS version >= current – 1 (e.g. Windows 11 24H2+, iOS 18+, Android 16+).
  • Disk encryption enabled (BitLocker/FileVault).
  • Defender for Endpoint healthy (no active severe alerts).
  • Secure boot + TPM where supported.

Example Compliance policy (Windows):

// Intune > Devices > Compliance policies
- Require BitLocker: Yes
- Minimum OS version: 10.0.22631.1
- Defender real-time protection: Required
- Require Secure Boot to be enabled: Yes
- Mark device noncompliant: Immediately on failure

Then wire that into Conditional Access:

Name: "Require compliant or MAM-managed device for M365"
Assignments:
  Users: All users
  Cloud apps: Office 365, SharePoint, Exchange, Teams
Conditions:
  Device platforms: All platforms
Controls:
  Grant: Require device to be marked as compliant
         OR require app protection policy (preview/MAM)

This gives you a soft landing: managed devices must be compliant; BYOD can still access via mobile apps with app protection (no local downloads, encrypted app container, etc.).

Step 4: Lock admin activity to secure workstations

Admin accounts signing in from random laptops is a breach waiting to happen. Move privileged work to a small set of hardened, monitored devices.

Approach:

  • Create an “Admin Workstation” device group in Intune (dynamic or assigned).
  • Apply a stricter baseline: no local admin, Device Control, WDAC or Defender Application Control policies, reduced browser surface.
  • Use Conditional Access to allow privileged roles to sign into admin portals only from this device group.

Example CA snippet:

Name: "Restrict admin portal access to secure workstations"
Assignments:
  Users: Directory roles = Global Admin, Security Admin, Privileged Role Admin
  Cloud apps: Microsoft Entra admin center, Azure portal, M365 admin center
Conditions:
  Device filter: device.deviceCategory -eq "AdminWorkstation"
Access controls:
  Grant: Require compliant device
         AND Require phishing-resistant MFA

4. Access Control: Conditional Access as Your Policy Engine

With identity and device signals in place, Conditional Access becomes your main Zero Trust enforcement tool. The mistake most teams make is creating 50+ random policies with overlapping logic.

Step 5: Build a small, opinionated CA policy set

A sane starting structure (adapt the details to your org):

  • Baseline
    • CA-100: Require MFA for all users, all apps.
    • CA-110: Block legacy auth (backup to tenant-level setting).
  • Device & location
    • CA-200: Require compliant or MAM-managed device for M365.
    • CA-210: Block access from high-risk countries / TOR / anonymous IPs.
  • Privileged & sensitive apps
    • CA-300: Restrict admin portals to secure workstations + phishing-resistant MFA.
    • CA-310: Require sign-in frequency <= 4 hours for finance/HR apps.
  • Risk-based
    • CA-400: Block high-risk sign-ins (Entra ID Identity Protection).
    • CA-410: Require password reset for medium-risk sign-ins.

Document those in a simple table and treat them like code: version, owner, change history, dependencies. Use “Report-only” mode whenever you add or significantly tweak a policy, and schedule weekly reviews of the impact before enforcing.

Step 6: Segment by app criticality, not random groups

Instead of one-size-fits-all rules, classify your apps:

  • Tier 0 – identity & security (Entra, Azure, M365 admin, security portals).
  • Tier 1 – business-critical & sensitive data (ERP, payroll, HR, finance, core line of business).
  • Tier 2 – standard collaboration (Teams, SharePoint, email, intranet).
  • Tier 3 – low-risk SaaS / utilities.

Then define controls per tier. For example, Tier 1 policy:

Name: "Tier1 - Strong access control"
Assignments:
  Users: All users
  Cloud apps: <list of Tier 1 apps>
Conditions:
  Sign-in risk: Medium and above
  Locations: All (no exclusions)
Access controls:
  Grant: Require MFA
         AND Require compliant device
Session:
  Sign-in frequency: 4 hours
  Persistent browser session: Disabled

This way, when a new app comes in, you decide its tier and it automatically inherits the right policies. Much easier to maintain than bespoke rules per application.

5. Micro-Segmentation: From Flat Networks to Scoped Access

A lot of breaches in 2026 still look the same: one compromised endpoint, then lateral movement across a flat network. Zero Trust means containing that blast radius.

Step 7: Segment networks around identities and apps, not VLAN art projects

If you still have a giant “server VLAN” that everything can talk to, start there. Your aim is to isolate:

  • Domain controllers and identity infrastructure.
  • Tier 0/Tier 1 app servers and databases.
  • OT/IoT segments (manufacturing, building management, cameras, etc.).

Typical pattern:

  • Use network security groups (NSGs) and Azure Firewall for Azure workloads.
  • Use segmented VLANs + firewall rules on-prem (or micro-segmentation via NAC/SDN where you have it).
  • Enforce access to these segments via application proxies or reverse proxies where possible, instead of raw network access.

Example NSG rules for an app subnet (simplified):

Priority 100: Allow HTTPS from AppGatewaySubnet to WebSubnet
Priority 200: Allow SQL from WebSubnet to DbSubnet (TCP 1433)
Priority 900: Deny all inbound from Internet
Priority 910: Deny all inbound from UserSubnets (no direct server access)
Priority 1000: Deny all inbound

The key is: users shouldn’t be able to RDP/SSH directly into high-value servers from their laptops. Force them through Bastion hosts, Just-In-Time access, or admin jump hosts with strong audit trails.

6. Operationalising Zero Trust: Make It Sustainable

Zero Trust is a direction of travel, not a project with an end date. But you need structure, or it turns into random acts of security improvement.

Step 8: Define a simple Zero Trust roadmap and owners

Build a 12–18 month roadmap with clear phases and owners. Example:

  • Phase 1 (0–3 months)
    • MFA for all, kill legacy auth, baseline CA policies in place.
    • Identify Tier 0/Tier 1 apps and admin accounts.
  • Phase 2 (3–9 months)
    • Intune compliance enforced for corp devices.
    • Admin workstation model implemented.
    • Micro-segmentation of domain controllers and Tier 0 apps.
  • Phase 3 (9–18 months)
    • PIM and JIT access for all privileged roles.
    • Data-level controls (sensitivity labels, DLP) for Tier 1 apps.
    • Continuous monitoring and risk-based policies tuned.

Each item should have an owner, a definition of done, and at least one measurable metric (e.g. % of admin sign-ins from secure workstations, % of cloud app traffic covered by CA policies).

Step 9: Close the loop with monitoring and incident playbooks

Zero Trust without visibility is just complexity. Make sure your logging and response keep up:

  • Send Entra ID, Intune, Defender, and firewall logs into your SIEM (e.g. Microsoft Sentinel).
  • Create detections for policy violations (e.g. legacy auth attempts, admin sign-ins from unknown locations, repeated CA policy failures).
  • Build simple, repeatable playbooks for common issues: CA lockouts, high-risk sign-ins, device non-compliance spikes, suspicious impossible travel.

Example quick-response playbook for high-risk sign-in:

  • Automatically block sign-in via CA (CA-400).
  • Trigger an automated ticket with user details and recent sign-in history.
  • Helpdesk script: call user, verify, trigger secure password reset and device check if needed.

One Concrete Next Step: Build Your First Five Policies

Don’t start with a 60-slide strategy deck. In the next week, aim to get these into at least report-only mode:

  • CA-100: Require MFA for all users, all apps.
  • CA-110: Block legacy authentication (plus tenant-level block).
  • CA-200: Require compliant or MAM-managed device for M365.
  • CA-300: Restrict admin portals to secure workstations + phishing-resistant MFA.
  • CA-400: Block high-risk sign-ins (with an agreed helpdesk playbook).

Once those are in and stable, you’ll already have moved your organisation meaningfully closer to Zero Trust — with measurable reductions in risk and clear foundations to build on. If you want a reality check on your draft policies or roadmap, this is exactly the kind of thing we help teams with at Amrani.tech.