NIST released the initial public draft of SP 800-82 Revision 4, Guide to Operational Technology (OT) Security, on September 21. Public comments are open until November 30. The draft restructures the guide around Cybersecurity Framework (CSF) 2.0, puts risk management under the new Govern function, adds zero trust principles to the architecture guidance, expands coverage of asset management, network monitoring and detection, and widens the sector scope to include building automation, water and wastewater, food and agriculture, freight rail, maritime vessels and IIoT with cloud convergence. It is a draft. SP 800-82 Revision 3 stays the current final version until NIST publishes Revision 4. 

Why this draft matters more than a routine update 

SP 800-82 has been the document OT security people reach for first for well over a decade. Auditors cite it. Procurement teams copy language from it. Plenty of internal OT security programs are, honestly, a lightly edited version of it. 

So when NIST reorganizes it, the effects travel. Questionnaires change. Board-level conversations about "are we following NIST" change. And the gap between what your plant actually does and what the reference document now says gets harder to ignore. 

Revision 3 landed in September 2023 and widened the scope from industrial control systems to operational technology in general. Revision 4 is the first full revision since then, and it is a bigger structural change than the version number suggests. There is a pre-draft call for comments that ran from late January into February, and the initial public draft that came out in September runs to roughly 320 pages. 

If you manage OT risk, you have until November 30. That is less than four weeks from today. 

The draft at a glance 

What changed in Rev 4: the seven changes that matter 

1. CSF 2.0 is now the structure, not an add-on 

In Rev 3, the Cybersecurity Framework showed up in a section toward the back of the document, mapped against CSF 1.1. In the Rev 4 draft, CSF 2.0 sets the skeleton of the main sections. The old risk management material is reorganized around the Govern function, which CSF 2.0 introduced. The remaining sections follow Identify, Protect, Detect, Respond and Recover. 

This is not cosmetic. Govern forces questions that many OT programs have quietly avoided: who owns OT risk, how it feeds into enterprise risk, and who has the authority to say no to a connectivity request. NIST also expands the discussion of how OT risk management fits into enterprise risk management, pointing to NIST IR 8286r1. 

The draft also leans on a consequence-driven view of risk, evaluating cyber controls alongside engineering countermeasures. That is how experienced plant engineers already think, and it is good to see it written down. 

2. The five defense-in-depth layers are gone 

If you learned OT security from Rev 3, you probably remember the five numbered layers in the architecture section: security management, physical security, network security, hardware security and software security. 

The Rev 4 draft drops that list. Its architecture section sorts capabilities into three groups instead: 

• System management functions, such as asset management, industrial code management, a configuration management database and work order integration. 

• Security controls that enforce protection at the points where access, transfer or observation happens. 

• Architecture patterns, including a two-firewall DMZ, VPN gateways that terminate in a DMZ instead of connecting straight into the control network, and segmentation between zones inside a site. 

Defense in depth is still there, just reframed. The draft argues it should be treated as more than layered tooling, and says plainly that a mature OT defense mindset is consequence-driven. The executive summary groups the overall strategy into five domains: governance and life cycle, architecture and boundaries, access control, system protection and detection, and system resilience. 

There is also a notable push for separating networks by purpose. Operational networks that carry process control traffic should be segmented from the management networks used for configuration, patching and access control, and vendors or other third parties should get access paths that are separate from both. 

3. Zero trust arrives, with a deliberate boundary 

This is the change getting the most attention, and also the one most often misread. 

The draft gives zero trust its own treatment in the architecture section, but it does not require a full zero trust architecture. It presents zero trust principles as an extension of controls many plants already run: approving privileged access per session, keeping OT credentials separate from corporate ones, scanning every file and USB drive that crosses a boundary, and monitoring that can revoke access in near real time. NIST also says OT authorization should not simply inherit trust from the enterprise identity domain. 

Then comes the carve-out. Many PLCs, controllers and HMIs cannot support the protocols and technologies needed to take part in a full zero trust implementation. So the draft recommends applying zero trust to compatible devices, which it places typically at Purdue Levels 3, 4 and 5 and in the OT DMZ. Everything below that relies on zone boundaries. The draft keeps the zone model, firewalls and the two-firewall DMZ, layering zero trust on top of them instead of replacing them. 

NIST also flags two practical cautions. A zero trust component sitting in the path of a request can add latency or become a point of failure, which matters when control functions are time-critical. And shared logins, still common on plant floors, undermine any policy built on identity. 

Our read: the scope is realistic, but it leaves a real question open. NIST itself acknowledges that boundary devices between zones do not stop lateral movement inside a zone. For the controllers that actually run the physical process, that means the draft's zero trust scope stops right where the consequence starts. That is worth thinking about before November 30 (more on that below). 

4. A supply chain section operators will actually use 

Section 3.3 on cybersecurity supply chain risk management is the part vendors should read twice. It tells operators to define the processes, technical mitigations and evidence they expect from the supplier of any OT component. The list includes: 

