A new compliance clock started running across Europe on September 11, 2026. Under Article 14 of the EU Cyber Resilience Act, any manufacturer selling a product with digital elements into the EU market, from industrial controllers to consumer apps, must now report an actively exploited vulnerability within 24 hours of becoming aware of it. A fuller notification is due within 72 hours, and a final report follows within 14 days of a fix becoming available. The obligation does not wait for the CRA’s broader design and lifecycle requirements, which do not bite until December 2027. It is live today, and it changes who inside a security organization has to move fastest when a zero-day turns up in production.
What actually changed today
The EU Agency for Cybersecurity (ENISA) marked the day by deploying what it calls the initial operating capability of the Single Reporting Platform (SRP), the online tool manufacturers and open-source software stewards now use to meet their CRA reporting duties. The pitch is simplicity: report once, and the platform routes the notification to every national Computer Security Incident Response Team (CSIRT) with jurisdiction over a market where the affected product is sold, while ENISA itself receives the information at the same time.
“Vulnerabilities in digital products are often exploited by threat actors to subvert or hamper critical services, such as healthcare, energy, transport or telecommunications,” Juhan Lepassaar, ENISA’s executive director, said in the agency’s launch statement. “The streamlined reporting and sharing of information on actively exploited vulnerabilities and severe incidents helps to build a more resilient Digital Single Market.”
Media Partner
That framing matters because the CRA’s reporting duty is not aimed at every vulnerability a vendor finds. It is triggered specifically by active exploitation, the same threshold CISA uses for its own Known Exploited Vulnerabilities catalog, and by “severe incidents” affecting the security of a product with digital elements. Routine bug fixes and internally discovered flaws that nobody has exploited stay outside Article 14’s 24-hour window.
How the clock actually runs
The European Commission’s own guidance on the reporting obligations lays out three fixed deadlines, all measured from the moment a manufacturer becomes aware of the qualifying event, not from when the flaw was introduced or even when it was first discovered internally by an engineering team that has not yet escalated it:
- An early warning within 24 hours, flagging that an actively exploited vulnerability or severe incident exists.
- A more detailed notification within 72 hours, adding the information gathered so far.
- A final report no later than 14 days after a corrective or mitigating measure becomes available, for vulnerabilities, or within one month of the 72-hour notification, for severe incidents.
Manufacturers submit once, to the CSIRT covering the EU member state where they have their main establishment (a separate rule sets the coordinating CSIRT for manufacturers based outside the bloc). That CSIRT then disseminates the notification, without delay, to every other CSIRT in a territory where the product is available, and to ENISA. There is one safety valve: under a delegated act the Commission adopted in December 2025, a CSIRT can delay onward dissemination in exceptional, cybersecurity-justified circumstances, so a still-unpatched flaw is not blasted across two dozen national response teams before a fix exists.
Manufacturers also have a separate duty to notify affected users of an actively exploited vulnerability or severe incident, and of any available fix, “without undue delay,” according to the Commission’s guidance.
Who this actually reaches
The Commission’s own framing of the CRA leans on ordinary, unglamorous examples rather than enterprise infrastructure: baby monitors, smartwatches, mobile apps, computer programs. That is deliberate. The regulation defines “products with digital elements” broadly enough to cover almost anything connectable, from consumer IoT to industrial control systems to the software a business sells outright, which means the reporting duty that started this week is not confined to the security vendors and cloud platforms this desk usually covers. A hardware manufacturer whose smart thermostat firmware gets actively exploited is now on the same 24-hour clock as an enterprise software vendor whose product gets hit by a nation-state actor.
The CRA entered into force in December 2024. Its headline requirements, the ones that force security-by-design and secure-by-default engineering into a product’s full lifecycle, do not become enforceable until December 2027. What went live this week is narrower and, in the short term, more operationally disruptive: the reporting duty in Article 14, which the regulation front-loaded well ahead of the rest of the rulebook specifically because a functioning early-warning system across the EU depends on companies actually using it before an incident forces the question.
Open-source software stewards are named in the same reporting framework, under Article 24(3) of the CRA, but their obligation does not start until December 2027, giving foundations and maintainer collectives a much longer runway than commercial manufacturers get.
The Commission has been trying to soften the landing. On July 27, 2026, it published practical guidance aimed at manufacturers, developers and businesses “of all sizes,” with particular attention to microenterprises and small and medium-sized businesses: 67 worked examples, use cases, flowcharts and graphs meant to answer the questions companies were actually asking, including when a product counts as in scope at all, what a “substantial modification” is, and how the reporting and risk-assessment duties work in practice. The guidance is explicitly non-binding. It is a compliance aid, not a safe harbor.
The Commission also describes the CRA as complementing the NIS2 Directive rather than replacing it, and the distinction matters for anyone trying to map their compliance obligations. NIS2 obligates a defined set of “essential” and “important” entities, hospitals, energy operators, digital infrastructure providers and similar, to report significant cyber incidents affecting their own operations. Article 14 of the CRA obligates manufacturers, a much broader and less sector-specific population, to report exploited vulnerabilities and severe incidents in the products they sell. A hospital and its medical-device supplier can each be on the hook for a report about the same underlying flaw, filed to different regulators under different rules, for different reasons.
What it means for the security leader
For a CISO or product security lead, Article 14 adds a new kind of clock to a calendar that already has several. GDPR’s 72-hour breach notification rule is a familiar rhythm inside most EU-facing organizations, and US-listed companies have been living with the SEC’s four-business-day disclosure trigger for material cybersecurity incidents, the rule this desk covered when Veradigm’s stolen vendor credentials became a public 8-K filing. Article 14 is a different animal from both. It is not about personal data, and it is not about materiality to investors. It is about exploited vulnerabilities in the product itself, and the trigger is “became aware,” a standard that puts pressure on internal escalation paths long before legal or communications teams are usually looped in.
That has a few concrete consequences. First, someone has to own the moment a vulnerability report, a threat-intel feed, or a customer ticket crosses the line from “reported” to “actively exploited and we know it.” Waiting for a formal CVE, a vendor advisory, or a Patch Tuesday bundle to start the clock is not compliant if a security team already has evidence of in-the-wild exploitation from its own telemetry. Second, the reporting obligation sits with the manufacturer, not the EU customer, which means any company selling software or connected hardware into the EU market now needs a defined internal owner for CRA submissions, whether or not it has a legal entity based in a member state. Third, the penalties are real: failures on core obligations, and the CRA classifies the Article 14 reporting duties as core, can draw fines of up to 15 million euros or 2.5 percent of global annual turnover, whichever is higher.
There is also a patch-prioritization angle. CyberTech has covered how a bare CVSS score tells a security team almost nothing about which flaw to fix first, and CISA’s Known Exploited Vulnerabilities catalog exists precisely to separate theoretical severity from active risk. Article 14 effectively exports that same exploited-in-the-wild logic into EU law and attaches a legal clock to it, which means a vulnerability management program’s existing “is this being exploited” triage step is no longer just a prioritization tool. For any product sold into the EU, it is now the input to a legal deadline.
The part that is still being built
ENISA was careful to describe today’s launch as the “initial operating capability” of the Single Reporting Platform, not a finished system. The agency says it will continue expanding the platform’s functionality over the coming months based on operational experience and user feedback, and it thanked national CSIRTs, the CRA Expert Group and a group of manufacturers who helped test the tool before launch. That is a reasonable way to ship a piece of shared EU infrastructure, but it also means the first cohort of manufacturers filing 24-hour warnings this month are doing so against a platform that its own operator says is still evolving. Security and legal teams that assume the SRP behaves like a mature, stable reporting channel from day one should plan for friction, not certainty, in exactly the early weeks when getting the process right matters most.
What to do now
Security leaders whose products reach the EU market, directly or through a distributor, have concrete work to do this quarter. Map which products qualify as having “digital elements” under the CRA’s broad definition, since it reaches well beyond traditional software into connected hardware and firmware. Assign a named owner, likely a joint function of security operations, product security and legal, for the decision of when the organization has “become aware” of active exploitation, since that moment starts the 24-hour clock regardless of whether a formal advisory exists yet. Confirm who inside the company will actually submit through the Single Reporting Platform and make sure that person has access before an incident forces a scramble. And treat the Commission’s July guidance and its 67 worked examples as the starting reference for edge cases, since the guidance, unlike the regulation itself, is written for the messy real-world question of whether a given product is even in scope.
Source: ENISA
