EU Cyber Resilience Act Article 14 reporting analysis

A vulnerability ticket used to be a queue item. As of September 11, for products with digital elements sold in the European Union, it can also be a regulatory clock. The Cyber Resilience Act is still mostly waiting in the wings, which is exactly why Article 14 matters: one part of the law has arrived early, and it lands directly inside incident response. The practical question is not whether a product team has read the CRA. It is whether someone can decide, inside 24 hours, whether an actively exploited vulnerability or serious incident must be reported, who files it, and what evidence goes with it. Lawyers call this a reporting obligation. Builders should call it a production workflow with a regulator at the end.

The part of the CRA that is already on the calendar Pearl Cohen describes

the CRA as being implemented in three phases: obligations for conformity assessment bodies from June 11, 2026, Article 14 vulnerability reporting from September 11, 2026, and the full CRA from December 11, 2027. Cybersecurity Time adds the useful correction that the Act entered into force on December 10, 2024, while its main obligations apply later. That distinction is not academic; it means teams can be out of scope for the full product requirements today and still in scope for reporting. Pearl Cohen says the CRA covers both hardware and software products with digital elements placed on the EU market. That is the phrase software vendors should underline, preferably before sales signs another EU customer on a Friday afternoon. This is not just a connected thermostat problem; it can reach software products if they are covered products with digital elements.

What Article 14 actually requires

Crowell says the Article 14 CRA reporting obligation applies from September 11, 2026, and can be enforced from that date, while the rest of the CRA generally applies from December 11, 2027. The firm also says manufacturers submit one notification through the single reporting platform to the relevant Computer Security Incident Response Team designated as coordinator and to ENISA. That notification is then shared with other relevant CSIRTs as appropriate, which is mercifully different from regimes where the filing map becomes its own incident. The legal text of Article 14 says a manufacturer must notify any actively exploited vulnerability in a product with digital elements once it becomes aware of it, simultaneously to the CSIRT coordinator and ENISA, using the single reporting platform. It also requires an early warning within 24 hours of awareness, and a further vulnerability notification within 72 hours unless the relevant information has already been provided. The 72 hour notice must include, as available, general information about the product, the nature of the exploit and vulnerability, corrective or mitigating measures taken, and measures users can take. Translated into operations, Article 14 means your incident workflow needs at least four fields that security tickets often scatter across chat, postmortems, and release notes. You need the affected product, the general exploit and vulnerability description, what the company has done, and what users can do. If that information is not capturable quickly, the reporting problem is already visible.

Who should care, including non

EU sellers Faegre Drinker frames the September 2026 deadlines as applying to connected product manufacturers and notes extraterritorial reach for US businesses. Pearl Cohen’s summary of Commission guidance confirms that the CRA applies to hardware and software products placed on the EU market. In plain English: being incorporated outside the EU is not a magic invisibility cloak if the product is made available there. This is where vendor contracts and internal ownership matter. If a manufacturer depends on a managed service provider, reseller, vulnerability researcher, cloud host, or component supplier to learn about exploitation, the company still needs a path from that signal to the Article 14 decision maker. The evidence provided here does not say every supplier must file, so do not let compliance folklore outrun the text. The safer operational move is to make sure contracts require prompt security notice, usable technical detail, and cooperation on mitigation communications. Crowell also flags authorized representatives and escalation processes capable of running against the 24 hour clock. That is a polite way of saying the reporting route cannot live in one person’s inbox. Product, security, legal, support, and customer communications need a rehearsed handoff, because the clock starts when the manufacturer becomes aware, not when the perfect postmortem draft is ready.

What to operationalize

this week Crowell recommends table top exercises, staff training, and cyber policy updates in response to the Article 14 clock. Those are not ceremonial compliance objects if they test the right failure modes: who identifies active exploitation, who decides severity, who opens the single reporting platform process, and who approves user mitigation language. A table top that ends with everyone agreeing to investigate further is not readiness; it is a meeting with snacks. The useful split is between what the law requires now and what the internet will claim it requires. Now: reporting of actively exploited vulnerabilities and serious incidents under Article 14, with a 24 hour early warning and a 72 hour follow up route, according to Crowell and the Article 14 text. Later: the full set of CRA essential cybersecurity requirements, which Pearl Cohen says applies from December 11, 2027. For builders, the immediate work is small but unforgiving. Map products sold or placed on the EU market, define awareness triggers, prepare notification templates, assign an authorized representative where needed, and rehearse the route to the single reporting platform. Then keep watching the gap between Article 14 enforcement and the full CRA date, because regulators tend to learn from the first filings long before the first fine appears.