The CRA requires a structured development process rather than a final pentest. What an SDL must do and how it proves CRA conformity.
The Cyber Resilience Act (CRA) requires manufacturers to integrate security into the development process from the very beginning rather than bolting it onto a product afterward. Manufacturers that cannot provide this evidence by the CRA obligations’ effective date in December 2027 (CRA-Pflichten ab Dezember 2027) risk losing access to the European market — not because a feature is insecure, but because a required process is missing. The structured framework for this is a secure development lifecycle (SDL).
The CRA sets out in Article 13 and Annex I a number of requirements that directly affect how products with digital elements are developed. Among other things, manufacturers must ensure their products reach the market with an appropriate level of protection, that risks are assessed systematically, and that security considerations are taken into account throughout the product lifecycle.
Crucially: the CRA asks not only for the outcome but for the way it was achieved. The technical documentation must show how security requirements were identified, implemented, and verified. That requires a structured, repeatable development process — not an ad-hoc project approach.
What is a secure development lifecycle?
A secure development lifecycle is a process framework that systematically embeds security activities into every phase of product development, from requirements analysis to maintenance. It is not a single tool or a one-off project. Activities span architecture and implementation through testing and release and interlock in every phase.
An SDL is more than a sequence of phases. It is organized into several thematic areas, some of which run continuously across the lifecycle:
- Planning and governance: Define security policies, roles, responsibilities, and competencies.
- Risk management: Systematically assess threats and risks in the specific product context.
- Requirements: Derive security requirements from the risk assessment.
- Architecture and design: Embed security early and make secure-by-default design decisions.
- Implementation: Apply secure coding guidelines and ensure they are followed.
- Verification and validation: Test and demonstrate security requirements, including through pentests.
- Documentation: Provide manuals and security guidance for users.
- Releases and updates: Deliver products securely and provide updates in a controlled manner.
- Suppliers and components: Secure purchased and open-source components with supplier diligence and SBOM.
- Vulnerability management: Record, assess, and remediate vulnerabilities throughout the support period.
- Securing infrastructure and production: Protect development and manufacturing environments.
Planning and governance as well as risk management steer the entire process. Documentation is created as part of development, and releases and updates follow development milestones. Vulnerability management, supplier and component integration, and securing infrastructure and production accompany development as supporting activities.
An SDL ensures that security does not depend on the availability of individual people but is embedded in the process. Threat analyses are not optional but a fixed part of the architecture phase. Security requirements do not arise from gut feeling but from a documented risk assessment. And verification does not happen only shortly before release but accompanies the entire development cycle.
For manufacturers that have not previously operated a formalized security development process, this means a fundamental change — not necessarily in what they develop, but in how they develop it.
Where the SDL addresses CRA requirements
The connection between an SDL and CRA conformity is not indirect. The CRA’s main requirements can be directly mapped to SDL activities.
| CRA requirement | What the CRA requires | SDL activity that meets it |
|---|---|---|
| Risk assessment (Article 13 paragraph 2) | Systematic evaluation of cyber risks | Threat and risk analysis during the design phase |
| Secure default configuration (Annex I) | Delivery with a secure default setting | Secure-by-default in architecture decisions |
| Documentation obligation | Evidence of the process, not just the outcome | Continuous evidence collection across all phases |
| Updates and changes | Security also during maintenance and change | Defect and change management in the SDL |
The last row is often overlooked in practice: updates and changes are also a process requirement, not merely a product feature.
IEC 62443-4-1 as a guidance framework
For manufacturers building or formalizing an SDL, IEC 62443-4-1 offers an established guidance framework. That standard describes requirements for a secure development process and covers areas such as security management, secure design, implementation, verification, and defect management. In addition, BSI TR-03185 on the secure software lifecycle describes requirements for a secure development process.
IEC 62443-4-1 is not a CRA-specific standard in the narrow sense: it was originally developed for industrial automation systems. However, it addresses many of the process requirements that the CRA places on manufacturers and is used by conformity assessment bodies as a relevant reference framework. Aligning your SDL with IEC 62443 as a basis for CRA implementation provides a solid foundation for CRA conformity assessment.
How CRA-compliant is your development process already?
IEC 62443-4-1 covers many of the CRA’s procedural requirements — but it does not replace a complete CRA assessment. Our check shows which requirements are already addressed and where gaps remain.
How future-proof is an SDL based on IEC 62443-4-1?
An SDL aligned today with IEC 62443-4-1 also contributes to the future CRA standards landscape. The horizontal EN-40000 series is being developed as a basis for all products with digital elements. Particularly relevant for the development process are EN 40000-1-2 (principles for cyber resilience) and EN 40000-1-3 (handling of vulnerabilities). Both are currently drafts and not yet harmonized.
For operational technology, selected parts of IEC 62443 will be transferred into the emerging CRA standards framework via an annex adaptation (prAA), including IEC 62443-4-1 for the development process. Anchoring your development process in IEC 62443-4-1 means building on a basis that will grow into the future CRA standardization rather than being replaced later. A status update on the horizontal EN-40000 standards provides an overview of the current state.
The machinery regulation also requires secure development
The CRA is not the only EU regulation that prescribes a secure development process. The new machinery regulation (EU) 2023/1230, which becomes mandatory in January 2027, contains explicit cybersecurity requirements for machines with digital components in Annex III.
For machine builders this means: an SDL not only addresses CRA conformity but also provides a foundation for complying with the machinery regulation. Two regulatory requirements, one process framework. This overlap makes building an SDL a strategic investment for manufacturers in the machine sector rather than mere compliance overhead. How CRA and the machinery regulation interact determines how much duplicate work you can avoid.
Is a pentest at the end enough for CRA conformity?
In practice, many manufacturers still treat security as something added after functional development: a pentest before release, a hardening measure after integration, a security review shortly before delivery.
Under the CRA, this approach will no longer be viable. The regulation requires that security be integrated into the development process, not applied afterward. The technical documentation must demonstrate the process, not just the end result. Retrospective hardening can fix product vulnerabilities, but it cannot prove a development process that never existed.
That does not mean pentests become useless. They remain a valuable verification tool, for example as recurring measures as shown by pentests in the machinery sector. The crucial point is that they must be part of an end-to-end process, not a substitute for one.
This is the decisive point: the CRA checks not only whether a product is secure but whether it was developed securely. Demonstrating this requires an SDL that exists before the first commit, not after the final test.
What this means for manufacturers
A secure development lifecycle is no longer an optional best practice. It is the operational prerequisite for CRA conformity. Manufacturers that do not operate a formalized SDL today face a fundamental process change that takes time and cannot be implemented in a few weeks before the deadline.
The requirements themselves are not a surprise. The CRA has been in force since 2024, and the machinery regulation was published in 2023. The question is no longer whether manufacturers must change their development process, but whether the remaining time is sufficient to do so in a structured way.
Your development process needs to change. Where do you start?
We analyze together which gaps your current process has regarding CRA conformity and show you a realistic entry path that fits your product landscape and schedule.
