What Changed in NIST's OT Guide, From the Plant Up

On 21 September 2026 NIST published the initial public draft of SP 800-82 Revision 4, Guide to Operational Technology (OT) Security, written by its Applied Cybersecurity Division with co-authors from MITRE. The comment window runs to 30 November 2026. Revision 3, final since September 2023, stays the published edition until the next one lands.

Two changes will reach the plant. The guide is now built around the six functions of Cybersecurity Framework 2.0, with the old risk-management chapter rewritten as Govern. Further down, three implementation sections got considerably longer: asset management, network monitoring and detection, and an architecture chapter that now turns on defending the systems which manage your controllers rather than the controllers themselves.

The reorganization is what gets quoted in slide decks. The three expanded sections are what gets quoted in an audit finding, because each one names an artifact a site either has or doesn't: an asset record carrying firmware versions, a network baseline that names protocol function codes, and a vendor access path with its own credential store. Food and agriculture enters scope for the first time too, which puts process lines inside the document's sector coverage rather than beside it. Where pasteurization, clean-in-place sanitation and allergen dosing sit under OT control, the draft treats a setpoint moved by the wrong hands, or a monitoring record that was never written, as the same class of event as contamination. That reading is correct, and it moves the finding off the IT risk register and onto the food-safety one. (EU operators get a parallel set of obligations through a different door, covered in what NIS2 asks of industrial operators.)

The record all of this has to produce

Work backwards from the output. At the end of the sequence the draft describes, you should be able to pull up any device on the site and answer a short list of questions without walking out to the panel: what is it, who made it and when, where is it mounted, what firmware is on it right now, who owns it, which safety or quality function depends on it, which regulator cares, and when did someone last connect to it.

The inventory section asks for most of that explicitly. Unique identifiers. Hardware detail down to vendor, model, serial and provenance. Software and firmware with version numbers, and a software bill of materials where the vendor ships one. A vendor repository: support contacts, warranty terms, recall notices, end-of-life dates. Named roles, so the asset owner and whoever carries operations, maintenance and security responsibility are written down rather than assumed. A separate subsection then adds criticality: which safety functions the device supports, its role in keeping the process running, and any regulatory oversight attached to it.

None of this is new as a concept. What's new is that the draft wires the record into detection, and says so plainly: detection tools should be integrated with asset management tools so that an event arrives carrying the device's location, firmware version and criticality. That integration is the difference between a usable alert and a line in a log. An unexpected write to a controller means almost nothing on its own. The same write against the grain dryer's aeration-fan controller, two firmware revisions behind, with vendor support already lapsed, is a decision you can make at 03:00.

Five ways to find a device, and the device picks one

On discovery, the draft walks five approaches and is candid about what each one costs you.

• Vendor engineering tools. The deepest detail available, since they speak the OEM's own management services and can read configuration, serials and firmware revisions directly. They cover one product line. Run four OEMs on site and you run four tools, each built for operations rather than for security, with no guarantee any two report the same fields.
• Passive network monitoring. Listens rather than asks, so it finds devices that never made it onto the drawing. Its coverage is entirely a function of where the listening sensors sit.
• OT-aware scanning. Interrogates devices over native industrial protocols, so it can pull identity from a multi-vendor estate with fewer tools. The draft says test it off-production and talk to your vendors first.
• Independent active scanning. Opens connections to whatever services a device exposes, sometimes with credentials, and returns the broadest picture including things the device never meant to publish. It can also degrade availability or trigger operations you didn't ask for.
• Software agents. Standard practice in IT, mostly unavailable here. PLCs, transmitters and other embedded devices don't run an operating system that supports them, and where a device does, the vendor's warranty or support terms may rule the agent out.

What reads as genuinely new guidance is how the draft picks between them. Method follows the equipment's age and capability rather than organizational preference: modern devices with processing headroom tolerate active interrogation, while older resource-constrained ones belong on passive monitoring, which sends them nothing. Legacy and isolated assets that no tool can reach get a physical inspection or a console session and a line typed into the record by hand. And the draft states the rule directly: don't apply one approach uniformly across an estate that mixes modern and legacy equipment.

That matters because a processing plant is exactly that estate. A recent line controller will answer an identity request politely. A fifteen-year-old weigh-filler PLC sitting behind a serial gateway on Modbus RTU will not be reached by anything that isn't the OEM's own tool, and an active scan aimed at a legacy embedded TCP stack can fill its connection table until it stops answering the SCADA poll. The scanner finishes its sweep and reports success. The operator loses the filler's weight feedback.

Two switches away, the sensor hears nothing

