The National Security Agency is applying one of cybersecurity’s most familiar ideas—zero trust—to systems that control water pumps, factory machinery, building equipment and other physical processes.
The principle is straightforward: assume that a network or account may already be compromised, and verify important connections rather than trusting them because they are inside a facility or belong to an approved user. The difficulty begins when the protected asset is not a laptop or cloud application, but a programmable controller that must keep a physical process running.
Operational technology, or OT, includes the systems that monitor or change conditions in the physical world. It can control industrial equipment, building automation, transportation systems, water and wastewater operations, laboratory facilities and other infrastructure. These systems often prioritize safety, predictable timing and continuous availability over the features expected in modern enterprise software.
That difference is why zero trust in OT cannot mean simply installing another identity product or placing a firewall around an old controller. It is more accurately a set of protective layers around equipment that may be too old, too specialized or too operationally important to replace immediately.
What the new guidance actually says
In guidance released October 8, the National Security Agency recommends zero-trust mitigation principles for operational technology in national-security systems, the Department of War and the defense industrial base. The agency says the guidance is also relevant to technical leaders and OT managers beyond those environments.
The NSA’s premise is not that organizations can guarantee the absence of intruders. It is that adversarial access may already exist, and that continuous verification can limit unauthorized access, lateral movement and persistence. For legacy OT, that means using controls around vulnerable equipment rather than pretending the equipment can instantly become modern.
The guidance is arriving alongside the initial public draft of NIST Special Publication 800-82 Revision 4, released September 21. NIST’s draft expands recommendations involving asset management, network monitoring, management-function security and zero-trust principles. Comments are open through November 30, 2026.
NIST describes OT as distinct from ordinary information technology because security decisions must account for performance, reliability and safety. That distinction is not a technical footnote. It changes what a security failure means.
On an office network, a failed authentication service may prevent employees from opening an application. In a control environment, the same dependency may interfere with monitoring, maintenance or command authority over a physical process. The result may be a security problem, an operational problem or both.
Verification can become a dependency
Enterprise zero trust is generally built around identity, policy and continuous evaluation. NIST’s foundational SP 800-207 describes zero-trust architecture as an approach that grants no implicit trust based solely on network location or ownership.
That model is useful. But an OT operator must ask a further question: what happens when the systems performing the verification are unavailable?
A plant, water facility or building may depend on centralized identity services, remote-access brokers, time synchronization, network-management tools, security monitoring, certificate authorities, cloud dashboards and configuration databases. If one of those services fails or is compromised, operators may have to choose between maintaining strict access controls and restoring the visibility or command functions needed to keep the process safe.
They may continue operating with uncertain device status. They may bypass a control to regain access. They may disconnect a vendor’s remote-management platform. Or they may shut down part of a physical process while determining whether the security system itself can be trusted.
None of those choices means zero trust has failed. They demonstrate that the architecture must include degraded operation and recovery, not just authorization at the moment of access.
What zero trust looks like around old equipment
Many controllers cannot support modern authentication, encryption or security software. Some cannot be patched without interrupting production. Others rely on proprietary engineering tools, obsolete operating systems or maintenance procedures controlled by outside contractors.
In those cases, practical zero-trust work may happen outside the controller:
- maintaining a current map of devices, connections and owners;
- placing legacy systems behind controlled gateways and segmented zones;
- restricting access by person, device, time and purpose;
- separating viewing, configuration and command authority;
- monitoring changes to control logic, set points and engineering workstations;
- limiting vendor access instead of leaving permanent remote accounts active;
- preserving an independent or manual operating path; and
- testing whether systems can be restored from known-good configurations.
These are not glamorous controls. They require documentation, engineering time and repeated testing. They also expose a fact that security programs often prefer to avoid: an organization may have a sophisticated policy while still lacking a reliable answer to the question of who can change a controller’s settings.
The earlier NSTAC report on information-technology and operational-technology convergence recognized that segmentation, firewalls, access controls and monitoring may serve as compensating measures for systems that cannot accept modern security protections. That is a realistic description of the installed base. It is not a claim that compensating controls erase the underlying engineering debt.
What the guidance does not prove
Federal guidance can identify useful controls. It cannot establish that a particular facility can operate safely during an identity-service outage, detect a compromised vendor account quickly or distinguish a legitimate engineering change from a malicious one.
Nor does a segmented network prove that a facility can recover after an intrusion. Isolation can reduce an attacker’s path to a controller, but it can also create blind spots if monitoring is incomplete. An inventory can identify a device without proving that its configuration is trusted. A backup can exist without ever having been restored successfully.
These limits matter because “zero trust” is increasingly used as if it were a product, certification or final security condition. It is none of those things. It is an architectural approach whose value depends on implementation, maintenance and recovery capability.
The cost is more than software
The largest operators and defense contractors may have the personnel and budgets to segment networks, monitor privileged access and test recovery. Smaller water utilities, rural providers, manufacturers, facilities teams and defense subcontractors may face the same technical expectations with fewer engineers and less ability to replace aging equipment.
The costs include asset discovery, network documentation, engineering review, controlled downtime, staff training, vendor renegotiation, logging, backup restoration and replacement of equipment that cannot be secured adequately. Communities may eventually pay as customers, taxpayers or consumers. They may also bear the consequences if a security improvement is deployed without a safe fallback and interrupts an essential service.
This is why OT security cannot be evaluated solely through compliance language. Operators should be able to answer practical questions: Which devices control the physical process? Who can reach them? Through what path? What permissions do they have? What happens if the identity provider or vendor platform is unavailable? Can the facility continue safely? Can it restore a trusted configuration without relying on the same system that may have been compromised?
The real test is continuity
Zero trust is useful in operational technology because it can narrow an attacker’s path to systems that cannot defend themselves. It can reduce unnecessary access, limit movement and make privileged changes more visible.
But it cannot make an obsolete controller trustworthy. It cannot replace missing operational knowledge. And it cannot guarantee that a facility will recover when its digital dependencies fail.
The strongest OT security program will therefore be judged less by whether an organization can say it has adopted zero trust than by whether it can keep a physical process safe when verification, monitoring or remote management breaks. In the control room, security is not complete when access is denied. It is complete only when operators know what remains trustworthy, what can continue running and how to recover without guessing.
