NIST SP 800-207 (Zero Trust Architecture): NIST SP 800-207 – Tutorial (about 60 minutes)

NIST Special Publication 800-207, Zero Trust Architecture, is the United States National Institute of Standards and Technology's vendor-neutral description of what "zero trust" means and how an organisation can build security around it. Security architects, network and identity engineers, cloud teams, auditors and public-sector programme managers around the world use it as the common reference model when they plan, buy or assess zero trust capabilities. After this tutorial you will be able to explain the ideas behind zero trust, name and place the logical components of a zero trust architecture, follow an access decision from request to enforcement, and plan a realistic, step-by-step migration for your own environment.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: This tutorial teaches NIST SP 800-207, Zero Trust Architecture, final version published in August 2020 by NIST (authors from NIST, Stu2Labs and the US Department of Homeland Security). It followed a first public draft in September 2019 and a second draft in February 2020. As of the verification date the NIST Computer Security Resource Center lists it as final and current, with no withdrawal, no errata and no draft revision announced. NIST has since added companion publications rather than rewriting it: SP 800-207A (September 2023) on access control for cloud-native applications across multiple clouds, the planning guide CSWP 20 (2022), and the practice guide SP 1800-35, Implementing a Zero Trust Architecture (final in June 2025). Verified 2026-10-29.

Who it is for: engineers, architects, security and compliance staff, IT managers and project people who keep hearing "zero trust" and want a solid, accurate foundation. It is equally useful if you work in a private company; SP 800-207 was written with US federal agencies in mind, but almost everything in it applies to any enterprise.

Prerequisites: none. A general idea of what networks, user accounts, firewalls and cloud services are will help, and every special term is explained the first time it appears.

Learning objectives. After completing this tutorial you will be able to:

Explain why the traditional "trusted inside, untrusted outside" perimeter model no longer fits modern enterprises, and what zero trust changes.
Describe the seven tenets of zero trust in SP 800-207 in your own words and recognise them in real designs.
Identify the policy engine, policy administrator, policy enforcement point and their supporting data sources, and trace an access request through them.
Compare the three architectural approaches and the main deployment models the publication describes.
Explain how a trust algorithm combines identity, device, resource and threat information into a decision.
Plan a phased migration using the publication's steps, and explain how progress is measured when no formal certification exists.
Relate SP 800-207 to companion and neighbouring frameworks such as SP 800-207A, SP 1800-35, the CISA Zero Trust Maturity Model and the NIST Cybersecurity Framework.

Lesson 1 – Origins, purpose and scope

The problem with the castle and moat

For decades most organisations protected their systems the way a medieval town protected itself: build a strong wall, guard the gates, and treat everyone inside as a friend. In network terms the wall was the firewall at the edge of the corporate network, the gates were the VPN and the internet connection, and "inside" meant any device plugged into the office network or connected through the VPN. Once you were inside, you could usually reach file servers, databases and administration consoles with little further checking. Security people call this implicit trust: trust granted simply because of where a connection comes from.

That model has three serious weaknesses. First, attackers who get past the wall once, for example with a stolen password or a phishing email that installs malware on one laptop, can then move sideways (laterally) through the network for weeks, because nothing inside asks them to prove who they are again. Many of the most damaging breaches of the last twenty years followed exactly this pattern. Second, the wall no longer surrounds the things that matter. Staff work from home and from mobile phones, applications run in several public clouds and software-as-a-service platforms, and contractors and partners need access to some systems but not others. Third, the location of a connection says very little about whether it is safe: a device on the office network might be infected, while a well-managed laptop on a hotel network might be perfectly healthy.

Figure 1 – The perimeter model trusts whatever is inside the wall, while zero trust checks each request and grants access to a single resource at a time.

Where zero trust came from

The ideas behind zero trust grew over many years. In the mid-2000s a group of large companies called the Jericho Forum argued for "de-perimeterisation", meaning that security should move from the network edge to the data and systems themselves. Around 2010 an analyst at the research firm Forrester, John Kindervag, popularised the term "zero trust" and the slogan often summarised as "never trust, always verify". In the following years Google described its internal BeyondCorp programme, which let employees work from untrusted networks without a classic VPN by checking user and device for every request. Inside the US government, the Defense Information Systems Agency (DISA) and the Department of Defense had already explored a "black core" strategy that moved security from the perimeter to individual transactions.

