Which products are covered by the CRA?

All products with digital elements that have a direct or indirect connection to a device or network, including embedded software, stand-alone software and mobile apps. Components placed on the market separately, including those supplied for integration into another manufacturer's product, are in scope too, and so are manufacturer-operated backend services where they qualify as remote data processing solutions the product needs for its functions. Outside the scope are software executed remotely and merely accessed by the user, products built solely for own use, national-security and defence products, genuine spare parts, and products under equivalent sectoral regimes such as medical devices, in-vitro diagnostics, vehicles, civil aviation and marine equipment.

Does the CRA apply to SaaS and web applications?

Not on that basis alone. Software that executes remotely and is merely accessed by the user, typically web applications used exclusively through a browser and websites, is not a product with digital elements. Standalone software supplied for local execution is, including downloaded or installed applications and browser extensions. Remote software is nevertheless caught as a remote data processing solution where another product with digital elements needs it to perform one of its functions; back-end systems doing subsequent processing that the product does not interact with directly are not. Where a service falls outside the CRA, NIS2 may still apply, but only if the provider is an in-scope entity in an in-scope sector.

Does the CRA apply to non-EU manufacturers?

Yes. What matters is that a product with digital elements is made available on the Union market, rather than the manufacturer's place of establishment. Non-EU manufacturers must be CRA-compliant before first placing a product on the EU market, and importers must verify that they are.

Does the CRA apply to free and open-source software?

Free and open-source software supplied outside a commercial activity is out of scope. What matters is whether the software is made available on the market in the course of a commercial activity, not the product it ends up in. Charging for the software itself makes it commercial, as does supplying it to monetise other products or services. The Commission's guidance makes clear that merely offering paid support (consultancy, training or professional services around freely available software) does not by itself make the supply commercial: the decisive question is whether access to the software itself, including its maintenance, is conditioned on payment. A free community edition can therefore remain out of scope even where the same provider sells a paid edition alongside it. Open-source stewards supporting commercial OSS have a dedicated light-touch regime ( Article 24 ).

Are open-source contributors covered by the CRA?

No. Responsibility follows control: whoever publishes and governs the project can be a manufacturer or steward. Contributing code, including holding technical permissions or submitting a pull request, does not by itself make a contributor a manufacturer or steward, and a contributor without primary decision-making authority over releases or project governance carries no CRA obligations for that contribution.

Are spare parts exempt from the CRA?

The exemption is narrow. Under Article 2(6) it applies where the part is specifically supplied to repair or extend the durability of a product already placed on the market; the fact that a product could technically replace a component is not enough, and the repair purpose should be evident from the supply context. Whether the part is “identical” turns on its functional role and cybersecurity-relevant characteristics: differences that do not affect the security profile are harmless, while differences in algorithms, protocols, cryptographic mechanisms or access controls can mean the part is a product with digital elements in its own right.

Do products already in development have to be redesigned?

Generally no. Products placed on the market from 11 December 2027 must meet the essential requirements, undergo conformity assessment and carry the CE marking, but manufacturers are not expected to reconstruct evidence and testing from earlier development phases retrospectively. Where that is no longer possible, a current cybersecurity risk assessment explaining how the existing design and safeguards address the identified risks can serve as the basis for the technical documentation.

What is the EU Cyber Resilience Act?

A horizontal EU regulation (2024/2847) setting mandatory cybersecurity requirements for hardware and software products sold in the EU. It covers secure design, vulnerability handling, documentation, conformity assessment and CE marking, and it is enforced through market surveillance.

When is a software product “placed on the market”?

When a completed version is first made available for distribution or use in the EU, regardless of when individual customers download or buy it. If version 1.0.0 is first offered on 1 January 2028, that is its placing-on-the-market date even for a customer who downloads it two years later. A later version such as 1.0.1 is not newly placed on the market unless it is substantially modified. Different variants that differ in components, configuration or enabled functionality can be separate products with their own dates.

What counts as a “substantial modification”?

A change that affects compliance with the essential cybersecurity requirements, or that alters the product's intended purpose and with it the cybersecurity risk profile. The decisive factor is the effect on the cybersecurity risk profile rather than the scale of the release: a technically large update may not qualify, and a small change may. The Commission's July 2026 guidance asks whether the update introduces new threat vectors such as additional interfaces, communication channels, execution environments or external dependencies; enables new attack scenarios; or materially changes the likelihood or impact of attack scenarios already identified. Security updates generally do not qualify, and neither does functionality that was already anticipated and assessed in the original risk assessment, even if it is switched on years later.

