IEC 62443-4-1
Certification preparation for the secure product development lifecycle
IEC 62443-4-1 specifies the process requirements for developing secure industrial products. It is the standard certification bodies audit against, and the most practical way to evidence the process obligations the Cyber Resilience Act imposes.
- Practices
- 8
- Requirements
- 47
- Maturity levels
- 4
- Typical target
- ML 2 – ML 3
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 answers exactly that. Its DM and SUM practices align closely with Annex I Part II, and its SR, SD, SI, and SVV practices generate the design and test evidence that supports Part I claims in your technical documentation.
Certification is not legally required by the CRA. But a certified SDL 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. The practices are not equally difficult — SM and SVV usually take the longest to reach a defensible state.
- 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 SDL 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
Preparation path
How we sequence a certification programme
- Phase 1
Gap assessment
Score all eight practices against the target maturity level and identify which requirements have no supporting evidence today.
- Phase 2
Process definition
Write the SDL process so it reflects how your teams actually work. Processes that fight the engineering culture do not survive to audit.
- Phase 3
Evidence accumulation
Run the process through real releases. Auditors want records generated by normal work, not artefacts produced for the audit.
- Phase 4
Audit dry-run
An internal assessment against the certification body checklist, with interviews, so findings surface before they cost you an audit cycle.
- Phase 5
Certification
Certification body engagement, evidence submission, audit support, and closure of any findings raised.
Score your SDL against all eight practices
The gap assessment returns a maturity score per practice, the evidence artefacts you are missing, and a sequenced remediation plan toward audit readiness.