Today we share a practitioner's guide to combining the world's two most authoritative OT security frameworks into a program that actually holds up in the field.  

Before we move forward, don't forget to check out our previous blog post on the new EU ICT Supply Chain Security Toolbox, here. 

Why have two frameworks and why use them together?

A common and understandable mistake is to pick one framework and build a program around it exclusively. Program managers often ask: Is IEC 62443 sufficient on its own? Is NIST SP 800-82 enough? The answer to both questions is: not quite, and here is why.

IEC 62443 is an engineering standard developed by ISA and adopted by IEC with deep involvement from control system engineers, process safety professionals, and OT vendors. Its core DNA is in the plant floor across zones and conduits, security levels, component requirements, and the Service Provider supply chain. It tells you what security properties your systems should have and more importantly to what degree.

NIST SP 800-82 with its latest Revision 3 (published September 2023), is essentially a guidance document. It is descriptive rather than prescriptive and it tells you what you should consider and how to think about ICS/OT security. It maps to the NIST Cybersecurity Framework (CSF 2.0), providing implementation tiers, profiles, and a comprehensive taxonomy of OT threats, vulnerabilities, and architectures.

02  Understanding Each Framework in Depth

IEC 62443: The Standard Series You Need to Know Cold

IEC 62443 is not a single standard — it is a family of standards organized into four series. Practitioners who treat it as a single document make critical implementation errors. Here is what each series covers and why it matters operationally:

The Security Level (SL) model is IEC 62443's defining contribution. SL1 through SL4 are not just severity ratings — they define the threat actor capability your controls must withstand:

NIST SP 800-82 Rev.3: What Changed and Why It Matters

Revision 3, published in September 2023, is a substantial update from Rev.2 (2015). The most important changes for practitioners:

•  Full alignment to NIST CSF 2.0, including the new Govern function. This formally elevates OT cybersecurity governance to the organizational level, not just the technical level.

•  Expanded coverage of cloud-connected OT, IIoT, and edge computing architectures not addressed in Rev.2 — critical for modern O&G and advanced manufacturing environments.

•  Updated threat landscape incorporating post-2015 ICS-specific malware: TRITON/TRISIS (SIS attack), INDUSTROYER2 (power grid), PIPEDREAM/INCONTROLLER (multi-platform ICS attack framework).

• Reference architectures updated with modern DMZ designs, defense-in-depth for OT networks, and guidance on OT SOC integration.

•  Explicit cross-reference mappings between SP 800-82 controls and IEC 62443, NERC CIP, and other OT frameworks — enabling multi-framework compliance alignment.

 03  The integration architecture: Making both frameworks work together

The key insight for successful integration is this: use NIST SP 800-82 / CSF as your program management skeleton, and IEC 62443 as your technical implementation specification. The CSF's six functions (Govern, Identify, Protect, Detect, Respond, Recover) provide the lifecycle structure. IEC 62443 fills each function with OT-specific engineering content.

 04  Asset Inventory & Risk Assessment: The Non-Negotiable Foundation

Every OT security program that has failed (and many have) failed at the foundation step itself. You cannot protect what you do not know exists. And in OT environments, the gap between the documented asset register and what is actually connected to the network is almost always larger than anyone in management believes.

Step 1: OT Asset Discovery — Do It Right

Never run active scanning tools on live OT networks. This is not a preference. Instead it is a safety and operational requirement. Active scanners send probes that can overwhelm the limited processing capability of older PLCs, corrupt memory on some legacy RTUs, and trigger unexpected behavior on safety-critical systems. This has happened in real environments. NIST SP 800-82 Rev.3 §6.2.1 explicitly cautions against active scanning in live ICS environments without vendor validation.

The correct approach is passive asset discovery: deploy a passive network tap or SPAN port on OT network switches and use a protocol-aware OT visibility tool to fingerprint devices from observed traffic. This approach, as defined in IEC 62443-3-2 §4.2, allows you to build an asset inventory that captures device type, vendor, model, firmware version, protocols in use, and communication patterns — without injecting a single packet into the OT network.

