Skip to content
FortaRisks
Back to blogCompliance

Cyber Resilience Act: as of this morning, you have 24 hours to report an exploited flaw

September 11, 2026 · 10 min read

As of this morning, a manufacturer that sells a digital product on the European market and learns that one of its vulnerabilities is being actively exploited has twenty-four hours to report it. Not to fix it, not to understand it: to report it.

This is Article 14 of the Cyber Resilience Act, Regulation (EU) 2024/2847, which entered into force on 10 December 2024 and whose reporting obligations apply from 11 September 2026. The rest of the text, the essential cybersecurity requirements, the CE marking, the declaration of conformity, waits until 11 December 2027. But the part measured in hours starts today.

Most of the commentary published this year treated the CRA as a product compliance topic to prepare for 2027. That framing just expired. What enters into application today is not a documentation requirement, it is an incident response procedure with a stopwatch on it.

What applies exactly, and on what clock

Two events trigger the duty: an actively exploited vulnerability in a product with digital elements, and a severe incident having an impact on the security of that product.

A vulnerability counts as actively exploited when there is reliable evidence that a malicious actor has exploited it in a system without the permission of that system's owner. The bar is not the publication of exploit code, nor a mention on a forum: it is evidence of real exploitation.

An incident is severe when it negatively affects, or is capable of negatively affecting, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive data, or when it has led, or is capable of leading, to the introduction or execution of malicious code.

The reporting timeline has three stages, and it is the same for both.

Twenty-four hours: the early warning. Without undue delay after becoming aware, and in any event within twenty-four hours. The warning indicates, among other things, the Member States where the product is available. At that stage nobody expects an analysis: they expect a signal.

Seventy-two hours: the notification. The general information available about the product, the general nature of the exploit and of the vulnerability, and any corrective or mitigating measures taken or available.

Fourteen days or one month: the final report. Fourteen days after a corrective measure becomes available for an exploited vulnerability, with a description of the flaw, its severity, its impact and, where applicable, information about the malicious actor. One month after the 72-hour notification for a severe incident.

The recipient is the CSIRT designated as coordinator in the Member State where the manufacturer has its main establishment, meaning where decisions about the cybersecurity of its products are predominantly taken. The information goes to ENISA at the same time. It all passes through one channel, the Single Reporting Platform operated by ENISA, live as of today: you report once, and distribution to the relevant authorities is handled for you. Access requires an EU LOGIN account and the prior registration of an assigned representative. That is not the kind of formality you sort out during the twenty-four hours that matter.

There is also a duty people forget to quote, and it will be the most visible one: the manufacturer must inform the impacted users of the vulnerability or incident and, where applicable, of the mitigation and corrective measures they can apply.

The transitional clause few people read

This is where the topic stops being theoretical for a lot of organizations.

The transitional regime provides that products placed on the market before 11 December 2027 are subject to the regulation's requirements only if they undergo a substantial modification after that date. Sensible, and reassuring for an existing catalogue.

Except that Article 69(3) sets that exception aside for Article 14 alone: the reporting obligations apply to all products with digital elements placed on the market before 11 December 2027.

In other words, technical documentation, CE marking and the declaration of conformity will only concern what you place on the market from December 2027. The twenty-four hour clock covers, as of today, what you sold in 2015, in 2020 and last month, as long as the product is still on the market. A manufacturer that built its CRA plan around its next product line finds out this morning that its installed base was the subject.

Are you in scope, from Canada?

The regulation is scoped by market, not by geography. A manufacturer established outside the Union that places a product with digital elements on the European market is subject to Article 14 on the same terms as a German or French manufacturer.

The definition of a product is deliberately broad: any hardware or software product capable of connecting, directly or indirectly, to a device or a network. That covers licensed enterprise software, a mobile application, connected industrial equipment, a consumer electronics product, a networking component. For the ecosystem we serve in Quebec and Ontario, manufacturing, energy, logistics, B2B software vendors, it means three families of organizations are concerned.

You license software or a service to European customers. You build connected equipment that is exported to the Union. Or you are a subcontractor whose component is integrated into a product that is itself placed on the European market, in which case the question to settle with your client is who, contractually, is the manufacturer within the meaning of the regulation, and who reports.

The level of the penalty says enough about how the legislator sees this. A breach of Article 14 falls under the highest ceiling in the regulation, in Article 64: up to 15 million euros or 2.5% of total worldwide annual turnover, whichever is higher. That is the same ceiling as a breach of the essential cybersecurity requirements. The European regulator therefore treats failing to report as being as serious as selling an insecure product.

Why twenty-four hours is an operations problem, not a legal one