Can importers or distributors become “manufacturers”?

Yes. An importer or distributor that places a product on the market under its own name or trademark, or substantially modifies a product and then makes it available, is treated as a manufacturer ( Article 22 ). Following the Commission's guidance, the resulting obligations attach to the modified part, and to the product as a whole only where the modification affects the cybersecurity of the product as a whole.

What makes a product “important” or “critical”?

Its core functionality, assessed for the product as a whole rather than for integrated components in isolation; a smartphone does not become a critical product merely because its operating system would classify higher on its own. Additional functions that merely complement or enhance the core functionality do not change the classification. Distinct modules are different: where a product is made up of modules with separate functionalities that are offered for separate purchase, licensing or subscription, each module is a standalone product and classified on its own. Implementing Regulation (EU) 2025/2392 supplies the technical descriptions for Annex III and Annex IV .

What is an SBOM and is it mandatory?

A software bill of materials is a machine-readable inventory of the components inside a product's software, comparable to a list of ingredients. The CRA requires manufacturers to draw one up for vulnerability handling; it does not have to be published.

When does the CRA apply?

In stages: it entered into force on 10 December 2024; conformity-assessment rules apply from 11 June 2026; reporting duties for exploited vulnerabilities and severe incidents from 11 September 2026; everything else from 11 December 2027.

Do products already on the market have to comply?

Not with the substantive requirements: products placed on the market before 11 December 2027 only fall in scope if they are substantially modified afterwards ( Article 69(2) ). The reporting duty under Article 14 is the exception; from 11 September 2026 it applies to all in-scope products regardless of when they shipped ( Article 69(3) ).

When does the 24-hour reporting clock start?

The deadline does not start at the first suspicion. Where a manufacturer detects a suspicious event, or a third party flags one, it must assess it immediately, but the deadline runs only from the point where that initial assessment establishes, with a reasonable degree of certainty, that a vulnerability in the product is being actively exploited or that a severe incident has compromised the product's security. The obligation to assess promptly is itself enforceable, particularly where the vulnerability may pose a significant risk.

Do vulnerabilities known before 11 September 2026 have to be reported?

There is no retroactive reporting duty: if the manufacturer was already aware before that date that a vulnerability was being actively exploited, no report is required. But if a vulnerability was known before 11 September 2026 without known exploitation, and exploitation then occurs or comes to light afterwards, it becomes an actively exploited vulnerability and must be reported.

How fast must vulnerabilities and incidents be reported?

For actively exploited vulnerabilities and severe incidents: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure becomes available (vulnerabilities) or one month after the 72-hour notification (incidents), all via ENISA's single reporting platform. Only vulnerabilities actively exploited in the manufacturer's own product trigger the duty: where the flaw sits in a third-party component but is not reachable or exploited in that product, no Article 14 report is due, though vulnerability handling and upstream reporting continue to apply.

How long must manufacturers provide security updates?

For the support period, which must reflect the expected time in use ( Article 13(8) ). Five years operates as a minimum safeguard rather than a default: products reasonably expected to be in use longer need longer support, and only genuinely shorter-lived products get less. The criteria include reasonable user expectations, the nature and intended purpose of the product and any EU law determining product lifetimes, and the reasoning belongs in the technical documentation. Iterative software needs a declared support period for each substantially modified version placed on the market. Each security update, once issued, must additionally remain available for at least ten years or for the remainder of the support period, whichever is longer. Article 13(10) offers relief: manufacturers may remediate only the latest version where users can upgrade free of charge and without additional costs; routine testing or configuration effort counts as normal, while mandatory new hardware or a rebuilt operating environment does not.

Does a substantial modification reset the support period?

Not automatically. A substantial modification triggers a reassessment against the Article 13(8) criteria, but the question is whether it changes the factors that determined the expected use time. If it does, the support period is recalculated; if it does not, for example where a software update adds functionality without extending the hardware's life or shifting user expectations, the remaining original support period continues to run, even where less than five years remain.

After a substantial modification, must the whole product be reassessed?

Not necessarily. Where someone other than the original manufacturer substantially modifies a product and makes it available, they take on manufacturer obligations for the modified part, and for the product as a whole only where the modification affects its overall cybersecurity. The Commission applies comparable proportionality to the original manufacturer: it remains the manufacturer, but may reuse documentation and testing for unchanged aspects and focus the conformity assessment on what actually changed.

