CRA Requirements: All 22 Essential Requirements of Annex I

Short answer: the requirements of the Cyber Resilience Act (Regulation (EU) 2024/2847) are the essential cybersecurity requirements of Annex I. Part I has 14 requirements for the product and Part II has 8 requirements for how you handle its vulnerabilities. They are the same for every product in scope, whatever its class, and they apply to products placed on the EU market from 11 December 2027.

Article 6 makes them the condition for selling at all: a product with digital elements may be made available on the market only if it meets Part I and the manufacturer's processes meet Part II. Everything else in the regulation, from the risk assessment to the CE marking, exists to show that these 22 requirements are met.

Part I: the 14 requirements for the product

Point 1 is the general rule: the product has to be designed, developed and produced to ensure an appropriate level of cybersecurity based on the risks. Point 2 then lists thirteen specific requirements that apply on the basis of the cybersecurity risk assessment and where applicable.

Point	What it asks for	Evidence that usually backs it
1	An appropriate level of cybersecurity based on the risks	The cybersecurity risk assessment and the design decisions it led to
2(a)	No known exploitable vulnerabilities when the product is made available	Vulnerability scan of the release against the SBOM, with every open finding triaged
2(b)	Secure by default configuration, with the option to reset to the original state	Default configuration list, no shared default passwords, reset procedure (security by default)
2(c)	Vulnerabilities can be fixed through security updates, automatic by default where applicable, with an opt-out and the option to postpone	Update architecture and settings (update requirements, secure update architecture)
2(d)	Protection from unauthorised access through authentication, identity or access management, and reporting of possible unauthorised access	Access control design, authentication tests, access event reporting
2(e)	Confidentiality of stored, transmitted and processed data, for example by state of the art encryption at rest and in transit	Encryption inventory and key management
2(f)	Integrity of data, commands, programs and configuration against unauthorised changes, and reporting of corruptions	Signed firmware and updates, integrity checks, secure boot where relevant
2(g)	Data minimisation: process only the data needed for the intended purpose	Data inventory mapped to product functions
2(h)	Availability of essential and basic functions, also after an incident, including resilience against denial of service	Resilience tests, rate limiting, safe failure modes
2(i)	Minimal negative impact on the availability of services provided by other devices or networks	Network behaviour analysis, traffic limits
2(j)	Limited attack surfaces, including external interfaces	Interface inventory, closed ports and services, debug interfaces disabled in production
2(k)	Reduced impact of an incident through exploitation mitigation mechanisms and techniques	Compiler hardening, memory protection, privilege separation
2(l)	Security information by recording and monitoring relevant internal activity, with an opt-out for the user	Security event logging (logging and monitoring, log integrity)
2(m)	Secure and easy permanent removal of all data and settings, and secure transfer where data can move to other products	Factory reset that erases user data, documented export path

The evidence column is practice, not law: the regulation says what has to be achieved, not how to prove it. Whatever you use goes into the technical documentation, which Article 31 requires to contain the means used to meet each requirement.

"Where applicable" is not an opt-out

The thirteen specific requirements apply "on the basis of the cybersecurity risk assessment and where applicable". That wording does not let you choose. Article 13(3) says the risk assessment has to indicate whether and, if so, in what manner each requirement of Part I, point 2 applies to the product, and how it is implemented.

A sensor with no user data has little to say about data deletion, and a device without a network interface has a small attack surface by nature. Both are valid conclusions, but each one needs its reasoning written down. A requirement marked "not applicable" without a reason is the first thing a market surveillance authority or a notified body will question.

Part II: the 8 vulnerability handling requirements

Part II is about the manufacturer's processes rather than the product, and it lasts as long as the support period: at least five years, unless the product is expected to be in use for less time (Article 13(8)).

Point	What it asks for	Where to start
1	Identify and document vulnerabilities and components, including a software bill of materials in a commonly used, machine-readable format covering at least the top-level dependencies	SBOM requirements
2	Address and remediate vulnerabilities without delay, including through security updates, separate from functionality updates where technically feasible	Vulnerability handling
3	Apply effective and regular tests and reviews of the product's security	Secure development lifecycle
4	Once an update is available, publicly disclose information about fixed vulnerabilities: description, affected product, impact, severity and how to remediate	Security advisories page
5	Put in place and enforce a coordinated vulnerability disclosure policy	CVD policy template
6	Facilitate the sharing of information about vulnerabilities, in the product and in third-party components, including a contact address for reports	A published security contact
7	Mechanisms to distribute updates securely, automatically for security updates where applicable	Secure update architecture
8	Disseminate security updates without delay and, unless agreed otherwise for a tailor-made product, free of charge, with advisory messages for users	Security updates policy