By 2019 the term was everywhere, but it meant different things to different vendors. Some used it for a firewall product, others for an identity service. NIST, in a project overseen by the Federal Chief Information Officer Council and with co-authors from the Department of Homeland Security, set out to write a neutral description that explains the concepts and a reference architecture without endorsing any product. The result was SP 800-207, released as a final publication in August 2020.

Purpose and scope

SP 800-207 is a guideline, not a regulation. NIST publications in the 800 series are written for US federal agencies and their contractors, and agencies often adopt them because other policies point to them. Private organisations use them voluntarily because they are free, well reviewed and independent of vendors. SP 800-207 has three main goals:

to give a common vocabulary and an abstract definition of zero trust and zero trust architecture (ZTA);
to describe the logical building blocks, several ways of combining them, and typical use cases;
to help organisations, especially federal agencies, plan a gradual move from a perimeter design to a zero trust design, including the threats that the new design itself introduces.

Just as important is what the publication does not do. It does not list mandatory controls, it does not name products, it does not offer a maturity scale or a certification, and it does not say that an organisation must throw away its existing network. It states plainly that most enterprises will run a hybrid of perimeter-based and zero trust designs for a long time. Zero trust, in the NIST view, is a journey of continuous improvement, not a box you tick once.

Why it became the reference

Two events turned SP 800-207 from a useful paper into a central document. In May 2021 US Executive Order 14028, Improving the Nation's Cybersecurity, directed federal agencies to plan their move to a zero trust architecture and referred to NIST guidance. In January 2022 the Office of Management and Budget issued memorandum M-22-09, a federal zero trust strategy that set agency goals to be reached by the end of fiscal year 2024. Around the same time the Cybersecurity and Infrastructure Security Agency (CISA) published its Zero Trust Maturity Model, and the Department of Defense published its own Zero Trust Strategy. All of these build on the model in SP 800-207, so anyone working with them needs to understand it first.

Lesson 2 – Key concepts and vocabulary

SP 800-207 uses a small set of carefully chosen words. Learning them makes the rest of the publication, and most zero trust conversations, much easier to follow. The definitions below are paraphrased.

Zero trust (ZT) – a collection of concepts and ideas aimed at making access decisions that are accurate, least-privilege and made per request, in a network that must be assumed to be compromised. It is a security philosophy, not a product.
Zero trust architecture (ZTA) – an enterprise's cybersecurity plan that applies zero trust concepts: the relationships between its components, the workflow plans and the access policies. A ZTA is something you design for your own organisation.
Zero trust enterprise – the network infrastructure, physical and virtual, plus the operational policies that an organisation has put in place as a result of its ZTA plan.
Resource – anything the enterprise wants to protect and control access to: data, an application, a service, a workload, a device or a computing function. SP 800-207 treats all of these as resources.
Subject – the person or thing requesting access to a resource. Subjects include human users, applications, services and devices acting on their own.
Asset – a device or piece of infrastructure, such as a laptop, server, phone, virtual machine or sensor. A subject uses an asset to make a request; the asset's health matters to the decision.
Non-person entity (NPE) – a subject that is not a human, such as a service account, an automated script or an artificial-intelligence agent. NPEs need identities and policies just like people do.
Implicit trust zone – an area where all entities are trusted at least to the level of the last checkpoint they passed. A ZTA tries to make these zones as small as possible, ideally just the resource behind its enforcement point.
Least privilege – giving a subject only the access it needs for the task at hand, for only as long as it needs it, and nothing more.
Policy decision point (PDP) – the logical function that decides whether a request is allowed. In SP 800-207 it is made up of the policy engine and the policy administrator.
Policy engine (PE) – the "brain" that evaluates a request against enterprise policy and outside information, using a trust algorithm, and decides to grant, deny or revoke access.
Policy administrator (PA) – the component that turns the engine's decision into action: it tells enforcement points to open or close a communication path and may issue a session-specific credential or token.
Policy enforcement point (PEP) – the gatekeeper on the path between subject and resource that enables, monitors and ends connections according to the administrator's instructions.
Trust algorithm (TA) – the process the policy engine uses to weigh the inputs about a request and reach a decision.
Control plane and data plane – the control plane carries the messages that make and communicate decisions (between PEP, PA and PE); the data plane carries the actual application traffic between subject and resource. SP 800-207 recommends keeping them logically separate.
Micro-segmentation – dividing the network into many small segments, each protected by its own enforcement point, so that compromise of one segment does not open the others.
Software-defined perimeter (SDP) – an approach in which an overlay network hides resources until a controller has authorised a specific subject to reach them.
Continuous diagnostics and mitigation (CDM) – systems that gather the current state of enterprise assets (patch level, configuration, installed software) and feed it into decisions. In the US government it is also the name of a DHS programme.