1. Criteria for secure software development and life cycle management. 

2. SLAs for how the supplier notifies you of vulnerabilities and how fast they resolve them. 

3. Maintenance and support agreements that set acceptable methods for vendor remote access, and require vendors to follow your access control procedures on site. 

4. Technical mechanisms covering hardware and software components, including HBOMs and SBOMs. 

5. Digital artifacts, such as signatures, to validate the authenticity of vendor-supplied hardware, software and firmware. 

6. Contract incentives that reward strong supplier security practices. 

Operators are also told to check products for unauthorized components, software, suppliers or regions, to control and audit remote access, to look for unapproved communication devices such as cellular modems, and to think about how hard it will be to get updates over the product's life. For IIoT, the draft asks operators to evaluate default credentials, firmware update mechanisms, secure boot, vulnerability disclosure practices, vendor remote access and end-of-support risk before deployment. 

Expect this to show up in tender documents fast. "We can provide that on request" is going to stop being a comfortable answer. 

5. Asset management and monitoring get real depth 

NIST's own project description makes a blunt point: organizations without a comprehensive OT asset management program may struggle to implement risk assessment, network segmentation, vulnerability management, incident response, zero trust and technology modernization. The draft responds by expanding its guidance on asset management and on network monitoring and detection. 

If you have been postponing the asset inventory conversation, this is the document that takes away the excuse. Everything else in the draft assumes you know what is on your network. 

6. The scope widened well beyond classic industrial plants 

The draft expands its introduction to OT sectors to cover: 

• Building automation and control systems (BACS) 

• Water and wastewater systems 

• Food and agriculture 

• Freight rail 

• Maritime vessels 

• Industrial IoT and cloud convergence, widening the IIoT coverage that Rev 3 had 

For operators in these sectors, each gets its own challenges and recommendations, which makes them useful as scenario material for tabletop exercises. 

7. The smaller items that will still affect your program 

• Post-quantum cryptography. A new subsection notes that many OT devices stay in service for decades, and tells organizations to begin assessing their cryptographic inventory now. 

• Resilience. Short sections cover analog backups that do not depend on the digital control system, and out-of-band management. 

• Appendices are moving. The Risk Management Framework discussion now sits in Appendix F. The OT overlay moves to Appendix E and, along with the RMF material, is planned to become a separate document. Threat sources and OT security organizations (Appendices C and D) are planned to become web resources. Note that Rev 3's appendix on OT security capabilities and tools does not appear in the draft's contents, and the reviewer note does not explain why. 

Rev 3 vs Rev 4 draft: side-by-side 

NIST SP 800-82 Rev 4 vs IEC 62443: how they compare 

This is the question we hear most from CISOs, usually phrased as "which one should we follow?" The honest answer is that they do different jobs. 

A few things stand out when you read them together. 

They already reference each other. SP 800-82 has pointed to ISA/IEC 62443 for years, and the standards take a broadly similar view on policies and procedures. Rev 4 does not change that relationship, it just makes the supplier-side expectations more explicit. 

The supply chain section is where they meet most closely. The six supplier expectations in Rev 4 section 3.3 line up naturally with what IEC 62443-4-1 (secure product development life cycle), 62443-4-2 (component requirements) and 62443-2-4 (service provider requirements) already ask for. A supplier that holds 62443 evidence will find the Rev 4 questionnaire much easier to answer. 

Security Levels fill a gap the NIST draft leaves open. IEC 62443-3-3 defines Security Levels from SL 1, which addresses casual or coincidental violation, up to SL 4, which addresses attackers with extended resources. NIST's consequence-driven framing tells you what you are protecting against. Security Levels give you a measurable target for how strongly. That is why many practitioners describe the pairing as NIST for strategic direction and IEC 62443 for operational execution. 

Regulation changes the answer. If you operate in the EU, NIS2 sets the legal outcomes and references 62443. In bulk power in North America, NERC CIP is the mandatory baseline. In those cases, 800-82 and 62443 become the how, not the why. 

Practical guidance: use Rev 4 (once final) to structure your governance and align with CSF 2.0 reporting. Use IEC 62443 to set zone and conduit designs, define target Security Levels and hold your suppliers to a testable standard. They are not competitors. Treating them as a choice is how programs end up with a policy that nobody can implement or an implementation nobody can justify. 

Where the draft is thin, and what to tell NIST 

A draft is an invitation to push back. Here are the places we would look at hard. 

The zero trust boundary below Level 3. The draft's scope stops at compatible devices, which leaves controllers and operator panels protected only at zone boundaries. NIST's own text concedes that those boundaries do not mitigate lateral movement within a zone. A joint government advisory published this year on attacks against internet-reachable PLCs described attackers copying controller project files and changing logic, and recommended restricting controller communications to expected devices. If you have isolated controllers individually without asking the devices to participate, for example through network-level segmentation in front of them, your field experience is exactly the evidence NIST needs. 

