Industrial operators face a dual mandate: keep production running without interruption while closing the cybersecurity gaps that regulators and attackers alike are scrutinizing. Many organizations already have IEC 62443 on their radar but struggle with fragmented policies, unclear IT/OT ownership, and a legitimate fear that any OT cybersecurity assessment could knock a line offline. This post explains how to treat IEC 62443 as a living operating model and how to scope assessments so they deliver real visibility without threatening production.
Why IEC 62443 Must Be an Operating Model
ISA/IEC 62443 is most useful when treated as a cybersecurity management system (CSMS) that connects business rationale, risk management, policy, access control, training, incident response, and continuous improvement—not a checklist you complete once and file away. Treating it as an operating program means policies are actively enforced, access-control governance is reviewed on a schedule, and incident response plans are exercised against realistic scenarios rather than approved on paper and forgotten.
Consider a plant manager at a facility running Rockwell’s PlantPAx platform who discovers that existing documentation fails to map roles to IEC 62443 access-control requirements. By framing the standard as an operating model, that team can audit current role assignments, identify where engineers and maintenance staff hold broader access than their jobs require, and close those gaps without a production freeze. The standard itself—maintained by ISA and published through ISA’s 62443 series—provides the structural scaffolding; the operating model supplies the discipline to keep it current.
Scoping an OT Cybersecurity Assessment Safely
The fear that a cybersecurity assessment will disrupt live production is well-founded, especially on legacy systems running DNP3 or Modbus that were never designed to tolerate unexpected traffic. That fear, however, is not a reason to skip testing—it is a reason to demand that any provider explain exactly how they will protect operations before a single packet is sent. If a vendor cannot answer that question clearly, they should not be on your network.
A practical scoping process starts with a complete asset inventory, including third-party devices and remote-access pathways that are easy to overlook. From there, testing is staged: passive network observation and architecture review first, active scanning only on isolated or non-critical segments, and any intrusive techniques reserved for maintenance windows. For a Siemens SIMATIC environment, that might mean evaluating historian and engineering workstation interfaces before touching anything in the control layer. For a Honeywell Experion deployment, it means coordinating with the vendor on system tolerances before scheduling a penetration test.
Scoping Checklist Before Any Assessment
- Asset inventory: Confirm a current list of OT assets, legacy systems, and all remote-access entry points.
- Network segmentation: Restrict active testing to non-critical segments; document blast-radius boundaries in advance.
- Vendor coordination: Engage OT vendors to confirm testing tolerances for specific hardware and firmware versions.
- Maintenance-window scheduling: Align any intrusive techniques with planned downtime to eliminate production risk.
- Documentation baseline: Gather existing network diagrams and policies before the assessment starts—gaps in documentation are findings too.
Four Steps to Implement IEC 62443 as an Operating Program
Turning the standard into day-to-day practice requires structure. Four steps consistently separate organizations that sustain a CSMS from those that produce a binder of policies no one reads.
Step 1: Define system and organizational scope. Before evaluating any control, map the systems, processes, and personnel in scope. Identify which protocols—OPC UA, DNP3, Modbus—run in critical systems and which roles hold access to them. A facility using Schneider Electric’s EcoStruxure platform may need to scope energy management separately from production lines because the risk profiles differ substantially.
Step 2: Separate documentation gaps from performance gaps. Missing records and actual vulnerabilities are not the same problem. An outdated network diagram is a documentation gap. Unpatched firmware in a Rockwell controller with a known exploit is a performance gap. Conflating the two produces a priority list that wastes remediation budget on paperwork while leaving real exposure unaddressed.
Step 3: Prioritize findings by risk, feasibility, and operational impact. A vulnerability in a DNP3 communication path that could enable a denial-of-service condition outranks a missing policy header in a non-critical system. Risk scoring should account for the operational consequence of exploitation, not just the technical severity. NIST SP 800-82 provides a complementary framework for evaluating ICS risk that pairs well with IEC 62443’s zone-and-conduit model.
Step 4: Treat audits as continuous improvement tools. A gap assessment or audit should feed directly back into the CSMS—policy updates, training adjustments, access-control reviews—not sit in a report that gets reviewed once. Organizations that build audit cycles into their operating calendar close gaps faster and demonstrate measurable maturity over time.
Aligning IEC 62443 with NIST and NERC CIP
IEC 62443 does not exist in isolation. Facilities on the North American electric grid must satisfy NERC CIP requirements; most industrial operators will also find NIST SP 800-82 guidance relevant to their ICS architecture. The overlap is significant, and a well-constructed CSMS can serve as the backbone for demonstrating compliance across all three frameworks simultaneously.
A facility running ABB’s Ability platform that must satisfy both IEC 62443 and NERC CIP, for example, can map NERC CIP’s access management and incident-response requirements directly into the CSMS structure rather than maintaining separate compliance programs. CISOs and compliance leads benefit from this consolidated approach when responding to auditors: one coherent program is easier to evidence than three parallel efforts with overlapping but inconsistent documentation.
Building a Cybersecurity Program That Lasts
OT cybersecurity maturity is not a destination—it is a sustained operating discipline. Treating IEC 62443 as a living program rather than a compliance milestone, and conducting OT cybersecurity assessments with a clear commitment to production safety, are the two practices that separate organizations with real resilience from those with a policy binder and hope. The technical environment will keep changing; the program needs the structure to change with it.
Before approving any OT assessment, ask whether the provider can explain how they will protect operations during testing. That single question will tell you most of what you need to know about whether they have actually done this work in industrial environments.
Ready to Strengthen Your OT Security Posture?
Red Trident offers a free OT security assessment consultation to help you identify gaps, align with IEC 62443, and protect production. Contact us today to schedule your consultation and take the first concrete step toward a resilient OT environment.
