NIST's New OT Guide Draws the Zero Trust Line at Level 3. Attackers Are Working Below It.

Quick answer: NIST released the initial public draft of SP 800-82 Revision 4, its Guide to Operational Technology Security, on September 21, 2026, with public comments open through November 30. The draft adds zero trust principles to OT security architecture but recommends applying them to compatible systems, typically those at Purdue Level 3 and above, because many controllers and operator panels cannot fully take part. That leaves the controllers running the physical process protected at the zone boundary, which the same section of the draft says does not stop an attacker who is already inside the zone.

In a chemical plant, the controller that holds a batch reactor at temperature sits a few network hops from the operator screens that display it, the engineering workstation that programs it, and the historian that logs its readings. Industrial security has long protected that cluster by putting a firewall on its boundary and trusting what is inside. The new draft of NIST SP 800-82, the U.S. government's reference guide for OT security, now addresses zero trust directly, and the line it draws runs straight through that cluster.

The draft organizes its guidance around the Purdue model, the standard way of layering a plant network, and its zero trust recommendation centers on the upper layers:

Section 5.3 makes two points a few paragraphs apart:

What NIST concedes

Inside a perimeter, users are typically trusted and given broad access, so 'boundary protection devices between zones do not mitigate lateral movement risks within a zone.' (Section 5.3)

Where NIST draws the line

Because many PLCs, controllers, and HMIs 'do not support the technologies or protocols required to fully integrate with a ZTA implementation,' the draft recommends applying zero trust to compatible devices, such as those typically found at Levels 3, 4, and 5 and in the OT DMZ. (Section 5.3.1)

Neither point is wrong, but together they leave the reactor controller where it started, behind a zone boundary that NIST itself says will not stop someone already inside.

Why does the line sit at Level 3?

The 321-page draft presents zero trust as an extension of controls many plants already run: per-session approval of privileged access, OT logins kept separate from corporate ones, scanning of every file and USB drive, and monitoring that can revoke access in near real time. It also keeps the zone model, with firewalls, a DMZ, and a new management network where vendor sessions need just-in-time approval. It layers zero trust on top of zoning, a sensible choice for plants that cannot rebuild their networks.

As NIST defines it, zero trust means every request to reach a system is checked close to that system and rechecked continuously, instead of being trusted because of where it comes from on the network. On a server or workstation, software on the machine can hold an identity and enforce that check. A PLC that shipped with a built-in web server and a shared maintenance password can do neither, and replacing controllers to fix that is not something a plant schedules lightly.

NIST also adds two cautions: a zero trust component in the path of a request can slow it down or become unavailable, and shared logins, still common on plant floors, weaken any policy based on identity. Few OT engineers will dispute either.

What attackers do below the line

Limiting controls at Level 3 have a cost, and joint advisory AA26-097A, first published April 7, 2026 by the FBI, CISA, NSA, and partner agencies and updated July 22, shows it. Iranian-affiliated actors went after PLCs from Rockwell Automation, Schneider Electric, and Siemens in three steps:

1. Connect to the controller using the manufacturer's own programming software.
2. Copy the project file that holds the controller's logic out to attacker infrastructure.
3. Change that logic, in some cases disabling shutdown and alarm logic so systems could enter unsafe conditions without operators being notified.

The controllers in the advisory were reachable directly from the internet, a path sound zoning closes. The advisory goes further, recommending firewall rules or access control features on the PLC itself so it accepts communications only from the control devices expected to talk to it. That is device-by-device isolation, the step the draft's zero trust scope stops short of below Level 3, and many controllers either lack those features or make them hard to manage one device at a time.

Inside a zone, isolation shrinks what can reach a controller from everything on the network to the few systems that need to, usually an operator panel and an engineering workstation. The workstation then becomes the path to guard, because it runs the same programming software the attackers used.

Zero trust without asking the device to participate

The draft's recommended zero trust scope typically ends at Level 3. Isolation enforced in the network can reach the network-connected controllers and operator panels below it.

