If you are securing an industrial environment, you have probably heard this question in two different conference rooms: "Are we 800-82 compliant?" and "Where are we on 62443 compliance?" Many enterprises treat these as parallel tracks, spinning up separate workstreams that duplicate effort, confuse plant personnel, and burn attention and budget. It needn’t be so.  

NIST SP 800-82 Rev. 3 which is the definitive U.S. federal guide for OT security explicitly references ISA-62443-2-1 as a suitable cybersecurity program standard for industrial automation and control systems (IACS). The two frameworks are designed to be complementary and not competitive. 800-82 strengthens your risk management architecture and control overlay while IEC 62443 provides your operational security program, system design methodology, measured risk suppression and technical requirements hierarchy. Together, these two form the most defensible and auditable OT security posture you can build.

Today’s blog post gives you a practitioner-level mapping, sequencing, and implementation guidance to make them work as part of a unified program aligned to your unique security and compliance needs.

Before we move ahead, don't forget to check out our previous blog post on the Adidas cyber incident here.

NIST SP 800-82 Rev. 3: The field manual

Released in the month of September 2023, Rev. 3 represents a substantial overhaul of the 2015 edition. Key changes include expanded coverage of IIoT and cloud-connected OT, tighter alignment with NIST CSF and SP 800-53 Rev. 5, supply chain security guidance, and a more stronger emphasis on continuous monitoring tailored to OT constraints. It is structured around:

• OT system categorization (say for example impact levels: Low, Moderate, High) based on confidentiality, integrity, and availability

• Control overlays that adapt SP 800-53 Rev. 5 controls to OT realities while recognizing that you cannot patch a running reactor or reboot a safety instrumented system mid-shift

• Risk management using a three-tiered approach: organization level, mission/business process level, and information/OT system level to offer a more graduated control framework

• Architecture guidance including defense-in-depth, network segmentation that is fully aligned with the Purdue model, and DMZ design

It is essentially a guidance document that tells you what to achieve. IEC 62443 on the other hand tells you how to structure your program to get there.

IEC 62443: The program architecture

The IEC 62443 series (jointly maintained with ISA as ANSI/ISA-62443) is the global standard for IACS security. It is organized into four groups:

The framework's foundational concepts are Security Levels (SL) and the Zone and Conduit model.

Security Levels run from SL 1 through SL 4:

• SL 1: Protection against unintentional or accidental misuse

• SL 2: Protection against intentional attack using simple means, low motivation

• SL 3: Protection against intentional attack using sophisticated means, moderate resources, automation-specific knowledge

• SL 4: Protection against state-level or well-funded adversaries with deep automation-specific knowledge.

Zones group assets with similar security requirements and criticality while conduits are the controlled communication pathways between zones. This model is the architectural backbone of everything in the 62443 series and offers a more nuanced control over your security measures.

A critical update: IEC 62443-2-1:2024 (released Aug 2024) restructured asset owner requirements into Security Program Elements (SPEs) and introduced a maturity model. It also explicitly addresses legacy systems while recognizing that IACS lifespans can exceed twenty years and that compensating controls, not just native technical capabilities, are acceptable when underlying systems cannot support modern security requirements.

Structural mapping: How IEC 62443 supports 800-82 compliance

The relationship is not at a one-to-one plane. Instead, it is architectural. Think of 800-82 as defining the compliance requirements and IEC 62443 as providing the program and technical machinery to meet them.

800-82 Section 4: OT Risk Management → IEC 62443-3-2 + 62443-2-1

NIST SP 800-82 Rev. 3 Section 4 defines OT risk management using a tiered approach. IEC 62443-3-2 is the operationalized equivalent: it defines the process for security risk assessment and system design, producing a Zone and Conduit model and documented Target Security Levels (TSLs) as outputs that are packaged into a Cybersecurity Requirements Specification (CRS).

How to execute this in practice:

• Use 800-82's risk framing (identify OT systems, categorize by impact) as your starting point. This gives you the business and mission context.

