Provetry
FRDEGet early access
Free check
Get early access

Provetry opens in November 2026. The free CRA check, the tools and the guides are available now.

CRA Annex I: the essential requirements, one by one

12 min read

On this page
  1. Start with the risk assessment
  2. Part I: security properties of the product
  3. Part II: vulnerability handling
  4. How to show you meet them
  5. How Provetry helps
  6. Sources

Annex I of the Cyber Resilience Act lists what every product with digital elements must achieve to be sold in the EU from 11 December 2027. It has two parts: Part I, the security properties of the product itself, and Part II, the way the manufacturer handles its vulnerabilities over the support period.

The requirements are written as outcomes, not techniques. Harmonised standards will describe recognised ways to meet them; until they are cited in the Official Journal, you show conformity by explaining the solutions you chose in your technical documentation. Use this guide as a checklist: for each requirement, note how your product meets it, or why it does not apply.

Start with the risk assessment

Article 13 asks you to assess the cybersecurity risks of the product before anything else, and to keep that assessment up to date for the support period. It decides how each Part I requirement applies to your product: the whole list (a) to (m) is introduced by “on the basis of the cybersecurity risk assessment” and “where applicable”. A requirement you consider not applicable must be clearly justified in the risk assessment itself, which belongs in the technical file.

Part I: security properties of the product

The first requirement is general: products must be designed, developed and produced to ensure an appropriate level of cybersecurity based on the risks. Then, on the basis of the risk assessment and where applicable, the product must:

(a) Ship without known exploitable vulnerabilities

No vulnerability that you know of and that can be exploited may remain when the product is placed on the market. In practice: scan the components of each release against vulnerability databases before shipping, and record why any remaining finding cannot be exploited (a VEX statement).

(b) Be secure by default

The product comes with a secure configuration out of the box, unless otherwise agreed with a business user for a tailor-made product, and the user can reset it to its original state. No default passwords shared across devices, unnecessary services off, debug interfaces closed.

(c) Receive security updates

Vulnerabilities must be fixable through security updates, including, where applicable, automatic updates installed within a reasonable time and on by default, with a clear way to opt out. Users are told when an update is available and can postpone it for a while.

(d) Protect against unauthorised access

Authentication, identity and access management appropriate to the product, and a report when unauthorised access may have occurred. Think brute-force protection, per-device credentials, least privilege.

(e) Protect confidentiality

Data the product stores, sends or processes, personal or not, is kept confidential: encryption at rest and in transit with current algorithms, and other technical means where needed.

(f) Protect integrity

Data, commands, programs and configuration are protected against manipulation or modification the user has not authorised, and corruption is reported. Signed firmware and signed updates, verified boot, checked configuration.

(g) Minimise data

Only the data that is adequate, relevant and limited to what the product’s intended purpose needs is processed.

(h) Keep essential functions available

Essential and basic functions stay available, including after an incident, with resilience and mitigation against denial-of-service attacks.

(i) Do not harm others

The product limits the negative impact that it, or devices connected to it, has on the availability of services provided by other devices or networks. A compromised device should not easily become part of a botnet flooding others.

(j) Limit the attack surface

Fewer exposed interfaces, fewer open ports, fewer components: the attack surface, including external interfaces, is kept to what the product needs.

(k) Reduce the impact of incidents

Exploitation mitigation mechanisms and techniques: memory-safe languages or hardening, sandboxing, privilege separation, so that one flaw does not give everything away.

(l) Record security events

The product provides security-related information by recording and monitoring relevant internal activity, such as access to or modification of data, services or functions, with an opt-out for the user.

(m) Let users erase and move their data

Users can remove all data and settings securely and easily, permanently, and, where data can be transferred to other products or systems, do so securely.

Part II: vulnerability handling

These requirements apply when the product is placed on the market and for the whole support period. Manufacturers must:

1. Know what is inside

Identify and document the vulnerabilities and components contained in the product, including by drawing up a software bill of materials in a commonly used, machine-readable format covering at least the top-level dependencies. See What is an SBOM? and the SBOM for the CRA.

2. Fix without delay

Address and remediate vulnerabilities without delay, in relation to the risks they pose, including by providing security updates. Where technically feasible, security updates are provided separately from functionality updates, so users are not forced to take new features to get a fix.

3. Test regularly

Apply effective and regular tests and reviews of the security of the product: code review, dependency scanning, penetration tests, fuzzing, chosen according to the risks.

4. Publish what was fixed

Once a security update is available, share and publicly disclose information about the fixed vulnerabilities: a description, the affected products, the impact and severity, and clear information helping users to remediate. In duly justified cases, when the security risks of publishing outweigh the benefits, publication may wait until users have had the chance to apply the patch. Machine-readable security advisories (CSAF) are the usual way.

5. Have a disclosure policy

Put in place and enforce a coordinated vulnerability disclosure policy. Our free disclosure policy generator writes one from your answers.

6. Be reachable

Take measures to facilitate the sharing of information about potential vulnerabilities in the product and its third-party components, including by giving a contact address for reporting them. A security.txt file is the standard way to publish it.

7. Distribute updates securely

Provide mechanisms to distribute updates securely, so vulnerabilities are fixed or mitigated in a timely manner and, where applicable for security updates, automatically.

8. Make fixes free and explained

Disseminate security updates without delay and, unless otherwise agreed with a business user for a tailor-made product, free of charge, with advisory messages telling users what they need to know and what to do.

How to show you meet them

For each requirement, the technical documentation (Annex VII) should say how it is met: the design choice, the test, the standard or the process, and where the evidence is. Keep it per product and per release:

  • the risk assessment and its conclusions requirement by requirement;
  • the SBOM of every release, and the vulnerabilities found with your decisions;
  • test reports;
  • the disclosure policy, the contact point and the advisories you published;
  • how updates are built, signed and distributed.

Harmonised standards will make this easier once they are cited: following them gives a presumption of conformity. Until then, the draft standards of the EN 40000 series, such as prEN 40000-1-3 on vulnerability handling, are a good guide to what auditors will look for.

How Provetry helps

Provetry covers most of Part II for you: an SBOM for every release, daily matching against new and exploited vulnerabilities, VEX decisions, your disclosure policy and security.txt, CSAF advisories and the reporting clock. Its compliance dossier walks through Part I requirement by requirement and keeps the answers in your technical file.

This guide is general information, not legal advice.

Sources