Notice how the vocabulary shifts attention. In a perimeter world the key words are "inside", "outside" and "network zone". In SP 800-207 they are "subject", "resource", "session" and "policy". The location of the network is just one signal among many.

Lesson 3 – Structure of the publication and its core ideas

A map of the document

SP 800-207 is a fairly short publication of about fifty pages, organised into seven main sections, a reference list and two appendices. Knowing the map helps you find the right part quickly.

Section 1, Introduction – history of zero trust in the federal government and the purpose of the document.
Section 2, Zero Trust Basics – the seven tenets and the view of the network that a ZTA assumes.
Section 3, Logical Components – the PE, PA, PEP and data sources, three architectural approaches, four deployment models, the trust algorithm and network requirements.
Section 4, Deployment Scenarios and Use Cases – typical situations such as branch offices, multiple clouds, contractors and public-facing services.
Section 5, Threats Associated with ZTA – what can go wrong with the new design itself.
Section 6, Interaction with Existing Federal Guidance – how ZTA fits the Risk Management Framework, the Privacy Framework, identity programmes, Trusted Internet Connections and other federal initiatives.
Section 7, Migrating to a ZTA – pure versus hybrid designs and a sequence of planning steps.
References and appendices – a reference list, then Appendix A (acronyms) and Appendix B (gaps in the state of the art that prevented an immediate move to ZTA at the time).

The seven tenets

The heart of the publication is a list of seven tenets, the principles an ideal ZTA would follow. NIST is careful to say these are goals; not every organisation can meet all of them fully, and some will apply them only to part of the enterprise. Here they are in plain words.

Everything is a resource. All data sources and computing services count as resources, including small devices, personal devices allowed onto the network and cloud services. If it holds or processes enterprise data, it is in scope.
All communication is secured, wherever it happens. Being on the corporate network does not make a connection trustworthy. Traffic inside the office deserves the same protection (confidentiality, integrity, source authentication) as traffic across the internet.
Access is granted per session, per resource. Trust is evaluated before access is given, and that access covers one resource for one session. Logging in to one system does not automatically open another.
Access is decided by dynamic policy. The decision considers the identity of the client, the application or service requested, the state of the requesting asset, and other behavioural and environmental attributes such as time, location or unusual activity. Policy is based on business needs and the enterprise's acceptable risk.
The enterprise monitors the security posture of all its assets. No asset is trusted by default. The organisation keeps measuring whether devices are patched, configured correctly and free of known compromise, and treats unhealthy devices differently.
Authentication and authorisation are dynamic and strictly enforced before access. This is a continuous cycle: obtain access, scan and assess threats, adapt, and re-evaluate trust during the session. It usually requires strong identity, multi-factor authentication and a way to re-authenticate when conditions change.
The enterprise collects as much information as it can and uses it to improve. Data about assets, network traffic and access requests feeds better policies and better decisions over time.

A useful way to remember them: tenets 1 and 2 define what is protected and that location gives no free pass; tenets 3, 4 and 6 describe how access is granted; tenets 5 and 7 describe the feedback loop of monitoring and learning.

The network view behind the tenets

