Ask a manufacturer what "security by design" means and you get something abstract: we think about security early, we do not bolt it on at the end. It is one of those phrases that gets used everywhere and defined nowhere. Under the CRA, it is not a phrase. It is the first requirement in Annex I, and it is worded so there is no way around it.
For the full regulation, see our complete guide to the EU Cyber Resilience Act.
What the requirement actually says
Annex I, Part I, point 1 of the CRA reads:
"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 stakes behind that sentence are not abstract. When the Commission proposed the CRA, its own estimate was that data breaches cost EU businesses at least €10 billion a year, and disruption attacks at least €65 billion. One widely cited figure puts global cybercrime costs at €5.5 trillion annually. Numbers like that are why the law exists.
On its own, the requirement reads like the soft language regulations are full of. It starts to matter once you look at what comes next. Point 2 lists the concrete controls: no known exploitable vulnerabilities, secure by default configuration, update mechanisms, access control, on through to point (m). Every item on that list carries the same qualifier: "on the basis of the cybersecurity risk assessment... and where applicable." If a control does not apply to your product, you document why and move on.
Point 1 has no such qualifier. No "where applicable." It is the one requirement in Part I that applies to every product, every time, regardless of risk class. You cannot tell a regulator "that does not apply to us" the way you can with point 2. Point 1 is not about a technical control. It is about the approach you took building the product in the first place.
One thing first: Annex I is enacted but not yet legally applicable. It takes effect 11 December 2027. The only obligation that bites earlier is Article 14 vulnerability reporting, which starts 11 September 2026. No regulator can hold you to point 1 today. That does not change one fact: the architecture decisions that decide whether your product meets it get made years before the deadline, not months before. Wait for 2027 to start thinking about this, and you are already late.
Why this is different from adding security at the end
The pattern that still dominates hardware development: build a product that works, then add security as a layer on top. Encryption gets bolted on right before shipping. A password field gets added because a customer complained. It is a patch-on-top-of-a-foundation approach, and it shows.
Security by design flips the order. The question is not "how do we protect what we already built," it is "what threats does this product face, and what does the architecture need to look like to account for them from day one." That is not a cosmetic difference. Build security into the architecture from the start, and it shapes which chip you choose, how the firmware is structured, how the update process works. Add it at the end, and you are limited to whatever hardware and code you already have. Some things cannot be fixed without a redesign.
The clearest public example of what "cannot be fixed without a redesign" costs in practice is the 2015 Jeep Cherokee hack. Researchers Charlie Miller and Chris Valasek, working with Wired's Andy Greenberg, took remote control of a Jeep Cherokee's transmission and brakes from around ten miles away while Greenberg was driving it on a highway at 70 mph. The way in was Uconnect, the vehicle's cellular-connected infotainment system - added for convenience, never architected with any real separation from the CAN bus, the internal network that also carries commands to steering and braking. Once the researchers had code execution on the infotainment chip, nothing meaningful stood between that chip and the vehicle's safety-critical systems. Fiat Chrysler recalled 1.4 million vehicles. The fix was not a patch for a bug in the ordinary sense - it meant rethinking how the entertainment system was allowed to talk to the rest of the car. That is a network-segmentation decision that has to be made at the architecture stage. Retrofitting it after 1.4 million units are already on the road is a recall, not an update.
That is why point 1 covers the whole process - "designed, developed and produced" - not just the finished product. The regulation does not care only about the end result. It cares whether you accounted for risk at every stage.
What this looks like in practice for embedded and IoT products
The principle stays abstract until you see it applied. Here is what security by design means technically, for a connected device:
- Secure boot. The device checks the firmware's digital signature before running it, instead of trusting whatever code sits in memory. CRA never names secure boot, but it is the standard engineering answer to point 2(f): protect the integrity of code and configuration against unauthorised change. You decide this at the microcontroller stage. You cannot patch it in later. Our guide to secure boot for IoT devices covers the implementation.
- SBOM (Software Bill of Materials). A structured, machine-readable list of every software component in the product. Not a security control by itself. It is visibility: you cannot manage the risk of a component you do not know exists, and you cannot act on a new CVE against a library you forgot was in there. See our guide to SBOM requirements for IoT manufacturers for what the CRA requires.
- Secure OTA updates. A firmware update channel that is itself protected against tampering. An insecure update channel bypasses every other control on the device. Our guide to secure firmware updates walks through what that looks like done right.
- Network and system segmentation. Which subsystems are allowed to talk to which, and through what gateway. CRA names this directly at point 2(j): "limit attack surfaces, including external interfaces." It is exactly the decision Uconnect's designers got wrong - a convenience feature sat on the same logical network as safety-critical controls, with no enforced boundary between them. Segmentation is invisible when it works and catastrophic when it is missing, which is why it has to be a deliberate architecture decision, not something inferred after the fact from whatever the wiring happens to allow.
None of these four is a feature you switch on or off. They are engineering decisions that follow the same principle: risk gets built into the architecture at the design stage, not patched in after. It's the same sequence we run at Platanor on every embedded engagement: the risk assessment happens first, as its own deliverable, before a single line of firmware gets written - and what comes out of it is a short list of concrete architecture decisions, not a slide deck, that the rest of the team then builds against.
The mistake we see most often
The most common mistake: treating security by design as a checklist. A team takes the list of CRA requirements, goes item by item, and at each one asks "do we have this?" instead of "do we need this, given the real threats to this product?"
That is dangerous both ways. On one side, you spend resources defending against a threat that does not apply to your product. On the other, worse side, you "close" a checklist item with a superficial control that would not survive a real attack - and still pass self-assessment. Uconnect's engineering team could plausibly have satisfied a component-level checklist - encrypted storage here, an authentication field there - and still shipped exactly what shipped, because the actual gap was architectural: nothing on the checklist asked whether the infotainment system should be able to reach the CAN bus at all.
Point 1 exists to prevent this. It is written as "based on the risks" - a risk-based approach, not a checklist. The regulation expects you to run a risk assessment first, under Article 13(2), then decide which point 2 controls apply and to what extent. Checklist thinking skips that step and jumps straight to ticking boxes. That is what point 1 guards against.
FAQ
Is security by design the same thing as security by default? No, though the terms are related. Security by design is about process - how the product gets architected. Security by default is point 2(b) of Annex I: the product ships with secure settings out of the box, nothing extra to enable. The second is one expression of the first.
Does this apply to hardware, or software too? Both. Point 1 covers "products with digital elements" - hardware, firmware, software components, and how they interact.
Is there anything similar outside the CRA? Yes. NIST and ETSI EN 303 645, the consumer IoT baseline standard, use similar language about building in security from the design stage. The CRA makes the principle a legal requirement across the EU, for a broad range of products - not just a best-practice recommendation.
If part of the firmware is outsourced, who is responsible for meeting this requirement? The manufacturer placing the product on the EU market, per Article 13 - responsibility does not transfer to a subcontractor just because they wrote the code. In practice, that means security-by-design decisions need to be specified and reviewed at the point where you engage an outsourcing partner, not assumed to be handled implicitly somewhere downstream. A firmware team that treats security as part of the architecture discussion from the first specification - not something layered on once the product logic is done - is the difference between inheriting point 1 compliance and inheriting a redesign.
Our product is already in development, not at the design stage. Where do we start? Start with a risk assessment - the kind Article 13(2) asks for - applied to your current architecture, not a checklist of requirements. That shows you which gaps matter most, so you can prioritise, even where some architectural decisions can no longer change without a rework.
Does building this in from day one mean slowing the whole project down? Not if it happens where it belongs - during architecture and threat modelling, before code gets written, rather than as a parallel workstream competing with feature development. A focused risk assessment against Article 13(2) for a typical connected device usually takes days, not months, and the output is a short list of architecture decisions - network boundaries, what needs a secure element, what the update path looks like - that then become part of the spec everyone builds against. The delay comes from skipping this step, not from doing it: teams that skip it tend to make the same decisions anyway, just later, under worse conditions, with the hardware already committed.
Sources: CRA Regulation (EU) 2024/2847 - Annex I Part I, points 1 and 2(b) and 2(f), Article 13(2), Article 14, Article 71; ETSI EN 303 645 consumer IoT baseline standard; European Commission press release IP/22/5374 (15 September 2022) on the CRA proposal; Andy Greenberg, "Hackers Remotely Kill a Jeep on the Highway - With Me in It," Wired, 21 July 2015; CERT/CC vulnerability note VU#819439
Denys Zaliznyak is the CTO of Platanor. Platanor designs and implements the security architecture and documentation IoT and hardware manufacturers need to work toward CRA and RED requirements. platanor.com/contact