The missing capabilities and tools appendix. If your team relied on that appendix, say so. 

Planned separate documents. Splitting the overlay and the RMF material into their own publications may be sensible, but it affects how you reference the guidance. Ask for a clear timeline and versioning approach. 

No final date and no word on a second draft. NIST has not said when Rev 4 will be final or whether another public draft will follow. Plan on Rev 3 for audits in the meantime, and track the new material as direction of travel. 

How to submit comments by November 30 

1. Download the draft PDF from NIST's publication page. The lines are numbered, so you can point to exact text. 

2. Fill in NIST's comment template (a spreadsheet). It asks for your name or organization, comment type (editorial, technical or general), page, line range, section, the comment itself, the rationale, and a proposed change. The proposed change column matters, so come with specific wording. 

3. Email it to sp800-82rev4@nist.gov by November 30. 

Two things to remember. NIST states comments may be released under the Freedom of Information Act, so do not include anything confidential. And the draft carries a call for patent claims sent to the same address. 

You do not need to be a vendor or a utility to comment. Operators with real plant experience carry the most weight. 

What OT security teams should do in the next 30 days 

None of this requires waiting for the final version. 

1. Read section 5 (architecture) and your sector section against your current network design. Note where your design relies on trust inside a zone. 

2. Check your asset inventory. Can you list every device that can reach each controller today? If not, that is the first project, not the fifth. 

3. Separate management from operations. Look at where patching, configuration and vendor access traffic runs relative to process control traffic. 

4. Audit vendor remote access. Who has it, how it is approved, how it is recorded, and whether anyone has installed a cellular modem that nobody approved. 

5. Ask your top five suppliers for SBOMs and signing details on the versions you actually run. Note who cannot answer. 

6. Map your program to the CSF 2.0 Govern function. Who owns OT risk, and does it roll up into enterprise risk reporting? 

7. Start a cryptographic inventory for long-lived devices. 

8. Decide whether to comment, and assign someone to write it before the deadline. 

How Shieldworkz supports teams working through this guidance 

Shieldworkz is an end-to-end industrial OT cybersecurity company serving critical infrastructure, with products, services and solutions that cover SCADA, OT and IoT environments under one roof. For teams translating the Rev 4 draft into practice, that typically means three starting points: 

• Visibility first. OT asset discovery and risk assessment, since the draft treats asset management as foundational. 

• Architecture review. Assessing segmentation, management network separation and remote access paths against the draft's architecture guidance and IEC 62443 zone and conduit principles. 

• Supplier and program readiness. Preparing governance, supply chain questionnaires and reporting that line up with CSF 2.0 and the Govern function. 

If you want a second pair of eyes on how your current program stacks up against the draft, talk to the Shieldworkz team. 

Frequently asked questions 

What is NIST SP 800-82 Rev 4? 

It is the draft fourth revision of NIST's Guide to Operational Technology (OT) Security. The initial public draft was released September 21 and restructures the guide around CSF 2.0, adds zero trust principles, and broadens the sectors it covers. 

When are comments due on the NIST SP 800-82 Rev 4 draft? 

November 30. Send them to sp800-82rev4@nist.gov using NIST's comment template. 

Is NIST SP 800-82 Rev 4 final? 

No. It is an initial public draft and its content may change. Rev 3 remains the current final version until Rev 4 is published, and NIST has not announced a final date. 

Is zero trust mandatory under the Rev 4 draft? 

No. The draft presents zero trust principles as something organizations can consider, builds on controls many plants already run, and recommends applying them to compatible devices, typically at Purdue Levels 3, 4 and 5 and in the OT DMZ. For non-federal organizations, use of the guide is voluntary. 

Does Rev 4 replace firewalls and DMZs in OT? 

No. The reference architectures keep zones, firewalls and a two-firewall DMZ, with zero trust layered on top. 

What is the difference between NIST SP 800-82 and IEC 62443? 

SP 800-82 is government guidance that sets program direction and shared vocabulary. IEC 62443 is a certifiable international standard series with detailed technical, system and supplier requirements, including Security Levels. Most mature programs use both. 

Does Rev 4 change which version I should audit against? 

Not yet. Rev 3 remains operative until Rev 4 is final, so keep auditing against Rev 3 and use the draft to plan. 

Who should comment on the draft? 

Anyone with OT experience. Operators, integrators and suppliers all have useful evidence, especially on where the draft's guidance is hard to implement. 

Additional resources     

Comprehensive Guide to Network Detection and Response NDR in 2026 here
OT Security Risk Exposure Calculator Workbook here
A downloadable report on the Stryker cyber incident here     
Remediation Guides here   
OT Security Best Practices and Risk Assessment Guidance here  
IEC 62443-based OT/ICS risk assessment checklist for the food and beverage manufacturing sector here