Step 2: Zone and Conduit Definition (IEC 62443-3-2 §4.3)

Once you have a complete asset picture, group assets into security zones based on: common security requirements, consequence of compromise, and operational function. A zone is a logical grouping of assets that share the same security level. A conduit is any communication path between zones — and every conduit must be documented, controlled, and protected.

In an oil and gas context, a typical zone structure looks like this: the Safety layer (SIS/ESD systems, minimum SL3) is fully isolated and communicates with the Basic Process Control layer (DCS, typically SL2) only via hardware data diode in the outbound direction. The Basic Process Control layer communicates with the Supervisory layer (SCADA/Historian, SL2) through a firewall conduit. The Supervisory layer communicates with the Enterprise/IT layer through a fully isolated DMZ with application-layer inspection. No zone has a direct connection that skips a layer. This is not architectural elegance — it is how you prevent a ransomware infection on a Windows corporate laptop from reaching a Rockwell ControlLogix.

Step 3: Risk Assessment — Consequence-First for OT

IEC 62443-3-2 defines a risk assessment methodology specific to IACS. The critical difference from IT risk assessment is that consequence must be evaluated in operational and safety terms, not just financial terms. A breach that costs $50,000 to remediate in an IT context might represent a catastrophic risk in an OT context if it involves loss of containment, environmental release, or defeat of a safety function.

NIST SP 800-82 Rev.3 aligns with this by defining consequence categories for ICS: safety (personnel injury/death), environmental release, production impact, and equipment damage. Use both frameworks' consequence definitions to build a consequence matrix that your process safety team can validate — because they are the subject matter experts on what a DCS setpoint manipulation actually means for process integrity.

05  Protection Controls: Where IEC 62443-3-3 FR1–FR7 Does the Heavy Lifting

IEC 62443-3-3 defines seven Foundational Requirements (FRs) and 51 system requirements (SRs) that describe the specific security capabilities a system must demonstrate at each Security Level. NIST SP 800-82 Rev.3 maps its control categories to these same FRs. Here is how to implement them operationally:

FR1: Identification and Authentication Control

Every user and device accessing OT systems must be identified and authenticated. In practice this means: eliminate shared accounts on HMI and EWS systems; enforce unique credentials per engineer, operator, and vendor; deploy multi-factor authentication on all remote access paths. For device authentication at SL2+, use certificate-based authentication where the OT component supports it — OPC-UA supports certificate-based mutual authentication and should be used in preference to legacy OPC-DA with DCOM authentication. At SL3 (SIS systems), require hardware tokens or equivalent strong authentication for any access to engineering workstations that can modify SIS logic.

FR2: Use Control

Authentication is not sufficient — authorization must be enforced. Separate roles into: Read-Only (operators monitoring process), Control (operators executing commands), Engineering (logic modification), Administration (system configuration), and Vendor (time-limited, session-controlled access). The most common FR2 failure in OT environments is that everyone uses the administrator account because no one took the time to build a proper role matrix. This means a contractor who needs to check a diagnostic reading has full write access to the DCS configuration — an unnecessary and dangerous privilege.

For remote access, enforce session-based authorization: each vendor or remote engineer access session requires explicit approval through a defined workflow, has a maximum session duration, is conducted through a jump server with session recording, and is terminated and logged. No always-on VPN tunnels into OT networks. No exceptions.

FR3 and FR4: Data Integrity and Confidentiality

Legacy OT protocols — Modbus TCP, DNP3 (without Secure Authentication), classic OPC-DA — were designed for reliability, not security. They have no built-in integrity or confidentiality mechanisms. This means an attacker with network access can read all process data, inject false commands, and replay captured legitimate commands. NIST SP 800-82 Rev.3 §6.2.4 and IEC 62443-3-3 FR3/FR4 both address this reality with the same pragmatic guidance: where you cannot replace the protocol, compensate with network controls (strict zone isolation, application-aware firewalls, anomaly detection); and where you can replace or supplement the protocol (OPC-UA, DNP3-SA, IPsec tunnels), do so.

