- What: NIST published the initial public draft of SP 800-82 Rev. 4, Guide to Operational Technology (OT) Security, on 21 September 2026. It is rebuilt around Cybersecurity Framework 2.0, which puts OT risk management under the Govern function, aligns to IR 8286r1 for enterprise risk, adds zero trust architecture guidance, relocates the Risk Management Framework to Appendix F, and widens sector coverage to building automation, water and wastewater, food and agriculture, freight rail, maritime vessels, and industrial IoT with cloud dependencies.
- Impact: Govern is the change everyone is quoting. The change that will fail assessments is quieter: expanded control guidance for asset management and network monitoring. Governance of an inventory you do not have is paperwork.
- The measurement: across the 33,323 internet-reachable control systems in our passive exposure index, 83.3 percent carry at least one known CVE and 14.5 percent carry one listed on CISA's Known Exploited Vulnerabilities catalog. That second figure did not improve while our coverage grew 17 percent.
- The gap nobody is citing: Rev 4 names RF threats (jamming, GNSS spoofing, wireless eavesdropping) as a defining characteristic of four of its six new sectors, then mentions radio frequency once across the whole Detect function. An operator can implement Section 4.3 in full and still not see the threat the document says defines their environment.
- Comment window: closes 30 November 2026. The draft is better served by plant-floor evidence than by another round of editorial comment, and we are filing ours.
What Rev 4 actually changes
Rev 3 shipped in September 2023 and did the renaming: Guide to Industrial Control Systems (ICS) Security became Guide to Operational Technology (OT) Security. Rev 4 keeps the title and rebuilds the frame underneath it.
Checked against the draft itself and the NIST announcement, the substantive changes are:
- CSF 2.0 as the organizing spine. OT risk is presented against the six Functions, with program ownership landing on Govern, the Function CSF 2.0 added in 2024.
- Enterprise risk alignment via NIST IR 8286r1, so OT risk is expressed in the vocabulary the rest of the business already reports in.
- Security architecture guidelines focused on protecting system management functions and applying zero trust principles, which Rev 3 largely treated as unreachable on a plant floor.
- The Risk Management Framework moved to Appendix F, out of the main narrative.
- Expanded guidelines for implementing OT security controls, including asset management and network monitoring and detection.
- Sector coverage widened past the traditional ICS set, to building automation and control systems, water and wastewater, food and agriculture, freight rail, maritime vessels, and IIoT with cloud dependencies.
The last two are missing from most of the summaries circulating this week, and they are the two that change what an assessment has to cover. One correction worth making while the draft is new: several widely shared posts dated it 18 September. NIST dates it 21 September 2026. This is also not the first Rev 4 text to surface. NIST posted an initial preliminary draft on 22 January 2026; September is the initial public draft, which is the one carrying a formal comment period.
Govern is the right headline. It is not the hard part.
Putting OT risk on Govern settles an argument that has cost real money. For a decade the plant engineer owned the control network because nobody else understood it, and the CISO owned the risk register because nobody else was asked to sign it. Neither owned the gap between them. Rev 4 says the gap belongs to the governance layer, which means a KEV hit on a PLC is now a decision somebody has to accept in writing rather than a ticket that ages quietly in a different department.
That is correct and overdue. It is also the easy half, because governance language is the half an organization can produce in a quarter. A policy that assigns OT risk to an accountable executive can be written by people who have never been in the building.
One in seven internet-reachable control systems we can see is running a vulnerability attackers are already using in the wild. Not theoretically exploitable. Catalogued by CISA as exploited. That proportion has held steady across two quarters while the population we track grew by 17 percent, which means the new exposure arrives in the same condition as the old.
Our measurement says the inventory is the live problem
We run a passive exposure index against internet-reachable OT: protocol identification from observed traffic and banners, no active interrogation of a controller. Current counts:
- 33,323 internet-reachable control systems identified
- 83.3 percent carrying at least one known CVE
- 14.5 percent carrying a CVE on CISA KEV, up a tenth of a point from 14.4 percent last quarter
- 17 percent growth in the population we can see, quarter over quarter
Read those together and the shape of the problem is not that operators are declining to patch known-exploited bugs on purpose. It is that in most of these environments nobody has a current list of what is reachable. The asset is not on the register, so the KEV advisory never maps to anything, so the risk is never accepted or rejected. It simply is not seen. Every water utility breach we have written up this year had this in common: the compromised device was reachable and nobody internal could produce an inventory entry for it until after the fact. The Colorado case and the coordinated Minnesota incident are both this failure, not a patching failure.
Which is why the asset management and network monitoring expansion is the part of Rev 4 we would put first. Govern tells you who signs. Inventory tells you what you are signing about.
The sectors Rev 4 adds are the sectors being hit
The widened sector list is not housekeeping. Building automation, water and wastewater, and freight rail are where this year's incidents landed, and they share a property the traditional ICS sectors do not: the operator is usually a municipality, a landlord or a mid-market firm with no OT security staff at all. A chemical plant has an engineer who knows the protocol. A county water district has a contractor and a maintenance window.
Maritime vessels are the most interesting addition, because vessel systems are reachable in ways a fixed plant is not, over satellite and shore-side links that change as the ship moves. Guidance that assumes a stable network perimeter does not survive contact with a hull. Credit where it is due: the draft does not inherit the plant-floor assumption here. Section 2.5.4 is a dedicated maritime subsection with its own example architecture, and it names ship-to-shore communication and the maritime-specific protocols (NMEA 0183/2000, IEC 61162-450) as defining characteristics rather than footnotes.
The gap nobody is talking about: RF
Here is the one we did not expect, and it is the reason this post took a second pass.
Rev 4 names radio-frequency threats as a defining characteristic of four of the six sectors it newly adds. In its own words:
- Building automation (p. 26): wireless signals are "broadcast through spaces shared by a wide variety of occupants and visitors" and are "inherently more exposed to eavesdropping, jamming, and unauthorized access".
- Food and agriculture (p. 29): autonomous field equipment relies on GNSS, so "spoofing, jamming, or natural disruption can halt or misdirect machinery across a wide area".
- Freight rail (p. 32): assets are mobile and dispersed, and links to wayside equipment and locomotives "may rely on cellular, radio, microwave, or other wireless".
- Maritime (p. 35): vessels are "heavily dependent on satellite communications; HF, VHF, and UHF Radio", with AIS, ECDIS and GPS/GNSS for navigation and GMDSS, distress beacons and NAVTEX for emergencies.
Now go to Section 4.3, the Detect function. It runs from page 91 to page 101 and carries both continuous monitoring and anomaly detection. Across those eleven pages it mentions radio frequency once, in a parenthesis, as an example of something that can alter a network time source.
An operator in any of those four sectors can implement the Detect function in full, pass an assessment against it, and still have no way to see the threat the document told them defines their environment. GNSS spoofing of a harvester, jamming of a wayside radio link and interference with a vessel's distress system produce no IP traffic at all. The monitoring Rev 4 prescribes watches networks. It cannot watch the spectrum, and an asset inventory built by network discovery will not contain the radios in the first place.
The sector sections and the Detect function do not meet. That is a structural gap, not a missing paragraph, and it is the fourth thing we are asking NIST to fix.
We should declare an interest, because it would be obvious anyway: we build passive RF monitoring for OT. We would make the same observation either way, and you can check it yourself in about five minutes by searching the draft for "wireless" and then reading Section 4.3.
What we are asking NIST for
We are filing a comment before the 30 November deadline. Four things, and none of them is a complaint about the restructure, which we think is right. The first three are about one seam, between the inventory the draft requires and the vulnerability review it expects you to run against that inventory:
- Add external exposure discovery to the method catalogue in 4.1.1.1 (p. 61, lines 2200 to 2254). The five methods listed are vendor management tools, passive network monitoring, OT-aware scanning, independent active scanning and software agents. Every one of them is an inside-the-network method that presumes you already know which networks to point it at. None of them is the outside-in view: what of your OT is reachable and fingerprintable from the public internet, which costs the device nothing because no traffic is sent to it. The draft's own case studies turn on precisely that exposure, including the CyberAv3ngers campaign against internet-exposed Unitronics controllers.
- Give 4.1.1.2 the technical attributes, not just the governance ones (p. 63, lines 2295 to 2302). The inventory is told to carry the responsible party, the operational criticality and any regulatory oversight. All three are right and all three are governance fields. Absent are vendor, model, and firmware or software version. Section 4.1.3 then tells organizations to review NVD and the KEV catalog (line 2445), which an inventory with no version field cannot be matched against. The gap between those two paragraphs is the gap our numbers measure.
- Add a monitoring subsection for radio frequency alongside the network one (Sec. 4.3.1). RF assets are an inventory obligation that network discovery cannot discharge; a spectrum baseline is the RF analogue of the traffic baseline Sec. 4.1.2 already requires; and the three failure modes worth detecting are the ones the sector sections already name, jamming, spoofing and an emitter that is not on the inventory. RF monitoring is passive, so it carries none of the availability risk the draft correctly attributes to active scanning, which is what makes it usable in the environments that refuse active methods.
- Add one worked example that carries a single KEV-listed vulnerability on an OT asset through to a documented Govern risk-acceptance decision. Every piece is already in the document separately: the KEV catalog in Appendix D.3.5, risk acceptance in the compensating-control discussion, and the Govern restructure itself. No single example connects them end to end, and that connection is the whole point of moving risk onto Govern.
If you operate OT, the comment window is the cheapest influence you will ever have on a document your auditor is going to hold you to for the next three years. Comments go to NIST by 30 November 2026. If you would rather send data than prose, we are happy to help you shape a submission from what your own environment shows.
How to file one. NIST takes comments at [email protected] and asks that you use its comment template, one row per comment with the page and line number, the type, and the proposed change. Prose in the body of an email is easy to write and easy to drop. The draft itself is at csrc.nist.gov/pubs/sp/800/82/r4/ipd.
What we built against Rev 4, before we asked for anything
We do not file comments on a standard we have not already measured ourselves against. Before this draft went anywhere near a blog post, we ran our own OT coverage against it and shipped the work.
Exposure is computed, not configured. Caver identifies an internet-reachable controller from the source address of the traffic actually reaching it, evaluated at query time. There is no exposure flag to populate, no field an integrator has to remember to set, and nothing to maintain as the estate changes. Point it at a feed that carries a source address and it answers the question the same way on day one as on day four hundred. That is a deliberate design choice, and it is the one that makes the answer true on a real network rather than on a diagram.
Every protocol we decode, including the ones Rev 4 just added. The exposure view reads all eight industrial protocols in the platform: Modbus, DNP3, BACnet, OPC UA, EtherNet/IP, S7comm, IEC 104 and Profinet. BACnet is the building-automation protocol and DNP3 is the water and wastewater protocol, which are precisely the two sectors this revision newly names. An operator in either one gets coverage from the same board as a refinery, not from a roadmap.
It reads a data classification, not a list of index names. The board asks for industrial data, not for eight specific places that data might be sitting. A new protocol source joins every one of these views the day it is onboarded, with no content change and no professional-services engagement. That is the difference between a product that tracks a standard and a product that has to be rebuilt each time one moves.
So when we tell NIST that external exposure discovery belongs in the asset-discovery catalogue, we are describing something already running, against the sectors Rev 4 added, in the hands of operators. We would rather bring working evidence to a comment period than an opinion.
What we did with the draft, in ten days
Receipts, because a vendor telling you they read a standard is worth nothing on its own.
- Read the document, not the announcement. That is the whole method, and it is why this post says things the summaries do not. The announcement is accurate and it is a summary, and a summary will not tell you that the draft already treats passive monitoring as a first-class discovery method at line 2210, or that maritime has its own subsection at 2.5.4. We checked every claim against the 300 pages before we made it.
- Corrected the date. The posts that surfaced this draft said 18 September. NIST's own page says 21 September 2026.
- Found the two changes the circulating summaries drop: the expanded asset-management and network-monitoring control guidance, and the widened sector list. Those are the two that change what an assessment has to cover.
- Counted, rather than characterised. The RF finding above is a count: four sector subsections name radio-frequency dependence, and Section 4.3 refers to radio frequency once across its eleven pages. Anyone can reproduce that in five minutes, which is the point.
- Filed four comments on NIST's own template, each pinned to a page and a line range, ahead of the 30 November deadline. NIST asks for the template; prose in an email body is easy to write and easy to drop.
- Measured our own platform against the draft and shipped the work first, as described above, so the comment we filed describes something already running rather than something planned.
- Updated our maritime collateral the same week. It cited Rev 3, which does not mention vessels at all.
Why the maritime section matters to us specifically
One part of Rev 4 reads like it was written about a problem we already built for, and it is worth being direct about that rather than coy.
Section 2.5.4 adds maritime vessels as a named OT sector, and describes the sector like this: vessels are "heavily dependent on satellite communications; HF, VHF, and UHF Radio"; navigation runs on AIS, ECDIS and GPS/GNSS; emergencies run on GMDSS, distress radio beacons and NAVTEX; and "depending on its operational phase (e.g., at sea, dry dock, in port), the vessel can present a different network topology and attack surface."
Every item on that list is a radio. None of them is an IP network, which is what Section 4.3 tells you to monitor. A vessel asset inventory built by network discovery contains none of them.
That is the gap we have been building against, and Rev 4 is the first time a NIST document has described this sector in those terms. We would rather say plainly that the draft validates a bet we already made than pretend we noticed it neutrally.
22 January 2026: initial preliminary draft. 21 September 2026: initial public draft published, comment period opens. 30 November 2026: comment period closes. Expect a second draft before a final, which puts the operative version somewhere in late 2027. Rev 3 remains the citable baseline until then, and we have updated our own OT collateral to cite the series rather than a pinned revision.
Questions about your exposure?
RedEye Security provides assessments for organizations that need to understand their real risk.
Talk to us