Requirements

Security by Design Under the CRA: What Annex I, Part I Actually Requires

Last updated · June 12, 2026

Security by design is one of those phrases that sounds meaningful until you have to explain what it means on a Monday morning with a sprint to ship. Under the EU Cyber Resilience Act (CRA), it has a precise legal meaning - and breaching it sits in the top penalty tier.

This guide unpacks what Regulation (EU) 2024/2847 actually demands, in plain English, so product managers and engineers can turn the text into real design decisions.

This article is general guidance, not legal advice. For advice specific to your product and situation, consult a qualified legal professional.

Key points

The CRA's main provisions apply in full from 11 December 2027. Products placed on the market before that date are only caught if they undergo a substantial modification afterwards.
Security by design is the obligation to build security in from the start - it lives in Annex I, Part I of the regulation.
The risk assessment required by Article 13 is the engine that drives every design decision. Without it, you cannot claim CE marking.
The bar is "appropriate to the risk" - not a fixed checklist, but a documented, proportionate response to the threats your product actually faces.
Breaching the essential requirements or Articles 13/14 carries fines of up to €15 million or 2.5% of worldwide annual turnover, whichever is higher.

What "security by design" means in the CRA

The phrase does not appear as a defined term in the regulation. What does appear - in Article 13(1) - is a clear obligation: when placing a product with digital elements on the market, manufacturers shall ensure that it has been designed, developed and produced in accordance with the essential cybersecurity requirements set out in Part I of Annex I.

That is security by design. It means security is integral to the product, not bolted on after the fact. The European Commission's own summary puts it plainly: the CRA establishes essential cybersecurity requirements that manufacturers need to comply with during the design, development and production of their products, as well as during the time those products are expected to be in use.

The regulation applies to any hardware or software product that can connect - directly or indirectly - to a device or network. That is a wide net.

The risk assessment that drives everything (Article 13)

Before you can implement the Annex I requirements, you need to know which of them apply to your product and how. That is the job of the cybersecurity risk assessment under Article 13(2).

The assessment must be taken into account across the entire lifecycle: planning, design, development, production, delivery, and maintenance. It is not a one-time document filed at launch. It must be updated when the product changes substantially.

The CRA does not mandate a specific methodology. Manufacturers can choose their own approach - STRIDE, attack trees, ISO/IEC 27005, whatever fits - as long as it is documented and defensible. What the regulation does require is that the assessment covers:

The product's intended purpose and reasonably foreseeable use
The operational environment and assets to be protected
Realistic threat actors and attack vectors
The likelihood and impact of exploitation

One important constraint: the adequacy of your security controls is judged against the product's risk profile, not your internal cost tolerance or commercial strategy. The Commission's draft guidance makes this explicit - commercial considerations are not relevant to whether the essential requirements are met.

The risk assessment then determines which of the Annex I, Part I(2) properties apply to your product and how they are implemented. If a requirement genuinely does not apply, you must include a clear justification in the technical documentation.

The Annex I, Part I requirements: what they actually say

Annex I is split into two parts. Part I covers product security properties - what the product itself must do. Part II covers vulnerability handling processes - what the manufacturer must do over the product's lifetime. This guide focuses on Part I.

Part I has two points. Point (1) is the overarching obligation: design, develop, and produce the product to ensure an appropriate level of cybersecurity based on the risks. Point (2) lists the specific properties that must be present on the basis of the risk assessment. Here is what each one means in practice.

No known exploitable vulnerabilities at launch

Products must be made available on the market without known exploitable vulnerabilities. This does not mean zero bugs - it means you must have tested, scanned, and remediated before shipping. Penetration testing, static analysis, and dependency audits are the practical tools here.

Minimal attack surface

Products must be designed, developed, and produced to limit attack surfaces, including external interfaces. In practice: disable unused ports and services by default, remove unnecessary features, and apply the principle of least privilege throughout the architecture. Every open interface is a potential entry point; the requirement is to keep that number as small as the product's function allows.

Access control and authentication

Products must ensure protection from unauthorised access by appropriate control mechanisms - authentication, identity management, access management - and must report on possible unauthorised access. The word "appropriate" matters: a consumer smart plug and an industrial control system face different threats and need different controls. Role-based access, multi-factor authentication, session timeouts, and brute-force lockouts are all relevant depending on the risk level.

Confidentiality and integrity of data