FR5: Restricted Data Flow

This is the zone and conduit model in practice. Every communication path between zones must be explicitly permitted — not the other way around. The default posture is deny. Firewall rules between OT zones should be as specific as possible: source IP, destination IP, port, and protocol. Any "any-to-any" rule in an OT firewall is a critical finding. For the highest-consequence paths (SIS to DCS, for example), implement unidirectional security gateways (hardware data diodes) that physically prevent any traffic from flowing in the high-security direction. Software-only firewalls, regardless of how well configured, can be misconfigured or exploited — hardware data diodes cannot pass traffic in the wrong direction by physics.

FR6: Timely Response to Events

You cannot respond to events you cannot see. This requires OT-specific security monitoring. IT SIEM tools without OT protocol awareness will generate enormous noise on OT networks and miss the actual meaningful indicators of compromise. The ideal architecture is an OT visibility platform deployed in passive mode that understands ICS protocols, feeds normalized alerts to a centralized monitoring function (OT SOC), and correlates events across zones. NIST SP 800-82 Rev.3 §6.2.8 provides architecture guidance for OT monitoring that aligns with IEC 62443's FR6 requirements.

FR7: Resource Availability

OT systems must remain available — often more critically than they must remain confidential. This means resilience and redundancy are security controls, not just engineering design choices. For critical OT systems, verify: controller redundancy (hot standby), network path redundancy (HSR, PRP, or RSTP with fast failover), power redundancy (UPS with generator backup), and configuration backup integrity. Critically, test restoration — a backup that has never been restored is an assumption, not a capability. NIST SP 800-82 Rev.3 §6.2.7 and IEC 62443-3-3 FR7 both require tested recovery capability, not just documented procedures.

6  Detection, Response, and Recovery: Closing the Loop

Building an OT Detection Capability

The OT threat landscape has changed fundamentally since 2017. The TRITON/TRISIS attack demonstrated that sophisticated adversaries specifically target Safety Instrumented Systems — the last line of defense before a physical process becomes dangerous. PIPEDREAM/INCONTROLLER, disclosed in 2022, demonstrated a modular attack framework capable of targeting Schneider Electric, OMRON, and other major OT platforms using native ICS protocols. These are not theoretical threats — they are documented, real-world capabilities deployed against critical infrastructure.

Detection in this environment requires OT-specific capabilities that IT security tools lack. A network intrusion detection system that does not understand Modbus function codes, DNP3 application layer content, or OPC-UA service operations cannot detect malicious OT protocol manipulation — because to it, all OT traffic looks like noise. Protocol-aware deep packet inspection, tuned specifically for OT environments, is not optional for SL2+ environments.

OT Incident Response: The Process-Safety Interface

The most underestimated aspect of OT incident response is the interface between a cyber event and a process safety event. A cyber attack on a DCS does not present like an IT security incident — it may initially manifest as unexplained process deviations, valve position discrepancies, or instrument readings that seem anomalous. The TRITON attack was first noticed by a process control engineer who saw unusual SIS behavior, not by a security analyst.

Your OT Incident Response Plan must therefore include: explicit triggers for escalation to the process safety emergency response team; defined roles for the PSSR (Pre-Startup Safety Review) team if the OT system must be returned to service after a cyber incident; and authority for Operations to isolate a compromised system from the process control network without waiting for IT/cybersecurity approval if safety is at immediate risk. NIST SP 800-82 Rev.3 §6.2.9 and IEC 62443-2-1 §4.3.6 both address incident response, but neither adequately addresses the safety-cyber interface in detail — your program must fill this gap using site-specific HAZOP and risk assessment inputs.

Recovery: The Forgotten Function

