NIST SP 800-82 OT Security Guide: Applying Revision 3 to Industrial Systems

Most industrial operators know they should secure their control systems, but few have a structured way to turn that intent into controls an assessor can test without disrupting production. NIST Special Publication 800-82 Revision 3, the Guide to Operational Technology (OT) Security, is the most widely used free reference for doing exactly that. This guide explains what Revision 3 contains, how its OT overlay to SP 800-53 Rev. 5 works, what it expects for identities and remote access, and how to apply it in a real plant, utility or building estate. It also covers the Revision 4 initial public draft released in September 2026. It is written for OT security leads, control engineers, assessors and the executives who fund the work. For the broader discipline, see the OT Security Guide.

Key takeaways

• Revision 3 is guidance, not a regulation. It was published on 28 September 2023, superseded Revision 2 from 2015, and becomes binding only when a contract, regulator or internal policy adopts it.
• The scope widened from ICS to all OT. Revision 3 covers industrial control systems plus building automation, transportation and physical access control systems, anything programmable that monitors or controls physical processes.
• Appendix F is the part assessors use. The OT overlay tailors SP 800-53 Rev. 5 controls into low, moderate and high impact OT baselines, with OT-specific discussion for each control across 19 families.
• Identity is a core control area, not an add-on. The guide calls for separate OT and corporate credentials, least privilege by role, and multi-factor authentication for remote access, which is where many real intrusions start.
• Revision 4 is in draft. The initial public draft released on 21 September 2026 restructures the guide around CSF 2.0 and the Govern function, with comments open until 30 November 2026. Build on Revision 3 now and track the draft.

What it is and who it applies to

SP 800-82 Rev. 3 is a NIST guide written by staff at NIST and MITRE. It describes OT topologies, the threats and vulnerabilities typical of those systems, and recommended countermeasures, while respecting what NIST calls the unique performance, reliability and safety requirements of OT.

• US federal agencies and their contractors: agencies operating OT (facilities, laboratories, dams, transport) use it alongside the NIST Risk Management Framework, and the Appendix F overlay is the natural way to select controls for an OT system in an authorisation package.
• Critical infrastructure operators: energy, water, manufacturing, chemicals and transport operators use it voluntarily as a reference architecture and control catalogue. Sector rules may reference it or overlap with it.
• Integrators and product suppliers: customers increasingly write SP 800-82 or overlay controls into procurement specifications, so suppliers need to know what they will be asked to evidence.
• Organisations outside the US: it is free, mature and maps cleanly to CSF, so it is often used alongside IEC 62443 even where 62443 is the primary standard. See the IEC 62443 Guide.

Structure and key requirements

Revision 3 has six main sections and seven appendices. Knowing which part answers which question saves a lot of time.

Defence in depth: the five layers

Section 5 organises the architecture around five layers. Every control you implement should sit in at least one of them, and critical assets should be covered by several.

1. Security management: the programme, policies, risk assessment and the management functions that configure and monitor everything else.
2. Physical security: site, building, cabinet and port access, because physical access to a PLC usually means control of it.
3. Network security: segmentation into zones following the Purdue style model, with a DMZ between enterprise and control networks, boundary protection and monitoring.
4. Hardware security: device hardening, secure boot and tamper features where available, and disabling unused physical interfaces.
5. Software security: application allowlisting, patch and configuration management, and secure engineering software.

The architecture section also deals with cyber-related safety, availability, geographically distributed systems and Level 0 field devices. Its main message is that a flat network between the corporate LAN and controllers is the single most dangerous design, and that traffic between enterprise and OT should terminate in a DMZ rather than pass directly. See the Network Segmentation Guide.

The OT overlay in Appendix F

The overlay is a tailored version of SP 800-53 Rev. 5 for OT. NIST describes it as standalone, so you can use it without reading the main body. It provides control baselines for low, moderate and high impact OT systems (Table 22), tailoring considerations (F.4), a discussion of OT communication protocols (F.5), and detailed control specifications for 19 control families, from Access Control (AC) to Supply Chain Risk Management (SR) (F.7). For each control the overlay can add OT Discussion text, explaining how to implement it without harming operations, and can add or remove enhancements.

Identity and NHI requirements

OT environments are dominated by identities that are not people: engineering workstation service accounts, historian and OPC connectors, SCADA polling accounts, controller passwords, vendor remote-support accounts and certificates on newer IIoT gateways. Revision 3 addresses identity mainly through the Protect function and the AC and IA families of the overlay.

