IEC 62443-4-1
The secure development process behind industrial products
IEC 62443-4-1 specifies requirements for a secure product development lifecycle for industrial components. It addresses how a manufacturer defines, runs and evidences its development process; IEC 62443-4-2 addresses the component’s technical security capabilities.
Why both
The standard does the work the regulation only describes
The CRA tells you that vulnerabilities must be identified, remediated without delay, tested for, and disclosed. It does not tell you what a compliant process looks like or what records to keep.
IEC 62443-4-1 offers a concrete process framework for that work. Its DM and SUM practices align closely with Annex I Part II, and its SR, SD, SI, and SVV practices can produce design and test evidence to support Part I claims in your technical documentation.
Certification is not legally required by the CRA. But a certified Secure SDLC gives you a third-party-verified answer to the hardest question an assessor can ask: prove it.
The standard
Eight practices, forty-seven requirements
Every requirement is auditable and needs evidence. Existing release, quality and safety processes can be used where they meet the requirements; all eight practices still need defined ownership and supporting records.
- SM13 requirements
Security management
The development process is defined, owned, and resourced. Covers scoping, roles and responsibilities, competence, the security of the development environment itself, and controls over third-party components.
- SR5 requirements
Specification of security requirements
Security requirements are derived from intended use and threat analysis, documented, reviewed, and traceable — not implied. Includes the product security context and threat model.
- SD4 requirements
Secure by design
Design applies defence in depth, least privilege, and secure design best practice. Design reviews and threat modelling happen at defined points, with findings tracked to closure.
- SI2 requirements
Secure implementation
Implementation follows documented secure coding standards, and implementation review verifies that security design was actually realised in the code.
- SVV5 requirements
Security verification and validation testing
Functional security testing, threat mitigation testing, vulnerability scanning, and penetration testing are planned, executed by competent people, and recorded.
- DM6 requirements
Management of security-related issues
Reported and discovered issues are received, triaged, assessed for severity, addressed, and disclosed. This practice maps closely onto CRA Annex I Part II.
- SUM5 requirements
Security update management
Updates are qualified, documented, delivered, and communicated within defined timeframes, including for the dependencies you did not write.
- SG7 requirements
Security guidelines
Users receive the documentation they need to deploy, operate, harden, and decommission the product securely, including defence-in-depth guidance.
Scoring
Maturity levels decide how much evidence you need
Each practice is scored independently. Certification typically targets Managed as a floor, with Defined for the practices most exposed to your product risk.
- ML 1InitialPractices happen, but ad hoc and largely undocumented. Outcomes depend on individuals rather than process.
- ML 2ManagedPractices are documented, planned, and performed by trained personnel with adequate resources. This is the practical minimum for certification.Typical certification floor
- ML 3DefinedPractices are standardised across the organisation and consistently applied, with auditable evidence generated as a by-product of normal work.
- ML 4ImprovingPractices are measured with metrics, and the process itself is continuously improved based on that data.
Audit reality
What an auditor will ask to see
Evidence cannot be manufactured retroactively in any credible way. This is why the process work has to start well before your target audit date.
- Documented Secure SDLC process description and scope statement
- Role definitions, competence records, and training evidence
- Product security context and threat models per release
- Security requirements with traceability to design and test
- Design and implementation review records with closed findings
- Secure coding standard and evidence of its application
- Test plans and results for SVV, including penetration test reports
- Issue register showing triage, severity scoring, and closure
- Update qualification records and release notes
- Published disclosure policy and security guidelines for users
Traceability and a target level for each practice
An auditor needs to follow a security concern from threat analysis through requirements, design, implementation, testing and release, and compare each practice with its target maturity level.
- Threat in the model
- Security requirement
- Design decision
- Code change
- Test result
- Release record
A control is difficult to defend when its records cannot be connected to the requirement it addresses or to a test that verifies it.
The target is set for each practice according to the certification scope and product risk. The same target level need not apply to every practice.
Preparation path
What certification preparation typically involves
Preparation generally starts with a gap review against the target maturity level, then defines or adapts the lifecycle, accumulates records through real releases and checks the evidence before a certification-body audit. The scope and sequence depend on the processes already in place and the certification scheme.
Assessments for this framework
Structured questionnaires scored entirely in your browser — no account, nothing transmitted. Each maps its result back to the requirement it measures.
Get in touch
Turn IEC 62443-4-1 into a process your teams can pass an audit on
A short description of what you build and how development is organised today is enough to start. We will come back with where the gaps against the standard are likely to be, and what closing them would involve for your team.
We reply within two working days.
Full contact detailsOpens our scheduling page in a new tab — pick a slot that suits you.
Useful in a first message
- What you build, how many product lines are in scope, and the platforms involved.
- How development is organised today — team size, release cadence, and your toolchain.
- Whether you are working towards a certification audit, a customer requirement, or a CRA deadline.
Please keep a first message free of confidential technical detail and trade secrets. Once we reply we can agree an encrypted channel for anything sensitive.