CRA topic guide
Security by design under the CRA
Last updated · 8 Jun 2026
Security by design is the core idea of the EU Cyber Resilience Act: products with digital elements must be designed, developed and produced to be secure, based on the risks they carry - not patched into shape after launch. It is captured in the Annex I essential requirements and applies in full from 11 December 2027.
TL;DR
- Security by design means building in security from the first design decision, proportionate to the product's risk.
- It is the spine of Annex I, Part I - the essential cybersecurity requirements every in-scope product must meet.
- It starts with a cybersecurity risk assessment that drives every later design choice.
- Breaching the essential requirements carries the CRA's highest penalty tier: up to €15m or 2.5% of turnover.
Overview
What it is
Security by design is the practice of treating cybersecurity as a first-class design constraint throughout a product's lifecycle, rather than a feature added late. Under the CRA it is not a slogan: it is a set of concrete, testable product properties - minimal attack surface, protection of data in transit and at rest, secure default configuration, resilience against denial-of-service, and the ability to be updated securely. Crucially, the bar is "appropriate to the risks", so a hardware security module is held to a higher standard than a single-player game.
The regulation
What the CRA requires
- Annex I, Part I requires products to be "designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks".
- Manufacturers must perform and document a cybersecurity risk assessment (Art. 13) that informs design, development, production and vulnerability handling.
- Specific properties include: secure-by-default configuration; protection from unauthorised access (e.g. authentication); confidentiality and integrity of data; minimisation of attack surface; and the ability to mitigate the impact of incidents.
- The risk assessment must be included in the technical documentation (Annex VII).
How to comply
How to comply
- Run a documented cybersecurity risk assessment early - and revisit it as the product evolves.
- Map each Annex I, Part I property to a concrete design control and a test that proves it.
- Minimise the attack surface: disable unused services, ports and interfaces by default.
- Protect data: encrypt sensitive data in transit and at rest; authenticate and authorise access.
- Design for updateability so vulnerabilities can be fixed securely throughout the support period.
- Capture all of this in the technical documentation so conformity can be demonstrated.
Watch out
Common mistakes
- Doing a risk assessment once and never tying it to actual design decisions or tests.
- Applying a one-size-fits-all security level instead of scaling it to the product's real risk.
- Leaving debug interfaces, default credentials or open ports enabled in shipped products.
- Treating security by design and secure by default as the same thing - they are related but distinct requirements.
FAQ
Common questions
- Is security by design legally binding under the CRA?
- Yes. It is expressed through the Annex I, Part I essential requirements, which are mandatory for in-scope products from 11 December 2027. Non-compliance sits in the highest penalty tier.
- What does "appropriate to the risk" mean in practice?
- You must base the level of security on a documented risk assessment of the specific product and its intended use. Higher-risk products (important and critical categories) require correspondingly stronger measures and stricter conformity assessment.
- How is security by design different from secure by default?
- Security by design covers the whole way a product is built; secure by default is the narrower requirement that the product ships in a safe configuration out of the box. Both are CRA essential requirements.
Related guides
More CRA topic guides
SBOM
SBOM (Software Bill of Materials) under the CRA
An SBOM is an "ingredients label" for your software: a machine-readable inventory of components and dependencies.
Secure by default
Secure by default under the CRA
Secure by default means the out-of-the-box configuration is the safe configuration.
Secure software development
Secure software development under the CRA
A secure software development lifecycle (SDLC) is implied throughout the CRA's essential requirements.
This is guidance, not legal advice
Sources
- [1]European Commission - CRA legislative summaryretrieved 8 Jun 2026
- [2]Regulation (EU) 2024/2847 - full text (EUR-Lex)retrieved 8 Jun 2026
- [3]European Commission - Cyber Resilience Actretrieved 8 Jun 2026
The CRA Brief
Stay current on CRA guidance
We watch Brussels so you don't. Plain-English CRA updates, free.
No spam. Unsubscribe anytime.