Of everything in the asset-management section, one sentence is worth more than the rest, and it's the one most rollouts discover late. The draft notes that, unlike typical IT designs, it is not unusual for an OT network to keep a large share of its traffic on one switch well inside the plant network, where a listening sensor never reaches it; asset owners, it says, have to work out from their own architecture where the sensors need to sit.

Picture the traffic on a CIP skid. Supply and return pumps, a steam valve, conductivity and temperature transmitters, a local controller sequencing rinse, caustic and acid steps, all handshaking across a switch inside the skid's own panel. Upstream, the historian gets a handful of summary tags: cycle start, cycle complete, peak temperature, final conductivity. Tap the DMZ uplink and you'll see those tags, which is to say you'll see the traffic you already trusted. The program download, the mode change, the setpoint write that shortened the acid step - all of that happened two switches away and never crossed your sensor.

The same shape repeats across a site: a burner management system on its own segment, a bottling line where filler, capper and labeller exchange interlocks over a local ring and publish only line-rate and reject counts upward, agitator and heat-exchanger loops inside a packaged skid that arrived from the OEM as a sealed network with one Ethernet port facing the plant.

Getting a sensor into those places is physical work, and the physics are unhelpful. Many panel switches in motor control cabinets are unmanaged five- or eight-port units with no mirroring function and no spare port, so the options are a TAP in series, a switch replacement during a shutdown, or nothing. Where mirroring does exist, a SPAN session is best-effort: the switch forwards production traffic first and drops mirrored frames under load, which means the capture thins out exactly when the network is busiest.

So triage rather than cover. The draft's own prioritization is sensible: critical assets first, then the network segments that carry them, then every point where communication crosses a boundary - the DMZ, the internet, an external party. It also singles out something most plant network diagrams get wrong. Cloud conduits, in its phrasing: connections from OT equipment to a cloud service that can bypass the usual network boundaries and aren't visible on a standard network drawing. On a real site that's an OEM telemetry box on a dryer with its own SIM card, a vibration gateway backhauling over cellular, a chiller with a service modem the refrigeration contractor fitted years ago and nobody decommissioned. Anything on the network that can't be tied to a known, authorized function is supposed to get investigated. Most sites turn up at least one.

A baseline that survives a recipe change

Once you can see the traffic, the draft asks you to write down what normal looks like across four dimensions: which devices talk to which, the protocols and ports they use, the polling intervals and data volumes they sustain, and the function codes or command types that appear inside the industrial protocol.

That last dimension is the one that earns the effort. Volume anomalies on a deterministic network are mostly changeover noise. Function codes are semantic. A controller that has only ever answered register reads, suddenly handling a write-multiple-registers request from an address that isn't the SCADA server, is a different event from a busy afternoon, and you can tell the two apart only if somebody wrote down which codes were normal.

Then the baseline starts to rot, and this is the step that decays first in practice. Process plants change legitimately and constantly: a recipe changeover alters polling patterns and data volumes, a firmware update shifts a device's port set, commissioning one new transmitter adds a communication pair. The draft acknowledges all of this. Not every deviation is malicious, baseline maintenance has to account for authorized change, and baselines need review when devices are added, networks reconfigured or processes modified. But it can't tell you who performs that review on a site where the monitoring tool belongs to one group and the changes get made by whoever is on shift.

The architecture chapter offers a useful handle. Among the system-management functions it lists is work order integration: the work order ties asset management, code management and access management together, so that every authorized change to a managed device lands in one audit record. Most plants already run a CMMS, so it's the cheapest item on the list. What's missing is the linkage. The work order records that a technician attended the filler; it doesn't record which engineering workstation connected, which program version went down, or who approved the session. Close that gap and the triage question becomes answerable in seconds instead of a morning: was there an open work order against this asset when its traffic changed?

Without it you get the outcome every control room already knows from unrationalized DCS alarms. Deviations arrive, nobody can attribute them, the standing explanation becomes "that one's always like that", and within two quarters the detection system is furniture.

Vendor access gets its own rails

In the architecture chapter the draft stops describing records and starts describing money.

Its central move is to extend network separation inside the OT environment. Operational traffic between supervisory systems and field devices is deterministic and latency-sensitive; management traffic (configuration, patching, access control sessions) is neither. So they shouldn't share infrastructure, the draft argues, because management activity then imports risk into process traffic, no independent policy can be applied to either, and an event on one propagates to the other. It sketches a management network split by function: asset and code management plus the configuration management database in one zone, patch staging and file transfer in a second, identity and access infrastructure in a third, and security monitoring in an isolated zone fed by one-way telemetry with no staff access path at all.

External access follows the same logic, and this is the expensive paragraph. Vendors are to get their own credential stores, entry points, firewall policy lanes and entitlement profiles, architecturally separate from internal management traffic, with just-in-time approval before any session opens. Standing, always-on vendor access is to be avoided; where it can't be eliminated, it gets formally risk-accepted and continuously monitored.