Section 2 also lists assumptions about the network that a ZTA should be designed for. In paraphrase: the private enterprise network is not an implicit trust zone; devices on the network may not be owned or configurable by the enterprise (guests, contractors, personal phones); no resource is inherently trusted, so every asset's posture must be evaluated; not all resources live on enterprise infrastructure (cloud and software-as-a-service); remote subjects cannot trust the local network they connect through; and assets and workflows that move between enterprise and non-enterprise infrastructure should keep a consistent security policy. These assumptions explain why the architecture puts checks next to each resource rather than at a single border.

Three approaches to building a ZTA

Section 3 describes three broad approaches. They are not exclusive; real designs mix them, but one usually leads.

Enhanced identity governance – the identity of the subject, and the privileges attached to it, is the main driver of policy. Device health and environment adjust the decision. This approach fits organisations that rely heavily on cloud and software-as-a-service applications, where they cannot control the network.
Micro-segmentation – resources or small groups of resources are placed in their own segments behind gateways, such as next-generation firewalls or host-based agents, that act as PEPs. This fits data centres and workloads the organisation controls.
Network infrastructure and software-defined perimeters – the network itself is programmed to create paths only for authorised sessions, often using an overlay network and software-defined networking. Resources stay invisible until access is granted.

Deployment models

The publication also describes four ways to arrange the components. In the device agent and gateway model, a software agent on the user's device talks to the policy administrator and a gateway sits directly in front of each resource. In the enclave model, the gateway protects a group of resources, such as a legacy application cluster, rather than each one. In the resource portal model, users reach resources through a portal or gateway without needing an agent, which suits contractors and personal devices but gives less information about device health. In the device application sandboxing model, approved applications run in isolated compartments (such as containers or virtual machines) on the device, protecting them from the rest of a possibly compromised machine. Choosing among these is a practical trade-off between control, visibility and convenience.

Use cases and threats

Section 4 walks through typical situations: an enterprise with satellite offices and remote staff; multiple cloud providers; contractors and visitors who need internet access or a few services but not the whole network; collaboration across organisational boundaries; and public-facing services where the enterprise cannot vet every user. Section 5 then reminds readers that the new design has its own risks. The decision process itself can be subverted if attackers or careless administrators change policy; the PA and PEP can become a single point of failure if they are unavailable; stolen credentials and insiders remain a risk, although their reach is smaller; encrypted traffic is harder to inspect; the logs and policy data that a ZTA collects become a valuable target; dependence on proprietary formats can lock an organisation to one vendor; and automated non-person entities that administer the ZTA need careful control. A good ZTA plan addresses each of these.

Lesson 4 – How it works in practice: components, decisions and migration

The logical components

SP 800-207 describes its architecture logically, meaning by function rather than by product. One commercial product might provide several functions, or one function might be spread across several products. The key idea is the separation between deciding and enforcing.

Figure 2 – The policy engine and administrator form the decision point, the enforcement point sits on the path to the resource, and many data sources inform each decision.

The policy engine receives information about a request, applies the trust algorithm and decides. It logs every decision. The policy administrator carries out the decision: it instructs the PEP to open a session, and in some designs creates a session-specific token or credential for the subject. If the engine later decides that access should end, the administrator tells the PEP to close the path. Together they form the policy decision point. The policy enforcement point is where the request actually passes. It might be a single gateway in front of a resource, or split into an agent on the client and a gateway next to the resource. Beyond the PEP lies only the resource itself, which is the smallest possible implicit trust zone.

The decision point relies on data sources. SP 800-207 names several kinds: a continuous diagnostics and mitigation system with device posture; industry or regulatory compliance requirements; threat intelligence feeds; network and system activity logs; data access policies that define who may use which data; the enterprise public key infrastructure (PKI) that issues certificates; the identity management system with user accounts and attributes; and a security information and event management (SIEM) system that collects security events. The more reliable these sources, the better the decisions.

Following one request

The sequence below shows a typical access request in a device agent and gateway design. Every step happens in seconds or less and is invisible to a well-served user.

Figure 3 – An access request travels through the enforcement point to the decision point and back, and the session can be cut off later if conditions change.

Two details matter. First, the decision is about a session with one resource, not about the whole network. Second, the last two arrows show continuous evaluation: if the device suddenly reports malware, or threat intelligence flags the user's account, the engine can revoke access mid-session. This is what people mean when they say zero trust is "continuous".

The trust algorithm