• Separate OT and corporate credentials: the guide recommends separate authentication mechanisms and credentials for OT and corporate users, so that a compromised corporate account does not unlock the control network. In practice this often means a separate OT directory or domain with no trust from the enterprise forest, or a one-way trust at most.
• Least privilege by role: restrict privileges to what each role needs. Operators, engineers, maintenance technicians and vendors need different rights, and the ability to download logic to a controller should be rare.
• MFA for remote access: the guide calls for multi-factor authentication on remote access to OT. The Colonial Pipeline attack began with a dormant VPN account without MFA; the operator then shut the pipeline down for about six days as a precaution, which shows how an IT-side identity failure can stop physical operations.
• Shared and local accounts: many HMIs and controllers only support a shared or local login. Record each one in the account inventory with an owner, vault the password, change it when staff with knowledge leave, and compensate with physical and network controls.
• Device and machine identities: IA-3 asks for device identification and authentication. Use it where protocols support it (for example certificates on newer gateways), and document network position as the compensating control where they do not.
• Default and embedded credentials: controllers and drives often ship with default passwords. Change them during commissioning and track them under IA-5.

Attackers rely on these gaps. In MITRE ATT&CK for ICS, Valid Accounts (T0859), External Remote Services (T0822) and Remote Services (T0886) describe the use of legitimate credentials and remote access paths. For a detailed treatment of OT accounts, jump hosts and vendor access, see the OT and ICS Identity and Access Guide and the OT Remote Access Guide.

Implementation steps

The order below follows the logic of Sections 3, 4 and 6 and the RMF steps in Section 4. It assumes an existing site with legacy systems, which is the common case.

1. Charter the programme. Get a senior sponsor, name an OT cybersecurity manager, and agree objectives, scope (sites, systems, networks) and responsibilities between engineering, IT security and operations. Section 3 also calls for a business case that ties investment to failure scenarios.
2. Build a cross-functional team. Include control engineers, operations, safety, IT security and procurement.
3. Inventory assets and data flows. Start passively: network traffic capture, engineering project files, controller backups and site walk-downs. Record firmware versions, protocols, accounts and remote access paths. See the OT Asset Visibility Guide.
4. Categorise systems and select a baseline. Assign low, moderate or high impact, taking safety and physical consequence into account, and select the matching Appendix F baseline.
5. Tailor the baseline. For each control, decide implement, implement with OT adaptation, or compensate. Record the reason and the compensating control. Pay attention to controls that could trip a process, such as account lockout on an operator HMI.
6. Fix the architecture first. Introduce or harden the DMZ, segment control zones and remove direct enterprise to controller paths. Put remote access through a single managed path with MFA and session recording.
7. Clean up identities. Remove dormant and unknown accounts, change default credentials, vault shared passwords, and separate OT from corporate authentication.
8. Deploy monitoring passively. Use span ports or taps for network monitoring; avoid agents or active scans on controllers until tested.
9. Test every change in a safe environment. Use a test bench, a simulator or a non-production line. Roll out to one cell or unit first, schedule changes in planned outage windows, and keep the previous firewall rule set, controller logic and configuration so you can roll back within the window if the process misbehaves.
10. Exercise response and recovery. Practise restoring controller logic and HMI projects from backup and run incident scenarios with operations. See the OT Incident Response Guide.

Decision guidance: what to do first

Evidence and assessment

An assessment against SP 800-82 is usually an assessment of the overlay controls in your chosen baseline plus the architecture in Section 5. Prepare the evidence before the assessor arrives.

• Asset and account inventory: devices, firmware, protocols, accounts (human, shared, service and vendor) with owners.
• Network diagrams and rule sets: zone diagrams showing the DMZ, and firewall rules with a business reason for each rule.
• Tailoring record: every control in the baseline with its status, OT adaptation and compensating controls.
• Remote access records: list of remote access paths, MFA configuration, session logs and recordings.
• Backup and restore tests: dated restore tests of controller logic and HMI projects.
• Monitoring output: alerts reviewed, with tickets showing follow-up, which also supports AU-6.

Detection and measurement

