NIST's OT Guide Now Starts With Govern. One in Seven Exposed Control Systems Is Already on KEV.

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.

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.

What we are asking NIST for

We are filing a comment before the 30 November deadline. Three things, and none of them is a complaint about the restructure, which we think is right. They are all about one seam:

• 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 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.