The Cyber Resilience Act is Regulation (EU) 2024/2847. It is product safety law: what is regulated is not the organisation but the product. Anyone making hardware or software with digital elements available on the Union market has to meet cybersecurity requirements for it and demonstrate that, as with other CE legislation.
Which products fall under the Cyber Resilience Act?
Covered are products with digital elements whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network. That ranges from operating systems, applications and libraries to controllers, sensors and connected consumer devices.
Excluded are product groups already governed by sector-specific Union law, such as medical devices, motor vehicles, civil aviation and marine equipment, as well as products developed exclusively for national security or defence purposes. Free and open-source software falls within scope only where it is supplied in the course of a commercial activity; for open-source software stewards the regulation provides a lighter set of obligations.
Which risk classes does the Cyber Resilience Act define?
| Category | Examples of classification | Route to conformity |
|---|---|---|
| Default products | the majority of all products with digital elements | self-assessment by the manufacturer |
| Important products, class I and II (Annex III) | products of heightened security relevance such as identity management, network components or operating systems | stricter procedures depending on class, often involving a notified body |
| Critical products (Annex IV) | particularly security-critical products | where applicable, European cybersecurity certification |
Article 32 narrows the self-assessment route further for important products, and the difference between the two classes is total rather than gradual: a Class I product may self-assess only where harmonised standards exist and have been applied in full; a Class II product has no self-assessment route at all: every route runs through third-party conformity assessment.
At the end sit the technical documentation, the EU declaration of conformity and the CE marking. Without them, a covered product may not be placed on the market.
What security requirements does the CRA set for products and manufacturers?
Annex I is in two parts. Part I describes properties of the product: a secure default configuration, no known exploitable vulnerabilities at the time of placing on the market, protection against unauthorised access, protection of confidentiality and integrity, data minimisation, availability of core functions, reduction of the attack surface, and the ability to apply secure updates.
Part II governs vulnerability handling across the lifecycle: a bill of materials for the software components (SBOM), remediating vulnerabilities without delay, regular testing, a coordinated vulnerability disclosure policy, public information about remediated vulnerabilities, and the secure distribution of security updates, which as a rule have to be provided free of charge.
The manufacturer sets a support period. It is meant to reflect the expected use time of the product and is as a rule at least five years, unless the product's lifetime is shorter.
What must be reported under Article 14?
Article 14 addresses the manufacturer, not the operator, and runs two separate tracks with different final deadlines.
| Trigger | Early warning | Notification | Final report |
|---|---|---|---|
| Actively exploited vulnerability (Art. 14(1), (2)) | 24 hours | 72 hours | no later than 14 days after a corrective or mitigating measure becomes available |
| Severe security incident (Art. 14(3), (4)) | 24 hours | 72 hours | within one month of the 72-hour notification |
Both clocks run from becoming aware, not from the preceding stage. Article 14(6) requires an intermediate report only on request. Under Article 14(5), a security incident is severe where it affects the product's ability to protect sensitive or important data and functions, or where it has led or can lead to the introduction or execution of malicious code.
Reports go simultaneously to the CSIRT designated as coordinator and to ENISA, both through the single reporting platform under Article 16. The competent CSIRT is that of the member state of main establishment; under Article 14(7) that is the state where decisions on the cybersecurity of the products are predominantly taken. For a manufacturer with its main establishment in Germany, that is the BSI. Separate from all of this is Article 14(8): affected users also have to be informed, where possible in a machine-readable format.
Which deadlines does Article 71 set?
The regulation was published in the Official Journal on 20 November 2024 (OJ L, 2024/2847) and entered into force in December 2024. Article 71(2) stages its application in three steps.
| From when | What applies |
|---|---|
| 11 June 2026 | Chapter IV (Articles 35 to 51): notifying authorities and conformity assessment bodies, so the assessment infrastructure is in place ahead of the conformity duty |
| 11 September 2026 | Article 14: the manufacturers' reporting duties |
| 11 December 2027 | the rest of the regulation; covered products may only be placed on the market once conformity is met |
The reporting duty reaches further back than the conformity duty: under Article 69(3), Article 14 also applies to covered products placed on the market before 11 December 2027. The vulnerability-handling duties in Annex I Part II do not travel with it; they reach an older product only on a substantial modification (Article 69(2)). For infringements the regulation provides tiered fine ranges that alternatively attach to worldwide annual turnover.
How does the Cyber Resilience Act differ from NIS2?
NIS2 obliges organisations to secure their own network and information systems. The CRA obliges manufacturers to put secure products on the market. The two interlock: what the CRA generates in product documentation, support periods and vulnerability information is precisely the material operators need for their supply chain risk management.
Where the requirements land in Rizzqo
The Cyber Resilience Act is held in Rizzqo as a requirement catalogue. What matters is what its requirements attach to, because that is what sets this catalogue apart from the others: the reference point is not your own IT estate but the product you ship.
In Rizzqo a product with digital elements is therefore an asset like a business process, and the systems of its development and delivery chain hang beneath it as supporting objects: build environment, repositories, dependency management, signing infrastructure and the suppliers involved, each with a category and a named owner. Requirements are dispatched through that classification, so each appears on the object where the relevant work actually happens. The technical documentation and the declaration of conformity remain separate documents.