• Use 62443-3-2 to conduct the system-level risk assessment. Work with your process safety engineers — HAZOP documentation is a goldmine for understanding consequence severity. Map process hazards to cyber threat scenarios (loss of control, denial of service to a safety function, unauthorized command injection).

• Assign Target Security Levels to each zone based on the threat scenarios and consequence analysis. A safety instrumented system zone protecting a high-hazard process should target SL 2 or SL 3. A corporate historian may be SL 1 with a one-way data diode as the conduit.

• Document everything in the CRS. This becomes your primary audit artifact for 800-82 Section 4 compliance.

Common mistake: Treating the Zone and Conduit model as a network diagram exercise. It is not. It is a risk classification exercise that drives control selection. Start with consequence analysis, then draw zones.

800-82 Section 5: Recommended security controls: IEC 62443-3-3 + 62443-4-2

800-82 Section 5 references the SP 800-53 Rev. 5 control families and provides OT-specific overlays. IEC 62443-3-3 provides 110 foundational requirements (FRs) organized into seven categories — Access Control (IAC), Use Control (UC), System Integrity (SI), Data Confidentiality (DC), Restricted Data Flow (RDF), Timely Response to Events (TRE), and Resource Availability (RA) — each tied to specific Security Level requirements.

The mapping between these two is one of the most useful tools available to an OT security practitioner. For example:

Access control (800-82/800-53 AC family). IEC 62443-3-3 IAC/UC requirements:

• 800-82 requires least-privilege access and multi-factor authentication for remote access. 62443-3-3 at SL 2 requires human user identification and authentication, and at SL 3 requires multi-factor for all accounts — giving you a testable technical threshold.

• When your OT vendor argues that MFA "can't be done" on a legacy HMI, 62443-2-1:2024 explicitly allows compensating controls. Document the compensating control, the residual risk accepted, and the compensating measures (separate jump host with MFA, session recording, time-limited access windows). This is your audit defensibility.

System Integrity (800-82 SI family): IEC 62443-3-3 SI requirements:

• 800-82 requires malware protection, software integrity verification, and security alerts. 62443-3-3 SI requirements at SL 2 include protection against malicious code, prevention of unauthorized modification, and reporting of integrity violations.

• Implementation: Whitelisting-based endpoint protection (not traditional AV) on HMIs and engineering workstations; read-only media controls; firmware verification where supported by the controller manufacturer.

Audit and accountability (800-82 AU family) and IEC 62443-3-3 TRE requirements:

• Both frameworks require logging, audit trails, and the ability to detect security events. In OT, this means deploying passive network monitoring that understands ICS protocols such as Modbus, DNP3, EtherNet/IP, PROFINET, IEC 61850 without injecting active traffic that can disrupt deterministic control loops. Any monitoring tool that actively polls OT devices has no place inside your control zone.

800-82 Section 6: Network Architecture and Defense-in-Depth: IEC 62443 Zone/Conduit Model

NIST 800-82 Rev. 3 endorses defense-in-depth architecture based on the Purdue model while acknowledging modern adaptations for cloud connectivity and IIoT. IEC 62443's Zone and Conduit model is the implementation framework.

Now let’s turn this into a concrete architecture:

• Level 0-1 (Field devices such as sensors, actuators, PLCs): No routable IP protocols if avoidable. Apply vendor hardening guides, change all default credentials, disable unused communication ports and services. These devices typically cannot be patched on a normal cycle; account for this in your risk register and compensating controls.

• Level 2 (Control/HMI): Micro-segment by process line or cell where feasible. Apply application allowlisting. Engineering workstations should never have internet access. Removable media controls are essential. Many of us may remember that the 2010 Stuxnet attack propagated via USB.

• Level 3 (Site Operations/MES): Aggressive north-south traffic filtering. Historians should push data upward through one-way enforcement where feasible; never allow a pull from Level 4 into Level 3. This is a conduit design decision, not just a firewall rule.

