Skip to content
WorakornKoonawootrittriron
Back to blog
Network security

Zero trust explained: what NIST SP 800-207 actually asks for

Zero trust is a set of principles, not a product. NIST SP 800-207's seven tenets, the PE/PA/PEP decision loop and CISA's maturity model, in plain terms.

Beginner9 min read

On this page
  1. The old picture: one guard at the lobby
  2. What NIST means, in plain words
  3. The three parts that make the decision
  4. What goes into a decision
  5. CISA's maturity model: a roadmap, not a checklist
  6. Three myths worth dropping
  7. A small first step
  8. Where to read next

"Zero trust" shows up on almost every security vendor's slides, often next to a product name. That makes it easy to think zero trust is something you buy. The idea itself is older, simpler and more useful than the marketing suggests, and the clearest description of it is free: NIST Special Publication 800-207, Zero Trust Architecture, published in August 2020.

This post walks through what that document actually says, using one picture the whole way: an office building with badge readers.

The old picture: one guard at the lobby

Imagine an office building with a single security desk at the front door. You show your badge once in the lobby, and after that you can walk into any room you like. The building assumes that anyone inside must belong there.

That is the classic "castle and moat" network. A strong firewall sits at the edge, and traffic that is already inside is trusted more or less by default.

The classic picture: the firewall at the edge checks a request once, and inside it reaches HR, APP and DB with no further checks

NIST's introduction explains why this stopped working. A single organisation may now run several internal networks, remote offices, remote and mobile staff, and cloud services, so there is no single, easily identified perimeter to guard any more (SP 800-207, section 1). The same section makes the second point: once attackers get past a perimeter, nothing stops them moving sideways from system to system.

In building terms, the staff now work from cafés and from home, half the filing cabinets have moved to a rented warehouse across town (the cloud), and someone who tailgates through the lobby can open every door.

The idea of moving away from trust-by-location is not new, either. SP 800-207 traces it back to the Jericho Forum's work on "de-perimeterisation" in 2004, and notes that the term "zero trust" itself was later coined by John Kindervag while at Forrester (SP 800-207, section 1.1).

What NIST means, in plain words

NIST describes zero trust as a set of ideas for making access decisions that are as accurate and as least-privilege as possible, per request, while treating the network as already compromised (SP 800-207, section 2). A zero trust architecture is then an organisation's plan for applying those ideas.

Two sentences from the document's own summary carry most of the weight (NIST CSRC):

  • No implicit trust is granted to a user account or device based solely on its physical or network location, or on who owns it (the organisation or the user).
  • Authentication and authorisation happen as separate steps before a session with a resource is set up.

SP 800-207 lists seven tenets. Here they are, shortened into everyday language (section 2.1):

  1. Every data source and computing service counts as a resource worth protecting.
  2. All communication is secured, wherever it happens. Being "on the office network" earns no extra trust.
  3. Access is granted per session, with the least privilege needed. Getting into one resource does not automatically get you into another.
  4. Access is decided by dynamic policy: who is asking, with which app, from what device and in what state, plus other behaviour and environment signals.
  5. The organisation watches the health and security posture of every device it owns or allows in. No device is trusted by default.
  6. Authentication and authorisation are dynamic and strictly enforced before access, and can be re-checked during a session.
  7. The organisation collects as much information as it can about its devices, network and traffic, and uses it to improve its policies.

NIST is honest that these are goals: the tenets are "the ideal goal", and not every one may be fully reached in its purest form (section 2.1).

Back to the building: zero trust means a badge reader on every door, and each reader asks a central system "should this person, carrying this badge, come into this room right now?" A badge that opened the lobby says nothing about the finance office.

Every door asks the policy engine. The office and the lab open; the finance door stays shut, even for someone already inside

The three parts that make the decision

SP 800-207 breaks the decision-making into a few logical parts (section 3). NIST notes that they can run on premises or as a cloud service, and that some implementations treat the PE and PA as a single service. What matters is the job each one does.

Part What NIST says it does In the building
Policy engine (PE) Makes the final decision to grant, deny or revoke access, using policy and outside inputs in a "trust algorithm", and logs the decision The central system that knows the rules
Policy administrator (PA) Carries out the decision: sets up or shuts down the path between the user and the resource, and can issue session-specific credentials The controller that tells a door to unlock, and locks it again
Policy enforcement point (PEP) Enables, monitors and finally ends the connection; it can be an agent on a laptop, a gateway in front of an app, or a portal The reader and lock on the door itself

NIST groups the PE and PA together as the policy decision point (PDP), and the PE and PA talk to the PEP over a separate control plane, apart from the data itself (section 3). The document also uses an airport to explain the idea of an "implicit trust zone": everyone past the security checkpoint mills around the boarding area trusted at the same level. Zero trust tries to make that trusted area as small as possible by moving the checks closer to each resource (section 2).