IEC 62443-3-3 FR7 and NIST CSF Recover function both require tested, documented recovery capability. In OT contexts, recovery is significantly more complex than IT recovery because: OT systems may require vendor-specific restoration procedures; logic downloads to PLCs and DCS controllers must follow defined sequences; process restart after an extended outage involves process safety considerations (purging, pressure checks, instrument verification) that may take days or weeks; and regulatory reporting requirements may apply to cyber incidents affecting process safety systems.

Define Recovery Time Objectives (RTOs) for each OT zone based on operational tolerance — not based on IT standards. An IT RTO of 24 hours for a non-critical system may be fine; an OT RTO of 24 hours for a pipeline SCADA system means a day of blind operation of a pressurized transmission system, which is not acceptable. These RTOs must be validated by operations and process engineering, not determined by IT.

07  Implementation Roadmap: A Realistic 24-Month Program Build

Building an OT cybersecurity program is a multi-year effort. The following roadmap is based on the dual-framework approach and is structured around the reality of OT operational constraints: you cannot disrupt operations, you cannot outpace your organization's change absorption capability, and you cannot ignore the maintenance window cycle.

MONTHS 1–3 · PHASE 1: FOUNDATION

Establish Governance and Baseline Visibility

Before any technical controls, you need organizational buy-in, defined roles, and a real asset picture. Without these, every subsequent activity is built on sand.

•  Draft and ratify OT Cybersecurity Policy aligned to IEC 62443-2-1 CSMS requirements

•  Define OT security roles (OT Security Lead, Site OT Security Representatives, vendor oversight function) and formalize in job descriptions or RACI

• Deploy passive OT asset discovery across all sites — build the definitive asset register

• Conduct initial Zone and Conduit mapping per IEC 62443-3-2 §4.3

• Establish OT-specific risk register template aligned to both IEC 62443-3-2 and NIST SP 800-82 consequence categories

• Baseline current Achieved Security Level (SL-A) against IEC 62443-3-3 FR1–FR7

MONTHS 3–6 · PHASE 2: RISK ASSESSMENT

Complete Risk Assessment and Define Target State

With visibility established, complete the formal risk assessment. This is the most important deliverable in the entire program — everything else flows from it.

•       Complete IEC 62443-3-2 risk assessment for all zones; establish SL-T for each zone

•       Identify and prioritize all SL gaps (SL-T minus SL-A) — these become your remediation backlog

•       Conduct NIST SP 800-82 Rev.3 aligned threat modeling including ICS-specific threat actors and TTPs

•       Identify all immediate/critical findings requiring treatment independent of planned program phases

•       Integrate risk register into enterprise risk management framework; present to senior management

•       Update or draft vendor security requirements aligned to IEC 62443-2-4

MONTHS 6–12 · PHASE 3: CORE CONTROLS

Implement Priority Protection Controls

Address critical and high-priority gaps. Focus first on network architecture (the biggest bang for the buck in OT security) and access control.

• Implement or remediate network segmentation: DMZ architecture between OT and IT; enforce zone boundaries with OT-appropriate firewalls

• Deploy data diodes on SIS-to-DCS data paths where SL3 is targeted

• Eliminate default credentials on all OT devices; implement role-based access control aligned to FR1–FR2

• Deploy jump server with session recording for all remote access to OT zones; enforce MFA on remote access

• Implement media scanning (Shieldworkz Media Scanning Solution or equivalent) for all removable media entering OT environments

• Deploy OT visibility platform in passive monitoring mode; establish alert triage procedures

• Develop and exercise first OT Incident Response tabletop including cyber-to-process-safety escalation

MONTHS 12–18 · PHASE 4: DETECTION & RESPONSE MATURITY

Build Sustained Detection and Response Capability

Move from reactive to proactive: continuous monitoring, threat hunting capability, and tested response procedures.

• Establish OT SOC function (internal or managed) with OT-specific detection use cases and playbooks

• Integrate OT visibility platform alerts into enterprise SIEM with OT-appropriate correlation rules