Compare the clocks. The GDPR allows 72 hours to notify a data breach. Law 25 requires notice promptly where there is a risk of serious injury. NIS2 imposes a 24-hour early warning, but on essential and important entities, about their own incidents.

The CRA asks you for twenty-four hours on an event that does not happen at your premises, but at your customers', on a product you sold. Three operational difficulties follow, and none of them is solved by a contract clause.

Detect. How do you learn that a flaw in your product is being exploited at a customer? Through a researcher, through an addition to CISA's KEV catalogue, through a customer calling your support desk, through a news article. If those four channels do not land in the same place, your twenty-four hour clock starts running without anyone knowing.

Qualify. Reliable evidence of exploitation is a judgement call, and it has to be made fast. This week's events show how uncomfortable that is: we noted on Friday that a vendor had written to its customers saying its flaw was being exploited, while its own release notes described a responsible disclosure with no confirmed exploitation. Two statements, one day apart, from the same vendor. Under the CRA that gap is no longer a communications slip: it is the starting point of a regulatory deadline, and it will have to be justified.

Report. The clock runs on calendar days. Friday evening and the Labour Day long weekend count the same as Tuesday morning. A procedure that depends on one person being reachable during business hours does not survive twenty-four hours.

What this calls for is not a compliance file. It is a named owner, an on-call rotation, a single channel where the four sources of signal converge, a written qualification criterion, and a reporting account created and tested in advance.

The other half of the story: you are also a buyer

The manufacturer reading is the one that worries people. The buyer reading is the one that pays off, and almost nobody is doing it.

The duty to inform impacted users means that your software and equipment vendors present on the European market now owe you information, knowingly, when a product of theirs that you use is being actively exploited. For a Canadian organization buying products that are also sold in Europe, and that is most of the tools in your stack, a transparency no contract guaranteed you becomes a regulatory obligation on the vendor.

Three things follow for your third-party risk management, to do before your next assessment campaign.

Add the question to the questionnaire: are your products placed on the European Union market, and are you therefore subject to the reporting obligations of Article 14 of the CRA? A yes gives you a basis to demand the same information, on the same clock.

Align your notification clause with that new floor. Many contracts provide for incident notification within 72 hours. A vendor subject to the CRA will produce a warning within 24 hours for the European authority: there is no reason its Canadian customer should learn about it three days later, or from the press.

And check that the information will land somewhere. A vendor notification that arrives in the generic inbox of a procurement team triggers nothing. It is the same blind spot described in our article on the eleven third-party vulnerabilities no questionnaire ever shows you: the information exists, it does not reach the person who decides.

Five things to do this week

  1. Settle whether you are a manufacturer under the regulation. List the products and software you place on the European market, directly or through an integrator. For each one, name who the CRA manufacturer is. If the answer is unclear on an integrated component, that is a question for your client this week, not in 2027.
  2. If you are, open the account now. Identify your coordinating CSIRT, create the EU LOGIN account, register the assigned representative on the Single Reporting Platform. Do it calmly, in advance.
  3. Write the qualification criterion. Half a page: what counts for you as reliable evidence of active exploitation, who establishes it, who decides to report, and what the default behaviour is in case of doubt. Doubt should lean towards reporting.
  4. Converge the four channels. Customer support, vulnerability disclosure inbox, monitoring of active exploitation catalogues, press. One arrival point, an on-call rotation that covers weekends.
  5. On the buyer side, add the CRA question to your vendor register and align your notification clauses. It is the fastest win in this whole affair, and it depends on nobody but you.

If you do not know today which of your vendors are subject to this obligation, nor where their notification would land, our free vendor security questionnaire already contains the subcontractor and incident notification sections this question builds on. And to connect a flaw listed in an active exploitation catalogue to what you actually expose, that is the job of the attack surface and third-party risk modules of the platform.

One last word on the calendar. The CRA joins a series we have been tracking for a year: NIS2 and DORA in Europe, Bill C-8 and the CPCSC in Canada. The movement is the same everywhere: reaction time becomes a number in a regulation, and accountability is named. A Canadian manufacturer that can report within twenty-four hours in Brussels will be able to do it in Ottawa.

Sources: Regulation (EU) 2024/2847, text of Article 14 · European Commission, CRA reporting obligations · European Commission, summary of the regulation · Text of Article 69, transitional provisions · Freshfields, reporting obligations take effect on 11 September 2026 · The National Law Review, key starting point for reporting obligations

30 minutes to know what to fix first.

A member of our team walks you through FortaRisks on threats relevant to your sector, and you leave with your priorities. No chatbot.