Secure Development Lifecycle Requirements under the CRA
Few terms come up as often in discussions of the Cyber Resilience Act as “security by design”, and few are misunderstood as often. Security by design is not an attitude, a quality promise, or a bullet point on a slide. It is a specific regulatory requirement, and you can only meet it if your development process is built for it.
The Cyber Resilience Act (Regulation (EU) 2024/2847), or CRA, requires manufacturers to build security into the development process from the start instead of adding it to a product afterward. If you cannot provide this evidence by the time the CRA obligations apply in December 2027, you lose access to the EU market. The reason would be a missing process, not an insecure function. The structured framework for this process is a secure development lifecycle (SDL).
Contents
- What the CRA requires from product development
- What is a secure development lifecycle?
- Where the SDL addresses CRA requirements
- IEC 62443-4-1 as a reference framework
- How durable is an SDL based on IEC 62443-4-1?
- The Machinery Regulation also requires secure development
- Is a pentest at the end enough for CRA conformity?
- What this means for manufacturers
What the CRA requires from product development
Article 13 and Annex I of the CRA set out requirements that directly affect how products with digital elements are developed. Among other things, manufacturers must ensure three things: their products reach the market with an appropriate level of security, risks are assessed systematically, and security is considered across the entire product lifecycle.
The CRA asks about the route as well as the result. The technical documentation must show how security requirements were identified, implemented, and verified. This requires a structured, repeatable development process rather than an ad hoc approach per project.
What is a secure development lifecycle?
A secure development lifecycle is a process framework that embeds security activities systematically in every phase of product development, from requirements analysis to maintenance. It is neither a single tool nor a one-off project. The activities run through architecture and implementation to testing and release, and they interlock in every phase.
An SDL is more than a sequence of phases. It is divided into several topic areas, some of which run continuously through the entire lifecycle:
- Planning and governance: Define security policies, roles, responsibilities, and competencies.
- Risk management: Assess threats and risks systematically in the context of the product.
- Requirements: Derive security requirements from the risk assessment.
- Architecture and design: Build security in early and make secure-by-default decisions.
- Implementation: Apply secure coding guidelines and make sure they are followed.
- Verification and validation: Test and demonstrate security requirements, including through pentests.
- Documentation: Provide manuals and security information for users.
- Releases and updates: Deliver products securely and provide updates in a controlled way.
- Suppliers and components: Secure purchased and open-source parts, with supplier due diligence and a software bill of materials (SBOM).
- Vulnerability management: Record, assess, and fix vulnerabilities throughout the support period.
- Infrastructure and production security: Protect the development and manufacturing environment.
Planning, governance, and risk management steer the whole process. Documentation is created as part of development, and releases and updates follow once development is complete. Vulnerability management, the integration of suppliers and components, and the protection of infrastructure and production accompany development as supporting activities.
With an SDL, security is anchored in the process and does not depend on the availability of individual people. Threat analyses are a fixed part of the architecture phase, not an option. Security requirements come from a documented risk assessment, not from gut feeling. Verification runs throughout the development cycle instead of only shortly before release.
For manufacturers without formalized secure development so far, this is a fundamental change. It may not change what you develop, but it does change how you develop it.
Where the SDL addresses CRA requirements
The link between an SDL and CRA conformity is direct. The essential requirements of the CRA map onto SDL activities.
| CRA requirement | What the CRA requires | SDL activity that meets it |
|---|---|---|
| Risk assessment (Article 13(2)) | systematic assessment of cybersecurity risks | threat and risk analysis in 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 approach, not only of the result | continuous evidence across all phases |
| Updates and changes | security during maintenance and changes as well | defect and change management in the SDL |
The last row is often overlooked in practice. Updates and changes are a process requirement, not a product feature.
IEC 62443-4-1 as a reference framework
If you want to build or formalize an SDL, IEC 62443-4-1 offers an established reference framework. The standard sets requirements for a secure development process and covers areas such as security management, secure design, implementation, verification, and defect management. In Germany, for example, the Federal Office for Information Security (BSI) also describes requirements for a secure development process in its technical guideline TR-03185 on the secure software lifecycle.
IEC 62443-4-1 is not a CRA standard in the narrow sense. It was originally developed for industrial automation systems. It does, however, address many of the process requirements that the CRA places on manufacturers, and conformity assessment bodies use it as a relevant reference. If you align your SDL with IEC 62443 as a basis for CRA compliance, you create a solid foundation for the CRA conformity assessment.
How CRA-ready is your development process?
IEC 62443-4-1 covers many of the CRA's process requirements, but it does not replace a complete CRA assessment. Our check shows you which requirements are already addressed and where gaps remain.
How durable is an SDL based on IEC 62443-4-1?
An SDL aligned with IEC 62443-4-1 today also pays off for the CRA standards that are still being developed. The horizontal EN 40000 series is intended as the basis for all products with digital elements. For the development process, EN 40000-1-2 (principles for cyber resilience) and EN 40000-1-3 (vulnerability handling) are particularly relevant. Both are still drafts and are not yet harmonized.
For operational technology, selected parts of IEC 62443 are being brought into the emerging CRA standards framework as supporting standards through an annex adaptation (prAA). IEC 62443-4-1 for the development process is one of them. If you base your development process on IEC 62443-4-1, you build on a foundation that will grow into future CRA standardization instead of being replaced later. For the current status, see our overview of harmonized standards for the CRA.
The Machinery Regulation also requires secure development
The CRA is not the only EU regulation that requires a secure development process. The new Machinery Regulation (Regulation (EU) 2023/1230), which applies from January 2027, contains explicit cybersecurity requirements for machinery with digital components in Annex III for the first time.
For machine builders, this means an SDL supports compliance with both the CRA and the Machinery Regulation. Two regulatory requirements share one process framework. This overlap makes building an SDL a strategic investment for machine builders rather than compliance overhead. How the CRA and the Machinery Regulation fit together 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, hardening after integration, or a security review shortly before delivery.
This approach will no longer hold up under the CRA. The regulation requires security to be part of the development process, not something that comes after it. The technical documentation must show the process as well as the result. Securing a product afterward can fix vulnerabilities in it, but it cannot demonstrate a development process that never existed.
This does not make pentests redundant. They remain a valuable verification tool, for example as a recurring measure, as described in our article on penetration testing for machine builders. What matters is that the pentest is part of a continuous process and does not replace it.
That is the decisive point. Under the CRA, the question is whether a product was developed securely, not only whether it is secure. Demonstrating this requires an SDL that is in place before the first commit, not after the last test.
What this means for manufacturers
A secure development lifecycle is no longer an optional good practice. It is the operational prerequisite for CRA conformity. Manufacturers without a formalized SDL today face a fundamental process change. That change takes time and cannot be done in a few weeks before the deadline.
None of these requirements comes as 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 have to change their development process, but whether the remaining time is enough to do it in a structured way.
Your development process has to change. Where do you start?
Together we analyze the gaps between your current process and CRA conformity, and we show you a realistic starting point that fits your product portfolio and your schedule.
