How To Set Up a Zero Trust Network in Your Company: A Step-by-Step Guide for 2026

Before you start: what zero trust actually is (and is not)

Zero trust is not a product you buy, a firewall you enable, or a checkbox in your identity provider. It is an operating model: every request to every resource is authenticated, authorised, and continuously evaluated regardless of where it originated. The corporate LAN is treated with the same suspicion as a coffee-shop Wi-Fi network, and the strength of the identity plus the posture of the device — not the IP address — determines what a user can reach.

That definition matters because most failed zero trust programmes fail for the same reason: the team bought a shiny SSE or ZTNA product, deployed it on a subset of applications, and declared victory while 90% of east-west traffic inside the datacentre continued to trust the network. Six months later the CISO discovers that lateral movement is still possible, the auditor is unimpressed, and the budget for phase two has evaporated.

This guide walks through the sequence that has worked repeatedly for teams we have advised — a phased twelve-to-eighteen-month rollout that hardens identity first, then device posture, then application access, then east-west segmentation, and finally the detection layer that closes the loop. You do not need to do it in one project. You do need to do it in this order.

Step 1 — Get identity right before you touch the network

Identity is the load-bearing wall of zero trust. If your identity provider cannot express fine-grained policy, evaluate risk signals in real time, and enforce phishing-resistant MFA, nothing else you do will matter. Start here.

Consolidate identity providers. Most enterprises we assess have three: a primary IdP (Entra ID or Okta), a legacy Active Directory forest, and one or two SaaS-native user directories that grew organically. Pick one authoritative source, federate the rest to it, and make single sign-on the default path for every new application. Every exception you allow at this stage becomes a permanent hole later.

Move every user to phishing-resistant MFA. SMS and TOTP are deprecated in every serious 2026 threat model. Deploy FIDO2 security keys or passkeys for the entire workforce; the marginal cost per user is small compared to a single successful account takeover. Enforce it with a conditional access policy that blocks legacy authentication protocols entirely — IMAP, POP, basic SMTP auth, ActiveSync — because attackers use them precisely because they bypass MFA.

Adopt least privilege for administrative access. Standing global-admin rights are the single biggest predictor of blast-radius when an identity is compromised. Move to just-in-time elevation via Privileged Identity Management (or the Okta equivalent), require an approval workflow for tier-zero roles, and log every activation to your SIEM.

Step 2 — Establish device posture as a policy input

A user identity alone is not a strong enough signal to grant access to sensitive resources. Zero trust requires you to know something about the device the request is coming from — is it managed, patched, encrypted, running an EDR agent, and free of known indicators of compromise.

Enrol every corporate endpoint into your MDM (Intune, Jamf, or a comparable platform). For BYOD, use app protection policies to enforce a separation between corporate and personal data without requiring full device management. Publish a short, plain-English policy that tells employees which device states qualify for which levels of access, so support tickets do not surprise anyone.

Wire device compliance state into your identity provider's conditional access engine. The rule is simple: if the device is non-compliant, the user gets a step-up challenge or is blocked from sensitive apps. Start with a small enforcement scope — the finance SaaS, the code repository, the admin consoles — and expand only when the operational load on the service desk has stabilised.

Step 3 — Put application access behind an identity-aware proxy

Replace legacy VPN access with an identity-aware proxy for internal web applications. Cloudflare Access, Zscaler Private Access, Google's BeyondCorp Enterprise, and Tailscale (for smaller teams) all work; the specific vendor matters less than the pattern. Every internal application sits behind a proxy that authenticates the user against your IdP, evaluates device posture, and only then forwards the request.

Migrate applications in waves. Start with low-risk internal tools — wikis, internal dashboards, staging environments — that have low change-management overhead. The goal of the first wave is not scale; it is to prove the deployment pattern, the observability, and the user experience, so that when you migrate the finance system in wave three there are no surprises.

For each application, document the policy explicitly: who can access, from which device posture, with what authentication assurance level, and what session lifetime. This document becomes your audit artefact and your onboarding guide for new engineers.

Step 4 — Segment east-west traffic inside the datacentre and cloud

This is the step most zero trust programmes never reach, and it is the one that actually stops ransomware. Perimeter-only architectures collapse the moment a single workstation is compromised because everything inside is reachable from everything else.

In cloud environments use native segmentation: AWS security groups aligned to workload identity, Azure network security groups plus Private Endpoints, and service-mesh identity (SPIFFE/SPIRE, Istio, or Linkerd) for Kubernetes clusters. In on-premises environments, microsegmentation platforms like Illumio or Guardicore let you enforce policy at the workload level without re-architecting the network. Whatever you choose, deploy in visibility mode first, review the traffic patterns for four to six weeks, then move to enforcement one segment at a time.

Write policies in terms of workload identity, not IP address. IPs churn; identities are stable. A policy that says 'the payments service may talk to the fraud-detection service on port 8443' will survive a decade of infrastructure change. A policy written in CIDR blocks will not survive the next migration.

Step 5 — Close the loop with continuous monitoring

Zero trust is not fire-and-forget. The 'continuous' part of continuous verification means you need telemetry from identity, device, network, and application planes flowing into a single detection pipeline.

At minimum, forward these logs into your SIEM or data lake: identity provider sign-in and audit logs, EDR telemetry from every managed endpoint, ZTNA proxy access logs, cloud control-plane logs (CloudTrail, Azure Activity, GCP Audit), and Kubernetes audit logs from every production cluster. Build a small number of high-signal detections first — impossible travel, MFA fatigue, sudden privilege escalation, workload identity used from an unexpected source IP — and iterate.

Run a quarterly purple-team exercise that exercises the whole stack: initial access via a phished credential, attempted lateral movement, attempted data exfiltration through the proxy. If any stage succeeds silently, that is the next thing to fix. This is the mechanism that turns a paper architecture into a defensible one.

Common mistakes and how to avoid them

The most common failure is treating zero trust as a network project. It is an identity project that touches the network. If your programme reports into networking rather than into identity or security engineering, expect friction.

The second most common failure is skipping the visibility phase before enforcement. Every large environment has surprising traffic patterns — that legacy batch job that nobody remembers writing, the vendor tunnel that predates the current CIO, the developer laptop that talks directly to production. Enforce first and you break them all in one afternoon. Observe first and you can fix them quietly.

The third failure is under-investing in end-user communication. Zero trust changes how people log in, how they access applications, and occasionally what they can do from a personal device. A weekly two-paragraph email to affected users during rollout will save more service-desk tickets than any technical mitigation.

A realistic twelve-month roadmap

Months 1–2: consolidate identity, enforce phishing-resistant MFA for admins, kill legacy auth protocols. Months 3–4: extend MFA to the whole workforce, enrol endpoints in MDM, publish the device-compliance policy. Months 5–7: deploy the identity-aware proxy, migrate the first ten internal applications. Months 8–10: begin cloud microsegmentation in visibility mode; wire all telemetry into the SIEM. Months 11–12: turn on enforcement for the first segments, run the first purple-team exercise, publish an executive-facing scorecard.

Twelve months in, a healthy programme has these characteristics: no user signs in without phishing-resistant MFA, every corporate endpoint reports compliance state to the IdP, every internal web app is reachable only through the proxy, at least one production segment is in enforcement mode, and every relevant log source lands in the SIEM within five minutes. That is not the end of the journey — no zero trust programme finishes — but it is the point at which a competent auditor will stop asking uncomfortable questions, and it is the point at which lateral movement stops being the cheap attack it is today.