CRA secure development is a product-level engineering discipline. Manufacturers need to connect cybersecurity risk assessment to security requirements, architecture, implementation, configuration, testing, release and maintenance. Secure by design and secure by default are important principles within that system, but the broader obligation is to produce risk-appropriate cybersecurity outcomes and retain evidence showing how those outcomes were implemented and verified.
Article 13 Makes Cybersecurity Part of Product Development
Article 13 places cybersecurity directly inside the manufacturer's product-development responsibilities. When placing a product with digital elements on the market, the manufacturer must ensure that it has been designed, developed and produced in accordance with the applicable essential cybersecurity requirements in Annex I Part I. This means CRA readiness cannot be completed only by a compliance team after engineering has finished. Product requirements, architecture, implementation choices, configuration, testing and release evidence all need to reflect the cybersecurity requirements relevant to the product.
- Treat CRA security requirements as product requirements.
- Include engineering and product-security teams early.
- Connect implementation controls to Annex I.
- Retain product-specific verification evidence.
The Cybersecurity Risk Assessment Drives the Development Process
Article 13 requires manufacturers to assess the cybersecurity risks associated with the product and use the outcome throughout planning, design, development, production, delivery and maintenance. The assessment therefore should not be a document created only for conformity preparation. It should influence security requirements, architecture, trust boundaries, privileges, exposed interfaces, configuration, update mechanisms, logging, dependency decisions and verification depth. When relevant risks change, the security decisions connected to them may also need to change.
- Identify relevant product cybersecurity risks.
- Translate risks into security requirements.
- Connect requirements to architecture and implementation.
- Define how controls will be verified.
- Reassess when product changes alter the risk picture.
Secure Development Is Broader Than Secure Coding
Secure coding is important, but CRA secure development begins before source code is written and continues after release. Architecture can create or remove attack paths. Product requirements can determine whether authentication or encryption is feasible. Default configuration can expose services unnecessarily. Build and release processes can introduce vulnerable dependencies or secrets. Update mechanisms determine whether later vulnerabilities can be corrected safely. A useful secure-development model therefore covers the entire engineering system rather than assigning cybersecurity only to individual developers.
- Product requirements.
- Architecture and threat modelling.
- Implementation and code review.
- Dependency and secrets management.
- Security testing.
- Release controls.
- Secure updating and maintenance.
Secure by Design Moves Security Decisions Earlier
Secure by design is a practical implementation principle used in current EU and ENISA CRA guidance. The operative Regulation does not define a standalone Annex I requirement using that exact phrase. Instead, Article 13 requires the cybersecurity risk assessment to shape the product across planning, design, development, production, delivery and maintenance, while Annex I defines the required cybersecurity outcomes. In practice, secure by design means making important security decisions while the architecture and product behaviour can still be changed efficiently rather than relying mainly on patches after release.
- Model threats before architecture becomes difficult to change.
- Define trust boundaries and privilege assumptions.
- Reduce unnecessary attack surface.
- Select controls based on identified product risks.
- Treat later testing as verification, not as the first security activity.
Secure by Default Defines the Product's Starting Security Posture
Annex I Part I point 2(b) explicitly requires, on the basis of the cybersecurity risk assessment and where applicable, products with digital elements to be made available with a secure-by-default configuration. Secure development therefore needs to control not only which security features exist but how the product behaves before users perform optional hardening. Services, privileges, accounts, remote administration, debugging features, interfaces and other security-sensitive settings should have a defensible initial posture. The detailed legal mechanics of point 2(b) are separate from the broader development principle addressed in this cluster.
- Define an approved default security baseline.
- Review unnecessary enabled services and interfaces.
- Review default privileges and credential behaviour.
- Verify the configuration actually delivered to users.
- Test reset behaviour against the intended secure baseline.
Security Requirements Need Traceability
A secure-development programme becomes much easier to defend when each important cybersecurity risk can be traced to one or more security requirements, implementation controls and verification activities. A product security requirement might specify authentication behaviour, update integrity, encryption, privilege boundaries, logging, interface restrictions or failure behaviour. The requirement should have an engineering owner and a planned verification method. This creates a chain from risk assessment to implemented control to evidence rather than leaving cybersecurity decisions scattered across design documents and issue trackers.
- Risk or threat.
- Security requirement.
- Implementing component or control.
- Engineering owner.
- Verification method.
- Evidence location.
Development Controls Should Be Integrated Into Normal Engineering
CRA security work is more sustainable when it is embedded into existing engineering processes. Threat modelling can be attached to architecture review. Secure coding requirements can be incorporated into development standards. Static and dynamic analysis can run in CI/CD. Dependency checks can run during builds. Security review can be part of pull-request and release processes. Security testing can be tied to risk and product changes. The purpose is not to add a separate compliance workflow beside product development, but to make the existing product-development system produce the security evidence required for the product.
- Architecture security review.
- Threat modelling.
- Secure coding controls.
- Automated security checks.
- Security testing.
- Release approval.
- Post-release vulnerability handling.
Release Should Be a Security Decision Point
Before a product version is released, the manufacturer should know whether the applicable security requirements have been implemented, whether relevant security testing has passed, whether known vulnerabilities have been evaluated and whether unresolved security issues are acceptable under the product's cybersecurity risk assessment. A release gate does not require every product to use the same process. It does require a controlled decision that connects the released version to its security evidence and open risks.
- Confirm required security controls are implemented.
- Confirm required tests have completed.
- Review unresolved vulnerabilities and findings.
- Confirm secure default configuration.
- Retain the release-security decision.
Secure Development Continues Into Maintenance
Article 13 expressly carries the cybersecurity risk assessment into maintenance. Secure development therefore does not end when a version is placed on the market. Vulnerability reports, dependency changes, threat intelligence, security updates and product modifications can reveal new risks or change earlier assumptions. The development lifecycle should connect post-market vulnerability handling back to product engineering so corrective measures can be designed, tested and released without losing traceability to the affected versions and requirements.
- Feed vulnerability findings back into engineering.
- Reassess risks when important assumptions change.
- Maintain secure update capability.
- Track security fixes across supported versions.
- Retain evidence during the support period.
Build Evidence While Building the Product
Technical documentation is easier to maintain when evidence is created as part of development rather than reconstructed immediately before conformity assessment. Useful evidence can include risk assessments, security requirements, architecture decisions, threat models, code-review records, security-test results, configuration baselines, dependency records, penetration-test findings, release approvals and update-mechanism tests. The evidence should be tied to the product or product family and the relevant version so a reviewer can understand how cybersecurity requirements were actually implemented.
- Create evidence during normal engineering activity.
- Keep evidence product-specific.
- Maintain version traceability.
- Connect evidence to the relevant Annex I requirement.
- Update evidence when the security design materially changes.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.