How does conformity assessment work?

Standard products self-assess (module A). Important products in Annex III class 1 may self-assess where the relevant requirements are covered by applicable technical instruments such as harmonised standards, common specifications or certification schemes; otherwise a notified body must be involved. Class 2 products face a more stringent route: a notified body (modules B+C or H) or certification under a European cybersecurity certification scheme. For critical products in Annex IV , the Commission can make such certification mandatory by delegated act; until it does, third-party assessment applies. There is no separate CRA mark: the familiar CE marking will carry the cybersecurity conformity, and the end date of the support period must be indicated clearly at the time of purchase, with a notification to users when it expires where technically feasible ( Article 13(19) ).

What are the penalties?

Tiered fines: up to EUR 15 million or 2.5% of worldwide annual turnover for breaches of the essential requirements and the core manufacturer duties ( Articles 13 and 14 ); up to EUR 10 million / 2% for other obligations, including those of importers and distributors and conformity-assessment duties; and up to EUR 5 million / 1% for supplying incorrect, incomplete or misleading information to authorities or notified bodies. In each case the higher amount applies, plus corrective orders up to product recalls ( Article 64 ). Non-compliance also feeds into contract and product-liability exposure.

How is the CRA enforced?

By national market-surveillance authorities operating under the EU market-surveillance framework (Regulation 2019/1020). They can demand technical documentation, order corrective action, and prohibit, withdraw or recall products; ENISA and the Commission can trigger action, and coordinated EU-wide “sweeps” of product categories are possible ( Article 60 ). Where non-compliance crosses borders, a Union safeguard procedure applies ( Article 55 ), and the Commission can intervene directly in urgent cases ( Article 56 ).

EU Cyber Resilience Act Compliance Timeline & FAQ: Every Key Date (Kept Current)

The Cyber Resilience Act sets cybersecurity requirements for nearly every hardware and software product sold in the EU. Its obligations apply in three waves between 2026 and 2027, including reporting duties that extend to products already on the market.

Last updated 2 September 2026

Key dates

2024-11-20
Published in the Official Journal
Regulation (EU) 2024/2847 is published; every later deadline counts from here (Art 71).
2024-12-10
Entry into force
Twenty days after publication. No obligations apply yet; the phase-in runs over three years.
2025-11-28
Important and critical product classes concretised
Implementing Regulation (EU) 2025/2392 provides the technical description of the important and critical product categories in Annexes III and IV (Arts 7 and 8).
2026-06-11
Notified-body framework applies
Chapter IV (Arts 35–51) on notified bodies and conformity assessment applies, so certification capacity can build before the main deadline.
2026-07-27
Commission guidance on applying the CRA
C(2026) 5252 final, the Commission's first official application guidance under Art 26. Non-binding and changes no date or obligation; covers scope, substantial modifications, support periods and reporting.
2026-09-11
Reporting duties begin
Manufacturers must report actively exploited vulnerabilities and severe incidents via ENISA's single reporting platform: early warning within 24 hours of becoming aware, notification within 72 hours, final report within 14 days of a corrective measure (vulnerabilities) or one month after the 72-hour notification (incidents). Also covers products placed on the market before December 2027 (Arts 14, 16, 69(3)).
2026-12-11
Notified-body capacity milestone
Member States are to strive for a sufficient number of notified bodies in the Union (Art 35(2)). Aspirational, not a manufacturer deadline.
2027-12-11
Full application
Essential cybersecurity requirements, manufacturer, importer and distributor duties, CE marking and market surveillance apply to products placed on the market from this date (Arts 6, 13, 52). Products placed earlier stay out of scope unless substantially modified (Art 69(2)).
2028-06-11
RED certificates lapse
EU-type examination certificates for radio-equipment cybersecurity under the RED Delegated Regulation expire; the CRA has fully taken over (Art 69(1)).

The Cyber Resilience Act (CRA) sets cybersecurity requirements for nearly every hardware and software product sold in the EU. Its obligations apply in three waves between 2026 and 2027, including reporting duties that extend to products already on the market. This page collects every deadline, together with answers to the questions raised most often in practice.

How to keep this straight

