Zero trust has been talked about for so long that it has started to sound like marketing. It is not. The core idea is simple and durable: stop trusting things just because they are inside the network. Every request to a resource should be authenticated, authorised, and continuously evaluated, regardless of where it originates. The hard part is not the philosophy, it is shipping it without halting the business. This roadmap lays out a phased rollout grounded in NIST Special Publication 800-207, sequenced so each phase delivers real risk reduction before the next one starts.
What zero trust actually means (and does not)
NIST 800-207 frames zero trust around a set of tenets rather than a product. Access is granted per session, decisions are based on identity plus device state plus other signals, and trust is never permanent. The model centres on a policy decision point and policy enforcement point that sit between every subject and every resource.
What it is not: a single appliance you buy, or a project you finish. There is no "zero trust in a box." Anyone selling you that is selling you one component. The practical goal is to move from implicit network trust to explicit, identity driven, continuously verified access, one domain at a time.
Phase one: identity and strong authentication
Identity is the foundation, so this is where every credible roadmap starts. Before touching the network, get your identity house in order. Consolidate to a single authoritative identity provider where possible, eliminate orphaned and shared accounts, and enforce phishing resistant multi factor authentication. Legacy authentication protocols that bypass MFA (older mail protocols are the classic example) need to be found and switched off, because attackers will route around your shiny new controls to reach the old door.
This phase also means cleaning up privileged access: no standing global admin, just in time elevation where you can, and a clear inventory of who can do what. Identity is the new perimeter, and if an attacker can simply log in as a valid user, no amount of segmentation downstream will save you. Getting identity right first is what makes everything after it meaningful.
Phase two: device posture and conditional access
Once identity is solid, add the device into the decision. A valid credential from an unmanaged, unpatched, or compromised device should not get the same access as one from a healthy, managed endpoint. This is where conditional access policies come in: combine the user identity, the device posture (managed, encrypted, patched, running EDR), the location, and the sensitivity of the resource to make a per request decision.
Practically, you start with high value applications and apply policies like "require a compliant device for finance systems" or "block legacy auth entirely" or "step up authentication for access from a new location." The aim is to make the access decision dynamic and signal driven, which is exactly the continuous evaluation that 800-207 calls for. Roll these policies out in report only mode first so you can see what would break before it does.
Phase three: ZTNA before retiring the VPN
The traditional VPN is the antithesis of zero trust: authenticate once, then get broad network level access to everything. Zero Trust Network Access (ZTNA) replaces that with per application access brokered by a policy engine. The user connects to the specific application they are authorised for, not to the network, and the application is never directly exposed to the internet.
The sequencing matters here. Deploy ZTNA alongside the VPN first, migrate applications onto it group by group, and only retire the VPN once coverage and user experience are proven. Trying to flip the switch overnight is how rollouts fail and how users end up locked out of the tools they need. Start with web based internal apps, which are easiest to broker, then work toward thicker client applications.
Phase four: microsegmentation, sequenced by criticality
Flat internal networks are why ransomware spreads from one infected laptop to the entire estate. Microsegmentation breaks the network into small zones with explicit policy between them, so a compromise in one place cannot move laterally to everything else.
This is the most operationally demanding phase, so sequence it by application criticality rather than trying to segment the whole environment at once. Start by isolating your crown jewels: the systems that, if breached, end the business. Identify the legitimate traffic flows to and from them (a discovery and monitoring period is essential here), then enforce policy that allows only those flows and denies the rest. Move outward to the next tier once each segment is stable. Done in this order, you get the biggest risk reduction earliest and avoid breaking production with overly tight rules.
Tying it together with monitoring
Zero trust generates a rich stream of authentication, device, and access decision logs. Feeding those into your detection capability closes the loop: continuous verification only works if someone is watching the verification decisions for anomalies. This is where zero trust and a managed detection capability reinforce each other, and it is why we treat them as parts of one programme rather than separate projects. You can read how we approach the build on our services page.
Key takeaways
- Zero trust is a set of principles from NIST 800-207, not a product you install.
- Start with identity and phishing resistant MFA, because identity is the real perimeter.
- Add device posture and conditional access so decisions use live signals, and test policies in report only mode first.
- Deploy ZTNA alongside the VPN and migrate per application before retiring broad network access.
- Microsegment last, sequenced by application criticality, starting with your crown jewels.
The roadmap works because each phase stands on its own. If budget or time runs out after phase two, you are still meaningfully more secure than you were. To scope a phased rollout for your environment, reach us through the contact page.