Security
Zero Trust in practice: what NIST SP 800-207 actually requires from your network
Zero Trust has become a marketing word. Almost every vendor sells a "Zero Trust solution" β and almost none of them match what NIST SP 800-207, the official NIST publication, calls Zero Trust. This article is the filter between doctrine and sales deck.
What NIST SP 800-207 says, in one sentence
Zero Trust is a set of design principles where trust is never implicit. Every access to every resource is evaluated continuously, dynamically and with the least possible privilege, taking identity, device posture, context and risk into account β regardless of whether the user is inside or outside the corporate perimeter.
The 7 official tenets (summary)
- All data sources and computing services are considered resources.
- All communication is secured regardless of network location.
- Access to individual resources is granted on a per-session basis.
- Access is determined by dynamic policy β identity, application, device posture, behavior and environmental attributes.
- The organization monitors and measures the integrity and security posture of all assets.
- All authentication and authorization is dynamic and strictly enforced before access.
- The organization collects as much information as possible about the current state of assets, infrastructure and communication, and uses it to improve security posture.
Architecture components (PE, PA, PEP)
The document describes a simple, powerful logical plane:
- Policy Engine (PE) β decides. Evaluates rules + telemetry + context and issues an access decision.
- Policy Administrator (PA) β enforces the decision. Creates, sustains or terminates the session between requester and resource.
- Policy Enforcement Point (PEP) β applies. Sits in the data path, opens or closes access as the PA directs.
On a real Cisco network the PE/PA typically lives in something like ISE integrated with SIEM/EDR; PEPs are switches, wireless controllers, firewalls (Secure Firewall), proxies (Umbrella/Secure Access) and application gateways.
What is NOT Zero Trust (even if the vendor says so)
- Legacy VPN that grants "access to the whole network" after login. That's a perimeter in disguise.
- MFA on its own, with no device posture evaluation.
- Microsegmentation based purely on VLAN/IP. NIST asks for identity as the primary dimension.
- "Implicit trust because you're in the office". NIST is explicit: location is not a trust criterion.
A realistic implementation roadmap
- Inventory and classification β you don't protect what you don't know. List resources, owners, criticality.
- Strong centralized identity β single IdP, universal MFA, automated account lifecycle.
- Device posture β EDR telemetry, patch compliance, disk encryption, before any sensitive access.
- Identity-based microsegmentation β TrustSec/SGT, identity-aware proxies, app-level segmentation.
- Dynamic policy and telemetry β decisions re-evaluated during the session, not only at login.
- Progressively retire VPN β replace broad access with per-application access (ZTNA).
How to harden this without relying on theory alone
Zero Trust breaks far more often from bad operations than from bad architecture. Misconfigured ACLs, conflicting ISE policies, fragile IdP-to-PEP integrations. TechLeague doesn't sell exam simulators; what it does is put engineers in real, timed challenges around segmentation, AAA, NAC and troubleshooting, with a public ranking. Train this every week and you ship real Zero Trust β not a slide deck.
Next step
Download the official NIST SP 800-207, read section 2 (tenets) and section 3 (components). Then map your network against those 7 tenets β you'll see the technical debt immediately. To train segmentation and NAC under pressure, check out the TechLeague practice tournaments.