Monitor for new devices on control networks, new or changed controller logic, firmware or parameter changes (ATT&CK for ICS Modify Parameter, T0836), engineering protocol commands from unexpected hosts, remote sessions outside approved windows, and logons with OT accounts from enterprise networks. Internet exposure of OT devices (Internet Accessible Device, T0883) should be checked externally on a schedule.

• Inventory coverage: percentage of OT assets with owner, firmware version and criticality recorded.
• Remote access under control: percentage of remote access paths that go through the managed path with MFA (target 100 per cent).
• Default and shared credentials: count of devices with known default credentials, and of shared accounts without a vaulted password.
• Baseline completion: percentage of Appendix F baseline controls implemented or formally compensated.
• Restore readiness: percentage of critical controllers with a successful restore test in the last 12 months.
• Detection latency: time from an unauthorised logic or configuration change to alert.

Mapping to other frameworks

Revision 3 Section 6 applies the CSF functions to OT. The table below maps the main themes to CSF 2.0 subcategories and SP 800-53 Rev. 5 controls; the CSF 2.0 mapping is our own, since Revision 3 predates CSF 2.0. Revision 4 draft aligns to CSF 2.0 directly.

• IEC 62443: 62443 is the international OT standard family with zones, conduits and security levels, and a product and integrator certification scheme. SP 800-82 is broader guidance with a control catalogue. Many operators use 62443 for architecture and supplier requirements and the overlay for control evidence. See the IEC 62443 Guide.

What changes in the Revision 4 draft

The initial public draft released on 21 September 2026 keeps the same purpose but changes structure and reach. NIST lists these updates:

• Sectors: expanded introduction covering building automation, water and wastewater, food and agriculture, freight rail, maritime vessels, and IIoT and cloud convergence.
• CSF 2.0: the document is restructured around CSF 2.0, with risk management reorganised under the Govern function.
• Enterprise risk: expanded discussion of aligning OT risk with enterprise risk management, referencing NIST IR 8286r1.
• RMF: discussion of RMF adoption in Appendix F.
• Controls: expanded guidance on asset management and network monitoring and detection.
• Architecture: guidance on protecting system management functions and applying zero trust principles.

Comments are open until 30 November 2026. Until a final Revision 4 is published, Revision 3 remains the current final version. If you are starting now, structure your programme around CSF 2.0 functions so the move is a mapping exercise rather than a rewrite.

Common pitfalls

• Applying IT controls unchanged: active vulnerability scans, forced patch reboots or lockout policies applied to controllers can trip processes. Use the OT Discussion text in the overlay and test on a bench first.
• Treating the guide as a checklist without tailoring: picking the high baseline and marking everything "not applicable" gives no assurance. Each gap needs a recorded compensating control.
• Forgotten remote access: vendor modems, cellular routers and legacy VPN accounts bypass the managed path. The Colonial Pipeline case shows what one dormant account can cause.
• Enterprise trust into OT: letting the corporate directory authenticate OT logons means an enterprise compromise reaches the control network. The guide's separate credential recommendation exists for this reason.
• Untested backups: controller logic backups that were never restored often fail when needed, or are older than the running logic.
• Inventory that stops at IP devices: serial and fieldbus devices at Level 0 and 1 are left out, so risk and recovery plans miss them.

Practitioner checklist

• Confirm which version you are working to (Revision 3 final) and assign someone to track the Revision 4 draft.
• Write a programme charter with sponsor, scope, objectives and a named OT cybersecurity manager.
• Build a passive asset and account inventory, including shared, service and vendor accounts.
• Categorise each OT system and select the matching Appendix F baseline.
• Record tailoring decisions and compensating controls for every baseline control.
• Put all remote access through one managed path with MFA, approval and session recording.
• Separate OT authentication from the corporate directory and remove default credentials.
• Establish a DMZ between enterprise and control networks and review rules against real protocol needs.
• Deploy passive network monitoring and alert on logic, firmware and parameter changes.
• Test restoring controller logic and HMI projects at least annually.

Standards and references

• NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
• NIST: SP 800-82 Rev. 3 full text (PDF)
• NIST: SP 800-82 Rev. 4 initial public draft
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0
• MITRE ATT&CK for ICS: Valid Accounts
• MITRE ATT&CK for ICS: External Remote Services

Related NHI Mgmt Group resources: OT Security Guide · IEC 62443 Guide · OT and ICS Identity and Access Guide · OT Asset Visibility Guide · OT Security Maturity Model