• DMZ (IT/OT boundary): Traffic crossing the IT/OT boundary must traverse the DMZ. Jump hosts for remote access, patch staging servers, AV update servers, and data aggregation services live here. Never allow direct connections between Level 4 IT and Level 2 control systems.

• Level 4/5 (Corporate IT, Cloud): The SIEM, SOAR, identity provider, and data lakes reside here. OT identities should be first-class citizens in your identity infrastructure and not an afterthought managed by a shared local admin account.

800-82 Supply chain risk management: IEC 62443-2-4

800-82 Rev. 3 dedicates significant attention to supply chain security — a major upgrade from Rev. 2. IEC 62443-2-4 (Security Program Requirements for IACS Service Providers) is the corresponding instrument. Use it to:

• Define contractual security requirements for system integrators, OEM remote access vendors, and IACS service providers

• Require evidence of 62443-2-4 compliance in vendor contracts

• Mandate vendor use of dedicated jump hosts rather than direct-to-control-system connections

• Require session recording for all third-party remote access — this is your incident investigation lifeline when a vendor connection becomes a threat vector

The uncomfortable truth about vendor access: The majority of OT security incidents involve a third-party connection such as direct VPN to a PLC, unsecured cellular modem installed by a chiller vendor, an integrator's laptop with stale credentials. 62443-2-4 gives you the contractual and programmatic teeth to address this.

800-82 Incident Response and recovery: IEC 62443-2-3 + 62443-2-4

800-82 Section 4.5 addresses OT incident response with important OT-specific considerations: safety primacy, maintaining physical process continuity, and the reality that you may need to continue running a partially compromised system because the alternative — shutting down — has worse safety consequences than a contained cyber event.

IEC 62443-2-3 (Patch Management in the IACS Environment) and the incident management elements of 62443-2-4 provide the operational procedures framework.

Practical implementation:

• Your OT Incident Response plan is not your IT IR plan with "OT" inserted at the top. Write separate runbooks for each major asset class: PLC compromise, historian ransomware, HMI malware, unauthorized engineering workstation access.

• Define your escalation path that includes process safety engineers, not just IT security. The OT security team does not unilaterally take a running process offline — that is a joint decision with operations leadership and safety engineering.

• Conduct tabletop exercises with plant floor personnel, not just IT staff. Your maintenance technicians are your first responders in a real incident.

• Document manual fallback procedures. If your OT network is isolated due to an incident, can your operators run the process manually? If not, that is a resilience gap to address before an incident forces the question.

 Implementation sequencing: Where to start?

Most organizations try to do everything at once and accomplish nothing thoroughly. Here is a sequencing that reflects how risk reduction actually accumulates:

Phase 1: Know what you have (Months 1-3)

Conduct passive asset discovery across your OT network. Do not deploy active scanning tools in a production OT environment without vendor-specific authorization and testing in a replica environment first. Tools like Claroty, Dragos, Nozomi Networks, and Microsoft Defender for IoT are designed for passive OT discovery. Output: an asset inventory tagged by zone, criticality, and supportability (supported vs. end-of-life vs. unsupported). This feeds both 800-82 Section 4 (system inventory) and 62443-3-2 (input to zone design and risk assessment).

Phase 2:  Segment and Protect What Matters Most (Months 2-6)

Based on your risk assessment and Zone/Conduit model, implement your network segmentation. Start with the IT/OT boundary — the DMZ if you don't have one, or hardening the one you do. Kill flat OT networks. Apply the conduit controls between your highest-consequence zones first. This yields the largest attack surface reduction fastest.

Phase 3: Identity and access hygiene (Months 3-6)

Eliminate shared accounts, especially on HMIs and engineering workstations. Implement role-based access control. Deploy a secure remote access solution (jump host + MFA + session recording) and shut down direct VPN access to OT devices. Require your vendors to use it. Implement privileged access management for engineering credentials.

Phase 4: Visibility and detection (Months 5-9)