NIST's definition asks for access decisions made close to the resource and re-evaluated continuously. What it does not say is that the actual resource has to make them. The joint advisory highlights the same point, noting that a gateway in front of the PLC "can enable MFA for remote access even if the PLC does not support MFA." For a controller that cannot run software or hold an identity, the decision can live in the network directly in front of it, as long as three conditions hold:

• Find every device without disrupting it. NIST treats an accurate asset inventory as foundational and warns that active scanning can disrupt plant systems. Discovery that works from the traffic devices already send avoids that risk.
• Isolate each device individually. When each controller sits in a network segment of its own, or shares one only with the devices it talks to constantly, nothing else can reach it except through policy, including devices inside the same zone.
• Make the decision locally. The draft wants time-critical control functions able to operate locally, and a check that sends plant traffic to a distant data center adds the delay NIST warns about.

Zscaler Zero Trust Branch is built around those conditions. Typically deployed at Level 3 or 3.5 in a Zero Trust Purdue architecture, its OT/IoT segmentation discovers and classifies devices from the traffic moving between them, without agents, scanners, or network access control. It then places each device in a segment of its own, so device-to-device connections pass a policy decision, with no re-addressing and no production downtime. That reaches network-connected controllers at Level 1 and operator panels at Level 2, the levels the draft leaves to zone boundaries.

The appliance at the site becomes each device's gateway, so device-to-device policy is enforced locally with no round trip to the cloud, which answers the latency concern NIST raises. For the redundancy NIST requires, sites typically run the appliances as an active and standby pair. Devices that need to talk constantly or ones which can’t support a network of one, such as a controller and the operator panel that watches it, can share a small segment and communicate directly, while anything leaving that segment still passes policy. Traffic headed beyond the site goes to the Zero Trust Exchange, where internet, SaaS, and private application policy is applied, so a compromised device cannot reach past the plant either.

Remote access also follows NIST's management-network pattern. Zscaler Privileged Remote Access brokers vendor and engineer sessions through the Zero Trust Exchange with no inbound ports open at the plant. It injects credentials from a vault and rotates them, so vendors never hold a password and shared logins stop circulating on the plant floor. Files a technician moves into a session can be scanned and detonated in Zscaler Cloud Sandbox before they reach the target, the remote-session counterpart to the file scanning NIST lists as zero trust in practice. Sessions are time-bound and recorded, which addresses the vendor access problem we see in almost every OT workshop.

If something still manages to get in, the Ransomware Kill Switch tightens device-to-device policy in graduated steps, the isolation discipline laid out in our analysis of CI Fortify.

It’s also important to understand the limits. Level 0, the sensors, valves, and motors wired directly to controllers, sit outside any network-based control and are generally protected through the controller. Isolation also cannot fix weaknesses in a specific controller or stop an attacker who already holds an expected device such as the engineering workstation, so the run-mode switch, programming protection, patching, and project-file integrity checks in the joint advisory still apply. A site that loses its cloud connection entirely needs its own isolation plan, which the CI Fortify guidance covers.

Three things to do before the comment period closes

First, map the carve-out against your own plant by listing what can reach each controller today, area by area. If the answer is anything in the zone, that is the exposure Section 5.3 describes.

Second, inventory the connectivity nobody approved. The draft warns that cellular modems and vendor-managed connections can bypass enterprise and OT security controls and tells operators to inventory, approve, and restrict them.

Third, comment. The Level 3 line is drawn around what the devices can do. Its control overlay already lists isolation of system components for high-impact systems, with no OT-specific discussion attached. Asset owners who have isolated controllers below Level 3 without asking the devices to participate can tell NIST so by emailing [email protected] by November 30, 2026, using the comment template on the draft's publication page.

To see where your plant stands against the draft, request an OT architecture workshop and we will map what can reach your controllers today. You can also hear from our customers directly on how they use Zscaler for OT security.