The Cyber Resilience Act, the CRA, is Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements. It entered into force on 10 December 2024 and applies in full from 11 December 2027. Two parts apply earlier: the reporting obligations in Article 14 apply from 11 September 2026, and the rules on notifying conformity assessment bodies have applied since 11 June 2026.
The CRA is product law, not organisational law. It does not ask whether a company has a certain security posture. It asks whether a product has certain properties, reaches the market with a CE marking, and receives security updates for its support period. Anyone who already places products under the Machinery Regulation or the Radio Equipment Directive knows the mechanics. For pure software manufacturers they are new.
This text explains who the CRA applies to, what it requires, when it applies and what happens on breach. Every statement names the Article it comes from. The text of the Regulation is on EUR-Lex at eur-lex.europa.eu/eli/reg/2024/2847/oj.
In short
- The CRA applies to hardware and software made available on the EU market that has a data connection to a device or network. That is almost all software and almost every connected device.
- Manufacturers carry most of it: essential requirements under Annex I, a risk assessment, technical documentation, vulnerability handling with an SBOM, security updates for the support period, conformity assessment, CE marking.
- From 11 September 2026 manufacturers must report actively exploited vulnerabilities and severe incidents within 24 hours, including for products already on the market.
- From 11 December 2027 the rest applies: without a conformity assessment and a CE marking, a new product with digital elements can no longer be placed on the market.
- Fines go up to EUR 15 million or 2.5 percent of worldwide annual turnover.
Who the CRA applies to
Article 2(1) sets the scope: the Regulation applies to products with digital elements made available on the market whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network.
A product with digital elements is, under Article 3(1), a software or hardware product and its remote data processing solutions, including software or hardware components placed on the market separately. Three consequences matter in practice:
- Software is a product. An operating system, a desktop application, a mobile app, a library another manufacturer builds in: all products with digital elements, as soon as they have a data connection.
- Components count on their own. A chip, a module or a software library placed on the market separately is a product in its own right and needs its own conformity.
- Remote processing is part of the product. If a product cannot perform its function without a specific cloud service, that service is part of the product (Article 3(2)). Pure software-as-a-service without such a product is not covered by the CRA; it falls under NIS2 where the provider is in scope there.
What is excluded. Article 2 carves out products already covered by sectoral rules with cybersecurity requirements: medical devices and in vitro diagnostics under Regulations (EU) 2017/745 and 2017/746, type-approved vehicles, civil aviation products, marine equipment. Also excluded are products developed exclusively for national security or defence purposes, and spare parts that replace an original part with identical properties.
Open source. Free and open-source software developed and supplied outside a commercial activity is not covered. A manufacturer that builds open-source software into a commercial product is fully responsible for that product. In between sits the open-source software steward under Article 24, for example a foundation that systematically supports a project: it has a lighter duty, a documented cybersecurity policy, and no CE marking.
If it is unclear whether a product is covered, the question takes minutes: Does the Cyber Resilience Act apply to you?
The three dates
Products placed on the market before 11 December 2027 have a transitional rule: they are subject to the requirements only if they are substantially modified after that date (Article 69(2)). The reporting obligations under Article 14 apply to those products anyway (Article 69(3)). A manufacturer selling software today must therefore be able to report from 11 September 2026, however far it is from a CE marking. What the two reporting duties require in detail is in Article 14 is two reporting duties, not one.
What manufacturers must do
Manufacturers' obligations are in Article 13. They fall into seven blocks.
1. Essential requirements under Annex I. Part I describes the product's properties: delivered without known exploitable vulnerabilities, with a secure default configuration, protection against unauthorised access, encryption of stored and transmitted data, a limited attack surface, and the ability to receive security updates. Part II describes the process: vulnerabilities and components identified and documented, vulnerabilities remediated without delay, security updates provided free of charge, a coordinated disclosure policy published. The full texts: properties of products and vulnerability handling.
2. Cybersecurity risk assessment. Under Article 13(2) and (3) the manufacturer assesses the product's risks, documents the outcome in the technical documentation and takes it into account in planning, design, development, production, delivery and maintenance.
3. Software bill of materials, SBOM. Annex I Part II(1) requires identifying and documenting vulnerabilities and components, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at least the top-level dependencies. The SBOM belongs in the technical documentation (Annex VII(8)); it does not have to be handed to users. A manufacturer that does make it available states in the user information where it can be found (Annex II(9)).
4. Support period. Under Article 13(8) the manufacturer determines the period during which vulnerabilities are handled. It must reflect the expected time of use and be at least five years, unless the product is expected to be used for less. Security updates must be provided for that period, and the period must be stated at the time of purchase.
5. Technical documentation and user information. Annex VII lists what the technical documentation must contain: description of the product, design and development, vulnerability handling, risk assessment, standards applied, test reports. Annex II lists what the user receives: a contact point for vulnerabilities, the intended purpose, the support period, instructions for secure installation and decommissioning. The texts: content of the technical documentation and information and instructions to the user.
6. Conformity assessment, declaration of conformity, CE marking. Which procedure applies depends on the product class, covered below. At the end stand the EU declaration of conformity under Annex V and the CE marking under Article 30.
7. Reporting obligations. Article 14: actively exploited vulnerabilities and severe incidents, each with an early warning within 24 hours, a notification within 72 hours and a final report. Notifications go through ENISA's single reporting platform to the competent CSIRT, determined by the manufacturer's main establishment.
The full list with the wording of every paragraph: obligations of manufacturers, Article 13.
Importers and distributors
Anyone importing a product from a third country checks under Article 19 that the manufacturer has carried out the conformity assessment, that the documentation exists and that the CE marking is affixed, and puts its own name and address on the product. Distributors check under Article 20 that the CE marking, the declaration of conformity and the user information are present. Neither may make a product available if they have reason to believe it is not compliant, and both must pass on vulnerabilities they learn of to the manufacturer.
An importer or distributor becomes a manufacturer itself under Article 21 if it places the product on the market under its own name or trademark or substantially modifies it. That catches white-label vendors and integrators more often than they expect. The texts: obligations of importers, obligations of distributors, cases in which manufacturers' obligations apply to importers and distributors.
Product classes and conformity assessment
The CRA has four tiers, and the tier decides who checks conformity.
The procedures are in Article 32 and the modules in Annex VIII: conformity assessment procedures. The Commission specifies the product categories of Annexes III and IV by implementing act.
A note on standards. The harmonised standards for the CRA are being drafted at CEN-CENELEC. Until a standard is cited in the Official Journal there is no presumption of conformity under Article 27, and a manufacturer of a class I product cannot base its self-assessment on it. Anyone planning today should budget for a notified body or check the classification of the product very carefully.
Fines
Article 64 sets three tiers. Breaches of the essential requirements in Annex I or of the obligations in Articles 13 and 14 cost up to EUR 15 million or 2.5 percent of worldwide annual turnover for the preceding financial year, whichever is higher. Breaches of the other obligations cost up to EUR 10 million or 2 percent. Incorrect, incomplete or misleading information to notified bodies and market surveillance authorities costs up to EUR 5 million or 1 percent. Member States set the details; in Germany market surveillance sits with the Federal Office for Information Security.
Microenterprises and small enterprises get no exemption from the obligations, but they do get relief on documentation, notified-body fees and Member State support (Article 33).
The CRA and the AI Act
An AI system that is also a product with digital elements is subject to both Regulations. Article 12 of the CRA links them: a high-risk AI system that meets the CRA's essential requirements and whose conformity assessment was carried out under the CRA is deemed to comply with the cybersecurity requirements of the AI Act (Article 15). Anyone who has to serve both Regulations saves a double assessment with this bridge, but must structure the documentation so that it holds up under both.
What to do now
- Record the scope decision in writing. For every product: covered or excluded, and why. Does the Cyber Resilience Act apply to you?
- Be able to report by 11 September 2026. Two reporting paths, one on-call rota, the competent CSIRT identified. Reporting readiness checklist
- Determine the product class. Default, class I, class II or critical. That decides whether a notified body is needed and how much time remains until December 2027.
- Set up the SBOM and the vulnerability process. Both are preconditions for reporting readiness and for Annex I Part II.
- Set and publish the support period. At least five years, unless the expected time of use is shorter.
- Start the technical documentation under Annex VII from the beginning, not at the end.
Frequently asked questions
Does the CRA apply to software-as-a-service? Not as such. A pure cloud service is not a product with digital elements. It is covered only as a remote data processing solution of a product, that is, where a product cannot perform its function without it. For pure services, NIS2 is the relevant rule.
Does the CRA apply to open-source software? Not to software developed and supplied outside a commercial activity. It applies to commercial products that contain open-source components, and the manufacturer is responsible for those components. Open-source software stewards under Article 24 have their own lighter duty.
Does the CRA apply to products already on the market? The reporting obligations under Article 14 do, from 11 September 2026. The other requirements only if the product is substantially modified after 11 December 2027.
What is the difference between the CRA and NIS2? NIS2 addresses organisations that provide certain services and requires risk management and reporting from them. The CRA addresses products and those who make and distribute them. A company can be subject to both: as an operator under NIS2 and as a manufacturer under the CRA.
Do I need a notified body? Not for a default product; self-assessment is enough. For class I only where harmonised standards cannot be applied in full, which is currently the case as long as none is cited in the Official Journal. For class II and critical products, always.
Do I have to publish the SBOM? No. It belongs in the technical documentation and must be produced on a reasoned request from market surveillance. Whether it is made available to users is the manufacturer's decision.
Sources
- Regulation (EU) 2024/2847, Cyber Resilience Act, in the Official Journal: eur-lex.europa.eu/eli/reg/2024/2847/oj
- ENISA, single reporting platform for Article 14 notifications: enisa.europa.eu/topics/product-security/single-reporting-platform-srp
- Every CRA obligation with its wording, Article by Article: Cyber Resilience Act obligations
This text is a cited starting point, not legal advice. The text of the Regulation prevails.
