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 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. 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 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
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 Secure SDLC 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.
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 detailsUseful 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.
The gap assessment returns a maturity score per practice, the evidence artefacts you are missing, and a sequenced remediation plan toward audit readiness.
Start the gap assessment