The trust algorithm is the reasoning inside the policy engine. SP 800-207 does not prescribe one algorithm; it describes the kinds of input and some design choices.

The inputs are: the access request itself (which resource, what action, from which asset and software version); the subject database (identity, roles, attributes, privileges and past behaviour); the asset database and observed state of the requesting device (managed or not, patch level, location, configuration); the resource's own policy requirements (for example, "finance staff only, managed device, strong authentication"); and threat intelligence plus logs (known attacks, suspicious patterns).

The publication describes two pairs of design choices. A criteria-based algorithm checks a set of qualifying attributes that must all be met, like a checklist, before access is granted. A score-based algorithm computes a confidence value from the inputs and compares it with a threshold set for the resource; it can allow fine adjustments, such as granting read access at a lower score than write access. A singular algorithm treats each request on its own, with no memory, while a contextual algorithm considers the subject's recent history, so that unusual behaviour, such as one account suddenly downloading thousands of records, can lower trust. NIST says a trust algorithm should ideally be contextual, but that this is not always possible with the infrastructure an enterprise has, and that security must be balanced with usability and cost: prompting people to re-authenticate when their behaviour is normal for their role only creates friction.

Network requirements

For the components to work, the infrastructure must meet some conditions, which SP 800-207 lists. In summary: the enterprise must be able to tell its managed assets from others and know their posture; it must be able to observe network traffic; resources should not be reachable except through a PEP; the control plane and data plane should be logically separated; remote assets should reach resources without first passing through the corporate network; and the decision infrastructure must scale to the load and stay available. These conditions explain why identity, device management and logging are usually the first investments in a zero trust programme.

Migrating: the planning steps

Section 7 is where theory meets reality. NIST distinguishes a pure ZTA, possible only in a new (greenfield) environment, from the common hybrid situation, in which zero trust and perimeter designs work side by side for years. For the hybrid path it gives a sequence of planning steps.

Figure 5 – The migration steps in SP 800-207 form a loop: after the first workflow is protected, the enterprise returns to assess and add the next one.

Identify actors. Build a picture of who and what makes requests: employees, contractors, administrators, service accounts and other non-person entities, with their privileges. Highly privileged accounts deserve special attention.
Identify assets. Inventory devices and resources, managed and unmanaged, including cloud services and "shadow IT" that grew without approval. You cannot protect what you do not know about.
Identify key processes and evaluate risks. List the business workflows, such as payroll, claims processing or software builds, rank them by value and risk, and pick a first candidate. NIST suggests starting with a low-risk process, so that early mistakes do not disrupt the whole organisation, and notes that workflows using cloud resources or used by remote workers are often good candidates.
Formulate policies. For the chosen workflow, decide which subjects may reach which resources, under what conditions, and what the PEPs and trust algorithm should check. Policies should follow least privilege.
Identify candidate solutions. Only now evaluate products and services, asking whether they fit the chosen deployment model, need agents on devices, support the existing infrastructure, and avoid lock-in.
Initial deployment and monitoring. Start in an observation mode in which policies are logged but not strictly enforced, or are relaxed, so the team can learn normal behaviour and tune rules without blocking work. Then tighten.
Expand. When the first workflow is stable, move to the next one, and keep reviewing the policies as the business changes.

The order is deliberate. A common mistake is to start at step 5, buying a product labelled "zero trust" before anyone knows which workflows and actors it should protect.

Lesson 5 – Assessment, certification and compliance

There is no SP 800-207 certificate

The most important fact for this lesson: there is no formal certification against NIST SP 800-207. NIST does not certify organisations or products against it, and it is written as guidance, without "shall" requirements an auditor could test line by line. It is a conceptual and architectural guideline. When a vendor says its product is "800-207 compliant" or "aligned", that is a marketing statement about how the product maps to the logical components, not a result of an official test. Treat such claims as a starting point for questions, not as evidence.

How progress is measured in practice

Because the publication has no built-in assessment scheme, organisations measure zero trust progress with other tools that build on it.