The CRA's dates only make sense next to its provisions. Every article referenced throughout this piece links straight into the consolidated text: read the CRA on Lawbster with linked cross-references, one-click language switching and the official guidance documents collected on the act's page. For the wider regulatory wave, see the EU AI Act compliance timeline and the Lawbster manifesto.

At a glance

The CRA entered into force on 10 December 2024. Its obligations phase in over three years (Art 71).
From 11 June 2026, the framework for notified conformity-assessment bodies applies (Arts 35–51), so certification capacity can build up early; Member States are to strive for a sufficient number of notified bodies by 11 December 2026 (Art 35(2)).
From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents via ENISA's single reporting platform (Art 14, Art 16): early warning within 24 hours of becoming aware, notification within 72 hours, final reports within 14 days of a fix (vulnerabilities) or one month after the 72-hour notification (incidents).
From 11 December 2027, the CRA applies in full: essential cybersecurity requirements (Art 6, Annex I), vulnerability handling, technical documentation, CE marking (Art 13) and market surveillance (Art 52).
Products placed on the market before 11 December 2027 stay out of scope unless substantially modified (Art 69(2)), with one exception: the reporting duty under Article 14 applies to them as well (Art 69(3)).
Which products count as “important” or “critical” (Annex III, Annex IV) has been concretised by Implementing Regulation (EU) 2025/2392 of 28 November 2025.
On 27 July 2026 the Commission published its first official guidance under Article 26 (C(2026) 5252 final). It is non-binding and changes no date or obligation, but it sets out how the Commission reads scope, substantial modifications, support periods and reporting.

Beyond the dates in the timeline, the CRA contains Commission evaluation and review duties (Art 70) and delegated-power provisions (Art 61, Art 62); they rarely drive day-to-day compliance, so we keep them out of the main timeline.

2024–2025 — Entry into force, and the classes take shape

The CRA is the EU's first horizontal product-cybersecurity law. It applies to “products with digital elements”: hardware and software with a direct or indirect data connection to a device or network, from smart thermostats to stand-alone accounting software and mobile apps. Manufacturers must build products securely (Annex I Part I), keep a machine-readable software bill of materials (SBOM), handle vulnerabilities throughout a support period of at least five years (Annex I Part II, Article 13), document everything, run a conformity assessment and affix the CE marking. Software that merely runs remotely and is accessed through a browser is not, on that basis alone, a product with digital elements; it is, however, covered as a remote data processing solution where another product needs it to perform one of its functions. The regulation entered into force on 10 December 2024, twenty days after publication in the Official Journal. The first implementing act followed on 28 November 2025: Implementing Regulation (EU) 2025/2392 concretises which product categories count as “important” or “critical” (Annex III and Annex IV), the classes that decide how demanding conformity assessment will be in 2027.

2026 — Reporting duties begin

Two dates matter this year. From 11 June 2026, the machinery for notified bodies starts operating, which determines whether enough certification capacity exists for the important and critical product classes (Articles 7 and 8, as concretised by Implementing Regulation 2025/2392) come 2027. By 11 December 2026, Member States are expected, as an aspirational duty under Article 35(2), to have a sufficient number of notified bodies in place. The technical backbone is also taking shape: the Commission anticipates the first harmonised-standards deliverables in Q3 2026, with the remainder due by 30 October 2027, priority on the important and critical categories.

From 11 September 2026, manufacturers must notify any actively exploited vulnerability and any severe incident affecting the security of their products via the single reporting platform operated by ENISA (Article 14, Article 16): an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report within 14 days of a corrective measure for vulnerabilities, or one month after the 72-hour notification for incidents. Under Article 69(3), this reporting duty also covers products placed on the market before December 2027.

On 27 July 2026 the Commission published its first application guidance under Article 26 (C(2026) 5252 final). The guidance is non-binding and changes no deadline, but it sets out the Commission's interpretation on the questions that shape day-to-day compliance: when the reporting deadlines start, when an update qualifies as a substantial modification, how the support period is determined, and how free and open-source software is treated. Statements of the Commission's position in this article are based on that guidance.

2027 — Full application, with a legacy carve-out

