IEC 62443-4-1: the secure development lifecycle for industrial products

What is IEC 62443-4-1?

IEC 62443-4-1:2018, Security for industrial automation and control systems, Part 4-1: Secure product development lifecycle requirements, was published in January 2018. In the standard's own scope, it "specifies process requirements for the secure development of products used in industrial automation and control systems". The life cycle it defines covers security requirements definition, secure design, secure implementation, verification and validation, defect management, patch management and product end of life.

It applies to the developer and maintainer of a product: the product supplier making controllers, embedded devices, network equipment, host software or applications. It does not apply to the integrator or the user of the product, who have their own parts of the series. ISA publishes the series as ISA/IEC 62443.

The standard describes process requirements, policies and procedures, rather than technical security features. The technical requirements for components are in IEC 62443-4-2.

The eight practices of IEC 62443-4-1

The requirements are grouped into eight practices, each with a short abbreviation that prefixes its requirement IDs. The ISA Global Cybersecurity Alliance lists 47 requirements in total:

Practice	Requirements	What it covers
1. Security management (SM)	SM-1 to SM-13	Planning and running the security process: responsibilities, expertise, development environment security, private keys, externally provided and third-party components, process verification, continuous improvement
2. Specification of security requirements (SR)	SR-1 to SR-5	Product security context, threat model, product security requirements and their review
3. Secure by design (SD)	SD-1 to SD-4	Secure design principles, defense in depth design, design review, design best practices
4. Secure implementation (SI)	SI-1 to SI-2	Security implementation review and secure coding standards
5. Security verification and validation testing (SVV)	SVV-1 to SVV-5	Requirements testing, threat mitigation testing, vulnerability testing, penetration testing, tester independence
6. Management of security-related issues (DM)	DM-1 to DM-6	Receiving, reviewing, assessing, addressing and disclosing security issues in the product
7. Security update management (SUM)	SUM-1 to SUM-5	Qualifying, documenting and delivering security updates, on time
8. Security guidelines (SG)	SG-1 to SG-7	User documentation for defense in depth, hardening, secure operation, account management and disposal

Practice 6: management of security-related issues (DM)

DM is the practice a PSIRT recognizes as its own. According to the ISAGCA, its processes are used for handling security-related issues of a product that is configured according to its defense in depth strategy. Its six requirements follow an issue from report to closure:

• DM-1: Receiving notifications of security-related issues
• DM-2: Reviewing security-related issues
• DM-3: Assessing security-related issues
• DM-4: Addressing security-related issues
• DM-5: Disclosing security-related issues
• DM-6: Periodic review of security defect management practice

In plain terms: take reports in, check them, assess them, fix them, tell users, and review the process itself.

That sequence is the vulnerability management lifecycle under another name, and DM-1 and DM-5 are where coordinated vulnerability disclosure comes in. Disclosure can be published as a CSAF advisory, with a VEX statement for versions that are not affected.

Practice 7: security update management (SUM)

SUM picks up where DM decides on a fix. Its processes, in the ISAGCA's summary, ensure that security updates for the product's hardware, software or firmware are tested for regressions and made available to users in a timely manner. The five requirements are:

• SUM-1: Security update qualification
• SUM-2: Security update documentation
• SUM-3: Dependent component or operating system security update documentation
• SUM-4: Security update delivery
• SUM-5: Timely delivery of security patches

SUM-3 is the one that reaches into your supply chain: updates to components and operating systems your product depends on. For an embedded product built on a Linux distribution, that can be most of the patches you ship.

Maturity levels

IEC 62443-4-1 does not ask whether a process exists; it asks how mature it is. It uses four maturity levels, based on CMMI for Development:

Level	Meaning
ML1 Initial	Processes are performed ad hoc or undocumented
ML2 Managed	Processes are documented and describe how the activity is delivered and managed
ML3 Defined (Practiced)	Processes are documented, executed and repeatable
ML4 Improving	Processes are improved over time using metrics for performance and effectiveness

The difference between ML2 and ML3 is practice. A written DM process can be ML2. ML3 means the process has been executed and repeated: issues received, assessed and closed, updates delivered, with the records to show it.

Certification

• ISASecure SDLA. The Security Development Lifecycle Assurance program certifies a development organization's lifecycle process to IEC 62443-4-1. Evaluations are done by chartered SDLA laboratories accredited as conformity assessment bodies.
• Certification bodies and the IECEE CB Scheme. Testing and certification bodies such as Applus+ and TÜV Rheinland assess suppliers against 62443-4-1 and state the maturity level achieved, including under the IECEE CB Scheme, which is applicable in more than 50 countries.