CISA Zero Trust Maturity Model. CISA's model, version 2.0 released in April 2023, organises zero trust into five pillars (identity, devices, networks, applications and workloads, data) and three cross-cutting capabilities (visibility and analytics, automation and orchestration, governance). For each pillar it describes four stages: Traditional, Initial, Advanced and Optimal. Agencies and many companies use it to rate where they are and plan the next stage. CISA's web page for it is now marked as archived, but the model remains widely used.
Federal policy goals. OMB memorandum M-22-09 (January 2022) gave US agencies specific objectives, for example phishing-resistant multi-factor authentication for staff, a complete inventory of devices, encrypted traffic, and treating applications as internet-connected, with a target of the end of fiscal year 2024. The US Department of Defense uses its own Zero Trust Strategy with target and advanced levels of capability.
Control frameworks. Many teams map their zero trust capabilities to controls in NIST SP 800-53 or to outcomes in the NIST Cybersecurity Framework, which can be assessed. The NCCoE practice guide SP 1800-35 includes mappings of zero trust principles and technologies to commonly used security standards and guidelines.
Internal metrics. Useful measures include the share of applications behind an enforcement point, the share of users with phishing-resistant authentication, the share of managed devices reporting posture, the number of standing administrative privileges removed, and how quickly access can be revoked.

Assessing a ZTA design

Even without a certificate, an auditor or architect can review a design against SP 800-207 with a few questions. Is every resource reachable only through an enforcement point? Are decisions made per session and per resource, or does one login still open the whole network? Which data sources feed the policy engine, and how reliable and timely are they? Is the decision infrastructure resilient, so that its failure does not stop the business or leave everything open? Who can change policies, and are those changes reviewed and logged? Are non-person entities covered? Are the logs protected, since they are now a rich target? Answers to these questions show how far the organisation has applied the tenets, and they map naturally to the threats listed in Section 5 of the publication.

Relationship to compliance obligations

For US federal agencies, following SP 800-207 is part of meeting federal zero trust policy, and agencies use the Risk Management Framework (SP 800-37) to authorise systems built on ZTA. For contractors, zero trust capabilities often help meet requirements such as those in NIST SP 800-171, but SP 800-207 itself is not usually written into contracts as a pass/fail standard. For private companies the publication is entirely voluntary; its value is that it gives a shared, independent model that boards, auditors and suppliers understand.

Lesson 6 – Worked example: a regional insurer adopts zero trust

Let us tie everything together with a realistic, fictional organisation. Harbourline Insurance is a regional insurer with about 1,800 employees, three offices, a large group of home-based claims handlers, and around 200 contractors who help during storm seasons. Its core claims system runs in its own data centre; email, collaboration and customer relationship management are software-as-a-service; and a new customer portal runs in a public cloud. Everyone connects through a VPN, and once connected they can reach almost every internal server.

The trigger

A contractor's laptop was infected through a malicious attachment. Using the VPN, the malware scanned the internal network and reached a file share with policyholder data before it was noticed. Nothing was stolen, but the board asked the chief information security officer for a plan that would stop a single infected device from reaching everything. The team chose SP 800-207 as its reference model because it is vendor-neutral and well known to regulators and auditors.

Step 1 – Actors

The team listed its subject types: office staff, home-based claims handlers, seasonal contractors, IT administrators, a small development team, and about 350 service accounts used by integrations and scheduled jobs. They discovered that 40 people had permanent domain administrator rights, and that many service accounts had passwords that never changed. These became early priorities.

Step 2 – Assets

Device management tools showed 2,100 managed laptops and phones, but network scans found several hundred more devices, including personal tablets and old servers nobody owned. The team began a proper inventory, recording owner, data held and patch status, and connected the device management system so that posture could later feed the policy engine.

Step 3 – Processes and risk

The team ranked workflows by business value and risk. Claims handling, which uses policyholder personal data and payment details, ranked highest. Contractor access ranked highest for likelihood of compromise, since contractors used their own laptops. NIST suggests a low-risk first process, but the team accepted a little more risk and decided to start with contractor access to the claims system, because it addressed the incident directly, touched a manageable number of users and could run beside the VPN without affecting staff.

Step 4 – Policies