• Implement OT patch management process aligned to IEC 62443-2-3: vendor coordination, staging environment testing, maintenance window scheduling

• Conduct OT vulnerability assessment across all critical systems using passive/low-impact methods

• Complete OT Business Continuity and Disaster Recovery planning; test configuration backup restoration

•  Launch OT security awareness training program for operators, engineers, and contractors

MONTHS 18–24 · PHASE 5: CONTINUOUS IMPROVEMENT

Institutionalize, measure, and improve

A cybersecurity program that does not continuously improve will decay. Threats evolve, systems change, people turn over. Build the mechanisms that sustain the program beyond the initial build.

•       Establish quarterly OT security performance reporting to senior management: KPIs including patch compliance percentage, open risk items, incident metrics, training completion

•       Integrate OT cybersecurity review into all OT change management (MOC) processes

•       Annual IEC 62443-3-2 risk assessment refresh; update SL-T and risk register

•       Annual OT incident response exercise (escalate from tabletop to live drill where safe)

•       Procurement standard update: all new OT procurements require IEC 62443-4-2 component SL certification or equivalent vendor SDL evidence

•       Supply chain security assessment: evaluate key OT vendors against IEC 62443-2-4 requirements

08  Governance: The difference between a program and a project

Technical controls without governance decay. The OT cybersecurity program must be sustained by organizational mechanisms that outlast individual staff, budget cycles, and management attention spans. IEC 62443-2-1 defines the Cyber Security Management System (CSMS) — the organizational system that ensures cybersecurity is a continuous management function, not a one-time project.

The CSMS should be OT-Specific

One of the most common governance failures is applying the organization's IT security policy — or even the IT ISMS (ISO 27001) — directly to OT without modification. IT and OT have fundamentally different priorities, risk tolerances, and operational constraints. An IT policy that requires MFA on all system access is correct and appropriate for IT. Applied naively to OT, it would mandate MFA for an operator who needs to acknowledge a high-priority alarm in two seconds or risk a process upset — which is why the OT CSMS must define OT-specific controls with operational context.

Change management is a securitycontrol

Every change to OT hardware, software, network configuration, or process is a potential security event. The Management of Change (MOC) process must include a mandatory OT cybersecurity review step. This means: before any change is executed in the OT environment, the OT security function reviews it for cybersecurity impact. New vendor connections, firmware updates, network reconfigurations, new devices added to the OT network — all must pass through this gate. NIST SP 800-82 Rev.3 §6.2.3 and IEC 62443-2-1 §4.2.3 both define change management as a core security management requirement.

Vendor and supply chain risk

In OT environments, the supply chain is the attack surface. OT vendors, system integrators, and service providers routinely have remote access to customer OT systems for remote diagnostics, emergency support, and planned maintenance. The SolarWinds attack demonstrated at scale what OT security practitioners have understood for years: trusted vendor connections are trusted attack vectors if the vendor's security posture is inadequate.

IEC 62443-2-4 defines security requirements that you can place on OT service providers contractually. The minimum requirements for any vendor with OT network access: documented security practices; use of dedicated, malware-scanned equipment for OT work; session-based access only (no always-on connections); session recording acceptance; and incident notification obligations. Audit these requirements — do not just collect signed attestations.

Metrics that add up to something

Most OT security metrics reported to management are activity metrics: number of policies written, number of training sessions completed, number of assets scanned. These measure effort, not security. The metrics that matter are outcome metrics aligned to your risk register:

This article reflects the technical positions and operational experience of the authors. It is intended for cybersecurity and operations professionals in industrial environments. Nothing in this document constitutes legal, regulatory, or safety engineering advice. All framework references are to publicly available standards; readers should consult current published versions for authoritative requirements. IEC 62443 is an active standards series and individual parts are subject to revision.

Connect with us to learn more on how you can leverage IEC 62443 and NIST SP 100-82 to build a cybersecurity program.

Download our checklist on IEC 62443 and NIST SP 100-82 integration, here