The strongest CRA development programme does not create a separate compliance process beside engineering. It embeds CRA controls into the normal product lifecycle and leaves a traceable evidence chain from cybersecurity risk to requirement, implementation, verification, release and maintenance.
The CRA Does Not Prescribe One Named SDLC Framework
Manufacturers do not need to adopt one specific framework called the CRA SDLC. Article 13 instead requires the cybersecurity risk assessment to be considered throughout planning, design, development, production, delivery and maintenance, while Annex I defines cybersecurity outcomes and vulnerability-handling requirements. The lifecycle can therefore build on an organisation's existing engineering process as long as the necessary security decisions, controls and evidence are integrated effectively.
- Keep the existing engineering lifecycle where it works.
- Map CRA obligations into each relevant stage.
- Add missing security controls rather than duplicating the whole process.
- Make evidence traceable to product versions.
Stage 1: Establish Product Security Governance
A secure development lifecycle needs clear ownership. Manufacturers should identify who owns the cybersecurity risk assessment, product security requirements, architecture review, vulnerability handling, security testing and release approval. Small organisations can combine roles, but responsibilities should remain explicit. The objective is to prevent cybersecurity decisions from becoming everyone's responsibility in theory and nobody's responsibility in practice.
- Name the product security owner.
- Name risk-assessment ownership.
- Name security-test ownership.
- Name release-risk approval authority.
Stage 2: Perform the Cybersecurity Risk Assessment Early
The Article 13 cybersecurity risk assessment should begin before important architecture decisions are fixed. It should consider intended purpose, reasonably foreseeable use, operational environment, assets to be protected and expected use duration. The assessment should identify which Annex I requirements apply and how the manufacturer intends to implement them. This provides the basis for security requirements rather than leaving teams to apply generic controls without understanding the product risk.
- Define intended purpose.
- Identify foreseeable use.
- Identify assets and environment.
- Determine applicable Annex I requirements.
- Record important cybersecurity risks.
Stage 3: Convert Risks Into Product Security Requirements
Each important cybersecurity risk should lead to a treatment decision. Where the product needs a technical control, that decision should become a product security requirement with an owner and verification method. Requirements can address authentication, confidentiality, integrity, secure configuration, update behaviour, resilience, logging and other relevant outcomes. A traceability matrix can connect the risk, Annex I reference, requirement, implementation and test evidence.
- Define measurable requirements.
- Assign owners.
- Define verification.
- Maintain risk-to-requirement traceability.
Stage 4: Perform Architecture Security Review and Threat Modelling
Architecture review should identify trust boundaries, privileged components, external interfaces, update paths, sensitive data and third-party dependencies. Threat modelling can identify credible attack paths and reveal where architecture needs additional controls. Important findings should create engineering actions rather than remain only in diagrams. Security-sensitive architecture changes should trigger review later in the lifecycle.
- Map trust boundaries.
- Map attack surfaces.
- Threat-model important flows.
- Record architecture security decisions.
Stage 5: Implement With Secure Coding and Dependency Controls
Implementation should follow stack-specific secure coding practices and use approved patterns for authentication, authorisation, input validation, cryptography, logging and secret handling. Automated static analysis, software composition analysis and secret scanning can provide repeatable coverage. Third-party components should be assessed in product context rather than treated as outside the manufacturer's security process.
- Use secure coding baselines.
- Review security-sensitive changes.
- Scan dependencies.
- Scan for exposed secrets.
Stage 6: Apply Effective Security Reviews
Annex I Part II point 3 explicitly requires effective and regular security tests and reviews. Reviews can include architecture review, threat-model review, code review, dependency review and review of security-sensitive configuration changes. Review depth should reflect product risk and change significance rather than applying the same ceremony to every minor edit.
- Review security-sensitive architecture changes.
- Review privileged code.
- Review dependency changes.
- Track findings to disposition.
Stage 7: Build Risk-Based Security Testing
Security testing should verify the controls selected from the cybersecurity risk assessment. Useful methods can include automated analysis, negative tests, access-control tests, interface testing, update testing, resilience testing and penetration testing where appropriate. Important fixes should become regression tests where practical so later versions do not quietly reintroduce the same weakness.
- Test important security requirements.
- Include negative cases.
- Use adversarial testing where appropriate.
- Create regression tests from significant defects.
Stage 8: Use Security Release Gates
Before release, the manufacturer should know whether required security controls were implemented and verified, which vulnerabilities or security findings remain open and whether any residual risk has been formally accepted. The release gate should apply to the actual artefact being distributed. CI/CD can automate deterministic checks while human approval remains available for findings requiring risk interpretation.
- Identify the release artefact.
- Verify required security checks.
- Review known vulnerabilities.
- Record approved exceptions.
- Retain release approval.
Stage 9: Maintain Secure Updating and Vulnerability Handling
The lifecycle continues after market placement. Vulnerability reports, component advisories and threat intelligence should feed into the manufacturer's vulnerability-handling process. Supported products need a secure update path capable of delivering remediation. Significant vulnerability findings should also feed back into requirements, threat models, coding standards and tests so the development process improves rather than treating every vulnerability as an isolated patch.
- Receive vulnerability reports.
- Assess affected versions.
- Develop and test remediation.
- Distribute updates securely.
- Feed lessons back into development.
Stage 10: Keep the Cybersecurity Risk Assessment Current
Article 13 requires the cybersecurity risk assessment to be documented and updated as appropriate during the support period. New interfaces, deployment models, dependencies, vulnerabilities and attacker techniques can change the product's risk profile. A mature lifecycle defines change triggers that cause the relevant part of the assessment, threat model, security requirements and tests to be revisited.
- Define risk-review triggers.
- Review architecture changes.
- Review significant vulnerabilities.
- Update controls and tests where needed.
Build Technical Documentation From Normal Engineering Evidence
Annex VII expects technical documentation to contain information about product design and development, vulnerability-handling processes, cybersecurity risk assessment, technical solutions and test evidence. The most efficient approach is to create those records during normal engineering activity. Architecture decisions, requirements, test results, release records and vulnerability evidence can then support technical documentation without requiring teams to reconstruct years of product history immediately before conformity assessment.
- Create evidence during engineering.
- Preserve version traceability.
- Map evidence to Annex I.
- Keep documentation current.
Measure Whether the Lifecycle Is Actually Effective
A secure development lifecycle should improve product security rather than merely create more checkpoints. Manufacturers can review repeated vulnerability classes, escaped defects, security-test failures, time spent remediating issues and exceptions repeatedly granted at release. Patterns can reveal where requirements, architecture review, coding standards or testing need improvement. The goal is a feedback loop in which real product-security experience strengthens the next development cycle.
- Review recurring vulnerability classes.
- Review escaped security defects.
- Review repeated release exceptions.
- Improve upstream controls.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.