The request waits at the PEP, the PE + PA check the inputs, and the gate opens for one session only

The part people tend to miss is the end of that loop. NIST says the PA can pause a session to re-authenticate, and is responsible for ending it after a time-out, when the work is done, or because of a security alert (section 3.3). The door closes behind you, and the next visit is checked again.

What goes into a decision

So what does the policy engine look at? NIST's "trust algorithm" section groups the inputs like this (section 3.3):

  • The access request itself: which resource, plus details about the requester such as OS version, the application used and patch level.
  • Identity (the subject database): who is asking, human or process, and what attributes and privileges they have. NIST advises giving privileges to each subject individually, not just because they fit a role.
  • Device health (the asset database): the known state of the device compared with what it shows now: software, integrity, location and patch level.
  • Resource requirements: the minimum bar for this resource, which can include the strength of authentication such as MFA, network location and data sensitivity.
  • Threat intelligence: feeds about active threats, which may also flag a device behaving suspiciously.

In building language: is this badge valid and is it really this person (identity), is the laptop they carry in a known, healthy state (device), is it a normal time and way to arrive (context), and how sensitive is the room (data)? A supply cupboard and a server room should not have the same bar.

CISA's maturity model: a roadmap, not a checklist

NIST explains what zero trust is. The US Cybersecurity and Infrastructure Security Agency (CISA) published a Zero Trust Maturity Model to help organisations plan how far along they are. Version 2.0 is dated April 2023 (CISA ZTMM v2.0 PDF).

It is built from five pillars: Identity, Devices, Networks, Applications and Workloads, and Data. Three cross-cutting capabilities run through all of them: Visibility and Analytics, Automation and Orchestration, and Governance (ZTMM v2.0, section 5).

Each pillar is described at four stages. Roughly, in CISA's terms:

Stage What it looks like
Traditional Manual set-up, static policies, one pillar at a time, least privilege only set at provisioning
Initial Starting to automate, some cross-pillar solutions, some least-privilege changes after provisioning
Advanced Automated controls where possible, coordinated across pillars, central visibility and identity
Optimal Fully automated, just-in-time access with dynamic policy, continuous monitoring across pillars

Two details in the document make it read like a roadmap rather than a scorecard. CISA says each pillar can progress at its own pace, which allows a gradual evolution that spreads the cost over time. It also says organisations should assess what they already have before investing in new zero trust capabilities (ZTMM v2.0, section 5). A team at "Initial" for networks and "Advanced" for identity is a normal, honest result.

Three myths worth dropping

"Zero trust is a product." NIST says plainly that zero trust is not a single architecture but a set of guiding principles, and that moving to it cannot be done just by swapping out technology (SP 800-207, section 1). Products can play the PE, PA or PEP roles. None of them is the strategy.

"Zero trust means trust nobody." The goal is not to deny everyone. It is to grant the right access, per session, based on evidence: authorised subjects get to their data, and everyone else doesn't (SP 800-207, section 2). People still get into the rooms they need. They just get checked at each door.

"We'll finish zero trust this quarter." NIST calls migration a journey and expects most organisations to run a hybrid of zero trust and perimeter-based security for an indefinite period, possibly moving one business process at a time (SP 800-207, section 7). CISA's stages say the same thing in a different shape.

A small first step

If you want to start on Monday, two things come straight out of the sources.

1. Know what you have. NIST says that before a zero trust deployment, an organisation should survey its assets, subjects (the people and services that request access), data flows and workflows. Without that knowledge, the policy engine ends up denying legitimate requests simply because it lacks information, and unknown "shadow IT" makes this worse (SP 800-207, section 7.3). You cannot put a reader on a door you don't know exists.

2. Make identity strong. In CISA's identity pillar, authentication at the Traditional stage uses passwords or MFA; Initial uses MFA; Advanced begins using phishing-resistant MFA; and Optimal keeps validating identity with phishing-resistant MFA, not only when access is first granted (ZTMM v2.0, table 2). CISA's fact sheet on the subject explains that some MFA methods are open to phishing, push bombing, SS7 exploitation or SIM swap attacks, and names FIDO/WebAuthn as the only widely available phishing-resistant option, with PKI-based MFA as the other phishing-resistant form (CISA, Implementing Phishing-Resistant MFA). It also says any MFA is better than none.

A practical way to combine the two: pick one important application, list who uses it and from which devices, and put strong authentication in front of it. That is one door with a good reader, and it teaches you most of what the next door will need.

The short version: stop trusting the lobby, put a reader on every door, and let each reader ask a well-informed central question every time someone wants in.

Sources

Keep reading

Related posts

Back to blog