IEC 62443-4-1 Secure Product Development Lifecycle | Automation Engineering Body of Knowledge

ISA/IEC 62443-4-1:2018 defines process requirements for a secure product development lifecycle used by Product Suppliers of IACS control systems and components. It answers how products should be designed, built, maintained and retired securely. Technical capabilities those products must offer are specified separately in Part 3-3 (systems) and Part 4-2 (components).

Product suppliers are the main audience. The primary goal is a framework for secure by design with a defence-in-depth approach across designing, building, maintaining and retiring products — so a claimed Security Capability Level (SL-C) is backed by implemented capabilities and known vulnerabilities that have been eliminated or mitigated.

Learning objectives

Explain the purpose of Part 4-1 and how it differs from Part 4-2.
Describe the eight security practices and what each contributes to defence-in-depth.
Relate SL-C, threat modelling and maturity levels (ML1–ML4) to supplier programmes.
Recognise how ISASecure SDLA / CSA / SSA certification paths use Part 4-1.

Primary and secondary goals

Primary goal — provide a product-development framework that addresses:

Secure by design
Defence-in-depth when designing, building, maintaining and retiring products
Support for meeting an overall product Capability Security Level (SL-C)

In teaching terms, SL-C work asks:

What SL-C is the product intended to support?
Are the security capabilities implemented correctly?
Have known security vulnerabilities been eliminated or mitigated?

Secondary goal — align the development process with industrial-user needs:

Security configurations and patch management policies/procedures that sites can use
Clear communication when product security vulnerabilities are discovered

Key concepts: threat modelling (impact analysis and resolution) and a defence-in-depth strategy as the philosophy of the secure product lifecycle.

Eight security practices

Part 4-1 groups supplier work into eight practices. Security management surrounds the other practices; defence-in-depth layers through requirements, design, implementation, V&V testing and guidelines.

Practice	Code	Clause	Focus	Page
1 – Security management	SM	5	Plan, staff, scope and govern the SDL (13 requirements)	Clause 5
2 – Specification of security requirements	SR	6	Security context, threat model, testable requirements (5)	Clause 6
3 – Secure by design	SD	7	Secure design principles and defence-in-depth (4)	Clause 7
4 – Secure implementation	SI	8	Implementation review and secure coding (2)	Clause 8
5 – Security verification and validation testing	SVV	9	Requirements, threat, vulnerability and penetration testing (5)	Clause 9
6 – Management of security-related issues	DM	10	Receive, assess, fix and disclose issues (6)	Clause 10
7 – Security update management	SUM	11	Qualify, document and deliver security patches (5)	Clause 11
8 – Security guidelines	SG	12	User docs for harden, operate, accounts and disposal (7)	Clause 12

Security management also covers ongoing handling of security defects and documentation updates as products evolve. Detailed requirement summaries sit on each practice page (SPE-style).

Maturity levels (Table 1)

How do we know a supplier is actually meeting practice requirements? Part 4-1 uses a maturity model based on CMMI-DEV, adapted into four ISA/IEC 62443-4-1 levels. An organisation may sit at different maturity for different requirements.

ML	ISA/IEC 62443-4-1 name	Meaning (teaching summary)
1	Initial	Ad hoc / incompletely documented development — repeatability across projects is unreliable.
2	Managed	Written policies and procedures exist; people are trained — but not every process has yet been practised on real products.
3	Defined (Practiced)	Processes have been practised with evidence; performance is repeatable across the organisation.
4	Improving	Combines CMMI-DEV Levels 4 and 5 ideas: metrics drive effectiveness and continuous improvement.

Annex B of Part 4-1 tabulates the requirements; Clause 5 onward defines each practice in detail. Applicable requirements still apply to a given product (see SM-5 scoping) even while maturity is rising over time.

Related: IEC 62443-2-1 Maturity Levels (related ML idea for asset-owner programmes — use each part’s own tables when scoring)

Product lifecycle vs Automation Solution lifecycle

Part 4-1 is independent of any one plant. Suppliers create and support products; integrators and asset owners later fold those products into an Automation Solution at a site. Secure products plus security guidelines feed design, implementation, operations and maintenance at the facility.

ISASecure® alignment

The ISA Security Compliance Institute (ISCI) operates independent product certification programmes aligned to these parts, including:

SDLA — Security Development Lifecycle Assurance (Part 4-1 process)
CSA — Component Security Assurance (Part 4-2 capabilities + SDLA)
SSA — System Security Assurance (Part 3-3 capabilities + SDLA)

Further information: ISASecure.org

Key takeaways

Part 4-1 is the supplier process standard for secure product development.
Eight practices cover management, requirements, design, implementation, SVV, issue handling, updates and guidelines.
Defence-in-depth and threat modelling are central; SL-C states what the product can support.
Maturity levels ML1–ML4 (CMMI-derived) measure how well practices are defined, practised and improved.
Part 4-2 (and 3-3) define the technical capabilities those processes must deliver.

Standards references

ISA/IEC 62443-4-1:2018 — Secure product development lifecycle requirements (primary).
ISA/IEC 62443-4-2 — Technical security requirements for IACS components.
ISA/IEC 62443-3-3 — System security requirements and security levels.
ISA/IEC TR 62443-2-3 — Facility patch management (counterpart to SUM).