Deploy OT-aware passive monitoring. Baseline normal industrial protocol behavior and alert on deviations such as unexpected function codes, new devices appearing on the network, anomalous traffic to Level 3/4. Feed events to your SIEM. Create OT-specific detection rules; IT security analysts will not know that a Modbus write to an unexpected register address is anomalous without guidance.

Phase 5: Program maturity (Ongoing)

Patch management per 62443-2-3 (risk-based, tested in a staging environment, coordinated with operations scheduling), continuous monitoring, incident response rehearsal, vendor compliance enforcement, and annual risk assessment updates using 62443-3-2 as the methodology.

Demonstrating compliance: The audit evidence stack

When a regulator, customer, or internal audit asks you to demonstrate 800-82 compliance, here is what you produce — and which 62443 artifact generates it:

Where organizations often fail

In over a decade of OT security practice, the same failure modes appear repeatedly. Be deliberately aware of these:

Applying IT security timelines to OT patch management. A critical patch on a Windows-based HMI does not get applied in 30 days if the HMI vendor has not validated the patch, you have a 24/7 production schedule, and the next scheduled maintenance window is in six months. 62443-2-3 explicitly addresses this with a risk-based patch management approach — assess the exploitability and impact of the unpatched vulnerability, implement compensating controls (network isolation, monitoring, temporary access restrictions), and document the accepted risk until the patch can be applied safely.

Segmentation on paper only. A Zone and Conduit diagram that does not match the actual network configuration is worse than no diagram — it creates false assurance. Verify your segmentation with periodic network reviews and passive traffic analysis. Your monitoring tool will tell you whether that historian is actually only talking to Level 3, or whether someone opened a direct connection to an engineering workstation last month.

Ignoring the human layer. IEC 62443-2-1:2024 includes Security Program Elements for security awareness, training, and organizational roles. 800-82 Section 4 similarly covers security awareness. Your maintenance technicians plugging in unauthorized USB drives, your operators giving remote desktop access to vendors without logging it, your engineering team using the same password across all PLCs — these are not technology failures. They are program failures. Security awareness and procedure enforcement are controls, not nice-to-haves.

Treating legacy systems as compliance exceptions to be ignored. Legacy IACS are explicitly addressed in 62443-2-1:2024 — they require compensating controls, documented residual risk, and a roadmap. An undocumented legacy PLC running on an unsupported operating system with no compensating controls is an open finding. A legacy PLC with network isolation, protocol filtering at the conduit, 24/7 passive monitoring, and a planned replacement in the capital budget is a managed risk. The documentation is the difference.

A strategic case: Why dual-framework programs win

Regulated sectors such as energy (NERC CIP adjacency), defense industrial base (CMMC), chemical (CISA Chemical Facility requirements), water (America's Water Infrastructure Act) are increasingly referencing both NIST SP 800-82 and IEC 62443 in regulatory guidance and customer security requirements. Building your program on both frameworks simultaneously is not compliance overhead instead it is insurance against future regulatory shifts, a competitive differentiator in customer security assessments, and a more technically sound security architecture than either framework provides alone.

The practical formula is: use IEC 62443 for program structure and governance, use NIST 800-82 for control selection and overlay, and use NIST CSF 2.0's Govern function to create executive visibility and accountability across the entire program.

Organizations that have built on this integrated foundation consistently outperform peers on both audit outcomes and actual incident response metrics because their security program reflects how industrial systems actually work, not how IT systems work with OT terminology bolted on.

Get in touch with us to learn more on complying with IEC 62443 and NIST SP 800-82 through a unified approach.

Key resources

• NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security — September 2023

• ISA/IEC 62443 Quick Start Guide — ISA

• CISA Known Exploited Vulnerabilities Catalog — for prioritizing patching under NIST SP 800-40 Rev. 4 guidance

• Strategic Implementation of ISA/IEC 62443-3-2 

• NIST SP 800-82 Rev. 3: Strategic Implementation Checklist