Zero trust has been the most overused phrase in cybersecurity marketing for the past five years, which is a shame because the underlying ideas in NIST SP 800-207 are genuinely useful. The standard does not describe a product, a network design, or a transformation programme. It describes a set of design principles for systems where every access decision is evaluated on its own merits — no implicit trust, no perimeter assumption, no "we are inside the network so we are safe."
What Zero Trust Actually Says
NIST SP 800-207 boils down to seven tenets. All resources are protected regardless of network location. Access is granted per-session, evaluated on context. Authentication and authorisation are dynamic, considering identity, device posture, behaviour, and risk. Communications are encrypted regardless of network location. Resource access is determined by policy that is continuously evaluated, not statically configured. The organisation collects telemetry to inform policy. And no asset is inherently trusted.
These tenets are what the architecture is supposed to satisfy. They are not what you implement directly. Implementation is a sequence of incremental shifts to your existing systems that move them closer to those tenets without requiring a full rebuild.
Days 1–30: Identity Is the New Perimeter
The single highest-leverage zero trust move is hardening identity. If your identity provider is the gate every access decision passes through, the rest of the architecture has somewhere to anchor. Concrete first-month moves: enforce phishing-resistant multi-factor authentication for all human users, eliminate shared accounts, audit and right-size service account permissions, and stand up a privileged access management workflow for any access that holds elevated rights even temporarily.
Days 30–60: Device Posture and Application Access
Once identity is sound, add the second factor that actually scales: device posture. Make access decisions consider whether the requesting device is enrolled, encrypted, patched, and not running known-bad software. The implementation does not require a full unified endpoint management rollout — most organisations can begin by gating access to high-value applications behind device posture checks, then expand the gate as coverage allows.
A common zero trust trap: the organisation buys a sophisticated policy engine, then never builds the telemetry the policy engine needs to make good decisions. The policy engine is the easy purchase. The signal sources — identity events, endpoint posture, network telemetry, application context — are where the work is. Without them, the policy engine makes binary decisions on bad data.
Days 60–90: Microsegmentation Where It Pays
Network segmentation under zero trust is targeted, not exhaustive. Identify the highest-value flows: regulated data systems, payment infrastructure, intellectual property repositories. Segment those first with explicit policy. Most organisations cannot microsegment everything inside 90 days, and the attempt produces fragile environments. Segment what matters, instrument what is left, and expand iteratively.
Mistakes That Quietly Sabotage Zero Trust
- Treating zero trust as a network project — it is an identity, device, and application project that happens to involve network controls
- Buying products before defining the policy decision and enforcement points
- Ignoring legacy applications that cannot meet modern auth standards — they need wrappers, not exclusions
- Underinvesting in identity governance — over-provisioned accounts undo every other control
- Forgetting east-west traffic — perimeter-only thinking leaves internal lateral movement untouched
Why 90 Days Is the Right Goal
Zero trust programmes that aim for 18-month transformations rarely finish them. Sponsorship moves on, priorities shift, the architecture document gets out of date. A 90-day cycle that delivers concrete, measurable improvements in identity, device posture, and segmentation builds momentum, demonstrates value to leadership, and sets up the next 90-day cycle. Zero trust is not done in 90 days. But the first meaningful version of it can be, and that is enough to keep the programme alive.