
The NIST 800-82 Guide to Securing Operational Technology
Emily Bonnie
Senior Content Marketing Manager
If your shop floor runs on programmable logic controllers (PLCs), CNC machines, human-machine interfaces (HMIs), or building automation systems, NIST Special Publication 800-82 is one of the most comprehensive resources available for protecting it against cyber threats that could disrupt production, compromise safety, damage equipment, or affect product quality.
Created by the National Institute of Standards and Technology, the guide has shaped operational technology (OT) security programs across critical infrastructure for more than a decade. On September 21, 2026, NIST released the initial public draft of Revision 4, which updates the guidance to reflect the NIST Cybersecurity Framework (CSF) 2.0, expanding connectivity, and a broader range of OT environments. Public comments are open through November 30, 2026.
For defense contractors, 800-82 addresses risks that familiar compliance frameworks don’t cover in detail. NIST 800-171 and CMMC focus on protecting controlled unclassified information (CUI), but they provide limited guidance on how to secure a production line where a reboot, vulnerability scan, or locked account could stop manufacturing or create a safety hazard.
NIST 800-82 was written with those conditions in mind. It explains how to structure OT networks, adapt conventional security controls to physical systems, monitor industrial environments, and manage cyber risk without compromising safety or reliability.
Below, we’ll explain what NIST 800-82 covers, how its network segmentation guidance and OT overlay work, how it relates to CMMC and other OT security standards, and how to use it to secure your own manufacturing environment.
Recommended reading
Why OT Security Is The New Priority for Defense Manufacturers
What is NIST 800-82?
NIST SP 800-82, Guide to Operational Technology (OT) Security, provides federal guidance for securing systems that interact with or control a physical environment. The current final version, Revision 3, applies to industrial control systems, building automation systems, transportation systems, physical access control systems, environmental monitoring systems, and other forms of OT.
In a defense manufacturing environment, that can include the PLCs running a production cell, the SCADA or HMI software operators use to supervise it, CNC machines, robotic systems, test equipment, process historians, HVAC controls, and badge-access systems.
Adopting NIST 800-82 is not a strict requirement. Private companies are not universally required to implement it, and there is no NIST 800-82 certification or accredited assessment program. It becomes binding when a contract, law, regulation, or customer requirement specifically incorporates it.
That said, defense contractors can still use it to adopt a recognized, risk-based approach to OT security — and it’s especially valuable when conventional security requirements don’t fit the technical or operational limitations of an older controller, embedded device, or safety-sensitive manufacturing process.
NIST 800-82 Rev. 3 vs. Rev. 2 vs. the Rev. 4 draft
NIST has revised 800-82 several times as industrial technology, threats, and security practices have evolved. Revision 3 expanded the publication from industrial control systems to address operational technology more broadly. The Revision 4 draft builds on that broader scope and reorganizes guidance around NIST CSF 2.0.
| Version | Title | Status | Major changes |
|---|---|---|---|
| Rev. 2 | Guide to Industrial Control Systems (ICS) Security | Superseded; published in 2015 | Focused on SCADA, distributed control systems, and PLC-based systems, with an ICS overlay based on SP 800-53 Rev. 4 |
| Rev. 3 | Guide to Operational Technology (OT) Security | Current final version; published September 28, 2023 | Expanded the scope from ICS to OT, updated architectures and threats, added alignment with the NIST CSF, and introduced an OT overlay based on SP 800-53 Rev. 5 |
| Rev. 4 initial public draft | Guide to Operational Technology (OT) Security | Draft released September 21, 2026; comments due November 30, 2026 | Aligns the guide with CSF 2.0, expands sector coverage, and adds guidance on governance, asset management, monitoring, cloud and IIoT connectivity, and zero trust principles |
Revision 3 is the version in use today. The Revision 4 draft may change before publication, and some appendices, including the OT overlay, may become separate documents when the final version is released. The public comment deadline and additional details are available on the NIST Revision 4 publication page.
How NIST 800-82 Rev. 3 is organized
Sections 1 and 2 establish the foundation. They explain the purpose and scope of the publication, introduce common OT systems and architectures, and describe how OT security priorities differ from those of conventional IT environments.
Sections 3 and 4 cover OT cybersecurity program development and risk management. They explain how to establish an OT security program and apply the NIST Risk Management Framework to operational systems.
Section 5 provides the architecture guidance, including defense in depth, network segmentation, and boundary protection. Section 6 maps OT security activities to the functions of the NIST Cybersecurity Framework. The appendices include OT threats, vulnerabilities, and incidents in Appendix C; security capabilities and tools in Appendix E; and the OT overlay in Appendix F, which tailors NIST SP 800-53 controls and baselines to OT systems.
Defense contractors focused on implementation will likely spend the most time in Section 5 and Appendix F. Together, they cover how to structure the environment and adapt conventional controls to physical systems.
NIST 800-82 network segmentation guidance for IT and OT separation
Network segmentation is a central part of the architecture guidance in 800-82. On a flat network, an intrusion that begins with a compromised office account or laptop may have a direct path to engineering workstations, HMIs, and production controllers. Segmentation limits those pathways and gives you more control over communications between business and manufacturing systems.
The guide recommends a multilayer topology that places the most critical communications in the most secure and reliable layers. It also calls for logical separation between corporate and OT networks as part of a broader defense-in-depth strategy.
The right design will depend on the size of your facility, the equipment you operate, and the consequences of a disruption. A smaller manufacturer might begin with three primary zones:
- A corporate IT zone for business applications, email, user workstations, and file storage
- An industrial demilitarized zone (DMZ) for shared services, monitoring platforms, data transfer, and controlled remote access
- A production OT zone containing manufacturing systems, engineering workstations, PLCs, HMIs, and other control equipment
Firewalls and access control lists enforce approved communications between these zones. Every zone boundary should function as an enforceable control, with documented rules specifying which systems, ports, protocols, and directions are allowed.
As the environment matures, the production network can be divided further by manufacturing cell, production line, equipment type, safety function, or mission consequence. A production line that would halt a contractual delivery if compromised may need stronger isolation and access restrictions. A test cell may deserve the same treatment if its failure would delay a qualification event.
The Purdue model and the OT DMZ
NIST uses the Purdue model as an example of a segmented OT architecture. The model organizes an industrial environment into levels, beginning with physical equipment and sensors, followed by controllers, supervisory systems such as HMIs and SCADA servers, site operations systems, and the enterprise network.
A DMZ sits between the enterprise and OT environments. It hosts services that need to exchange information across the boundary, such as a replicated historian, a patch-staging server, a file-transfer service, or a remote-access jump host.
Enterprise users connect to the appropriate service in the DMZ. Separate, tightly restricted connections support communication between the DMZ and production systems. This architecture prevents direct traffic between the corporate and OT networks and creates a controlled location for inspecting, authenticating, and logging cross-boundary activity.
A smaller manufacturer does not need to reproduce every level of the Purdue model to benefit from this approach. A business zone, an industrial DMZ, and one or more production zones can provide a strong foundation.
Firewalls, unidirectional gateways, and data diodes
Stateful firewalls are the most common way to enforce boundaries between zones. A well-designed rule set denies traffic by default and permits only approved communications between identified systems.
Virtual local area networks (VLANs) can separate traffic logically, but they need firewall rules, access control lists, routing restrictions, or other filtering to control communications between segments.
Some high-consequence environments use unidirectional gateways, commonly called data diodes, to enforce one-way communication in hardware. For example, a data diode can send historian or monitoring information from the OT network to the enterprise while physically preventing return traffic.
This approach works well when information only needs to flow in one direction. Processes that require two-way communication, including some forms of vendor support, need a separate controlled pathway.
Dual-homed devices, remote access, and other common gaps
Segmentation can be weakened by connections that bypass the approved architecture. One example is a dual-homed engineering workstation with one network interface connected to the corporate network and another connected directly to the control network. That workstation creates a bridge around the firewall and DMZ.
Vendor access can create similar exposure. Machine builders and system integrators often need remote connectivity for maintenance, troubleshooting, or software updates. Vendor-installed cellular modems and always-on remote desktop connections can introduce unmonitored pathways into production.
Route remote access through a controlled gateway or jump host in the DMZ. Require multifactor authentication, approvals, time-limited access, and session logging. Review vendor access regularly and remove accounts and connections that are no longer required.
Your segmentation architecture can also affect CMMC scope. Keeping CUI off production equipment and establishing a defensible boundary between OT and systems that handle CUI may reduce the number of assets included in an assessment.
Recommended reading
A Guide to the DFARS Clauses Behind CMMC & How They’ve Changed in 2026
NIST 800-82 controls and the OT overlay
NIST 800-53 is the federal government’s primary catalog of security and privacy controls, and NIST 800-53B defines control baselines for systems at different impact levels. Because those baselines apply across many types of information systems, some of their requirements need to be adapted for OT.
The OT overlay in Appendix F provides that adaptation by connecting the guide’s architecture principles to specific safeguards. It establishes OT-specific baselines for each impact level, explains how individual controls apply to operational systems, and identifies circumstances where a control may need to be tailored or supported by compensating safeguards.
This guidance is especially useful when a standard IT control could interfere with safe or reliable operation. Account lockout is a common example. Locking an account after repeated failed login attempts can reduce password-guessing attacks, but locking the only available operator out of an HMI during an alarm condition could create a greater risk.
In that situation, controls such as restricted physical access, network-level access restrictions, closely monitored authentication attempts, or a supervised break-glass procedure may reduce the same risk while preserving operator access.
To use the overlay, begin by determining the impact level of each OT system. Consider what could happen if its confidentiality, integrity, or availability were compromised. An OT impact analysis should include worker safety, equipment damage, environmental harm, production loss, product quality, and contractual delivery.
The selected impact level determines which baseline provides the starting point. You can then review the OT-specific discussion for each control and document how it is implemented, tailored, or supported by a compensating safeguard.
The overlay is the closest NIST 800-82 comes to a control checklist. The publication itself does not establish a single fixed number of controls for every OT environment. The applicable controls depend on the system’s impact level, architecture, operating conditions, and risk decisions.
Applying the NIST Cybersecurity Framework to OT
NIST 800-82 Rev. 3 uses the NIST Cybersecurity Framework (CSF) to organize OT security activities across five core functions: Identify, Protect, Detect, Respond, and Recover. This structure helps manufacturers build a security program around operational outcomes and see how individual safeguards work together.
- Under Identify, you develop an accurate inventory of OT hardware, software, firmware, control logic, communications pathways, and system dependencies. You also assess how the failure or compromise of each asset could affect worker safety, production, product quality, contractual delivery, and the environment.
- The Protect function covers safeguards such as access controls, network segmentation, secure configuration, removable-media management, workforce training, and maintenance procedures. These measures should reflect the technical limitations and operating requirements of the systems they protect.
- Detect focuses on recognizing anomalous activity without interfering with production. This may include passive network monitoring, changes to controller logic, unexpected communications, unauthorized devices, failed authentication attempts, or deviations from established system behavior.
- Under Respond, you establish procedures for containing and investigating an incident while preserving safe operations. Response plans should define decision-making authority, escalation paths, evidence-preservation requirements, and coordination among security, engineering, operations, safety, legal, and contract teams.
- The Recover function addresses the restoration of controller logic, system configurations, production recipes, engineering files, and other operational data. Recovery plans should account for system dependencies and establish a safe, tested sequence for returning equipment to service.
These functions work together to provide a practical structure for managing OT risk across the system lifecycle. Revision 3 maps to the five functions in CSF 1.1. The Revision 4 draft updates that alignment to CSF 2.0, including its Govern function.
Recommended reading
The NIST Cybersecurity Framework 2.0: What Is It & How to Comply [+ Checklist]
How NIST 800-82 relates to CMMC and NIST 800-171
Neither NIST 800-171 nor CMMC 2.0 requires defense contractors to implement NIST 800-82.Â
DFARS 252.204-7012 requires applicable contractors to protect covered defense information on covered contractor information systems by implementing NIST 800-171. Whether an OT asset falls within that environment depends on the information it handles and the security role it performs.
An OT asset may be in scope if it processes, stores, or transmits CUI. Other systems may also be relevant if they provide security protections for the in-scope environment, including identity services, firewalls, monitoring platforms, and vulnerability-management systems.
For example, an engineering workstation that receives CUI drawings and transfers production instructions to a controller may be in scope. An isolated manufacturing cell that does not handle CUI and is separated from assets that do may fall outside the assessment boundary.
To determine if an asset is in scope, document its data flows, connections, users, dependencies, and security role. This provides stronger support for a scoping decision than labels such as “factory network” or “isolated system.”
CMMC Level 2 identifies five asset categories:
- CUI assets process, store, or transmit CUI.
- Security protection assets provide security functions or capabilities to the contractor’s CMMC assessment scope.
- Contractor risk managed assets can process, store, or transmit CUI but are managed through the contractor’s risk-based security policies, procedures, and practices.
- Specialized assets include OT, Internet of Things and Industrial Internet of Things devices, government-furnished equipment, restricted information systems, and test equipment that can process, store, or transmit CUI but cannot be fully secured.
- Out-of-scope assets cannot process, store, or transmit CUI and do not provide security protections for CUI assets.
Under 32 CFR 170.19, Specialized Assets must be documented in the asset inventory, addressed in the System Security Plan (SSP), managed through risk-based security policies and practices, and represented in the network diagram of the assessment scope.
NIST 800-82 gives contractors a recognized source for defining that risk-based treatment. Referencing its architecture guidance and OT overlay can help you explain how specialized equipment is segmented, monitored, accessed, maintained, and recovered when every NIST SP 800-171 requirement cannot be implemented directly on the device.
Use the Department’s current CMMC scoping guidance, your system architecture, and the requirements in each contract to determine how your OT should be categorized. Confirm consequential or uncertain decisions with a qualified advisor or assessor.
NIST 800-82 vs. IEC 62443 and other OT security standards
NIST 800-82 is one of several standards and frameworks used to manage OT security. Each serves a different purpose, and many organizations use a combination of them.
| NIST SP 800-82 | ISA/IEC 62443 | NIST CSF 2.0 | |
|---|---|---|---|
| What it is | U.S. federal guidance for securing OT | International standards series for industrial automation and control system security | Outcome-based framework for managing cybersecurity risk |
| Cost | Free | Standards are generally purchased from ISA or IEC | Free |
| Primary audience | OT asset owners and operators | Asset owners, system integrators, service providers, and product suppliers | Organizations in any sector |
| Certification | No certification program | Certification programs exist for products, processes, and professionals | No certification program |
| Best used for | OT architecture, risk management, and tailoring SP 800-53 controls | Zones and conduits, security levels, and requirements for asset owners and suppliers | Organizing a cybersecurity program and communicating risk |
ISA/IEC 62443 is especially useful when you need to establish security requirements for equipment manufacturers, product suppliers, and system integrators. It provides a common model for designing zones and conduits, assigning security levels, and evaluating the security capabilities of industrial products and service providers.
NIST 800-82 provides detailed guidance for designing your own OT environment and selecting or tailoring safeguards. The NIST CSF supplies an organization-wide structure for managing cybersecurity outcomes and communicating risk to leadership.
CISA and international partners have also published complementary architecture guidance. Creating and Maintaining a Definitive View of Your Operational Technology Architecture, released in September 2025 and co-sealed by CISA, the FBI, the UK National Cyber Security Centre, and other partners, focuses on maintaining an accurate record of OT assets, communications, and dependencies. That visibility supports the segmentation, monitoring, and risk-management activities that are a key part of 800-82.
How to implement NIST 800-82Â
The first step in applying NIST 800-82 to your production floor involves comparing your existing environment with the guide’s architecture and control recommendations. The goal is to identify exposures, document current safeguards, and develop a prioritized improvement plan.
There is no official standalone NIST 800-82 checklist, but the following process provides a useful structure.
- Build a complete OT asset inventory. Document controllers, HMIs, engineering workstations, historians, network devices, safety systems, connected machines, software, firmware, control logic, external connections, and responsible owners. Passive discovery tools and physical walkdowns are generally safer for legacy equipment than active scanning.
- Map the architecture and data flows. Record how OT systems communicate with each other, the business network, cloud services, the internet, and outside vendors. Look closely for dual-homed devices, cellular modems, remote-access tools, wireless connections, and communications that bypass established boundaries.
- Determine contractual and CMMC scope. Identify which assets process, store, transmit, or protect covered defense information. Document the applicable CMMC asset category, data flows, dependencies, and rationale for each scoping decision.
- Assign an impact level. Evaluate the consequences of a loss of confidentiality, integrity, or availability for each important OT system. Include safety, equipment damage, environmental impact, production loss, quality problems, and delayed contractual deliveries.
- Compare the architecture with Section 5. Review the environment against the guide’s defense-in-depth, network segmentation, boundary protection, remote-access, and system-hardening guidance.
- Assess safeguards using the OT overlay. Select the overlay baseline that matches the system’s impact level. Record whether each applicable control is implemented, partially implemented, missing, or infeasible in the current environment.
- Document compensating controls. When a safeguard cannot be implemented directly, identify an alternative that reduces the same risk. Explain the technical limitation, the selected measure, and how its effectiveness will be monitored.
- Prioritize remediation by mission consequence. Address exposures that could create the greatest safety, production, quality, or contractual impact. Some early improvements may involve removing unused connections, changing firewall rules, disabling dormant vendor accounts, or restricting removable media without modifying the controllers themselves.
- Validate changes before deployment. Test patches, configuration changes, firewall rules, and automated response actions in a lab or controlled environment whenever possible. Include engineering, operations, and safety personnel in reviews of changes that could affect the physical process.
- Repeat the assessment as the environment changes. Review the assessment when you add equipment, change the network architecture, introduce new data flows, or give a vendor remote access. Revisit the program again when Revision 4 is finalized.
The final result should include more than a list of failed controls. After completing the above, you should have an updated asset inventory, current network and data-flow diagrams, documented scope decisions, prioritized risks, control implementation records, compensating-control justifications, and a remediation roadmap that accounts for production schedules and maintenance windows.
What the NIST SP 800-82 Rev. 4 draft means for your OT program
If you are starting an OT security program now, build it using Revision 3. It remains the current final version, and work based on its defense-in-depth architecture and OT overlay should continue to provide value after Revision 4 is published.
The draft shows where NIST is placing more emphasis. Governance receives dedicated treatment through alignment with the Govern function in CSF 2.0. Asset management and network monitoring receive additional attention, and the architecture guidance expands its discussion of management functions and zero trust principles.
Revision 4 also reflects a broader range of operating environments. Its expanded coverage includes building automation, water and wastewater systems, food and agriculture, freight rail, maritime systems, and industrial environments that use cloud services and the Industrial Internet of Things.
If your program has limited governance, incomplete asset records, weak monitoring, or growing cloud and IIoT connectivity, the draft can help inform your longer-term roadmap. Continue to cite and assess against Revision 3 until the new version is finalized, and clearly identify any draft guidance you adopt early.
NIST is accepting public comments on the initial draft through November 30, 2026. Manufacturers can use the comment process to raise issues involving legacy equipment, production constraints, small-business resources, safety requirements, or guidance that is difficult to apply in real operating environments.
Manage OT compliance alongside your broader CMMC program
NIST 800-82 gives defense manufacturers a detailed foundation for OT architecture, risk management, and control selection. Applying it also creates documentation and coordination work: defining system boundaries, maintaining asset inventories, recording compensating controls, connecting safeguards to evidence, and tracking remediation as the environment changes.
Secureframe Defense helps teams manage this work in one place. Organizations can map controls across CMMC, NIST SP 800-171, and other applicable frameworks; identify evidence gaps; collect evidence through supported integrations; track remediation; maintain SSP and Plan of Action and Milestones documentation; and track their SPRS score in real time.
Engineering teams still own securing equipment, validating process changes, and evaluating safety consequences. Secureframe gives compliance and security teams visibility into the requirements, evidence, risks, and remediation work tied to the systems in scope.
Strengthen your security posture
FAQs
What is the latest version of NIST SP 800-82?
Revision 3, Guide to Operational Technology (OT) Security, is the current final version. It was published on September 28, 2023. NIST released the initial public draft of Revision 4 on September 21, 2026, with comments due November 30, 2026. Revision 3 remains authoritative until Revision 4 is finalized.
Is NIST SP 800-82 mandatory for defense contractors?
NIST 800-82 is voluntary guidance unless a contract, law, regulation, or customer requirement specifically incorporates it. Defense contractors often use it to define a risk-based approach for securing OT, including Specialized Assets addressed in a CMMC SSP.
Does CMMC require NIST SP 800-82?
CMMC Level 2 assesses the requirements in NIST SP 800-171 and does not establish a separate requirement to implement NIST 800-82. However, the CMMC rule requires contractors to document and manage applicable OT assets according to their asset category. NIST 800-82 can help define and support those security practices.
What is the difference between NIST SP 800-82 and NIST SP 800-53?
NIST SP 800-53 is a broad catalog of security and privacy controls. NIST SP 800-82 focuses on operational technology and includes an OT overlay that adapts SP 800-53 controls and baselines to the performance, reliability, and safety requirements of OT systems.
How many controls are in NIST SP 800-82?
NIST 800-82 does not establish one fixed set or number of controls for every OT system. Appendix F provides OT-specific baselines derived from NIST SP 800-53 for low-, moderate-, and high-impact systems. The applicable safeguards depend on the system’s impact level and the organization’s risk decisions.
What does NIST 800-82 recommend for IT and OT network segmentation?
The guide recommends a multilayer architecture with logical separation between enterprise and OT networks. A DMZ can host systems and services that need to exchange information across the boundary, while stateful firewalls, access restrictions, and, where appropriate, unidirectional gateways enforce approved communications. The guidance also discourages connections, such as dual-homed devices, that bypass boundary protections.
What is an OT overlay?
An OT overlay tailors a broader control framework to the needs of operational systems. The overlay in Appendix F of Revision 3 adapts NIST SP 800-53 Rev. 5 controls and baselines to account for OT safety, availability, performance, and reliability requirements.

Emily Bonnie
Senior Content Marketing Manager
Emily Bonnie is a seasoned digital marketing strategist with over ten years of experience creating content that attracts, engages, and converts for leading SaaS companies. At Secureframe, she helps demystify complex governance, risk, and compliance (GRC) topics, turning technical frameworks and regulations into accessible, actionable guidance. Her work aims to empower organizations of all sizes to strengthen their security posture, streamline compliance, and build lasting trust with customers.