A 62443-4-1 certificate covers the supplier's development process, not a single product. Products are assessed separately against 62443-4-2.

How 62443-4-1 relates to the rest of the series

• IEC 62443-4-2, technical security requirements for IACS components: what the product must be able to do. 4-1 is how you build and maintain it.
• IEC 62443-3-3, system security requirements and security levels: the equivalent technical requirements at the system level.
• IEC 62443-2-4, security program requirements for IACS service providers: the integrators and maintenance providers who install and service your product at the asset owner's site, and who depend on your security updates and guidelines.

Mapping IEC 62443-4-1 to PSIRT work

PSIRT activity	Where it lands in 62443-4-1
Intake of vulnerability reports	DM-1
Triage and analysis	DM-2, DM-3
Remediation	DM-4, SUM-1
Advisories and disclosure	DM-5, SUM-2
Patches for third-party components	SUM-3, with SM-9 and SM-10 on externally provided and third-party components
Release of the fix	SUM-4, SUM-5
Metrics and process review	DM-6, SM-13

This mapping is ours, by requirement title. The standard does not mention PSIRTs by name; the same work is described in FIRST's PSIRT Services Framework and in ISO/IEC 30111.

SBOMs as evidence for DM and SUM

The 2018 requirement titles do not mention SBOMs. But many of the security issues in an industrial product are in components its supplier did not write: the Linux kernel, OpenSSL, BusyBox, a protocol stack. Answering DM-2 and DM-3 for a new advisory means knowing which products and versions contain the affected component. Documenting SUM-3 updates means knowing which component versions each release shipped with. At ML3, those answers need records behind them.

A component list written by hand, or a scan of the source tree, goes stale. An SBOM from the build that produced the release does not, as long as the build itself is recorded.

Where CRACI fits

CRACI does not certify anything under IEC 62443, and it does not run your development process. Its records can serve as evidence for parts of it: the inventory of components in each release, and monitoring of shipped builds for new vulnerabilities.

CRACI runs GitHub Actions builds, Yocto builds included, on its own runners and records the packages each job actually fetched, including transitive dependencies, packages restored from caches and dependencies no lockfile lists. Each SBOM carries a completeness state and exports as CycloneDX or SPDX. Monitored SBOMs are re-evaluated continuously, build history shows which past builds contained a vulnerable dependency, and the inventory view shows which versions are deployed to which products. Vendor SBOMs for bought-in components are monitored alongside your own builds. See vulnerability tracking and CRACI for PSIRTs.

IEC 62443-4-1: frequently asked questions

What is IEC 62443-4-1?

IEC 62443-4-1:2018, Secure product development lifecycle requirements, is the part of the IEC 62443 series that sets process requirements for suppliers developing products used in industrial automation and control systems. It covers security requirements, secure design, implementation, verification and validation, defect management, patch management and product end of life.

What are the eight practices of IEC 62443-4-1?

Security management (SM), specification of security requirements (SR), secure by design (SD), secure implementation (SI), security verification and validation testing (SVV), management of security-related issues (DM), security update management (SUM) and security guidelines (SG). Together they hold 47 requirements.

What is the difference between IEC 62443-4-1 and 62443-4-2?

4-1 is about the process a supplier uses to develop and maintain products. 4-2 sets technical security requirements for the components themselves, such as embedded devices, network devices, host devices and software applications. A supplier is typically assessed against 4-1 for its development process and against 4-2 for a specific product.

Which IEC 62443-4-1 practices cover vulnerability management?

Mainly practice 6, management of security-related issues (DM-1 to DM-6), which covers receiving, reviewing, assessing, addressing and disclosing security issues, and practice 7, security update management (SUM-1 to SUM-5), which covers qualifying, documenting and delivering security updates on time. This is the work a PSIRT does.

What are the IEC 62443-4-1 maturity levels?

Four levels, based on CMMI for Development: ML1 Initial (ad hoc or undocumented), ML2 Managed (documented processes), ML3 Defined or Practiced (documented, executed and repeatable) and ML4 Improving (processes improved over time using performance metrics).

How do you get IEC 62443-4-1 certified?

Through an accredited certification body. ISASecure's SDLA program certifies development organizations to IEC 62443-4-1 through chartered laboratories, and certification bodies such as TÜV Rheinland and Applus+ issue 62443-4-1 certificates that state the maturity level achieved, including under the IECEE CB Scheme.

Does IEC 62443-4-1 require an SBOM?

The 2018 requirement titles do not mention SBOMs. Several requirements deal with externally provided components and with updates to dependent components and operating systems, and a reliable list of the components in each release is the practical way to show how you handle them.