Cyber Resilience Act (EU) 2024/2847 — manufacturer obligations from 11 September 2026

For twenty years, product cybersecurity in the EU was regulated in fragments: partly through the Radio Equipment Directive, partly through sectoral rules, mostly not at all. Regulation (EU) 2024/2847 — the Cyber Resilience Act — ends that. It covers every product with digital elements made available on the Union market, from a router to a software library sold as a product, and ties it to CE marking.

The nearest deadline is not far off. On 11 September 2026 the reporting obligations begin: actively exploited vulnerabilities and severe incidents must be reported within 24 hours. This applies to products already on the market too. Full application follows on 11 December 2027. For manufacturers this means not only new engineering work, but a new set of data that must reach the user and stay true for years — the same problem the digital product passport solves in other compliance areas.

Key takeaways

Regulation (EU) 2024/2847 entered into force on 10 December 2024. It applies in stages: notified body provisions from 11 June 2026, reporting obligations from 11 September 2026, full application from 11 December 2027.
The scope is horizontal: products with digital elements — hardware and software whose use involves a direct or indirect data connection to a device or network. Products covered by separate regimes are excluded: medical devices, motor vehicles, civil aviation, marine equipment and the defence domain.
Most products go through self-assessment (Module A). Important products in Annex III class I need a notified body if harmonised standards have not been fully applied; class II and critical products in Annex IV always require a notified body or certification.
The support period is set by the manufacturer, but as a rule it cannot be shorter than five years — unless the product’s expected use time is shorter. Its end date (month and year) must be stated at the point of purchase.
An SBOM — a machine-readable software bill of materials covering at least the top-level dependencies — is an Annex I requirement. It must be kept current and made available to market surveillance authorities on request.
Security updates are free of charge, and once issued must remain available for at least ten years or until the end of the support period, whichever is longer.
Conformity is confirmed by an EU declaration of conformity and CE marking — the same instruments as in the rest of EU product law.
The top penalty tier for breaching the essential requirements and the obligations in Articles 13 and 14 is EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher.
The CRA does not establish a digital product passport. What it does create is a set of product- and version-specific information that must remain reachable for years — and that is a data management problem.

What the Cyber Resilience Act actually is

The CRA is a horizontal act: it does not describe one industry but a shared property of products. That property is the presence of a digital element and the ability to exchange data. Structurally it belongs to the family of product law familiar from CE marking: essential requirements in an annex, conformity assessment, technical documentation, a declaration and a mark.

The novelty lies elsewhere. Product law so far assessed goods at the moment of placing on the market — after that, the regulator’s interest largely ended. The CRA does not accept that premise. The duty to handle vulnerabilities, issue updates and report incidents runs across the entire declared support period. A product compliant on the day of sale can become non-compliant two years later if the manufacturer stops patching known vulnerabilities.

The CRA also tidies up existing law. Delegated Regulation (EU) 2022/30, which since 2025 delivered cybersecurity requirements through the Radio Equipment Directive, is repealed on the date the CRA becomes fully applicable — 11 December 2027. The essential requirements in Annex I cover everything the radio equipment rules covered, so the double regime disappears.

What counts as a “product with digital elements”

The definition is broad, deliberately so. It means a hardware or software product whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network. It extends to remote data processing solutions where these are necessary for the product to function.

In practice it is easier to point at what falls outside the scope, because the list of exclusions is closed and specific:

Medical devices and in vitro diagnostic medical devices — Regulations (EU) 2017/745 and (EU) 2017/746.
Motor vehicles — Regulation (EU) 2019/2144.
Civil aviation — Regulation (EU) 2018/1139.
Marine equipment — Directive 2014/90/EU.
Products developed exclusively for national security or defence purposes, and products not supplied in the course of a commercial activity.

Beyond those exclusions the scope is very wide. Software sold as a product is covered just as a device is. Free and open-source software developed non-commercially is not — but Article 24 creates a separate, lighter role for the open-source software steward, for entities that provide sustained support for the development of such software intended for commercial use.

Three risk levels, three assessment routes

The regulation scales its rigour according to the impact a security breach in a given product could cause.

Default products — the large majority of the market. The manufacturer performs internal control (Module A), draws up the technical documentation and the declaration itself. No notified body is needed.

