IEC 62443-4-1: the secure product development lifecycle, explained

Published by the IEC as IEC 62443-4-1:2018, Edition 1.0 ("Security for industrial automation and control systems – Part 4-1: Secure product development lifecycle requirements"), the standard is part of the broader 62443 series that also includes 4-2 (component technical requirements), 3-3 (system-level security requirements and security levels) and 2-4 (requirements for service providers). A component or product maker working only toward 4-2 is, in ISA's own framing, addressing the technical slice of a bigger picture; 4-1 is the process slice underneath it.

The IEC catalogue entry states the scope directly: the standard "specifies the process requirements for the secure development of products used in industrial automation and control systems." Its lifecycle "includes security requirements definition, secure design, secure implementation (including coding guidelines), verification and validation, defect management, patch management and product end-of-life," and the requirements "can be applied to new or existing processes for developing, maintaining and retiring hardware, software or firmware." Two consequences follow for device makers. Firmware is explicitly in scope, so an embedded team cannot treat 4-1 as a software-only standard. And the requirements "only apply to the developer and maintainer of the product, and are not applicable to the integrator or the user"; integration and maintenance services fall under IEC 62443-2-4 instead. As read on 10 November 2026, the entry lists publication on 15 January 2018, a stability date of 2027 and a next-edition project at the stage "Preparation of CC" (committee draft). In the US the same text is ANSI/ISA-62443-4-1-2018; the ISA series page notes a December 2020 editorial corrigendum that changed only its title. For the wider OT security context, start from our NIST SP 800-82 guide.

IEC 62443-4-1 organises its requirements into eight practices that run across a product's lifecycle: Security Management, Specification of Security Requirements, Secure by Design, Secure Implementation, Security Verification and Validation Testing, Management of Security-Related Issues, Security Update Management, and Security Guidelines. The exact clause wording and numbering sit inside the paywalled standard text, which is the authoritative source to cite in a technical file or a customer response.

IEC 62443-4-1 measures how mature an organisation's secure development process is across those eight practices, on a scale commonly described as Initial, Managed, Defined and Improving. This is a different axis from the Security Levels (SL) used in 62443-4-2 and 3-3, which describe what a component or system can technically withstand (for example, SL1 against casual attackers up to SL4 against sophisticated, well-resourced adversaries). It is easy to conflate the two because both series use a 1-to-4-style scale; 4-1's scale is about the builder's discipline, 4-2's is about the product's capability.

ISASecure, the ISA Security Compliance Institute's certification body, runs SDLA (Security Development Lifecycle Assurance) certification, which certifies a named development organisation's documented process against IEC 62443-4-1 — it certifies the organisation's process, not a specific product. ISASecure's current scheme (3.0.0, effective 16 June 2020 per ISASecure) does not use numbered levels; it is a pass/fail certification that the organisation's process conforms. An earlier SDLA 2010.1 scheme used four numbered certification levels aligned to the standard's older structure, but ISASecure states that scheme is no longer valid. If you see a vendor claim an "SDLA Level" today, ask which scheme version it was certified against.

See IEC 62443-4-2 component requirements for the four component types and how CSA tests them, and IEC 62443-4-2 vs the Cyber Resilience Act and EN 18031 for the technical-requirements side and how it lines up against EU rules.

No EU Official Journal citation making IEC 62443-4-1, or ISASecure's SDLA certification, a harmonised standard for the Cyber Resilience Act, RED/EN 18031 or the Machinery Regulation (EU) 2023/1230 could be found at the time of writing, and CRA harmonised standards for connected products generally are still being drafted by CEN, CENELEC and ETSI. A claim that 4-1 or SDLA grants presumption of conformity under EU law should not be assumed. The CEN, CENELEC and ETSI M/606 work programme (version V1, 2 April 2025) lists a European amendment, EN IEC 62443-4-1:2018/prAA, among the supporting OT deliverables for the CRA, assigned to CLC/TC 65X WG 3; like any EN, it would give presumption of conformity only once its reference is published in the Official Journal. Our M/606 guide tracks the dates. What it does give you, today, regardless of formal recognition: a documented process you can point to as evidence of due diligence when a regulator, auditor or customer asks how you develop secure products, and a structure that maps naturally onto the process obligations the CRA already imposes directly, such as a documented vulnerability-handling process and a coordinated disclosure policy. See CRA Annex I explained and vulnerability disclosure policy template.

Each practice produces records that the CRA asks for, though not one to one. The table is our reading of where a practice's output can serve as evidence for a provision of Regulation (EU) 2024/2847; it is not an official crosswalk.

Two CRA duties need explicit additions to a generic 4-1 process. The first is the reporting clock: Article 14 has applied since 11 September 2026 under Article 71, with a 24-hour early warning for actively exploited vulnerabilities; see CRA 24-hour reporting. The second is a machine-readable SBOM covering at least top-level dependencies (Annex I Part II(1)); see firmware SBOM. The intake and disclosure side is covered in the CVD process under ISO/IEC 29147 and 30111.

Synthetic example: no real company. A 60-person maker of remote I/O modules has one firmware team of eight, ships two releases a year and receives vulnerability reports through a sales email address. It wants to know how far it is from an SDLA assessment and what the CRA adds. Over two days, its security lead rates the evidence for each practice:

The plan follows the CRA calendar, not the table order. First comes issue intake and triage, because Article 14 reporting already applies: a PSIRT contact, a CVD policy and a triage log. Second, a firmware SBOM per release and a known-vulnerability check against it. Third, security requirements and a threat model for the current hardware. Fourth, robustness testing. An SDLA assessment makes sense only after two releases have gone through the revised process, because the certifier samples artifacts from real products.

Takeaway. A gap review is a table of evidence, not of opinions. If a practice cannot point to a document or a record, rate it missing.

• Writing the process the month before the audit. SDLA certifies a versioned process plus artifacts; a brand-new document has no artifacts to sample.
• Reading a maturity rating as a security level. How disciplined the process is says nothing about a product's SL-C.
• Scoping too narrowly. If the documented process excludes firmware or a product family, those products are outside the certificate.
• Applying 4-1 to integration work. The catalogue scope limits it to developers and maintainers; integration services are covered by 2-4.
• Leaving security guidelines to technical writers alone. The hardening guide is also CRA Annex II user information and needs engineering input.
• Running 4-1 and CRA work as two projects. Most records serve both. Keep one evidence set and map it twice.

SoftWSP reviews component-maker development processes against IEC 62443-4-1's practices and the technical requirements in 4-2, and produces the SBOM and vulnerability evidence that sits alongside both: see machine builders and device firmware security. On the platform side, that evidence is a firmware SBOM in CycloneDX JSON, matched against NVD, CISA KEV, FIRST EPSS and CISA CSAF ICS advisories, with an AI-drafted report that cites each source for an engineer to review.

This guide is general information, not legal advice.