You have probably been treating the EU Cyber Resilience Act (CRA) as a 2027 problem: 11 December 2027 is when the full product-security requirements land. But there is a second date, and it has already passed. Article 14’s reporting duties began binding manufacturers on 11 September 2026, applying to products already on the EU market, wherever your business is headquartered.
Those are two different obligations: a build you can plan for, and an event-triggered clock already running. Here is what fires it, where the reports go, and how it sits against NIS2, GDPR and the wider software supply chain security in 2026 compliance picture.
What does the EU Cyber Resilience Act Article 14 actually require of manufacturers?
Article 14 is a notification duty. It obliges the manufacturer of a product with digital elements to report two events: an actively exploited vulnerability, or a severe incident affecting its security. You are not required to hold an SBOM or disclosure policy upfront; those live in Article 13 and Annex I, later.
When an event happens, a staged clock starts: a 24-hour early warning, a 72-hour detailed notification, and a final report within 14 days of a corrective measure, or one month for a severe incident. For a vulnerability, the 14-day final report runs from when a fix becomes available, not from awareness.
The clock starts on “becoming aware”: reasonable certainty an event occurred, not the first alert or the end of an investigation. Miss the window, and Article 64(2) puts breaches of Articles 13 and 14 in the top penalty tier: €15 million or 2.5% of worldwide turnover.
“Actively exploited” is defined narrowly in Article 3(42): reliable evidence that a malicious actor has exploited a vulnerability without the owner’s permission. A disclosed-but-unexploited CVE, a proof of concept, or a bug from a bounty program does not qualify; a missing patch is irrelevant.
A severe incident, defined in Article 14(5), is broader: anything that negatively affects, or is capable of affecting, a product’s availability, authenticity, integrity or confidentiality, or that could introduce or execute malicious code in build and distribution infrastructure. Capability is enough; you do not get to wait for realised harm, as Ecocomply observes.
The authoritative sources are Regulation (EU) 2024/2847 on EUR-Lex and the ENISA guidance around the Single Reporting Platform. A report is only as good as the component inventory behind it: if you cannot answer “which products and versions contain this?” inside 24 hours, that is what an SBOM or attestation actually proves. The duty carries no EU-establishment qualifier: it sits on manufacturers of products with digital elements, so a scope and category assessment decides who is caught.
Why did the CRA reporting duties begin on 11 September 2026, ahead of the 2027 requirements?
The reporting duty is already live, and it was brought forward deliberately. Article 71(2) phases the CRA in three steps: conformity assessment bodies from 11 June 2026, Article 14 alone from 11 September 2026, and everything else from 11 December 2027.
Early warning of actively exploited vulnerabilities has immediate value: exploitation intelligence flows to ENISA, national CSIRTs and Member State authorities as soon as the platform is live. That is the whole point, and a real case like this npm worm shows the kind of event the clock exists to catch. Article 14 is event-triggered and needs no upfront preparation, whereas Article 13 and Annex I demand systemic change and the longer runway.
Reports are filed through the ENISA Single Reporting Platform, which routes one submission to the coordinating CSIRT and ENISA simultaneously. For manufacturers with no EU establishment, Article 14(7) sets a cascade: authorised representative, then the largest importer, then the largest distributor, then the highest user concentration. The cascade fixes the postbox but never moves the duty off the manufacturer.
How does CRA Article 14 reporting differ from NIS2 and GDPR notification duties?
Reporting is only one of several clocks that can start on the same event. They look similar, so they get conflated. All three ask the same question: has something crossed the line where someone outside the organisation needs to know? As Sysdig puts it, each regime chose its own word for that line: the CRA says “severe” (or “actively exploited”), NIS2 says “significant”, GDPR says a risk to people’s rights and freedoms.
The triggers differ in kind. CRA Article 14 is product-centred, firing on something you sell. NIS2 is entity-centred, firing on a significant incident affecting an essential or important entity’s services. GDPR Article 33 is data-centred, firing on a personal-data breach. The clocks differ too: 24/72/14 or one month for the CRA, 24/72/one month for NIS2, a flat 72 hours for GDPR. The recipients differ: coordinating CSIRT and ENISA, national competent authority, supervisory authority.
The consequence is that one supply-chain compromise can start all three clocks at once, each with its own deadline and recipient. You cannot discharge one by complying with another; scope for one does not imply the others. One detection process that forks at the point of sending is the practical way to handle that.
The microenterprise carve-out in Article 64(10) excuses micro and small enterprises from fines for the 24-hour early warning only. It does not excuse reporting, and the later deadlines still apply.
How should you prioritise a CRA reporting capability against the December 2027 essential requirements?
The sequence follows once you accept that the reporting duty is already live. Build the reporting capability first: it binds from 11 September 2026 and is the first place fines will land. Then build toward the Annex I essential requirements and CE marking that arrive on 11 December 2027.
Both share one foundation: SBOM generation and impact analysis. It identifies affected products and versions fast, inside the 24-hour window today, and underpins Annex I conformity later. A manufacturer cannot report what it cannot detect, as Element’s guidance puts it.
Scope follows the product. If your software is placed on the EU market, you carry the duty regardless of where your business is headquartered, and an authorised representative or importer only changes where the report is received. This is the perimeter that SBOM and impact analysis are built to defend, and it sits inside the supply chain compliance picture.
Conclusion
Article 14 is an event-triggered clock that has been running since 11 September 2026, and treating the CRA as one uniform 2027 problem leaves you exposed on the only part of the regime that already binds. The near-term job is a minimal 24-hour capability built on the SBOM foundation described above, with the Annex I requirements and CE marking to follow. The defensible response throughout is a single process that forks into each notification. For the perimeter, the threat and the clock that frame this series, the pillar page is the place to start.
Frequently Asked Questions
What counts as an “actively exploited vulnerability” under the CRA?
It means there is reliable evidence that a malicious actor has exploited a vulnerability in a system without the owner’s permission, as defined in Article 3(42). The definition is deliberately narrow: it excludes disclosed but unexploited CVEs, proof-of-concept code and good-faith bug-bounty research. A published CVE on its own does not start the 24-hour clock.
Where do I report an actively exploited vulnerability or severe incident under Article 14?
Reports go through the ENISA Single Reporting Platform, which routes one submission to the coordinating CSIRT and ENISA at the same time. If your company has no EU establishment, Article 14(7) sets a routing cascade (authorised representative, then largest importer, then largest distributor, then highest user concentration), but that only fixes the reporting postbox. The duty stays with you as the manufacturer.
Where can I find the official EU Cyber Resilience Act text and ENISA guidance?
The authoritative source is Regulation (EU) 2024/2847 on EUR-Lex, which carries the full Article 14 text and the phased application dates. ENISA publishes the supporting guidance, including documentation for the Single Reporting Platform, and the Commission issues implementation guidance. Treat these primary sources as your reference point rather than second-hand summaries of the CRA.
Does the CRA Article 14 reporting duty apply to companies outside the EU, such as Australian firms?
Yes. The duty attaches to manufacturers of products with digital elements that reach the EU market, and it carries no EU-establishment qualifier. An Australian firm whose software is placed on the EU market carries the same reporting obligation as a European one, regardless of where the company is headquartered. Scope follows the product, not the company’s address.
Does appointing an authorised representative remove my CRA Article 14 reporting duty?
No. An authorised representative or an EU-based importer changes where the report is received, not who owes it. Article 14(7)’s cascade simply gives manufacturers with no EU establishment a defined reporting postbox. The legal duty to detect, classify and notify an actively exploited vulnerability or severe incident stays with the manufacturer, wherever it is based.
Do I need an SBOM before I can file a CRA Article 14 report?
No. Article 14 creates no upfront SBOM mandate; it is an event-triggered reporting duty, and nothing in it requires a completed inventory before you notify. In practice, though, a report is only as good as the component inventory behind it, because you need to answer “which products and versions contain this?” inside the 24-hour window. An SBOM makes that answer fast and defensible.
Does the microenterprise carve-out exempt small businesses from CRA reporting altogether?
No, and this is a common misreading. The Article 64(10) carve-out excuses micro and small enterprises from fines tied to the 24-hour early warning only. It does not exempt them from reporting, and it does not shield them from the 72-hour detailed notification, the final report, or the penalties attached to those. An SMB should still verify its position during scope and category assessment.
What is a “product with digital elements” under the CRA?
It is any software or hardware product, including its remote data processing solutions, that is placed on the EU market and connects to a device or network. That covers most commercial software, embedded firmware and connected devices. Article 14’s duty sits on the manufacturers of these products, so classifying whether your offering is a product with digital elements is the first step in deciding if the CRA catches you.
What happens if I miss the 24-hour CRA early warning deadline?
The 24-hour early warning is a legal deadline, not a best-effort target, and missing it exposes you to the same enforcement as any other Article 14 failure, with fines up to €15 million or 2.5% of worldwide annual turnover. Because the clock starts the moment you have reasonable certainty an event occurred, a slow internal detection or escalation process is the most common way firms blow the window.
Do I need to report when the exploited vulnerability sits in a third-party component I use?
Often yes. Article 14 is triggered by the effect on your product, not by who wrote the vulnerable code. If an exploited vulnerability or severe incident affects a product with digital elements that you place on the EU market, the duty falls on you as its manufacturer, even when the flaw originates upstream. This is why dependency visibility and impact analysis belong in your reporting capability from day one.
Does the CRA Article 14 duty apply to open-source software maintainers?
It depends on how the software reaches the market. A purely non-commercial open-source project that is not placed on the EU market as a product generally falls outside the manufacturer duty. Once code ships as part of a product with digital elements, the manufacturer placing it on the market carries the Article 14 obligation. Commercial open-source vendors that put software on the market are manufacturers in their own right.
Do I need a CRA reporting process if my products never reach the EU market?
No. Article 14 is a market-based duty, so if none of your products with digital elements are placed on the EU market, the reporting obligation does not attach. The trap works the other way: a single EU customer or distributor can pull a product into scope, so confirm your market reach before assuming you are clear.