Important products, Annex III class I — among others password managers, antivirus software, identity and privileged access management systems, VPNs, operating systems, routers and switches, microprocessors with security-related functionality, smart home virtual assistants, internet-connected toys and wearables. Self-assessment remains possible, but only where harmonised standards or common specifications have been fully applied. Without them, a notified body steps in.

Important products, Annex III class II — for example firewalls, intrusion detection and prevention systems, hypervisors and tamper-resistant microprocessors. Here a notified body or a European cybersecurity certification scheme is mandatory.

Critical products, Annex IV — the strictest tier, with a mandatory notified body or certification. Technical descriptions of the categories are set out in Commission Implementing Regulation (EU) 2025/2392.

The practical conclusion is the same as with any regulation involving notified bodies: classify early. If a product lands in class II or Annex IV, the notified body’s lead time becomes part of the go-to-market plan rather than a formality at the end.

Manufacturer obligations — what actually has to be done

Essential requirements, part one: product properties

Annex I Part I describes what the product must be like. The key points: placed on the market without known exploitable vulnerabilities, delivered with a secure default configuration and the ability to reset to factory state, protecting the confidentiality, integrity and availability of data, minimising the attack surface, limiting data collection to what is necessary, and allowing security updates to be installed — where possible automatically and with clear notification to the user.

Essential requirements, part two: vulnerability handling

Annex I Part II describes a process that must work throughout the support period:

An SBOM in a machine-readable format, covering at least the top-level dependencies, kept up to date. There is no duty to publish it to users, but it must be made available to market surveillance authorities on request.
Addressing and remediating vulnerabilities without delay, including by issuing security updates.
Regular security testing and reviews.
Public disclosure of information about fixed vulnerabilities once an update is available.
A coordinated vulnerability disclosure policy and a single point of contact for reporting.
Free distribution of security updates without delay.

The support period — a new data field with commercial consequences

This is the obligation that most often catches people out. The manufacturer sets the support period during which it effectively handles the product’s vulnerabilities, but it cannot be shorter than five years — unless the product’s expected use time is shorter than five years. The end date, to the month and year, must be clearly stated at the point of purchase.

A second horizon sits on top of it. Once issued, a security update must remain available for at least ten years from its release, or until the end of the support period if that ends later. This is an infrastructure commitment: somebody has to keep files and information reachable for a decade, across system and domain changes.

Vulnerability and incident reporting — the 11 September 2026 deadline

Article 14 introduces the obligations that start earliest and cover products already on the market. Actively exploited vulnerabilities and severe incidents affecting the security of the product must be reported to the CSIRT of the manufacturer’s main establishment and to ENISA, through a single reporting platform.

Stage	Deadline
Early warning	24 hours
Main notification	72 hours
Final report — vulnerability	14 days after a corrective measure is available
Final report — severe incident	1 month

The 24-hour early warning is an operational deadline, not a legal abstraction. It means the on-call rota, the escalation path and platform access must exist in advance. Micro and small enterprises are not fined for missing the 24-hour deadline, but the reporting duty itself still applies to them.

Information to users — Annex II

Annex II lists the information that must accompany the product: identification of the type, batch or serial number, manufacturer details including address and contact point, a single point of contact for reporting vulnerabilities and a pointer to where the disclosure policy can be found, the intended purpose, instructions for secure installation and operation, how to obtain security updates, and the end date of the support period.

Timeline

Date	What happens
10 December 2024	Regulation (EU) 2024/2847 enters into force
11 June 2026	Notified body provisions apply (Chapter IV)
11 September 2026	Reporting obligations apply (Article 14) — including for products already on the market
11 December 2027	Full application: essential requirements, conformity assessment, CE, documentation
11 June 2028	EU type-examination certificates issued in the transition period expire

Products placed on the market before 11 December 2027 become subject to the full requirements only if they are substantially modified after that date. The reporting obligations, however, cover them regardless.

It is worth reading these dates alongside the Machinery Regulation (EU) 2023/1230, which applies from 20 January 2027. A machine with digital elements falls into both regimes within less than eleven months: the Machinery Regulation treats cybersecurity as a functional safety requirement, while the CRA imposes horizontal obligations on software, controllers and connectivity. These are two complementary regimes, not alternatives.

What this means for product data