For this workflow they wrote policies in plain language first. Contractors may reach only the claims application, not file shares or servers. They must sign in with phishing-resistant multi-factor authentication. Because their devices are not managed, they get access only through a browser-based portal, with downloads and copying of data blocked. Access is limited to their contract dates and normal working hours of their region; access at other times needs a supervisor's approval. Claims handlers who are employees, on managed devices that report healthy posture, get full application access including attachments. Any device reporting malware, or any account flagged by threat intelligence, loses access immediately.

Step 5 – Candidate solutions

Mapping these policies to SP 800-207, the team chose a resource portal model for contractors (no agent needed on devices they do not own) and a device agent and gateway model for employees (rich posture information). Their existing identity provider would act as part of the policy engine, combined with an access gateway product as policy administrator and enforcement point. During evaluation they asked vendors how decisions could be exported in open formats, to reduce lock-in, and how the gateways behaved if the decision service was unavailable.

Step 6 – Initial deployment

The new path ran for four weeks in observation mode next to the VPN. Logs showed that some contractors legitimately needed a reporting tool the team had forgotten, so the policy was updated. They also found that the score-based rule for unusual sign-in locations produced too many false alarms for staff travelling between offices; they adjusted the threshold and added a step-up authentication prompt instead of a straight denial. Then contractors were moved off the VPN completely, and the claims servers were placed in a micro-segment that accepts connections only from the gateway.

Step 7 – Expand

With the first workflow running, Harbourline went back to step 3. Next came administrator access: standing domain administrator rights were replaced with just-in-time elevation through the same decision point, with every elevation logged. Then the developers' access to cloud workloads, where the team followed SP 800-207A to apply identity-based policies between services. The VPN is planned to be retired for staff within two years; until then the insurer runs a hybrid architecture, exactly as NIST expects.

Measuring progress

The security team reports quarterly on a short set of measures: the share of applications behind an enforcement point, phishing-resistant authentication coverage, managed devices reporting posture, standing privileged accounts, and mean time to revoke access after an alert. To communicate with the board they use the CISA maturity stages, rating each pillar honestly; identity reached "Advanced" in the first year while data protection remained "Initial". No certificate was involved at any point; the evidence was the design, the logs and the measures.

What the example shows

Harbourline did not "buy zero trust". It used the tenets to set direction, the logical components to describe its design, the deployment models to fit different user groups, the trust algorithm to define decisions, and the migration steps to move one workflow at a time. It also considered the threats from Section 5: resilience of the decision service, protection of logs, control over policy changes and vendor lock-in.

Lesson 7 – Relationship to other standards and frameworks

SP 800-207 is the conceptual core of a family of zero trust documents, and it sits next to broader security frameworks. Understanding the relationships prevents a common confusion: trying to use one document for a job another was written for.

Document	Owner and type	Relationship to SP 800-207
NIST SP 800-207A (2023)	NIST, architecture guideline	Extends the model to cloud-native applications in multiple clouds, with identity-based policies enforced by API gateways, service-mesh sidecar proxies and workload identities.
NIST SP 1800-35 (2025)	NIST National Cybersecurity Center of Excellence, practice guide	Shows how to build ZTA with commercial products: example implementations built with industry collaborators, lessons learned and mappings to security controls.
NIST CSWP 20 (2022)	NIST, planning guide	Explains how to plan a ZTA using the Risk Management Framework steps, for administrators and managers.
CISA Zero Trust Maturity Model 2.0 (2023)	US CISA, maturity model	Turns zero trust concepts into five pillars, three cross-cutting capabilities and four maturity stages, used to measure progress.
US DoD Zero Trust Strategy (2022) and reference architecture	US Department of Defense, strategy	Applies zero trust across defense systems with seven pillars and target capability levels; builds on the same core ideas.
NIST Cybersecurity Framework 2.0 (2024)	NIST, outcome framework	Describes overall cybersecurity outcomes (govern, identify, protect, detect, respond, recover); a ZTA is one way to achieve many protect and detect outcomes.
NIST SP 800-53 Rev. 5	NIST, control catalogue	Provides assessable controls, such as access control and system monitoring, that a ZTA implements; used when systems must be authorised.
ISO/IEC 27001	ISO and IEC, management system standard	Certifiable framework for managing information security; a ZTA can be one of the measures chosen in its risk treatment.

