How Industrial Automation Companies Are Managing IEC 62443 Cybersecurity Requirements

The Compliance Landscape Has Shifted

Three years ago, IEC 62443 appeared in procurement documents as a aspirational reference. Procurement teams asked vendors to describe their “approach to cybersecurity” and the standard was cited as guidance. That era is over.

Today, energy infrastructure procurement in the EU explicitly references IEC 62443-2-4 (service provider security requirements) and IEC 62443-3-3 (system security requirements) as minimum certification criteria for control system vendors. The US Department of Energy’s cybersecurity baseline for operational technology, updated guidance from CISA, and the EU Cyber Resilience Act have collectively made IEC 62443 compliance a hard gate — not a differentiator, but a prerequisite for contract award.

For automation OEMs and system integrators, this creates an engineering process problem that no amount of documentation retrofitting can solve. The standard doesn’t ask for security policy documents. It asks for demonstrable security requirement coverage, traceable from threat assessment through security level assignment, component selection, and verification. That is a systems engineering problem, and most automation companies are finding their existing tooling was never designed for it.

What IEC 62443 Actually Demands From an Engineering Team

The standard is a family, not a single document, and the distinction matters for understanding where the engineering burden lands. IEC 62443-2-4 governs what a service provider (integrator) must do operationally. IEC 62443-3-2 governs security risk assessment for systems. IEC 62443-3-3 defines system-level security requirements organized around foundational requirements (FRs) and security levels (SL-1 through SL-4). IEC 62443-4-2 defines component-level technical requirements.

The traceability chain that auditors and certification bodies now expect runs like this: hazard and threat identification → security level target assignment → system security requirements derived from FRs → component-level security requirements derived from system requirements → verification and test evidence.

This chain has two properties that break document-based requirements management:

First, it is bidirectional. A change to a threat model — say, adding a new attack vector because a component vendor has published a CVE — must propagate downstream to affected security requirements, and those changes must be traceable back to their source. In a document-based system, this propagation is manual, slow, and frequently incomplete.

Second, it crosses the safety/security boundary. IEC 62443-3-2 explicitly requires that security risk assessments consider safety implications. IEC 61511 (process safety) and IEC 62061 (machinery safety) increasingly reference security as a hazard source. In practice, this means a security countermeasure like disabling a diagnostic port can affect a safety function, and that dependency must be managed, not assumed.

Most automation engineering teams today manage these two domains in separate tool instances, separate document trees, and with separate engineering teams that communicate through formal review meetings. That structure cannot sustain the traceability chains the standard requires.

Where the Traceability Gaps Are in Practice

Across public certification audits, published non-conformance findings, and conversations with engineering managers at automation OEMs, three categories of traceability gap appear consistently.

Threat model disconnected from requirements. The TARA (threat analysis and risk assessment) is frequently conducted by a security specialist team using a dedicated tool — ThreatModeler, Microsoft Threat Modeling Tool, or custom Excel frameworks — and its outputs are summarized in a report. That report is then used as an input to requirements, but the connection is narrative, not structural. When the threat model is updated, requirements are not automatically flagged for review. Auditors who trace a requirement to its source and find only a document reference with no version control or impact analysis flag this as a gap.

Security level targets not derived from system context. IEC 62443-3-2 requires that SL targets be derived from a site-specific risk assessment, not assigned generically. Many integrators assign SL-2 across a zone because it matches their product capability, not because the risk assessment justified that target. When asked to show the derivation chain from risk assessment to SL assignment to requirements, they cannot produce it. This is increasingly a non-conformance finding in third-party audits.

Component-level requirements not traced to system-level requirements. IEC 62443-4-2 compliance for individual components is easier to obtain because component vendors can pursue independent certification. But integrators assembling certified components into a system must show that the system security requirements are satisfied by the combination of component behaviors. This system integration traceability — showing that FR7 (resource availability) at SL-2 is satisfied by these specific component configurations — is typically missing or asserted without evidence.

What Mature Teams Are Actually Doing

The automation companies that are ahead of this problem share two practices that less mature teams have not yet adopted.

They model security requirements as first-class system requirements, not a parallel documentation track. This means security requirements live in the same requirement management system as functional and safety requirements, with the same discipline around parent-child relationships, change history, and verification linkage. A security requirement like “the control network shall reject unauthenticated configuration commands” is parented to a system security requirement derived from FR2 (use control), which is parented to an SL target derived from the TARA, which is parented to the threat scenario that justified it. Every link in that chain is explicit, not implied.

They have invested in connecting the TARA to the requirements base. The best implementations treat threat scenarios as a requirement source — a specific class of parent object that generates derived security requirements. When a threat scenario is added, modified, or retired, the requirements it parents are flagged for review. This is graph-based dependency management applied to a security engineering workflow.

