Zero Trust Architecture Guide: What NIST SP 800-207 Actually Requires

Share

Written by Mark Fermor. Zero Trust is a security architecture strategy, not a product category. This guide sets out what NIST SP 800-207 describes, how the logical components fit together, and where the model reaches its limits.

The definition worth using

NIST Special Publication 800-207 defines Zero Trust as a set of principles that move defences from static, network-based perimeters to focus on users, assets and resources. The operating assumption is that no implicit trust is granted on the basis of network location or asset ownership. Every access request to a resource is evaluated on its own merits, and authorisation is granted per session.

Two consequences follow. Being inside a network no longer confers access. And authentication is not a one-off event at the front door; it is a continuous evaluation that can withdraw access when conditions change.

The tenets, in operational terms

• All data sources and computing services are treated as resources.
• All communication is secured regardless of network location. There is no trusted internal network.
• Access to individual resources is granted on a per-session basis, with least privilege.
• Access is determined by dynamic policy, including client identity, application state, requesting asset posture, and behavioural or environmental attributes.
• The organisation monitors and measures the integrity and security posture of all owned and associated assets. No asset is inherently trusted.
• Authentication and authorisation are dynamic and strictly enforced before access is allowed, and re-evaluated during the session.
• The organisation collects as much information as possible about assets, network infrastructure and communications, and uses it to improve its security posture.

The logical architecture

SP 800-207 separates the decision from the enforcement, which is the structural idea that makes Zero Trust implementable.

• Policy Engine (PE). Decides whether to grant access to a resource for a given subject, using policy and external inputs.
• Policy Administrator (PA). Establishes or tears down the communication path, and issues the session credentials.
• Policy Enforcement Point (PEP). Enables, monitors and terminates the connection between subject and resource. It sits in the data path; the PE and PA sit in the control plane.

Around these sit the inputs that make policy dynamic: identity management, device posture and compliance state, threat intelligence, activity logs, data classification, and industry or regulatory policy.

Deployment approaches

• Device agent and gateway based. An agent on the endpoint coordinates with a gateway fronting each resource. Strong control, and the most demanding to roll out across an unmanaged estate.
• Enclave based. A gateway protects a group of resources rather than each one individually. Realistic where legacy applications cannot sit behind an individual gateway.
• Resource portal based. Subjects reach resources through a portal that acts as the enforcement point. Simplest to adopt, with the weakest visibility of endpoint posture.
• Application sandboxing. Approved applications run in isolated environments on the asset, reducing dependence on the health of the host operating system.

Most real programmes end up hybrid, and that is a legitimate outcome provided the boundaries between approaches are deliberate.

Migration that does not stall

1. Inventory subjects, assets and business processes. Zero Trust cannot enforce policy about resources you have not enumerated.
2. Identify the highest-value workflows and map their actual data flows, including administrative and backup traffic, which is routinely forgotten.
3. Fix identity first. Strong authentication, privileged access management and lifecycle hygiene are the substrate. Without them, dynamic policy has nothing trustworthy to evaluate.
4. Insert enforcement points around one workflow in monitoring mode, then move to enforcement.
5. Expand by workflow, not by network. Segmenting networks without per-resource authorisation produces smaller perimeters, not Zero Trust.
6. Instrument continuously, since policy quality depends entirely on the fidelity of the telemetry feeding it.

Where Zero Trust reaches its limits

Three limits deserve honest statement, because vendor material rarely acknowledges them.

Operational technology. Many industrial devices cannot authenticate, cannot run an agent, cannot tolerate the latency of an inline enforcement point, and cannot be patched on a normal cycle. In these environments Zero Trust principles are usually applied to the systems and people that reach the process, with segmentation and boundary design doing the work at the process layer. ISA/IEC 62443 zone and conduit design remains the primary construct there, and the Purdue Model remains a useful functional reference.

The control plane itself. The Policy Engine, Policy Administrator, identity provider and their logs become the most valuable target in the estate. An attacker who compromises policy administration inherits the ability to authorise themselves. Zero Trust concentrates trust rather than eliminating it, and the control plane needs its own containment and recovery design.

Recovery. Zero Trust governs access to resources. It does not, by itself, guarantee that a clean copy of a resource exists after a successful intrusion. If recovery data is authorised by the same identity plane and reachable over the same fabric, a sufficiently privileged compromise can authorise its destruction, and every policy decision along the way will have been correct.

Zero Trust and physical controls

The recovery and control plane limits are the two places where physical measures usefully complement dynamic policy. A logical authorisation decision, however well designed, is only as trustworthy as the credentials and control plane that produced it. A physical state change is not authorised by that plane at all.

Firevault works on this narrow seam. Offline Secure Storage® holds selected recovery, configuration and evidential material on storage that is physically disconnected when it is not in use, so that a copy which must survive a compromise of the identity plane is not reachable by it. Control by Firevault is a suite of nine purpose-built tools and techniques that give physical control over the paths into and across an estate, applied through Blueprints that treat a specific risk, which is relevant where a path such as vendor access or a management route does not need to exist continuously.

This is complementary to a Zero Trust programme rather than an alternative to one. Identity, posture, per-session authorisation and telemetry remain the core of the architecture.

Frequently asked questions

Can we buy Zero Trust?

No. Products implement components such as enforcement points and policy engines. The architecture is yours to design.

Is Zero Trust the same as micro-segmentation?

No. Micro-segmentation is one technique that can serve an enforcement objective. Zero Trust requires per-request authorisation of access to resources.

Does Zero Trust replace VPNs?

It usually replaces the model in which a VPN grants broad network access, in favour of authorised access to specific resources.

Does Zero Trust work in OT?

The principles apply to the people and systems reaching the process. At the process layer, segmentation, boundary design and 62443 zones and conduits do most of the work.

How Firevault would handle this

A recovery copy an attacker cannot reach

Offline Secure Storage® keeps a clean copy of your data on hardware that is physically disconnected, so backup and recovery do not depend on systems an intruder can touch.