Count the standing connections on a mid-size process site and you'll typically find several, each arriving attached to a service agreement: the filler OEM, the robot integrator, the boiler controls house, the refrigeration contractor. In practice most are a persistent VPN tunnel terminating somewhere convenient, authenticated with a shared credential, unrecorded. The draft calls out that pattern by name: a persistent VPN tunnel with weak authentication lets an attacker reach paths the firewall would otherwise block. It's the same exposure as a PLC with a routable address, with a service contract wrapped around it. Removing standing access means reopening service agreements. That's a procurement conversation before it's a network change, and it's the single item on this list most likely to stall.

One more reversal sits in the same section: a dedicated OT authentication server inside the management network, kept apart from enterprise directory services, so that stealing a corporate login doesn't hand anyone the management tier. Plenty of sites consolidated OT logins into the corporate directory precisely because it was easier to administer. The draft asks for that to be unwound, and it's right about why.

Zero trust stops below the controller

The zero trust chapter is more useful than its title suggests, mostly because it sets a boundary. Many OT components (PLCs, controllers, HMIs) simply don't support the protocols a zero trust architecture needs, so the draft scopes it to compatible devices at the functionally higher levels of the architecture and the OT DMZ, Purdue Level 3 and above. It also points out that shared credentials, still common in control rooms, make the model unworkable until they're separated, which turns credential separation and privileged access management into preconditions rather than parallel projects.

The engineering caution is the valuable part. The draft asks you to consider what a zero trust component adds to the latency of a resource request, and what happens when one of those components goes unavailable, then to build in redundancy accordingly. Work that through for a plant and the reason for the scoping becomes obvious. A policy decision point that fails closed in front of an HMI during an upset is a safety problem; one that fails open is a security problem. Neither belongs in front of a control loop, which is why the draft keeps the whole apparatus above it.

Where the draft hedges on machine learning

A subsection on emerging detection covers machine learning models and digital twins as complements to signature- and threshold-based detection. It opens by noting that adoption for OT anomaly detection remains limited in current industry practice, which is a fair description, and then lists the cautions.

Training and running these models needs extensive historical and live process data, pushing collection and retention past what conventional monitoring requires. Training-data integrity governs everything downstream, because a model fitted to an unrepresentative or already-compromised baseline returns unreliable results with no outward sign of it. The models can also behave non-deterministically across runs and versions, which complicates validation. Digital twins carry their own list: bidirectional synchronization to physical assets is a new attack surface, a twin that drifts out of sync stops flagging real anomalies, and a compromised twin can be driven to mask the behavior it was installed to catch.

Every one of those cautions lands. The training-data point in particular deserves more weight than a draft can give it. A behavior model fitted to six months of site history encodes whatever was true during those six months, including the undocumented vendor session that polled a controller every thirty seconds throughout. The model learns that as normal and will defend it. For anyone running a plant-side stack that collects and models process signals, the retention window, lineage and integrity questions the draft raises about security models are the same ones that govern the bearing-degradation and fouling models a reliability group already trusts. Same historian, same gaps, same vulnerability to a baseline period that wasn't clean.

Who this architecture was written for

The management-network design assumes an organization that has a configuration management database, an access manager, a security monitoring function and enough people to operate four separated zones. Plenty of sites in the sectors this draft newly covers have none of those.

The draft concedes the point itself, in the food and agriculture section: a baseline level of digital maturity can't be assumed across that sector, and guidance written for well-resourced enterprises won't reach most of the organizations in it. For small operations it names a much shorter list (multi-factor authentication, regular offline backups, sound password practice, awareness training) on the grounds that those deter the opportunistic scanning behind most attacks at that scale. Its own framing says to evaluate each function and pattern against asset criticality and operational constraints rather than implement the tables as written.

So the realistic read, for a single-line creamery with one controls engineer and four OEM service contracts, is that the zoned management network isn't the deliverable. What transfers at that scale is narrower: the asset record, criticality assigned to the handful of devices that can hurt someone or spoil a batch, and a function-code baseline on the two or three segments that carry them. The rest of the architecture chapter is written for a site that already has a controls group. The draft would be stronger if it said which paragraphs were which.

Notes

This is a draft, and the shape of it will move. The document already flags that two appendices are headed for separate publication and two more to web-based resources before the final, so anything taken from it now wants rechecking against the published version.

SP 800-82 is US federal guidance and carries no legal weight outside that context. For an EU plant the binding obligations arrive through NIS2 and its national transposition, with IEC 62443 doing most of the technical work in plant specifications and supplier contracts; the NIST material is useful there as implementation detail, not as the compliance baseline.