Secure by Design vs. Secure by Default: What This Actually Means Under the CRA
Secure by design and secure by default are two separate obligations under the Cyber Resilience Act, not two names for the same requirement. Both sit inside Annex I, and meeting one does not automatically satisfy the other.
Secure by designcovers how your product gets built: the ARCHITECTURE decisions made during development.
Secure by default covers how your product arrives: the CONFIGURATION it ships with, before anyone touches a setting.
What’s the Difference Between Secure by Design and Secure by Default?
Secure by design is about the choices baked into your product while it’s being developed. It covers who gets access to what, which parts of the system talk to each other, how updates get delivered, and how the whole architecture behaves under attack. None of that shows up on a spec sheet, but it determines how hard your product is to compromise in the first place.
Secure by default is about the state your product is in the moment someone turns it on. A customer who never opens a settings menu should still end up reasonably protected. If reaching that baseline requires technical expertise the customer does not have, the product fails secure by default regardless of how well it was architected.
A product can get one right and still fail the other. Strong architecture does not fix a shared factory password, and a locked-down configuration does not fix a design that lets one compromised component take down the whole system.
What Do These Principles Look Like on My Product?
Deciding, during development, that only your own backend can write to the database is a secure by design choice. It shapes the architecture before a single unit ships.
Shipping a device that refuses to activate until the customer changes the factory password is a secure by default choice. It has nothing to do with how the software was built and everything to do with the state it arrives in.
Both examples solve real problems. The first limits what an attacker can do if a service gets compromised. The second closes the single most common entry point into connected devices: a password everyone already knows.
Where Do These Rules Actually Come From?
Article 13(2) of the CRA requires a cybersecurity risk assessment that feeds directly into your technical documentation, and Annex I sets out what that assessment has to achieve. Secure by design and secure by default both trace back to that same annex, expressed as separate essential requirements rather than a single combined one.
ENISA published the first practical playbook translating these principles into checklists built for small manufacturers in July 2026. Its Annex C maps 22 specific security principles directly to the CRA’s essential requirements, giving a concrete answer to a question the regulation itself leaves fairly abstract: what does secure by design actually require you to build.
What Can I Fix on My Product Right Now?
A handful of changes cover a large share of secure by default gaps without touching your architecture at all.
Remove any shared or factory-set password and require a unique one per device or account.
Encrypt communications starting from the very first connection, instead of adding encryption later.
Turn off any feature or service the product does not need by default, so the customer opts in rather than opts out.
Keep automatic security updates on by default, while still letting the customer postpone one if timing genuinely matters to them.
None of these require a redesign. They require deciding what state the product should be in before it leaves the factory.
Twenty-two principles sound like a lot, and they are not a checklist to clear in one pass. ENISA’s own guidance frames adoption as progressive: start with the changes that address your product’s actual risks, and build from there.
None of that changes what the CRA already requires by law. Progressive adoption means sequencing the work sensibly, not delaying obligations that already apply to your product.
Getting both obligations right takes more than an afternoon of configuration changes, though it does not require a dedicated security department either. If you are not sure which secure by design or secure by default gaps apply to your product, get in touch for a quote and we can walk through it together.