From 11 December 2027, the CRA applies in full to every product with digital elements placed on the market from that date: essential cybersecurity requirements, vulnerability-handling processes, technical documentation, conformity assessment and CE marking, backed by market surveillance. Fines are tiered: up to EUR 15 million or 2.5% of worldwide annual turnover for breaches of the essential requirements, with lower tiers of up to EUR 10 million / 2% and EUR 5 million / 1% for other infringements (Article 64). Products already on the market before that date remain outside the substantive requirements unless they undergo a substantial modification (Article 69(2)). The Commission assesses this by reference to the cybersecurity risk rather than the size of the release: a security update does not trigger the CRA merely because it is technically extensive, while a change to the intended purpose that shifts the cybersecurity risk profile does. The relevant date is determined for each individual unit rather than for the product line, and where a modification does trigger the CRA, the manufacturer may reuse documentation and testing for the parts that did not change.

2028 — The transition's end

One trailing date remains. EU-type examination certificates issued for radio-equipment cybersecurity under the RED Delegated Regulation stay valid until 11 June 2028 (Article 69(1)); from 11 December 2027 the CRA takes over as the horizontal regime. For most manufacturers the relevant obligations are in place from 2027; for radio-equipment makers this certificate transition is the final step.

Where the CRA meets other EU digital laws

AI Act: Article 12 CRA bridges the two regimes. For high-risk AI systems that are products with digital elements, CRA conformity feeds the cybersecurity requirements of the AI Act, so a single assessment can serve both regimes. See also the EU AI Act compliance timeline. The CRA itself flags AI-specific risks: cybersecurity risk assessments for AI products must address threats such as data poisoning and adversarial attacks (Recital 51), and the 2026 Digital Omnibus on AI points to CRA conformity assessment as the primary route where high-risk AI systems are also products with digital elements.
Product Liability Directive: the new Product Liability Directive (PLD) expressly treats software as a product and covers damage from cybersecurity defects; a product that misses the CRA's essential requirements can therefore trigger both regulatory enforcement and civil liability. Member States must transpose the new PLD by 9 December 2026.
NIS2: purely remote services fall outside the CRA and may fall under NIS2; NIS2 entities in turn rely on CRA-compliant products for their supply-chain security duties. Recital 125 makes the link explicit: securely built CRA products are meant to ease NIS2 entities' supply-chain obligations.
Cybersecurity Act: certification of critical products (Annex IV) runs through European cybersecurity certification schemes established under the Cybersecurity Act (CSA).
GDPR: the CRA's secure-by-design duties protect the same personal data the General Data Protection Regulation (GDPR) governs; Annex I CRA and Article 32 GDPR point in the same direction.
Reporting consolidation ahead: the wider Digital Omnibus proposes a single-entry point, built on the CRA's ENISA reporting platform, through which notifications under the CRA, NIS2, the GDPR, DORA and the CER Directive could be filed once. See our Digital Omnibus explainer.

Frequently asked

