CRA Annex I explained: essential cybersecurity requirements in plain English
Annex I of the Cyber Resilience Act is the technical heart of the law. Part I says what a product must be like: secure by default, updatable, free of known exploitable vulnerabilities, protected against unauthorised access and tampering. Part II says what the manufacturer must do for the whole support period: keep an SBOM, fix vulnerabilities quickly, run a disclosure policy and ship free security updates. Both apply from 11 December 2027.
Below, each point is paraphrased, followed by what it usually means for an embedded device. Back to the Cyber Resilience Act hub.
Part I – requirements for the product
Point (1) – Products must be designed, developed and produced to ensure an appropriate level of cybersecurity based on the risks. This is why the cybersecurity risk assessment (Art. 13(2)) comes first: it decides how the points below apply.
Point (2) – On the basis of that risk assessment, and where applicable, products must:
| Point | Plain-English meaning | Typical firmware evidence |
|---|---|---|
| (a) No known exploitable vulnerabilities | Do not ship with publicly known vulnerabilities that can be exploited in your product | SBOM-based vulnerability scan of the release build, VEX for “not affected” decisions |
| (b) Secure by default, with reset | Safe out of the box; user can reset to the original secure state | No shared default passwords, services off unless needed, factory reset |
| (c) Fixable through security updates | Vulnerabilities can be fixed by updates; automatic updates on by default where applicable, with opt-out, notification and postponement | Signed OTA, update settings in the UI or app |
| (d) Protection from unauthorised access | Authentication and access control; report possible unauthorised access | Unique credentials, brute-force limits, admin access logging |
| (e) Confidentiality | Encrypt relevant data at rest and in transit with state-of-the-art mechanisms | TLS with current ciphers, encrypted credential storage, no hard-coded keys |
| (f) Integrity | Protect data, commands, programs and configuration against unauthorised modification; report corruption | Secure boot, signed firmware and configuration, authenticated APIs |
| (g) Data minimisation | Process only data needed for the intended purpose | Review telemetry and cloud uploads |
| (h) Availability of essential functions | Keep basic functions working, including after an incident and under denial-of-service | Watchdogs, rate limiting, safe fallback modes |
| (i) Do not harm others | Minimise the product’s negative impact on other devices and networks | Outbound rate limits, no open relays or reflectors |
| (j) Limit attack surface | Reduce exposed interfaces, including external ones | Disable telnet, debug UART/JTAG, unused ports and test endpoints |
| (k) Exploit mitigation | Reduce the impact of an incident with exploitation mitigation techniques | Stack canaries, NX, ASLR, privilege separation, hardened build flags |
| (l) Security logging | Record and monitor relevant internal activity such as access or changes, with user opt-out | Log of logins, configuration and firmware changes |
| (m) Secure deletion and transfer | Let users permanently remove all data and settings; transfer data securely where supported | Full wipe on reset, secure export |
Two practical notes:
- “Where applicable” is not an exemption by default. If a point does not apply, say why in the risk assessment, which becomes part of the technical documentation (Annex VII).
- Tailor-made business products can deviate from secure-by-default and free updates only where agreed between manufacturer and business user, as stated in points (b) and Part II (8).
Part II – vulnerability handling duties of the manufacturer
These apply for the support period, which is at least five years unless the product’s expected use time is shorter (Art. 13(8)).
| Point | Plain-English meaning | What to set up |
|---|---|---|
| (1) Identify components, keep an SBOM | Document vulnerabilities and components, including an SBOM in a common machine-readable format covering at least top-level dependencies | SBOM per firmware version in CycloneDX or SPDX; see firmware SBOM |
| (2) Fix without delay | Address and remediate vulnerabilities without delay, including through security updates; separate security and feature updates where technically feasible | Patch process with target times by severity |
| (3) Test regularly | Apply effective, regular security tests and reviews | Fuzzing, code review, penetration tests on each major release |
| (4) Disclose fixed vulnerabilities | After a fix is out, publish a description, affected products, impact, severity and remediation advice; delay is allowed only in justified cases until users could patch | Public security advisories page |
| (5) CVD policy | Put in place and enforce a coordinated vulnerability disclosure policy | Published policy: see our VDP template |
| (6) Make reporting easy | Facilitate sharing of vulnerability information, including for third-party components, with a contact address | security.txt, security@ address, PGP key |
| (7) Secure update distribution | Mechanisms to distribute updates securely and in a timely way, automatically where applicable for security updates | Signed update server, integrity checks, rollback protection |
| (8) Free updates with advisories | Disseminate available security updates without delay and free of charge (unless agreed otherwise for tailor-made products), with advisory messages | Release notes that state the security impact and user action |
How Annex I connects to the rest of the CRA
- Article 13 makes Annex I binding on manufacturers and adds the support period, the 10-year availability of updates and the single point of contact.
- Article 14 adds the 24-hour reporting duty on top of Part II. See CRA 24h/72h reporting.
- Annex II lists the information you must give users, such as the support end date and where to report vulnerabilities.
- Annex VII lists the technical documentation, which must show how each Annex I point is met and include the SBOM and the CVD policy.
- Harmonised standards will give a presumption of conformity with Annex I once their references are published in the Official Journal; publication dates are (to be confirmed).
Where firmware projects usually fall short
In our experience the hardest points for devices built on vendor SDKs are Part I (2)(a) (known vulnerabilities in an old kernel or TLS library), (2)(f) (no secure boot on the chosen chip) and Part II (2) (no way to rebuild and ship a fix). These are design and supply-chain questions, so start them first.
Softwsp maps your firmware against each Annex I point and fixes what can be fixed at firmware level: device firmware security. For a task list, see the CRA checklist for device makers.
This guide is general information, not legal advice.
Frequently asked questions
What is Annex I of the Cyber Resilience Act?
Annex I lists the essential cybersecurity requirements. Part I covers the properties of the product itself; Part II covers how the manufacturer handles vulnerabilities during the support period.
Does every Annex I requirement apply to every product?
Part I point (1) always applies. The points under Part I (2) apply on the basis of the cybersecurity risk assessment and 'where applicable', so you justify in the technical documentation why a point does not apply. Part II applies to all manufacturers.
Does Annex I require an SBOM?
Yes. Part II point (1) requires a software bill of materials in a commonly used, machine-readable format covering at least the top-level dependencies. It goes into the technical documentation; publishing it to users is optional.
Are automatic updates mandatory?
Where applicable, automatic security updates must be enabled by default with a clear opt-out and the option to postpone. Security updates must also be free of charge, except where agreed otherwise for tailor-made business products.