Neither practice requires exotic technology. Both require deliberate modeling discipline and tooling that supports structured parent-child relationships and impact analysis across heterogeneous requirement types.

The Safety-Security Convergence Is No Longer Theoretical

For the past decade, the academic and standards community has discussed “safety and security co-engineering” as an emerging area. It is now emerging in procurement contracts.

Several energy sector OT procurement packages in Europe now explicitly require that vendors demonstrate a unified safety and security requirement management process — not just that they have safety certification and security certification separately, but that the interactions between safety functions and security countermeasures have been analyzed and managed in a single traceable framework.

This is a significant engineering process requirement. Safety analysis under IEC 61508 or IEC 62061 identifies safety instrumented functions (SIFs) with integrity targets expressed as SIL (Safety Integrity Level). Security analysis under IEC 62443 identifies security countermeasures with integrity targets expressed as SL. The interaction zone — where a security countermeasure affects a safety function’s availability, reliability, or response time — must be explicitly managed.

Today’s dominant approach is to conduct a “security impact on safety” analysis as a separate study, document it in a report, and include the report in the safety case. This works at low system complexity. It does not work for complex distributed control systems with hundreds of safety functions and a large attack surface. At that scale, you need the safety functions and security countermeasures modeled as connected objects so that impacts can be computed rather than manually enumerated.

How Modern Tooling Is Addressing This

The incumbent requirements management tools in automation — IBM DOORS/DOORS Next, Jama Connect, Polarion, Codebeamer — were designed around document structure and hierarchical requirement sets. They can be configured to manage security requirements, and teams that have invested in custom module structures and attribute schemas have achieved functional implementations. The limitation is not capability but architecture: document-based tools require users to manually maintain the cross-domain connections that safety-security convergence demands.

Flow Engineering, built natively on a graph data model, represents requirements, threat scenarios, safety functions, components, and verification evidence as nodes with explicit typed relationships. This means the TARA-to-requirement linkage that is a manual discipline in document-based tools becomes a structural property of the model. An impact analysis query — “show me all security requirements that depend on threat scenario X, and all safety functions that share components with those security countermeasures” — is a graph traversal, not a manual cross-reference exercise.

For IEC 62443 specifically, Flow Engineering’s model supports the SL derivation chain as a formal parent hierarchy, which means auditors can trace any security requirement backward to its risk assessment justification without leaving the tool. The AI-assisted gap analysis — which compares the requirement set against the foundational requirement coverage matrix from IEC 62443-3-3 — surfaces coverage gaps before the certification audit finds them.

The trade-off is scope. Flow Engineering is focused on requirements engineering and traceability. Teams that need integrated FMEA tooling, hardware bill-of-materials management, or full PLM workflows will need to connect it to complementary tools. That is an intentional specialization, not an omission — and for teams whose primary pain is traceability rather than data management breadth, it is the right trade-off.

The Competitive Reality

The automation OEMs that will sustain competitive position in IEC 62443-required markets are those that can demonstrate traceability efficiently, not just produce compliance artifacts. The certification audit is not the hard part. The hard part is maintaining compliance across product revisions, responding to new CVEs with documented impact analysis, and showing customers a living security case rather than a point-in-time certification document.

Document-based processes can produce the artifact set for an initial certification. They cannot sustain a living security case across a product’s operational lifecycle without engineering overhead that most OEMs cannot staff at scale.

The integrators winning in this environment are building three capabilities: structured requirements models that connect TARA outputs to system and component requirements; formal safety-security interaction analysis embedded in the requirements model rather than conducted as a separate study; and tooling that supports iterative update and impact analysis rather than periodic document refresh.

Honest Assessment

IEC 62443 compliance is solvable with current tooling if teams are willing to invest in process discipline. The standard’s requirements are specific but not unreasonable. The traceability chain from threat to countermeasure to verification is well-defined. The challenge is not understanding what is required — it is building and maintaining that chain at the scale and velocity that modern automation product development demands.

The companies that treat this as a documentation problem will continue to produce certification artifacts through intensive pre-audit effort. The companies that treat it as a systems engineering problem — modeling security requirements with the same structural discipline applied to functional requirements — will find that compliance is a byproduct of good engineering practice rather than a separate program of work.

That distinction is becoming visible to procurement teams. Energy and process automation customers are starting to ask for living security cases, post-certification vulnerability response evidence, and safety-security interaction analyses as contract deliverables. The automation companies that have built the process infrastructure to produce those deliverables efficiently are accumulating a structural advantage that will compound as regulatory pressure increases.

The tooling landscape is catching up to the requirement. The engineering teams that recognize this as a systems architecture problem — not a compliance documentation problem — are the ones positioned to lead.