NIST’s new draft guidance for operational technology security is a useful signal for plant, utility, manufacturing, and facilities teams: zero trust cannot stop at the office network. If the policy boundary ends at Purdue Level 3 while controllers, operator panels, engineering workstations, and vendor paths remain broadly reachable below it, the architecture still leaves attackers room to move where operational authority lives.

Zscaler’s analysis of NIST SP 800-82 Revision 4 makes that point clearly: the initial public draft brings zero trust concepts into OT security, but defenders still have to translate those ideas into local, low-latency controls that work for industrial environments. A PLC cannot always run an agent. A legacy HMI may not support modern identity. Some control traffic cannot tolerate a cloud round trip. That does not mean zero trust is impossible in OT; it means the trust decision often has to be enforced by the network directly in front of the asset.

What changed

NIST released the initial public draft of SP 800-82r4, Guide to Operational Technology Security, on September 21, 2026, with comments open through November 30, 2026. The draft updates NIST’s long-running OT security guidance and expands coverage around asset management, monitoring, detection, management functions, and zero trust principles.

That matters because SP 800-82 is not just another white paper. It influences how federal agencies, regulated sectors, critical infrastructure operators, auditors, vendors, and government contractors talk about OT security maturity. When NIST adds zero trust language to OT guidance, procurement teams and security assessors eventually start asking what that means in real networks.

The risk is that organizations treat zero trust as a Level 3 management-network project: broker remote access, add MFA for engineers and vendors, monitor the industrial DMZ, and call it done. Those controls are important, but they do not fully answer the attack path below Level 3.

The Level 3 problem

In many Purdue-model environments, Level 3 is where operations management, historians, patch systems, jump hosts, and engineering access aggregation tend to sit. It is a logical place to add identity-aware access controls. The trouble is that industrial impact often occurs beneath it:

  • Level 2 operator workstations and HMIs can become the attacker’s control surface.
  • Level 1 controllers can accept commands from systems that are already trusted on the plant network.
  • Engineering workstations can carry project files, firmware tools, and programming authority.
  • Vendor access can become persistent access if credentials, jump paths, or remote tools are not tightly controlled.
  • Flat cells or overly broad VLANs can let one compromised asset talk to far more equipment than the process actually requires.

That is the defensive gap. A user may pass MFA at the boundary, but once the session reaches a permissive OT segment, the environment may still depend on old assumptions: trusted subnets, shared local accounts, permissive firewall rules, weak device identity, and limited east-west visibility.

Zero trust for OT has to be local

For SMB manufacturers, utilities, water districts, facilities operators, and government contractors with industrial systems, the practical version of OT zero trust is not “put every PLC behind an agent.” It is closer to this:

  • Know what exists without breaking it. Passive discovery is often safer than aggressive scanning. Asset inventory should identify controllers, HMIs, engineering stations, historians, protocol flows, firmware versions, and normal communication pairs.
  • Define who or what actually needs to talk. A controller and its HMI may need continuous communication. A random workstation in the same zone probably does not. Vendor access should be explicit, time-bound, and brokered.
  • Enforce policy close to the process. If a control decision has to leave the site before allowing time-sensitive traffic, it may violate the reliability and latency assumptions OT depends on. Local enforcement matters.
  • Reduce east-west trust. A compromised endpoint inside the plant should not automatically inherit broad reachability to controllers, panels, historians, and engineering tools.
  • Keep safety and fail-safe requirements separate from IT convenience. Segmentation plans must preserve deterministic operations, maintenance paths, emergency procedures, and local control.

This is where the Zscaler analysis is useful: it frames the control point as the gateway or segmentation layer in front of the device, not the device itself. That is the right mental model for legacy OT. The PLC does not need to understand every identity signal if the path to the PLC is constrained by policy, observed continuously, and limited to systems with a legitimate operational role.

What defenders should review now

This draft is still open for comment, so organizations do not need to wait for a final publication to learn from it. The immediate action is to map where current controls stop.

  • Draw the real trust boundary. Mark which OT assets are protected by identity-aware controls, which are only protected by subnet/VLAN placement, and which are reachable through legacy firewall rules.
  • Review Level 2 and Level 1 communication paths. Identify whether HMIs, engineering stations, historians, and controllers can talk only to expected peers or whether broad lateral movement is still possible.
  • Audit remote vendor access. Require named users, MFA, approval, time limits, session recording where feasible, file-transfer controls, and post-session review. Shared vendor passwords should be treated as a finding.
  • Baseline engineering workstation behavior. Watch for project-file changes, programming activity outside maintenance windows, new tools, removable media use, and unexpected outbound access.
  • Separate visibility from enforcement. Many sites collect OT telemetry but do not have tested procedures for isolating a compromised HMI, vendor session, or engineering laptop without taking down production.
  • Document compensating controls. If a controller cannot be patched or authenticated directly, document the network, process, and monitoring controls that reduce its exposure.

Why this matters for government contractors

Government contractors often focus on enterprise compliance: email, endpoints, cloud identity, CUI handling, and audit evidence. But many contractors also run warehouses, labs, building automation, test equipment, manufacturing cells, logistics systems, cameras, badge systems, environmental controls, or industrial support networks. Those systems may not look like “critical infrastructure,” but they can still interrupt contract performance or become a bridge into sensitive business systems.

The right question is not whether a small contractor has a perfect Purdue model. The right question is whether operational systems have the same broad implicit trust that attackers abuse in enterprise networks. If they do, the contractor’s OT risk is not just a plant-floor issue; it is a business-continuity, safety, incident-reporting, and customer-trust issue.

Bulwark Black assessment

NIST’s draft moves the conversation in the right direction, but the real work is implementation below the comfortable policy layer. Zero trust in OT should not mean forcing IT controls onto fragile systems. It should mean removing unnecessary trust from the paths that can affect physical operations.

For most organizations, the first win is not a large platform purchase. It is a defensible map of assets, communication pairs, vendor access paths, engineering authority, and isolation options. Once those are known, segmentation and access controls can be applied where they reduce actual process risk instead of where they are easiest to deploy.

The standard to aim for is simple: a compromised laptop, vendor credential, HMI, or remote support session should not automatically become operational authority across the plant.

Original source: Zscaler — NIST’s New OT Guide Draws the Zero Trust Line at Level 3. Attackers Are Working Below It.