Threat Modeling for IEC 62443-4-1: OT and Product Security

IEC 62443-4-1:2018 Security for industrial automation and control systems – Part 4-1: Secure product development lifecycle requirements, published by the IEC in January 2018 (ISBN 978-2-8322-5239-0) is the standard product suppliers use to demonstrate a secure development lifecycle for components going into industrial automation and control systems (IACS): PLCs, RTUs, HMIs, industrial gateways, and similar OT products. Unlike PCI DSS or FDA’s guidance, where the threat-modeling connection has to be built from adjacent language, IEC 62443-4-1 states it directly. Practice 2 of the standard, Specification of Security Requirements, contains requirement SR-2, titled verbatim “Threat model.”

SR-2 requires that a process be employed to ensure every product has a threat model specific to its current deployment scope, used for identifying, communicating, and understanding threats and their mitigations. The requirement sits immediately after SR-1 (product security context) and directly informs SR-3, which requires that security requirements be reviewed and validated against the threat model set in SR-2 meaning the standard treats the threat model as a dependency other requirements are checked against, not a standalone deliverable.

This is a materially different posture than PCI DSS or FDA guidance, where threat modeling supports a broader requirement. Under IEC 62443-4-1, the threat model is the requirement, and a supplier without one has an open gap in a named control, not an interpretive one.

SR-2’s language — a threat model “specific to the current deployment scope of the product” — is a pointed requirement for OT and product security specifically, because IACS components rarely operate in a single, predictable environment. The same PLC or industrial gateway might be deployed in a water treatment facility, a manufacturing line, or a substation, each with different network exposure, different adjacent systems, and different consequence profiles if compromised. A threat model built for one deployment context doesn’t automatically hold for another.

PASTA’s decomposition and attack-modeling stages are built around exactly that kind of context sensitivity — the methodology treats the deployment environment and business impact as inputs to the model, not an afterthought layered on top of a generic architecture review. For a product supplier working through SR-2, that means the threat model documents which deployment scope it covers, what assumptions it makes about that environment, and what changes if the product is deployed elsewhere — the same kind of environment-of-use reasoning FDA’s guidance asks for in medical devices, applied here to industrial control components instead of connected devices

SR-2 doesn’t stand alone in the standard’s Practice 2:

• SR-1 (product security context) requires documenting the minimum environment requirements and assumptions the product is designed against — the baseline SR-2’s threat model builds on.
• SR-3 requires that security requirements be reviewed and revised for validity against the threat model set in SR-2, meaning changes to the threat model should trigger a review of downstream requirements, not sit isolated in a design document.

An amendment currently in process for the standard (EN IEC 62443-4-1:2018/prAA:2026) proposes changes to related management-practice language (SM-3) around identifying which products require these processes, but does not alter SR-2 itself. As of this writing, IEC 62443-4-1:2018 remains the current, normatively referenced edition for the threat model requirement.

EC 62443-4-1 is built around a maturity model — Practice 13 (Continuous Improvement) expects that SDL processes, including threat modeling, are not a one-time exercise but improve and stay current as products evolve. A threat model produced once at initial certification and never revisited doesn’t reflect that maturity expectation, particularly for long-lived OT products that stay in field deployment for years after initial development.

TMaaS is structured for that continuity: threat models maintained as living artifacts as the product’s architecture, firmware, and deployment guidance evolve, rather than a single document filed away after certification. For a supplier maintaining SR-2 compliance across a product’s lifecycle — including legacy products retrofitted with a threat model created after the fact, which the standard’s own guidance acknowledges is a valid approach for existing products — that continuity is the difference between a threat model that satisfies an auditor once and one that holds up across recertification cycles.

IEC 62443-4-1 certification is issued by accredited certification bodies evaluating a supplier’s full SDL against the standard’s practices — Security Management, Specification of Security Requirements, Secure Design, Secure Implementation, Verification and Validation Testing, Defect Management, Patch Management, and Security Guidelines. A threat model satisfies SR-2 specifically; it does not by itself satisfy the standard’s other twelve practices, and no vendor can represent that a threat model alone results in certification.