Let us be explicit, because this is often confused: the Cyber Resilience Act does not establish a digital product passport. There is no passport obligation in it, no data carrier and no registry. The passport obligation comes from ESPR and from sectoral acts that expressly mandate it.

But the set of information duties the CRA creates is a data management problem to a degree that is hard to overlook:

Identity at version level. The SBOM changes with every software release. A bill of materials that does not say which version it describes is useless as evidence. This is the same versioning-rather-than-overwriting principle the passport rests on.
The end-of-support date as a field, not a sentence in a leaflet. It must be given at purchase, consistent across every sales channel, and verifiable years later. A mismatch between the product page in your shop and the one at a distributor stops being cosmetic.
A resolvable data carrier. The vulnerability contact point, the disclosure policy and update information must be reachable throughout the support period. A code that resolves to the current record handles this better than an address printed in a manual six years ago. We cover the variants in our article on QR codes versus GS1 Digital Link.
Multilingualism. Annex II information must be intelligible to users in the countries where the product is made available. With digital documentation that is not a translation project but a field with language versions.
Continuity across a decade. Ten-year availability of updates and information is a service commitment that survives migrations, rebrands and changes of supplier.

For electronics there is a further practical argument. The same product category sits simultaneously in the sights of ESPR, the RoHS directive and e-waste rules. A company that keeps substance data in one place, repairability data in another and software support data in a third is maintaining three registers about the same product. Getting product data in order once serves all of these directions — a good starting point is our complete list of DPP data requirements.

An honest note on the limits of a provider’s role: myDPP does not perform security testing, does not generate or validate SBOMs, does not run the vulnerability handling process, does not assess CRA conformity, is not a notified body and does not file Article 14 reports. It stores, versions and publishes verified product data and maintains the carrier that opens it. Responsibility for compliance stays with the manufacturer.

Preparation — five steps

Classify the portfolio. Establish which products are products with digital elements, then which fall into Annex III class I or II, or Annex IV. That determines whether a notified body is needed — and how long assessment will take.
Stand up reporting before 11 September 2026. Name the responsible people, write down the escalation path for the 24-hour early warning, register for platform access and rehearse it on a test case. This deadline does not wait for the rest of the project to be ready.
Set support periods and record them as data. For each product family, fix an end-of-support date, justify it against the expected use time, and put it in the system that feeds your shop, your distributors and your documentation — not just in a product deck.
Build SBOM generation into the release process. A bill of materials assembled by hand once a quarter will diverge from reality at the first patch release. Binding the SBOM to a version and to an item is work on the data side, not the legal side.
Get the Annex II information in order. The contact point, the disclosure policy, secure configuration instructions and the end-of-support date must be consistent across every language and channel, and reachable for years.

The wider data programme is covered in our DPP implementation checklist.

Frequently asked questions

Does the CRA apply to products I sold before 2027?

Partly. The full requirements — essential requirements, conformity assessment, CE — reach a product placed on the market before 11 December 2027 only if it is substantially modified after that date. The Article 14 reporting obligations, however, cover products already on the market from 11 September 2026, regardless of when they were sold.

Do I have to publish an SBOM for my customers?

No. Annex I requires you to draw up and maintain a machine-readable bill of materials covering at least the top-level dependencies, and to make it available to market surveillance authorities on request. Publishing the SBOM to users is a commercial decision, not a legal obligation.

Can I set a support period shorter than five years?

Only where the product’s expected use time is shorter than five years, and you need to be able to justify that. Otherwise five years is the floor, and if the product is genuinely used for longer, the support period should reflect the actual use time.

Does the Cyber Resilience Act introduce a digital product passport?

No. The CRA contains no passport obligation and no data carrier requirement. What it does impose are product- and version-specific information duties that must remain available throughout the support period and for a decade after an update is issued. The data requirements converge with passport requirements, so one clean-up serves both directions.

Sources

Regulation (EU) 2024/2847 — Cyber Resilience Act — EUR-Lex
The Cyber Resilience Act — summary of the legislative text — European Commission
Regulation (EU) 2023/1230 — machinery — EUR-Lex
Regulation (EU) 2024/1781 (ESPR) — EUR-Lex
Delegated Regulation (EU) 2022/30 — cybersecurity under the Radio Equipment Directive — EUR-Lex