The CRA essential cybersecurity requirements
Short answer. Annex I is two lists doing two different jobs. Part I is about the product — thirteen properties it must have. Part II is about you — eight processes you must run for the whole support period.
And one difference matters more than any individual requirement: Part I is qualified by your own risk assessment. Part II is not.
Almost every summary of the Cyber Resilience Act you will read presents Annex I as a single checklist of twenty-one items. That framing is what leads manufacturers to treat all twenty-one the same way, and then to be surprised by which ones an assessor actually pushes on.
The shape of Annex I
| Part I | Part II | |
|---|---|---|
| Heading | Cybersecurity requirements relating to the properties of products with digital elements | Vulnerability handling requirements |
| Subject | The product | The manufacturer's processes |
| Items | A chapeau in point 1, then thirteen lettered requirements (a)–(m) in point 2 | Eight numbered requirements |
| Qualified by your risk assessment? | Yes — point 2 opens “on the basis of the cybersecurity risk assessment … and where applicable” | No — it reads “Manufacturers of products with digital elements shall” |
| Runs for how long? | Assessed at placing on the market, maintained through conformity | Placing on the market and the whole support period, per Article 13(8) |
That last row is the one that changes how a business is run rather than how a product is built. Part I is something you can finish. Part II is something you operate.
The chapeau, which is the real requirement
Annex I Part I point 1 reads, in full:
Products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks.
One sentence, no sub-points, and it is the requirement most likely to decide an argument. The thirteen lettered requirements in point 2 are specific and testable; the chapeau is the general one, and it is not discharged by working through the thirteen. A product can plausibly satisfy (a) to (m) and still not ensure an appropriate level of cybersecurity based on its particular risks.
Practically, this is why the reasoning in your risk assessment carries more weight than the conclusions. “Appropriate” and “based on the risks” are both relative to your product, and the only way to show they are satisfied is to show the risks you identified and what you did about them.
Part I: the thirteen product properties
Point 2 of Part I lists thirteen requirements, (a) through (m). Read in the Official Journal they are considerably more specific than most summaries make them sound — several carry conditions and carve-outs inside the requirement itself.
| What it requires | Worth noticing | |
|---|---|---|
| (a) | Made available without known exploitable vulnerabilities | “Known” and “exploitable”. Not vulnerability-free — which is why the SBOM and your triage process matter as evidence |
| (b) | Secure by default configuration, including the possibility to reset to the original state | Carries an express exception for a tailor-made product agreed with a business user |
| (c) | Vulnerabilities addressable through security updates — where applicable automatic, on by default, with a clear opt-out, notification of available updates, and the option to postpone temporarily | The longest requirement in the list, and four distinct features hide inside it |
| (d) | Protection from unauthorised access by appropriate control mechanisms, and reporting on possible unauthorised access | The reporting half is routinely missed. Access control alone does not satisfy (d) |
| (e) | Confidentiality of stored, transmitted or processed data, “such as by encrypting relevant data at rest or in transit by state of the art mechanisms” | Encryption is given as an example, not as the sole means |
| (f) | Integrity of data, commands, programs and configuration against unauthorised manipulation, and reporting on corruptions | Again a reporting limb, again easy to skip |
| (g) | Data minimisation — process only what is adequate, relevant and limited to the intended purpose | Applies to “personal or other” data, so it is broader than the GDPR principle it echoes |
| (h) | Availability of essential and basic functions, also after an incident, including resilience against denial-of-service | “Essential and basic functions” is your definition to make and defend |
| (i) | Minimise negative impact on the availability of services provided by other devices or networks | The anti-botnet requirement. About what your product does to everyone else |
| (j) | Limit attack surfaces, including external interfaces | Designed, developed and produced — build and shipping configuration both count |
| (k) | Reduce the impact of an incident using appropriate exploitation mitigation mechanisms and techniques | Hardening. Naming the specific mitigations you use is the whole answer here |
| (l) | Provide security-related information by recording and monitoring relevant internal activity, with an opt-out for the user | Logging is required; so is letting the user switch it off |
| (m) | Let users securely and permanently remove all data and settings, and where data can be transferred, ensure that is done securely | Secure erase plus secure export. Two features, one letter |
Two patterns are worth pulling out, because they account for most of the gaps we see. First, three requirements have a reporting or user-facing limb — (d), (f) and (l) — and a product that implements the protective half without the informational half does not meet them. Second, several letters are two requirements wearing one label: (c) has four features in it, (m) has two.
Part II: the eight processes
Part II opens flatly: “Manufacturers of products with digital elements shall”. There is no risk-assessment qualifier and no “where applicable”. All eight apply.
- Identify and document vulnerabilities and components, including by drawing up a software bill of materials in a commonly used, machine-readable format covering at the very least the top-level dependencies.
- Address and remediate vulnerabilities without delay, including by providing security updates; where technically feasible, security updates are to be provided separately from functionality updates.
- Apply effective and regular tests and reviews of the security of the product.
- Publicly disclose fixed vulnerabilities once an update is available, with a description, identification information, impacts, severity and remediation guidance — with a limited right to delay publication in duly justified cases.
- Put in place and enforce a coordinated vulnerability disclosure policy.
- Facilitate information sharing about potential vulnerabilities, including by providing a contact address for reports.
- Provide mechanisms to securely distribute updates, automatically where applicable for security updates.
- Disseminate available security updates without delay and free of charge, with advisory messages telling users what to do.
Requirement 8 deserves a note. Security updates must be free of charge, and the only exception in the text is where a manufacturer and a business user have agreed otherwise in relation to a tailor-made product. A paid security-update tier for an ordinary commercial product is not compatible with Part II point 8.
Each of these eight is covered in more detail in the eight vulnerability-handling requirements.
Why “where applicable” is not a way out
Part I point 2 is introduced by these words:
On the basis of the cybersecurity risk assessment referred to in Article 13(2) and where applicable, products with digital elements shall …
Read quickly, that looks like discretion. Read properly, it moves the burden. The requirements apply as your risk assessment determines they apply, and Article 13(3) then says the risk assessment must indicate whether and, if so in what manner, the Part I point 2 requirements are applicable to your product and how they are implemented.
So the regulation anticipates that some of the thirteen will not apply, and requires you to say which and why. A blank is not an answer; neither is a tick. This is precisely why the risk assessment carries more weight than its length suggests — it is the document in which the applicability of thirteen requirements is settled.
The standards that would make this easier do not exist yet
Article 27(1) provides that a product conforming to a harmonised standard whose reference has been published in the Official Journal is presumed to conform to the Annex I requirements that standard covers. That is the normal European mechanism: the standard turns an abstract requirement into a testable one.
For the CRA, those references have not been published. Article 27(2) lets the Commission adopt common specifications instead, but only where a standardisation request has failed and no reference is expected within a reasonable period — so that route is a fallback, not a parallel option. Article 27(8) gives a third route: an EU statement of conformity or certificate under a European cybersecurity certification scheme adopted under Regulation (EU) 2019/881, again only in so far as it covers the Annex I requirements.
The practical consequence today is blunt. With nothing to cite, your own reasoning is the whole of your argument, which is a good reason to write it as though somebody will read it adversarially. See the dates and the standards timeline for where that work has got to.
Where the twenty-one duties become documents
Annex I is a list of requirements, not a list of deliverables. The deliverables come from elsewhere in the regulation, and each one draws on a different slice of Annex I.
| Document | Required by | Which part of Annex I it carries |
|---|---|---|
| Cybersecurity risk assessment | Article 13(2)–(3), Annex VII point 3 | Part I, point 1 and all of point 2 — including applicability |
| Technical documentation | Article 31, Annex VII | Evidence for Part I and Part II together |
| EU declaration of conformity | Articles 13(12), 28, Annex V | The assertion that the applicable Part I and Part II requirements are met |
| Software bill of materials | Annex I Part II point 1 | Part II, point 1 |
| Coordinated vulnerability disclosure policy | Annex I Part II point 5 | Part II, points 4, 5 and 6 |
| Information and instructions for users | Article 13(18), Annex II | Where Part I properties are disclosed to the person using them |
When all of this binds
Article 71(2) sets the dates. The Regulation applies from 11 December 2027; Article 14 — the reporting duties — has applied since 11 September 2026; and Chapter IV, on conformity assessment bodies, since 11 June 2026.
For products already on the market, Article 69(2) is the provision that matters: products placed on the market before 11 December 2027 only become subject to the requirements in the Regulation if, from that date, they undergo a substantial modification. But note Article 69(3): by way of derogation from that, the Article 14 reporting obligations apply to products placed on the market before 11 December 2027 anyway. Your existing fleet is outside Annex I and inside the reporting regime, today.
An honest note on our own confidence. The wording of Annex I Parts I and II, Article 27, Article 71(2) and Article 69 we have read directly in the Official Journal and are confident of. The interpretive claims — that the point 1 chapeau is a free-standing requirement not discharged by satisfying (a) to (m), and that requirement 8's free-of-charge rule prevents a paid security-update tier — are our reading of the text, not statements from the Commission or any authority, and a lawyer might put them differently. Nothing here is legal advice.
Twenty-one requirements, one reasoned answer each
Answer the questionnaire once and get the risk assessment, technical documentation, declaration of conformity and disclosure policy generated from those answers — each requirement addressed by name, each citation to the Article or Annex it comes from, every version kept and dated.
Not sure the regulation applies to what you sell? Take the two-minute check first.