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

IEC 62443-4-1 is the part of the ISA/IEC 62443 series that sets requirements for a secure product development lifecycle (SPDL): how a component or product supplier specifies, designs, implements, verifies, and maintains security across a product's whole life, not what the finished product technically does. The companion standard, IEC 62443-4-2, covers that technical side. A buyer who asks "is this PLC secure?" is really asking two separate questions, and 62443-4-1 answers the first one: was it built by a process that takes security seriously.

What IEC 62443-4-1 is

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 eight practices

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; treat specific clause numbers as to be confirmed against your purchased copy before citing them in a technical file or a customer response.

Practice	What it is about, in plain terms
Security management	Governance of the development process itself: roles, policies, and how security decisions get made and tracked
Specification of security requirements	Capturing the security requirements a product must meet before design starts
Secure by design	Building security into architecture and design decisions, not retrofitting them
Secure implementation	Coding and configuration practices that avoid introducing vulnerabilities
Security verification and validation testing	Testing that the product actually meets its security requirements
Management of security-related issues	A process for receiving, triaging and acting on vulnerability reports during the product's life
Security update management	Getting security patches to customers in a controlled, timely way
Security guidelines	Documentation that tells integrators and users how to deploy and operate the product securely

Maturity levels: a process scale, not a product scale

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 SDLA certification

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.

How 4-1 and 4-2 fit together

	IEC 62443-4-1	IEC 62443-4-2
What it covers	The supplier's development process	The component's technical requirements
Certifies	An organisation (via SDLA)	A product (component technical requirements, SL-C)
Typical question it answers	"Did you build this securely?"	"What can this component withstand?"
Relationship	A 4-2 technical claim is generally only as credible as the 4-1 process behind it	Builds on, and is usually assessed alongside, a conformant 4-1 process

See 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.

Does it help with the CRA, RED or Machinery Regulation?

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. Treat any claim that 4-1 or SDLA grants presumption of conformity under EU law as to be confirmed, not assumed. 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.

A workable starting process

1. Map your current development process against the eight practices, even informally, before deciding whether to pursue SDLA certification.
2. Start with the two practices regulators check first in practice: management of security-related issues (your intake and triage process) and security update management (how fixes actually reach customers). Both overlap directly with CRA and PSTI disclosure duties.
3. Keep 4-1 process evidence and 4-2 technical evidence in separate, cross-referenced files — a certifier or customer may ask for either independently.
4. Treat SDLA certification as a credibility signal for customers and tenders, not a regulatory requirement, until an EU harmonisation decision says otherwise.

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.

This guide is general information, not legal advice.