Security by Design
The EU Cyber Resilience Act (CRA) makes security by design a legal requirement for all digital products. Unlike vague industry buzzwords, the law mandates that manufacturers assess risks and build security into the architecture from the outset. Failure to do so can lead to costly recalls, as seen i…
The European Union’s Cyber Resilience Act (CRA) is set to reshape how manufacturers build digital products. Rather than treating security as an afterthought, the law requires that every product with digital elements be designed, developed and produced with an appropriate level of cybersecurity based on a risk assessment. This is not a marketing slogan – it is a binding legal obligation that will come into force on 11 December 2027, with vulnerability reporting starting 11 September 2026.
What the CRA Actually Demands
Annex I, Part I, point 1 of the CRA states: “Products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks.” The language is clear and non‑negotiable. Unlike the later points that list specific controls – such as secure boot, secure OTA updates, network segmentation and a software bill of materials – point 1 applies to every product, regardless of risk class. It is a procedural requirement: the design process itself must be risk‑driven.
Point 2 of the same annex provides a concrete checklist of controls that must be applied “on the basis of the cybersecurity risk assessment… and where applicable.” If a control does not apply, manufacturers must document why. Point 1, however, has no “where applicable” qualifier, making it universal. It is the only requirement that cannot be waived by claiming irrelevance.
Why Timing Matters
Design decisions that shape whether a product meets point 1 are made years before the 2027 deadline, not months. Waiting until the last minute to think about security is too late; the architecture will already be locked in. This contrasts sharply with the current industry practice of building a functional product first and then adding security layers on top. That “bolt‑on” approach often fails, as demonstrated by the 2015 Jeep Cherokee hack, where an infotainment system that lacked proper network segmentation allowed attackers to commandeer the vehicle’s brakes and steering from a remote location.
The Jeep incident forced Fiat Chrysler to recall 1.4 million vehicles. The fix required a fundamental redesign of how the infotainment system communicated with the vehicle’s safety‑critical network – a change that could not be achieved with a simple patch.
Security by Design in Practice
For embedded and IoT devices, security by design translates into specific engineering choices that must be made early:
- Secure boot – The device verifies the firmware’s digital signature before execution, preventing unauthorized code from running.
- Software Bill of Materials (SBOM) – A machine‑readable list of all software components, enabling manufacturers to track vulnerabilities in third‑party libraries.
- Secure OTA updates – Firmware update channels that are themselves protected against tampering, ensuring that updates cannot become an attack vector.
- Network and system segmentation – Clear boundaries between subsystems, limiting attack surfaces and preventing a compromised component from reaching critical controls.
These decisions are not optional add‑ons; they are integral to the product’s architecture. Implementing them after hardware is finalized can require costly redesigns or recalls.
Common Pitfalls
Manufacturers often treat the CRA as a simple checklist, ticking boxes without assessing whether each control is relevant to their specific threat landscape. This approach can lead to two problems:
- Resources are wasted on unnecessary controls that do not mitigate real risks.
- Superficial compliance is achieved while deeper architectural gaps remain, as was the case with the Jeep infotainment system.
Point 1 forces a risk‑based approach. Under Article 13(2), manufacturers must conduct a risk assessment before deciding which controls apply. Skipping this step defeats the purpose of the CRA and can expose products to preventable attacks.
FAQs
Is security by design the same as security by default? No. Security by design refers to the process of embedding security into the architecture. Security by default, defined in point 2(b) of Annex I, means the product ships with secure settings out of the box.
Does the CRA apply to hardware, software, or both? Both. The regulation covers any product with digital elements, including hardware, firmware, and software components.
What if part of the firmware is outsourced? Responsibility remains with the manufacturer that places the product on the EU market. Security‑by‑design decisions must be specified and reviewed at the point of outsourcing.
Will building security in from day one slow the project? Not if it is done during architecture and threat modelling, before code is written. A focused risk assessment typically takes days and results in a concise list of architectural decisions that become part of the specification.
In short, the CRA turns a best‑practice recommendation into a legal requirement, forcing manufacturers to think about security at the very beginning of the design process. Those who do not will face costly recalls, regulatory fines, and reputational damage.
Why it matters
The CRA’s security‑by‑design mandate protects consumers and businesses from the escalating costs of cyberattacks, which the EU estimates at €75 billion annually. Early design decisions can prevent costly recalls like the Jeep hack and ensure compliance with a law that will be enforceable in 2027.
Key points
- CRA makes security‑by‑design a legal requirement for all digital products.
- Point 1 applies universally; it cannot be waived or ignored.
- Risk assessment must precede any control implementation.
- Early architectural decisions prevent costly redesigns and recalls.
- Checklist‑only approaches can miss deep security gaps.
- Secure boot, SBOM, OTA updates, and segmentation are core engineering choices.
Frequently asked questions
Is security by design the same as security by default?
No. Security by design refers to the process of embedding security into the architecture, while security by default means the product ships with secure settings out of the box.
Does the CRA apply to hardware, software, or both?
Both. The regulation covers any product with digital elements, including hardware, firmware, and software components.
What if part of the firmware is outsourced?
Responsibility remains with the manufacturer that places the product on the EU market. Security‑by‑design decisions must be specified and reviewed at the point of outsourcing.
Will building security in from day one slow the project?
Not if it is done during architecture and threat modelling, before code is written. A focused risk assessment typically takes days and results in a concise list of architectural decisions.