A simple way to remember the family: SP 800-207 says what zero trust is and its logical parts; SP 800-207A applies it to cloud-native services; CSWP 20 helps you plan; SP 1800-35 shows how to build it with real products; the CISA model helps you measure it; and control frameworks such as SP 800-53, the CSF and ISO/IEC 27001 let you govern and assess it as part of the wider security programme.

Zero trust also overlaps with industry terms you will meet. Secure access service edge (SASE) and security service edge (SSE) describe cloud-delivered bundles of networking and security functions; zero trust network access (ZTNA) usually refers to products that replace VPNs with per-application access. These product categories can implement parts of SP 800-207, especially the PEP and PA roles, but none of them is a complete ZTA by itself, because a ZTA also needs identity governance, device posture, data policies, monitoring and an organisational plan.

Common pitfalls and best practices

Pitfalls

Treating zero trust as a product. Buying a tool labelled "zero trust" without a policy model, inventory or workflow plan usually moves the perimeter rather than removing implicit trust.
Trying to convert everything at once. A "big bang" migration breaks business processes and loses support. SP 800-207 expects a gradual, hybrid path.
Ignoring non-person entities. Service accounts, scripts, workloads and automated agents often hold more privilege than people; leaving them out leaves the biggest doors open.
Making the decision point a single point of failure. If the policy engine or administrator goes down and there is no plan, either the business stops or teams create risky bypasses.
Weak data sources. A trust algorithm fed by an incomplete asset inventory or stale identity data makes confident but wrong decisions.
Forgetting to protect the policy and logs. Whoever can change policy controls access to everything; the collected logs reveal the whole environment to an attacker.
Too much friction. Constant prompts and false denials push users to workarounds. Poorly tuned contextual rules are a common cause.

Best practices

Start with identity. Consolidate identities, remove standing privileges and roll out phishing-resistant multi-factor authentication early; most other capabilities depend on it.
Know your assets and data. Build and maintain inventories of devices, applications and data, with owners, before writing detailed policies.
Pick one workflow and learn. Choose a valuable but manageable first workflow, run it in observation mode, tune, then enforce and expand.
Write policies in business language first. Agree with business owners who needs what and when, then translate into technical rules.
Design for resilience and openness. Make the decision service highly available, define fail-safe behaviour, and prefer solutions that use open, exportable formats.
Govern policy changes. Review, approve and log every change to access policy, and restrict who can make them.
Measure and report honestly. Use a maturity model and a few clear metrics to show progress over time, rather than claiming to be "fully zero trust".

Summary and key takeaways

NIST SP 800-207 (final, August 2020, still current) is a vendor-neutral guideline that defines zero trust, zero trust architecture and their logical components.
Zero trust removes implicit trust based on network location; every request to a resource is checked on identity, device state and context.
Seven tenets guide the design: everything is a resource, all communication is secured, access is per session, decided by dynamic policy, based on monitored asset posture, strictly enforced before access, and continuously improved with collected data.
The policy engine decides, the policy administrator acts on the decision, and the policy enforcement point controls the connection; many data sources feed the decision.
Architectures lean on enhanced identity governance, micro-segmentation or software-defined perimeters, and can be deployed as agent and gateway, enclave, resource portal or application sandbox models.
Migration is gradual and usually hybrid: identify actors, assets and processes, write policies, choose solutions, deploy in observation mode, then expand.
There is no SP 800-207 certification; progress is measured with tools such as the CISA Zero Trust Maturity Model, federal policy goals, control frameworks and internal metrics.
Companion documents, SP 800-207A, CSWP 20 and SP 1800-35, apply, plan and implement the model in more detail.

Reflection questions

Think of one system in your organisation that anyone on the internal network can reach today. What would its enforcement point be, and which conditions should the policy engine check before granting a session?
Which of the seven tenets would be hardest for your organisation to meet, and what would be a realistic first step toward it?
Your organisation has many contractors using their own devices. Which deployment model would you choose for them, and what information would you lose compared with managed devices?
If your policy decision service became unavailable for an hour, what should happen to existing and new sessions, and how would you decide?
How would you explain to your leadership, in five sentences, why buying a single "zero trust" product will not make the organisation zero trust?