AUGUST 27, 2026
On 11 September 2026 the EU Cyber Resilience Act stops being a design conversation and becomes a stopwatch. From that date, CRA reporting obligations require any manufacturer placing a product with digital elements on the European market to file an early warning within 24 hours of becoming aware that a vulnerability in one of its products is being actively exploited. Most of the preparation happening across the industry right now is aimed at the wrong half of that sentence. Teams are building reporting templates, assigning owners and mapping escalation paths, all of which addresses the 24 hours. Very few are working on the four words that actually start the clock: within 24 hours of becoming aware.
| 24 hours Early warning deadline for an actively exploited vulnerability, from 11 September 2026 (Source: Regulation (EU) 2024/2847, Article 14) | 88% Vulnerabilities exploited in H1 2026 that were attacked within 48 hours of disclosure (Source: CrowdStrike 2026 Threat Hunting Report) | EUR 15M Maximum administrative fine for breaching Article 14, or 2.5% of worldwide annual turnover, whichever is higher (Source: Regulation (EU) 2024/2847, Article 64) | 66% Organisations still unfamiliar with the CRA six months before the obligations begin |

The Cyber Resilience Act entered into force in December 2024 and its full set of essential requirements applies from December 2027. Article 14, the reporting article, arrives early. From 11 September 2026 manufacturers carry three separate reporting duties, and they run on different timetables — together, these form the CRA reporting obligations that take effect first, well ahead of the rest of the Act.
When a manufacturer becomes aware that a vulnerability in one of its products is being actively exploited, it files an early warning within 24 hours. A fuller vulnerability notification, carrying the assessment and any corrective or mitigating measures, follows within 72 hours. The final report is due no later than 14 days after a corrective or mitigating measure becomes available.
A severe incident affecting the security of the product triggers the same 24 hour early warning and the same 72 hour notification, but the closing report is due within one month rather than 14 days.
Separately from the regulator, affected users are informed without undue delay, together with the corrective or mitigating measures available to them. This duty has no fixed hour count attached to it, which in practice makes it the one most likely to be handled last and least well.
All regulatory reporting goes through a single route. The manufacturer reports once through the CRA Single Reporting Platform, the notification reaches the CSIRT of the member state where it has its main establishment, and the information is made available to ENISA at the same time. That receiving CSIRT then shares the notification without delay with every other CSIRT in whose territory the product has been made available.

Read Article 14 closely and the operative trigger is not the exploitation, the disclosure or the patch. It is awareness. The 24 hours run from the moment the manufacturer becomes aware, which means the regulation measures something the manufacturer controls only indirectly.
This produces an uncomfortable asymmetry. A manufacturer with excellent external visibility learns about exploitation early, starts its clock early, and reports on a timeline that looks responsive. A manufacturer with poor visibility learns about the same exploitation three weeks later from a customer, a journalist or a national CSIRT. Its 24 hour clock technically starts on time, because it started when awareness arrived, but by then the exploitation has been running for three weeks, other CSIRTs have not been warned, users have not been told, and the reporting record shows an organisation that was the last to know about its own product.
The regulation does not punish slow awareness directly. Market surveillance authorities, customers and the press will. And because every report lands on one shared platform, disclosure behaviour becomes comparable across an entire product category for the first time.
The gap between exploitation starting and a manufacturer noticing is not a paperwork problem. It is a detection problem, and the numbers say the window is narrow.
Eighty eight percent of vulnerabilities exploited in the first half of 2026 were attacked within 48 hours of disclosure, and the share of vulnerabilities compromised on or before their public disclosure date has reached 32.1%, meaning exploitation frequently precedes the existence of a fix at all. When roughly a third of exploitation happens before disclosure, the assumption that a manufacturer will find out through the ordinary disclosure process fails for a third of cases by definition.
There is also the case that flatters nobody: the slow exploitation. A critical virtualisation management flaw patched at the end of July 2026 saw no observed compromise for five days, then reached 343 networks in roughly 48 hours and 361 across 47 countries shortly after. Five days is generous by 2026 standards, and it is still shorter than most organisations take to notice that a shipped product is under attack.
One detail is routinely misread. The obligation attaches to manufacturers placing products with digital elements on the EU market, including manufacturers established outside the European Union. Coverage follows where the product is sold, not where the company is registered. A vendor headquartered anywhere in the world that sells connected products into the European market is fully inside scope, and so is a company that considers itself a software business rather than a manufacturer, if what it ships is a product with digital elements.
The financial exposure sits in the highest penalty tier. Non-compliance with Article 14 carries administrative fines of up to EUR 15,000,000 or 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher. Reporting is not a lower tier procedural duty in this regulation. It sits alongside the essential cybersecurity requirements themselves. That is what makes CRA reporting obligations a board-level risk item, not a documentation task.
The reporting workflow is the easy half and most teams will have it ready. The awareness half needs work that looks nothing like compliance work. Meeting CRA reporting obligations depends on solving that half first.
The 24 hour clock applies to products already on the market, including versions shipped years ago and still deployed. An inventory that covers what is currently supported is not the same as an inventory that covers what is currently running, and Article 14 cares about the second one.
Internal telemetry tells you about the instances you operate. It says nothing about the customer deployments that make up most of your installed base. External discovery of exposed instances of your own product, running versions you no longer support, is the single most direct way to shorten the gap between exploitation and awareness.
Exploit code, access listings and target lists circulate in closed forums and marketplaces well before a coordinated disclosure lands in your inbox. For the third of cases where exploitation precedes disclosure, this is often the only channel through which awareness can realistically arrive in time.
Awareness is a legal state with a 24 hour consequence, so the moment it is reached should be a named decision by a named role, recorded with a timestamp. Left undefined, it becomes a question answered retrospectively by a regulator, which is the worst possible time to answer it.
| Brandefense Capability | How It Applies to CRA Reporting |
| EASM | External Attack Surface Management discovers exposed instances of your own products, shadow IT, forgotten subdomains and certificates, which is how you learn what is still deployed and reachable before someone else tells you. |
| Cyber Threat Intelligence | Threat actor tracking and TTP mapping across 36+ detection mechanisms and 13,000+ security controls surface active exploitation of the technologies you ship, which is the signal that starts the Article 14 clock. |
| Dark Web Monitoring | Collection across surface, deep and dark web through 190+ sensors in 40+ countries, around the clock, covers the closed channels where exploit code and target lists circulate before coordinated disclosure. |
Understanding the EU Cyber Resilience Act: Strengthening Digital Security Across the EU: https://brandefense.io/blog/eu-cyber-resilience-act-strengthening-security/ Background on the regulation itself, its scope and its security by design requirements.
No Patch Exists Yet: Who Owns the Pre-Disclosure Window?: https://brandefense.io/blog/pre-disclosure-exploitation/ The ownership question behind the third of exploitation that happens before a fix exists.
Vulnerability Exploitation Trends: H1 2026: What Threat Actors Are Actually Using: https://brandefense.io/blog/vulnerability-exploitation-trends-h1-2026/ The exploitation timing data this article draws on, including the negative mean time to exploit.
Why Vendor Security Questionnaires Don’t Work (And What Actually Does): https://brandefense.io/blog/why-vendor-security-questionnaires-dont-work/ Why point in time attestation fails against continuous risk, the same failure mode as annual product security review.

Take control of your digital security with an exclusive demo of our powerful threat management platform.