Products must protect the confidentiality of stored, transmitted, or otherwise processed data - personal or otherwise - such as by encryption. They must also protect the integrity of data, commands, programs, and configurations. In short: encrypt data in transit and at rest, validate inputs, and use message authentication where commands could be tampered with.

Resilience

Products must protect the availability of essential and basic functions, also after an incident, including through resilience and mitigation measures against denial-of-service attacks. The product should degrade gracefully, not catastrophically. It should also minimise the negative impact on the availability of services provided by other devices or networks - your product should not become a vector for attacking the infrastructure around it.

Secure updates

Products must ensure that vulnerabilities can be addressed through security updates, including - where applicable - through automatic security updates enabled as a default setting, with a clear and easy-to-use opt-out mechanism. The update mechanism itself must be authenticated and integrity-verified. Security updates must be provided free of charge across the support period, which is presumed to be at least five years unless a shorter use is expected.

Exploitation mitigation

Products must be designed to reduce the impact of an incident using appropriate exploitation mitigation mechanisms and techniques. Sandboxing, containerisation, privilege separation, and memory-safe languages all count here. The goal is containment: if an attacker gets in, they should not be able to take down the whole product.

Data minimisation and secure erasure

Products must process only data that is adequate, relevant, and limited to what is necessary. They must also provide users with the ability to securely and permanently remove all data and settings. Build data minimisation into the data model from the start, not as an afterthought.

Security by design vs. secure by default

These are related but distinct obligations. Security by design is about the architecture and the development process - it governs how the product is built. Secure by default is about the product's out-of-the-box configuration - it governs how the product ships.

A product can be well-architected (good security by design) but ship with a universal default password (failing secure by default). The CRA requires both. The secure-by-default requirements - no default passwords, minimal attack surface in the factory configuration, a reset-to-secure-state capability - sit in Annex I, Part I(2)(b) and are triggered by the same risk assessment.

A useful rule of thumb: security by design asks "how is this built?" — secure by default asks "what does the user get on day one?" Both are required. Neither substitutes for the other.

"Appropriate to the risk" - what that means in practice

The CRA is risk-based, but that does not make it optional or vague. The regulation is explicit: you cannot justify non-compliance by citing low risk. What you can do is apply proportionate protections and document them transparently.

A smart thermostat and an industrial control system both face the Annex I requirements, but the controls that satisfy those requirements will look very different. The thermostat might need TLS for data in transit and a forced password change on first use. The ICS might need hardware security modules, network segmentation, and formal threat modelling against nation-state actors.

The risk assessment is the document that justifies the gap between the two. Without it, you have no defence.

The penalty exposure

Breaching the essential requirements in Annex I, or the obligations in Articles 13 and 14, is the top penalty tier under Article 64: up to €15 million or 2.5% of worldwide annual turnover, whichever is higher.

This is not a theoretical risk. Market surveillance authorities in each Member State will have the power to require manufacturers to demonstrate conformity, withdraw non-compliant products, and impose fines. The fine ceiling is high enough that product security needs to be a board-level concern, not just an engineering one.

What to do now

The deadline is 11 December 2027, but the risk assessment needs to happen before design decisions are locked in - not the week before launch.

Confirm your product is in scope

Check whether your product connects to a device or network and is placed on the EU market commercially. Use the scope checker if you are unsure.

Run a cybersecurity risk assessment

Document your product's intended purpose, operational environment, threat actors, attack vectors, and the likelihood and impact of exploitation. Choose a methodology (STRIDE, ISO/IEC 27005, etc.) and stick to it. This document goes into your technical file.

Map the Annex I, Part I requirements to your product

For each of the Part I(2) properties, determine whether it applies and how you will implement it. If a requirement genuinely does not apply, write down why. Undocumented exclusions are not exclusions.

Build the controls into the architecture

Minimal attack surface, access control, encryption, resilience, and update mechanisms are architecture decisions. They are much cheaper to build in at design time than to retrofit after a conformity assessment flags them.

Check your secure-by-default configuration

Separately from the architecture, audit what the product looks like on day one. No universal default passwords, unnecessary services off, secure protocols enabled. See the secure by default guide for the full checklist.

Keep the risk assessment alive

Update it when the product changes substantially. A new feature that expands the attack surface, a new integration, a change in the operational environment — any of these may require a reassessment and updated technical documentation.

For a deeper look at the architecture principles behind these requirements, see the security by design guide. To stay current as the Commission publishes implementing acts and harmonised standards, subscribe to The CRA Brief - a short, plain-English digest of what changes and what it means for your product.