The Cyber Resilience Act, Regulation (EU) 2024/2847, does not certify products against a standard. It requires every product with digital elements in scope to meet the essential cybersecurity requirements in Annex I, and it requires the manufacturer to show that it does, in a technical file, through whichever conformity assessment route the product's tier allows. Annex I is therefore the list that every other obligation hangs off: the risk assessment is a risk assessment against it, the technical documentation documents it, the notified body checks it.
It is two pages in the Regulation and it is worth having as one table. Here it is, with the reading that decides whether a requirement can be excluded.
The structure, and the one distinction that matters
Annex I has two parts.
Part I, "Cybersecurity requirements relating to the properties of products with digital elements." Point 1 is the general requirement: an appropriate level of cybersecurity given the risks. Point 2 lists thirteen specific properties, (a) to (m), and opens with the words "on the basis of the cybersecurity risk assessment referred to in Article 13(2) and where applicable". That phrase does the work. A Part I point 2 requirement can be left out of a product, but only on the basis of the risk assessment and with the justification written into the technical documentation. "We did not think about it" is not an exclusion.
Part II, "Vulnerability handling requirements." Eight requirements about what the manufacturer does over the product's support period, not about the product itself. None of them is "where applicable". They apply to every product in scope, including the smallest.
That distinction is the first thing to get right in a technical file, and it is the one the free scope determination does not cover, because it belongs to the product, not to the question of whether the Regulation applies.
Part I: properties of the product
| Reference | Requirement | What has to be true | Applies |
|---|---|---|---|
| Part I, point 1 | Appropriate level of cybersecurity by design | The product is designed, developed and produced to ensure a level of cybersecurity appropriate to the risks, based on the cybersecurity risk assessment. | always |
| Part I, point 2(a) | No known exploitable vulnerabilities at release | The product is made available on the market without known exploitable vulnerabilities. | where applicable |
| Part I, point 2(b) | Secure by default configuration | The product ships with a secure default configuration, including the possibility to reset it to its original state, unless otherwise agreed with a business user for a tailor-made product. | where applicable |
| Part I, point 2(c) | Security updates | Vulnerabilities can be addressed through security updates, including automatic updates by default with a clear opt-out and notification to users, where applicable. | where applicable |
| Part I, point 2(d) | Protection from unauthorised access | Appropriate control mechanisms, including authentication, identity and access management, and reporting of possible unauthorised access. | where applicable |
| Part I, point 2(e) | Confidentiality of data | Stored, transmitted or otherwise processed data, personal or other, is protected, for instance by encryption at rest and in transit using state-of-the-art mechanisms. | where applicable |
| Part I, point 2(f) | Integrity of data, commands and configuration | Stored, transmitted or processed data, commands, programs and configuration are protected against manipulation or modification not authorised by the user, and corruptions are reported. | where applicable |
| Part I, point 2(g) | Data minimisation | Only data that is adequate, relevant and limited to what is necessary for the intended purpose is processed. | where applicable |
| Part I, point 2(h) | Availability of essential and basic functions | Essential and basic functions remain available, also after an incident, including resilience and mitigation against denial-of-service attacks. | where applicable |
| Part I, point 2(i) | No negative impact on other devices and networks | The product minimises its own negative impact on the availability of services provided by other devices or networks. | where applicable |
| Part I, point 2(j) | Limited attack surface | Attack surfaces, including external interfaces, are limited. | where applicable |
| Part I, point 2(k) | Reduced impact of incidents | The impact of an incident is reduced using appropriate exploitation mitigation mechanisms and techniques. | where applicable |
| Part I, point 2(l) | Security logging and monitoring | Security-related information is provided by recording and monitoring relevant internal activity, including access to or modification of data, services or functions, with an opt-out for the user. | where applicable |
| Part I, point 2(m) | Secure and easy removal of data and settings | Users can securely and easily remove all data and settings permanently, and where data can be transferred to another product, this happens securely. | where applicable |
Part II: vulnerability handling
| Reference | Requirement | What has to be true |
|---|---|---|
| Part II, point 1 | Identify and document vulnerabilities and components, with an SBOM | Vulnerabilities and components in the product are identified and documented, including a software bill of materials in a commonly used machine-readable format covering at least the top-level dependencies. |
| Part II, point 2 | Remediate vulnerabilities without delay | Vulnerabilities are addressed and remediated without delay, including by providing security updates; where technically feasible, security updates are separate from functionality updates. |
| Part II, point 3 | Regular testing and review | Effective and regular tests and reviews of the product's security are applied. |
| Part II, point 4 | Disclose fixed vulnerabilities | Once a security update is available, information about fixed vulnerabilities is shared and publicly disclosed: description, affected products, impacts, severity, and how users remediate; disclosure may be delayed where the security risk of publishing outweighs the benefit. |
| Part II, point 5 | Coordinated vulnerability disclosure policy | A policy on coordinated vulnerability disclosure is put in place and enforced. |
| Part II, point 6 | A contact for reporting vulnerabilities | Sharing information about potential vulnerabilities is facilitated, including a contact address for reporting vulnerabilities discovered in the product. |
| Part II, point 7 | Secure and timely distribution of updates | Mechanisms exist to securely distribute updates so that vulnerabilities are fixed or mitigated in a timely manner, and, where applicable to security updates, automatically. |
| Part II, point 8 | Free security patches with advisories | Security patches or updates are disseminated without delay and, unless otherwise agreed for a tailor-made product, free of charge, accompanied by advisory messages giving users the relevant information, including on potential action to take. |
Reading the list
The words are paraphrased; the references are not. The "what has to be true" column is our plain-language reading of each point, kept short. Classify against the Regulation's wording, which the references let you find in seconds, and quote it in the file.
Part II presumes four documents exist. A coordinated vulnerability disclosure policy (point 5), a public contact for reporting (point 6), a software bill of materials (point 1) and a way to distribute updates securely and free of charge (points 7 and 8). Most small manufacturers have none of the four written down. They are not hard to write; they are hard to remember to write before someone asks.
"Without known exploitable vulnerabilities" is a state at release, not a promise. Part I, point 2(a) is about the moment the product is made available. What happens after that is Part II, and the Article 14 reporting duty, in force since 11 September 2026, sits on top of it for vulnerabilities that are actively exploited.
The support period is part of the answer. Article 13(8) requires the manufacturer to determine a support period during which Part II is delivered, of at least five years unless the product is expected to be in use for less, and to state it. A file that lists the Part II requirements without saying for how long is incomplete.
Exclusions are an argument, not a tick. For each Part I, point 2 requirement you do not implement, the file needs the risk assessment's reason. A notified body, or a market surveillance authority once your member state has named one, will read those reasons before anything else.
What to do with it
For each product in scope, one row per requirement: implemented, how, and where the evidence is; or excluded, on the basis of which risk-assessment finding. Twenty-two rows. That table, with the tier and the scope determination in front of it, is most of a technical file's spine, and it is the table the December 2027 deadline is really about.
Sources
- Regulation (EU) 2024/2847, Annex I Parts I and II; Article 13(2) for the risk assessment the "where applicable" refers to; Article 13(8) for the support period; Article 31 and Annex VII for the technical documentation; Article 71(2) for the dates.
- The Commission's technical FAQ on the CRA, version 1.3 of 1 July 2026, on exclusions from Part I, point 2.
This is not legal advice. The references are there so you can read each requirement in the Regulation and decide for your own product.