Annex I: the essential requirements, explained

Annex I is where the CRA stops being abstract. It sets out the essential cybersecurity requirements every in-scope product must meet, in two parts: Part I is about the security properties of the product itself, and Part II is about the processes a manufacturer must run to handle vulnerabilities over time. Crucially, the requirements are risk-based — you apply them in proportion to your product's cybersecurity risk assessment, so not every clause weighs the same for every product.

Part I — Security properties of the product

These describe how a well-secured product should behave. Paraphrased and grouped for clarity, a product should:

Be secure by design and by default

• Ship in a secure configuration out of the box, with the ability to reset to that secure state.
• Reduce the attack surface — expose only the interfaces and services actually needed.
• Not be released with known exploitable vulnerabilities.

Protect access and data

• Enforce authentication and access control appropriate to the product — for example, no shared default passwords, and protection of privileged functions.
• Protect the confidentiality of stored and transmitted data, typically with encryption where appropriate.
• Protect the integrity of data, commands, configuration and the software itself against unauthorised change.
• Practise data minimisation — process only the data necessary for the product's purpose.

Stay available and resilient

• Maintain availability of essential functions, including resilience against and mitigation of denial-of-service conditions.
• Limit the product's own ability to cause harm to the networks or devices around it.

Be observable and updatable

• Record and monitor relevant security-related events (logging), so problems can be detected and investigated.
• Provide security updates, where appropriate automatically, with a clear mechanism to deliver them safely — and let users remove or securely wipe data when they dispose of the product.

Part II — Vulnerability handling over the support period

Part II recognises that no product stays secure by itself. Over the product's support period, the manufacturer must run an ongoing process. Paraphrased, you must:

• Identify and document the vulnerabilities and components in your product — including producing a software bill of materials (SBOM) in a common, machine-readable format.
• Remediate without delay — address vulnerabilities promptly, including by providing security updates.
• Test and review the security of the product regularly.
• Once a fix is available, share information about fixed vulnerabilities, including a description, severity, and guidance for users.
• Operate a coordinated vulnerability disclosure (CVD) policy so researchers and others can report issues to you responsibly.
• Provide a contact point for reporting vulnerabilities and make it easy to find.
• Distribute updates securely and in a timely way, with mechanisms to ensure updates are authentic and, where relevant, that users are informed.

The SBOM connection

A software bill of materials is the thread that ties much of Part II together. If you do not know what components — and which versions — are inside your product, you cannot tell whether the latest disclosed vulnerability affects you, and you cannot demonstrate that you are managing that risk. A good SBOM lets you answer "are we affected?" in minutes rather than weeks, and it is increasingly what customers and auditors expect to see.

How manufacturers usually demonstrate compliance

Annex I states what must be achieved, not the exact how. In practice, manufacturers meet the requirements by leaning on recognised engineering practices and, where available, harmonised standards: following these gives a presumption of conformity for the parts they cover. (Note that formal standards documents are themselves copyrighted; you obtain them from the relevant standards bodies — this article describes the requirements in our own words, not the standards' text.)

This article paraphrases the requirements in plain language for orientation and is not legal advice. The binding wording is in Annex I of Regulation (EU) 2024/2847.