Engineering Secure‑by‑Design Systems: Practical Patterns for CRA‑Compliant Product Development

This guest post by Bram Blaauwendraad (Bureau Veritas) focuses on the engineering side of CRA readiness, especially for embedded systems. It highlights four practical areas where teams can make the biggest impact.

1. Make secure development practical for engineers

The CRA expects products to be secure by design and by default, but in practice this only works if developers know what that actually means in their day-to-day work. It helps to define a small, consistent set of secure development practices that apply across all products, regardless of their classification, and make these easy to find and use. Think of guidance that is embedded in engineering workflows rather than sitting in policy documents.

Training and tooling are key here. Integrating checks into IDEs, pipelines, and templates makes it much easier to follow the right practices by default. In our experience, organisations that operationalise security in this way move much faster towards CRA compliance than those that rely on policy alone.

2. Assess Full Solutions

Although the CRA seems to focus on transactional products (e.g. if you sell a phone, it needs to be secure), in reality many organisations deliver integrated solutions made up of multiple components. From a risk perspective, the final solution is what matters. This means you need to understand how components interact and what risks emerge when they are combined, especially in engineering-to-order (ETO) scenarios.

When a client asks you to deviate from a reference architecture, it is good practice to perform a “deviation risk assessment” on what has changed and why it matters. The CRA also requires products to be secure by default, so if a customer requests a change that weakens security, that risk should be clearly documented and agreed. In some cases, organisations choose to formally transfer that risk through contractual arrangements, but the key point is transparency and traceability.

3. Maintain clear Software and Hardware BOMs

The CRA puts strong emphasis on handling vulnerabilities throughout the product lifecycle, not just before release. This includes identifying components, monitoring for vulnerabilities, and providing timely fixes. In practice, this means you need a clear view of what is inside your product, including third-party software and hardware.

Maintaining a Software Bill of Materials, and where relevant a Hardware BOM, makes this much more manageable. It allows you to track newly disclosed vulnerabilities and assess their impact quickly. Organisations that already have structured processes for monitoring CVEs and distributing patches will find themselves in a much better position when the CRA requirements become fully enforceable.

4. Threat Modeling as part of risk assessment

A well-documented cybersecurity risk assessment is at the heart of CRA compliance. It should describe how the product is used, what assets need protection, and which risks are relevant in its expected environment. In practice, this often takes the form of threat modelling combined with architectural documentation of security controls, data flows, and trust boundaries.

This is not just a one-off. The risk assessment needs to be maintained over time and updated periodically or when new vulnerabilities or changes arise. It also becomes an important piece of evidence during conformity assessments or after incidents. Organisations that invest in this early tend to have a much clearer and defensible security posture later on. Threat Modeling is generally something that engineers can excel at as they know the technical details of their products intimately, although there tends to be a small learning curve.

Bram Blaauwendraad and his colleague Gaurav Raina (Bureau Veritas) are keynote speakers at the D&E event. You can register for the event free of charge at: fhi.nl/dene.