Which products are covered by the CRA?: All products with digital elements that have a direct or indirect connection to a device or network, including embedded software, stand-alone software and mobile apps. Components placed on the market separately, including those supplied for integration into another manufacturer's product, are in scope too, and so are manufacturer-operated backend services where they qualify as remote data processing solutions the product needs for its functions. Outside the scope are software executed remotely and merely accessed by the user, products built solely for own use, national-security and defence products, genuine spare parts, and products under equivalent sectoral regimes such as medical devices, in-vitro diagnostics, vehicles, civil aviation and marine equipment.
Does the CRA apply to SaaS and web applications?: Not on that basis alone. Software that executes remotely and is merely accessed by the user, typically web applications used exclusively through a browser and websites, is not a product with digital elements. Standalone software supplied for local execution is, including downloaded or installed applications and browser extensions. Remote software is nevertheless caught as a remote data processing solution where another product with digital elements needs it to perform one of its functions; back-end systems doing subsequent processing that the product does not interact with directly are not. Where a service falls outside the CRA, NIS2 may still apply, but only if the provider is an in-scope entity in an in-scope sector.
Does the CRA apply to non-EU manufacturers?: Yes. What matters is that a product with digital elements is made available on the Union market, rather than the manufacturer's place of establishment. Non-EU manufacturers must be CRA-compliant before first placing a product on the EU market, and importers must verify that they are.
Does the CRA apply to free and open-source software?: Free and open-source software supplied outside a commercial activity is out of scope. What matters is whether the software is made available on the market in the course of a commercial activity, not the product it ends up in. Charging for the software itself makes it commercial, as does supplying it to monetise other products or services. The Commission's guidance makes clear that merely offering paid support (consultancy, training or professional services around freely available software) does not by itself make the supply commercial: the decisive question is whether access to the software itself, including its maintenance, is conditioned on payment. A free community edition can therefore remain out of scope even where the same provider sells a paid edition alongside it. Open-source stewards supporting commercial OSS have a dedicated light-touch regime (Article 24).
Are open-source contributors covered by the CRA?: No. Responsibility follows control: whoever publishes and governs the project can be a manufacturer or steward. Contributing code, including holding technical permissions or submitting a pull request, does not by itself make a contributor a manufacturer or steward, and a contributor without primary decision-making authority over releases or project governance carries no CRA obligations for that contribution.
Are spare parts exempt from the CRA?: The exemption is narrow. Under Article 2(6) it applies where the part is specifically supplied to repair or extend the durability of a product already placed on the market; the fact that a product could technically replace a component is not enough, and the repair purpose should be evident from the supply context. Whether the part is “identical” turns on its functional role and cybersecurity-relevant characteristics: differences that do not affect the security profile are harmless, while differences in algorithms, protocols, cryptographic mechanisms or access controls can mean the part is a product with digital elements in its own right.
Do products already in development have to be redesigned?: Generally no. Products placed on the market from 11 December 2027 must meet the essential requirements, undergo conformity assessment and carry the CE marking, but manufacturers are not expected to reconstruct evidence and testing from earlier development phases retrospectively. Where that is no longer possible, a current cybersecurity risk assessment explaining how the existing design and safeguards address the identified risks can serve as the basis for the technical documentation.
What is the EU Cyber Resilience Act?: A horizontal EU regulation (2024/2847) setting mandatory cybersecurity requirements for hardware and software products sold in the EU. It covers secure design, vulnerability handling, documentation, conformity assessment and CE marking, and it is enforced through market surveillance.
When is a software product “placed on the market”?: When a completed version is first made available for distribution or use in the EU, regardless of when individual customers download or buy it. If version 1.0.0 is first offered on 1 January 2028, that is its placing-on-the-market date even for a customer who downloads it two years later. A later version such as 1.0.1 is not newly placed on the market unless it is substantially modified. Different variants that differ in components, configuration or enabled functionality can be separate products with their own dates.
What counts as a “substantial modification”?: A change that affects compliance with the essential cybersecurity requirements, or that alters the product's intended purpose and with it the cybersecurity risk profile. The decisive factor is the effect on the cybersecurity risk profile rather than the scale of the release: a technically large update may not qualify, and a small change may. The Commission's July 2026 guidance asks whether the update introduces new threat vectors such as additional interfaces, communication channels, execution environments or external dependencies; enables new attack scenarios; or materially changes the likelihood or impact of attack scenarios already identified. Security updates generally do not qualify, and neither does functionality that was already anticipated and assessed in the original risk assessment, even if it is switched on years later.
Can importers or distributors become “manufacturers”?: Yes. An importer or distributor that places a product on the market under its own name or trademark, or substantially modifies a product and then makes it available, is treated as a manufacturer (Article 22). Following the Commission's guidance, the resulting obligations attach to the modified part, and to the product as a whole only where the modification affects the cybersecurity of the product as a whole.
What makes a product “important” or “critical”?: Its core functionality, assessed for the product as a whole rather than for integrated components in isolation; a smartphone does not become a critical product merely because its operating system would classify higher on its own. Additional functions that merely complement or enhance the core functionality do not change the classification. Distinct modules are different: where a product is made up of modules with separate functionalities that are offered for separate purchase, licensing or subscription, each module is a standalone product and classified on its own. Implementing Regulation (EU) 2025/2392 supplies the technical descriptions for Annex III and Annex IV.
What is an SBOM and is it mandatory?: A software bill of materials is a machine-readable inventory of the components inside a product's software, comparable to a list of ingredients. The CRA requires manufacturers to draw one up for vulnerability handling; it does not have to be published.
When does the CRA apply?: In stages: it entered into force on 10 December 2024; conformity-assessment rules apply from 11 June 2026; reporting duties for exploited vulnerabilities and severe incidents from 11 September 2026; everything else from 11 December 2027.
Do products already on the market have to comply?: Not with the substantive requirements: products placed on the market before 11 December 2027 only fall in scope if they are substantially modified afterwards (Article 69(2)). The reporting duty under Article 14 is the exception; from 11 September 2026 it applies to all in-scope products regardless of when they shipped (Article 69(3)).
When does the 24-hour reporting clock start?: The deadline does not start at the first suspicion. Where a manufacturer detects a suspicious event, or a third party flags one, it must assess it immediately, but the deadline runs only from the point where that initial assessment establishes, with a reasonable degree of certainty, that a vulnerability in the product is being actively exploited or that a severe incident has compromised the product's security. The obligation to assess promptly is itself enforceable, particularly where the vulnerability may pose a significant risk.
Do vulnerabilities known before 11 September 2026 have to be reported?: There is no retroactive reporting duty: if the manufacturer was already aware before that date that a vulnerability was being actively exploited, no report is required. But if a vulnerability was known before 11 September 2026 without known exploitation, and exploitation then occurs or comes to light afterwards, it becomes an actively exploited vulnerability and must be reported.
How fast must vulnerabilities and incidents be reported?: For actively exploited vulnerabilities and severe incidents: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure becomes available (vulnerabilities) or one month after the 72-hour notification (incidents), all via ENISA's single reporting platform. Only vulnerabilities actively exploited in the manufacturer's own product trigger the duty: where the flaw sits in a third-party component but is not reachable or exploited in that product, no Article 14 report is due, though vulnerability handling and upstream reporting continue to apply.
How long must manufacturers provide security updates?: For the support period, which must reflect the expected time in use (Article 13(8)). Five years operates as a minimum safeguard rather than a default: products reasonably expected to be in use longer need longer support, and only genuinely shorter-lived products get less. The criteria include reasonable user expectations, the nature and intended purpose of the product and any EU law determining product lifetimes, and the reasoning belongs in the technical documentation. Iterative software needs a declared support period for each substantially modified version placed on the market. Each security update, once issued, must additionally remain available for at least ten years or for the remainder of the support period, whichever is longer. Article 13(10) offers relief: manufacturers may remediate only the latest version where users can upgrade free of charge and without additional costs; routine testing or configuration effort counts as normal, while mandatory new hardware or a rebuilt operating environment does not.
Does a substantial modification reset the support period?: Not automatically. A substantial modification triggers a reassessment against the Article 13(8) criteria, but the question is whether it changes the factors that determined the expected use time. If it does, the support period is recalculated; if it does not, for example where a software update adds functionality without extending the hardware's life or shifting user expectations, the remaining original support period continues to run, even where less than five years remain.
After a substantial modification, must the whole product be reassessed?: Not necessarily. Where someone other than the original manufacturer substantially modifies a product and makes it available, they take on manufacturer obligations for the modified part, and for the product as a whole only where the modification affects its overall cybersecurity. The Commission applies comparable proportionality to the original manufacturer: it remains the manufacturer, but may reuse documentation and testing for unchanged aspects and focus the conformity assessment on what actually changed.
How does conformity assessment work?: Standard products self-assess (module A). Important products in Annex III class 1 may self-assess where the relevant requirements are covered by applicable technical instruments such as harmonised standards, common specifications or certification schemes; otherwise a notified body must be involved. Class 2 products face a more stringent route: a notified body (modules B+C or H) or certification under a European cybersecurity certification scheme. For critical products in Annex IV, the Commission can make such certification mandatory by delegated act; until it does, third-party assessment applies. There is no separate CRA mark: the familiar CE marking will carry the cybersecurity conformity, and the end date of the support period must be indicated clearly at the time of purchase, with a notification to users when it expires where technically feasible (Article 13(19)).
What are the penalties?: Tiered fines: up to EUR 15 million or 2.5% of worldwide annual turnover for breaches of the essential requirements and the core manufacturer duties (Articles 13 and 14); up to EUR 10 million / 2% for other obligations, including those of importers and distributors and conformity-assessment duties; and up to EUR 5 million / 1% for supplying incorrect, incomplete or misleading information to authorities or notified bodies. In each case the higher amount applies, plus corrective orders up to product recalls (Article 64). Non-compliance also feeds into contract and product-liability exposure.
How is the CRA enforced?: By national market-surveillance authorities operating under the EU market-surveillance framework (Regulation 2019/1020). They can demand technical documentation, order corrective action, and prohibit, withdraw or recall products; ENISA and the Commission can trigger action, and coordinated EU-wide “sweeps” of product categories are possible (Article 60). Where non-compliance crosses borders, a Union safeguard procedure applies (Article 55), and the Commission can intervene directly in urgent cases (Article 56).