NIST SP 800-207 describes zero trust architecture around two logical components: a policy engine that decides, and a policy administrator that establishes or tears down the connection. Section 5.1 states their position plainly: “No communication between enterprise resources occurs unless it is approved and possibly configured by the PE and PA.”

That sentence is the whole architecture in one line, and it is also the problem for anything that runs without a network. An ATM, a kiosk, a device in a shop back office authenticates the person standing in front of it. There is no path to a policy engine at that moment — not because something broke, but because that is how the device is deployed.

What the document actually says about unreachability

It does address it, and it is worth quoting rather than paraphrasing, because the framing matters more than the fact.

Section 5.2, Denial-of-Service or Network Disruption:

If an attacker disrupts or denies access to the PEP(s) or PE/PA (i.e., DoS attack or route hijack), it can adversely impact enterprise operations. Enterprises can mitigate this threat by having the policy enforcement reside in a properly secured cloud environment or be replicated in several locations following guidance on cyber resiliency.

And immediately after, a concession that is easy to skip past:

This mitigates the risk but does not eliminate it.

The section closes by noting that an operational error at a hosting provider “could prevent an entire enterprise from functioning if the policy engine or policy administrator component becomes inaccessible from the network.”

Every mitigation on offer is availability engineering: put the components somewhere robust, replicate them, follow the cyber-resiliency guidance. That is the right answer when unreachability is a failure. It is not an answer when unreachability is the design.

The document goes further in Appendix B, which lists what its authors considered unsettled. Section B.4.7 is titled Resilience of ZTA to Enterprise and Network Disruption, and it belongs to a list introduced as “gray areas in knowledge about operational ZTA environments” that are “areas of future work for researchers.” Its example is a cloud-hosted policy engine that survives a DDoS but cannot reach the enforcement points sitting with the resources.

So the honest summary is this: SP 800-207 knows the case exists, offers availability engineering for it, admits that does not close the gap, and files the remainder as research. An implementer with genuinely disconnected devices is not being negligent by finding no recipe there. There isn’t one.

The tenet that actually bites

The awkward requirement is not connectivity as such. It is tenet 6:

All resource authentication and authorization are dynamic and strictly enforced before access is allowed. This is a constant cycle of obtaining access, scanning and assessing threats, adapting, and continually reevaluating trust in ongoing communication.

A constant cycle needs something to cycle against. On a device that sees the network occasionally, or never, continual re-evaluation is not available at any price. Neither is tenet 5’s continuous diagnostics of asset posture, nor tenet 7’s collection of current state to feed back into policy.

This is where a lot of vendor writing quietly cheats, by describing a scheme that satisfies the tenets and then applying it to devices that cannot satisfy them. Worth being precise instead: those tenets are not met on a disconnected device. What can be met is the part that matters most for the sign-in decision — that trust is evaluated per session, that network location grants nothing, and that no asset is trusted by virtue of being inside a perimeter.

Moving the decision in time rather than in space

There is more than one way to live with this. A device can cache the last decision it received and act on it until it goes stale. A policy engine can be replicated down to the branch or onto the device itself — section 5.2’s advice taken to its limit. Access can be granted locally and reconciled centrally afterwards. Each trades something different: freshness, operational surface, or accountability for what happened in the gap.

The reading we work from is that the policy decision does not have to happen at the same moment as the access request. It has to happen before it, under enterprise control, with a result the device can verify on its own.

In practice that means the evaluation runs when a credential is issued — identity, the role that is opened, which devices it applies to, until when — and the outcome is sealed with a signature. The device holds the enforcement point and verifies the signature, the validity period, the scope and the revocation list locally. Connectivity is needed to manage the fleet, not to open the door. The mechanics on Linux are covered in our earlier piece on Zero Trust across a Linux estate.

What is genuinely lost is worth naming. Continual re-evaluation collapses into two coarser instruments: a short validity period, so that a decision expires on its own, and a revocation list, which reaches a given device on its own schedule rather than instantly. Between the moment a decision changes centrally and the moment the device learns of it, the device is acting on stale policy. That interval is bounded and measurable, and shortening it costs credential lifetime and distribution frequency — an explicit trade, not a solved problem.

Honest boundaries

SP 800-207 is guidance, not a conformance standard. It defines no certification and no test, so “compliant with 800-207” is not a claim anyone can make — including us. What the document supports is an argument: which tenets a design meets, which it approximates, and which it cannot meet on a given class of device.

For unattended devices that argument has a clear shape. Per-session evaluation, no trust from network location, no implicit trust in the asset — met. Continual re-evaluation, continuous posture monitoring, real-time context — not met, and replaced by bounded validity and revocation with a stated propagation window. A reader who wants a stronger claim than that should be suspicious of who is offering it.

Sources