NIST SP 800-82: The ICS Security Playbook Explained
Every serious conversation about securing SCADA in the United States eventually cites the same document: NIST Special Publication 800-82. It is free, it is vendor-neutral, and it is the reference that TSA directives, EPA guidance, insurers, and auditors quietly borrow from when they decide what "reasonable OT security" means. Revision 3 - retitled the Guide to Operational Technology Security - is the current edition, and it is long. This guide gives you the working version: what 800-82 actually covers, whether it binds you, how it fits with IEC 62443 and the NIST Cybersecurity Framework, how US operators put it to work, and how to turn its recommendations into sharp questions for any SCADA vendor.
From the Merobix industrial security hub - every security, compliance & certification guide in one place.
What NIST SP 800-82 Is - and What It Is Not
SP 800-82 is NIST's comprehensive guide to securing operational technology: SCADA systems, distributed control systems, PLCs, RTUs, and - since Revision 3 - the broader OT family including building automation, physical access control systems, and industrial IoT. It was first developed in the 2000s when "ICS security" barely existed as a discipline, revised in 2015 (Rev 2), and substantially rewritten as Revision 3, published by NIST in September 2023.
Three things it is: a shared vocabulary for how OT differs from IT security, a catalog of architecture and control recommendations tailored to environments where a reboot can stop production, and a bridge that connects OT practice to the rest of the NIST ecosystem - the Cybersecurity Framework and the SP 800-53 control catalog.
Three things it is not: it is not a regulation (no private operator is fined for ignoring it), it is not certifiable (there is no "800-82 certified" - treat any vendor claiming that as a red flag), and it is not a checklist you can complete in an afternoon - it expects you to run a risk-based program, not tick boxes.
What Revision 3 Actually Covers
The current edition is organized around a handful of load-bearing themes:
- OT overview and threat landscape. How control systems work, how they differ from IT, and the incident history - from Stuxnet to ransomware - that motivates the rest. Our companion piece on OT vs IT security differences unpacks this theme in depth.
- Risk management for OT. Applying the NIST risk framework to environments where the consequence side of the equation includes physical damage, environmental release, and human safety - not just data loss.
- OT cybersecurity architecture. Network segmentation, zones and DMZs, firewalls between enterprise and control networks, remote access patterns, and defense in depth - the guide's most-cited chapter, and the one that maps directly onto SCADA purchasing decisions.
- Applying the Cybersecurity Framework to OT. Rev 3 structures its guidance around CSF functions so an OT program can report in the same language as enterprise security.
- An OT overlay of SP 800-53 controls. The federal control catalog, tailored for OT - which controls apply, which need compensating approaches, and where availability constraints change the answer.
The consistent thread is pragmatism: 800-82 repeatedly acknowledges that you often cannot patch promptly, cannot install agents on a PLC, and cannot take production down for security's convenience - and then tells you what to do instead: segment, restrict access, monitor, and plan response.
Is It Mandatory? The Honest Answer
For US federal agencies operating control systems, NIST guidance is effectively binding. For private operators, 800-82 is voluntary - but it becomes binding through the side door with remarkable consistency:
- TSA pipeline security directives require cybersecurity implementation plans whose expected content tracks 800-82's architecture and access-control guidance closely - see our TSA directives guide.
- EPA and water-sector guidance points utilities to NIST references when conducting AWIA risk assessments.
- Cyber insurers and customer questionnaires borrow their OT questions from it, whether they cite it or not.
- Post-incident scrutiny - regulators, lawyers, and boards asking "was this operator following recognized practice?" reach for 800-82 as the US benchmark of reasonable care.
The practical posture: treat it as the definition of defensible practice. If your program can be described in 800-82's terms, every downstream audit gets easier.
How 800-82 Maps to IEC 62443 and NIST CSF
Buyers meet three frameworks in every OT security conversation, and they are complements, not competitors:
| Attribute | NIST SP 800-82 | IEC 62443 | NIST CSF 2.0 |
|---|---|---|---|
| What it is | Free descriptive guidance for securing OT | Normative international standard family for IACS security | High-level risk framework, six functions |
| Primary audience | Asset owners and their security teams | Asset owners, integrators, and product vendors (separate parts for each) | Executives and whole-of-organization programs |
| Certifiable? | No | Yes - product and system certification schemes (ISASecure, exida) | No |
| Graded security levels | No - risk-based tailoring | Yes - SL1 through SL4 by attacker capability | Tiers describe program maturity, not system strength |
| Geographic gravity | United States | International | US origin, global adoption |
| Best used for | Building and defending your internal OT program | Specifying requirements for systems and vendors you buy | Organizing and communicating the overall program |
A clean division of labor emerges: CSF organizes the program and the board conversation, 800-82 tells your team how to secure OT specifically, and 62443 gives you contract language - security levels and certifications - to demand from vendors. Rev 3 makes the first mapping explicit by structuring guidance around CSF functions, and it acknowledges 62443's zone-and-conduit model in its architecture guidance. Deep dives on both companions: our IEC 62443 certification guide and certifications explainer.
How US Operators Actually Use It
In the field, 800-82 shows up in four recurring ways:
- As the skeleton for risk assessments. Water utilities doing AWIA assessments, pipeline operators writing TSA implementation plans, and manufacturers running their first OT risk review all crib its threat categories and architecture recommendations rather than inventing their own.
- As the referee in IT/OT arguments. When the corporate security team wants to run vulnerability scans against the PLC network and the operations team refuses, 800-82 is the neutral document both sides accept - it validates OT's availability concerns while denying OT a free pass on security.
- As policy raw material. Its recommendations convert almost line-by-line into internal standards: remote access policy, segmentation requirements, logging expectations, incident response roles.
- As justification in budget season. "NIST recommends this and we do not do it" remains one of the most effective sentences in a capital request.
The Recommendations That Should Shape Your SCADA Purchase
Strip the document to the guidance that directly affects what you buy, and you get a short list:
- Segment ruthlessly. No direct path from enterprise or internet to control devices; cross zone boundaries only through controlled conduits. A SCADA architecture that needs inbound firewall rules into the OT zone works against this from day one - the case for outbound-only gateway architectures in one sentence.
- Authenticate humans individually. Unique accounts, MFA, least privilege by role, prompt de-provisioning. Shared operator logins fail the guidance outright.
- Protect data in transit. Encrypt communications leaving the control network; manage device identities and credentials deliberately.
- Log and monitor. Capture security-relevant events - logins, failures, configuration and control changes - in tamper-resistant form, and watch them.
- Control the write path. Changes to the process (setpoints, commands) deserve stronger controls than reads: authorization, validation, and recorded outcomes.
- Plan for degraded operation. Store-and-forward through outages, tested backups, and an OT-specific incident response plan.
This list doubles as a scorecard for platforms. Merobix was engineered along exactly these lines: an outbound-only gateway that requires no inbound OT firewall rules, per-user MFA (TOTP and passkeys) with per-site role authorization, TLS on cloud, MQTT, and industrial connections, signed telemetry envelopes with replay detection, immutable audit records with runtime threat monitoring delivered to email, SMS, webhook, or SIEM, and control-tag authorization with setpoint bounds checking on every write - with the full detail published on our security page. Merobix also maps its platform controls to IEC 62443 and runs a SOC 2 readiness program, so the 800-82-shaped questions in your assessment have documented answers.
Key takeaway: NIST SP 800-82 is not a law and not a certificate - it is the playbook US assessors, insurers, and regulators quietly grade you against. Use it three ways: structure your internal OT program on its guidance, translate its architecture chapter into hard requirements for any SCADA purchase, and expect every serious vendor to answer its themes - segmentation, individual authentication, encrypted transport, tamper-resistant logging, controlled writes - fluently and in writing.
Turning 800-82 Into Vendor Evaluation Questions
Close the loop by making the guidance interrogative. Six questions cover the core:
- What firewall rules does your architecture require at the OT boundary, and in which direction?
- Is every user individually identified with MFA, and can roles restrict both visibility and control actions per site?
- How is data protected in transit on every hop - field to gateway, gateway to platform, platform to user?
- Which security events do you log, are the logs tamper-resistant, and how do they reach our SIEM?
- What validation happens before a setpoint write reaches a device, and what record exists afterward?
- How does the system behave through a connectivity outage, and how are backups and restores tested?
A vendor who answers all six specifically - with architecture documents, not adjectives - is aligned with the playbook whether or not they cite it. A vendor who answers with "military-grade encryption" and no specifics has told you what you need to know. Bring the list to a Merobix demo and ask them live; the broader question bank is in our 50 vendor security questions.
Frequently Asked Questions
What is NIST SP 800-82?
NIST Special Publication 800-82 is the US National Institute of Standards and Technology's guide to operational technology (OT) security - the closest thing the industry has to a free, comprehensive playbook for securing SCADA systems, DCS, PLCs, and related control systems. Revision 3, published in 2023, retitled it the Guide to Operational Technology Security and broadened it beyond classic industrial control systems to cover building automation, physical access control, and industrial IoT. It explains how OT differs from IT, how to run an OT risk program, how to architect defensible control networks, and how to tailor NIST's general security controls to environments where availability and safety come first.
Is NIST SP 800-82 mandatory?
Not for private operators - it is guidance, not regulation. US federal agencies must apply NIST controls to their own systems, which pulls 800-82 into government-operated OT. For everyone else it becomes binding indirectly: TSA pipeline security directives, EPA water-sector guidance, cyber insurers, and customer security questionnaires all reference or borrow from it, and auditors treat it as the standard of reasonable care for US operators. In practice, if you run OT in the United States and something goes wrong, the question asked afterward is usually whether you followed the practices 800-82 describes.
What is the difference between NIST 800-82 and IEC 62443?
They approach the same problem from different directions and work best together. NIST 800-82 is free descriptive guidance for asset owners - it explains threats, architecture patterns, and how to tailor security controls to OT, but nothing is certified against it. IEC 62443 is a formal international standard family with normative requirements, four graded security levels (SL1 to SL4), and certification schemes such as ISASecure that vendors and products can actually be certified under. A common pattern: use 800-82 to structure your internal program and risk assessment, and use IEC 62443 security levels and certifications to specify requirements for vendors and systems you buy.
What changed in NIST 800-82 Revision 3?
Three big things. First, scope: the guide moved from industrial control systems specifically to operational technology broadly, adding building automation systems, physical access control, and IIoT devices. Second, alignment: Rev 3 ties OT security to the NIST Cybersecurity Framework and provides an OT-tailored overlay of the SP 800-53 control catalog, so OT programs plug into the same language enterprise security teams already use. Third, modernization: expanded treatment of risk management, defense-in-depth architecture, and current practices reflecting how threats and technology - including cloud-connected monitoring - evolved since Revision 2 in 2015.
How should buyers use NIST 800-82 to evaluate SCADA vendors?
Turn its recommendations into vendor questions. The guide's core themes translate directly: How does your architecture support network segmentation, and does it require inbound firewall rules into the OT zone? Is authentication unique per user with MFA, and is least privilege enforceable per role and per site? Are all communications encrypted and device identities managed? What security events are logged, are logs tamper-resistant, and can they reach our SIEM? How are patches delivered and validated? A vendor fluent in these answers - with architecture documentation to back them, the way Merobix publishes its outbound-only gateway design, role model, and audit-chain approach - is demonstrating alignment with the playbook US assessors actually use.
Sources & Further Reading
- NIST SP 800-82 Rev. 3: Guide to Operational Technology (OT) Security - National Institute of Standards and Technology
- NIST SP 800-82 Rev. 2: Guide to Industrial Control Systems (ICS) Security (withdrawn, superseded by Rev. 3) - National Institute of Standards and Technology
- NIST Cybersecurity Framework (CSF 2.0) - National Institute of Standards and Technology
- NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations - National Institute of Standards and Technology
- ISA/IEC 62443 Series of Standards - International Society of Automation
- Surface Transportation Cybersecurity Toolkit (Security Directives) - Transportation Security Administration
- AWIA Section 2013: Risk and Resilience Assessments and Emergency Response Plans - U.S. Environmental Protection Agency
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.