Point 4 allows a delay in duly justified cases, when publishing the details would put users at more risk than it helps, until users have had the chance to apply the patch. Keep a record of the decision: vulnerability handling records are what prove Part II is working.

How the requirements connect to the rest of the CRA

• Risk assessment (Article 13(2) to (4)). It comes first and decides how each requirement applies. It is documented, kept up to date during the support period and included in the technical file.
• Technical documentation (Article 31 and Annex VII). It holds the evidence for every requirement and has to exist before the product is placed on the market. See the technical file structure.
• Conformity assessment (Article 32). The class decides who checks the requirements, not which ones apply. Default products can be self-assessed. Class I products can be self-assessed only when harmonised standards, common specifications or a European cybersecurity certification scheme are applied in full. Class II products need a notified body or a certificate. See Class I vs Class II.
• User information (Annex II). Contact details, the support end date, secure use instructions and where to find the EU declaration of conformity travel with the product.
• Reporting (Article 14). Separate from Annex I and already in force: actively exploited vulnerabilities and severe incidents go to the CSIRT and ENISA within 24 hours. See Article 14 reporting.

Harmonised standards and the presumption of conformity

Annex I says what has to be achieved and leaves the how to standards. The Commission has asked CEN, CENELEC and ETSI to draft harmonised standards for the essential requirements. Under Article 27(1), a product that follows a harmonised standard is presumed to meet the requirements that standard covers, but only once the standard's reference is published in the Official Journal of the EU.

Until then, you demonstrate conformity directly against Annex I, requirement by requirement, and record the existing standards you relied on. The current status is in our guide to CRA harmonised standards. For radio products, the cybersecurity requirements of the Radio Equipment Directive already apply and follow their own standards: see CRA vs RED.

Dates

• 11 June 2026: the rules on notified bodies (Chapter IV) apply.
• 11 September 2026: the reporting obligations of Article 14 apply, including to products already on the market.
• 11 December 2027: the essential requirements of Annex I and the conformity assessment apply to every product placed on the market from that day. More in the CRA timeline.

A practical order to work through them

1. Confirm scope and class. Check that the product is in the CRA at all (CRA scope) and which class it falls in. The free scope wizard does both.
2. Do the risk assessment. It sets the applicability of each Part I requirement and the support period.
3. Map every requirement to evidence. One line per requirement: applicable or not and why, how it is met, and where the proof is. The CRA checklist follows this structure.
4. Set up the Part II processes. SBOM, CVD policy, security contact, advisories and update distribution, all running before the product is placed on the market.
5. Assemble the technical file and the declaration of conformity. Then the conformity assessment route for your class, and the CE marking.

Regulus walks a product through all 22 requirements, records the status and evidence of each one and turns it into the technical documentation: see Annex I requirements in Regulus.

Frequently asked questions

How many essential requirements does the CRA have?

Annex I has two parts. Part I sets the requirements for the product: one general requirement (an appropriate level of cybersecurity based on the risks) and thirteen specific ones, points (a) to (m). Part II sets eight vulnerability handling requirements for the manufacturer's processes. That makes 22 in total.

Do the requirements depend on the product class?

No. The essential requirements are the same for default, Class I, Class II and critical products. The class only changes the conformity assessment procedure, that is, whether you can self-assess or need a notified body or a certificate (Article 32).

Can I skip a requirement that does not fit my product?

Only with a reason. The specific requirements of Part I apply where applicable, and the cybersecurity risk assessment has to indicate whether and how each one applies (Article 13(3)). A requirement you treat as not applicable needs that justification in the technical documentation.

When do the CRA requirements apply?

The essential requirements apply to products placed on the EU market from 11 December 2027. The reporting obligations of Article 14 already apply since 11 September 2026, including to products placed on the market before that date.

Does the CRA require an SBOM?

Yes. Part II, point 1 of Annex I requires a software bill of materials in a commonly used and machine-readable format covering at least the top-level dependencies. It goes in the technical documentation; you do not have to publish it.

Are there harmonised standards for the CRA requirements yet?

CEN, CENELEC and ETSI are drafting them under a Commission standardisation request. A standard only gives a presumption of conformity once its reference is published in the Official Journal of the EU (Article 27(1)). Until then, you show conformity against Annex I directly.