CRA Reporting Obligations: The 24-Hour Clock Starts When You Find Out

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
Timeline showing the awareness gap before the CRA reporting obligations clock starts, from exploit forum posts to the 24-hour early warning deadline
Visual overview of the CRAR reporting process, highlighting key steps and deadlines for compliance.

What Changes on 11 September 2026

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.

Track one: an actively exploited vulnerability

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.

Track two: a severe security incident

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.

Track three: the people using the product

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.

CRA Reporting Obligations Hinge on One Phrase: Becoming Aware

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.

Why Awareness Is the Hard Part

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.

The exploitation window closes before most reporting windows open

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.

Coverage Follows the Market, Not the Head Office

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.

Closing the Awareness Gap Before 11 September

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.

Know what you actually shipped

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.

Watch the product from the outside

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.

Monitor where exploitation is discussed before it is disclosed

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.

Decide now who is allowed to say the word aware

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 Coverage

Brandefense CapabilityHow It Applies to CRA Reporting
EASMExternal 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 IntelligenceThreat 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 MonitoringCollection 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.

RELATED READING

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.

SHARE THIS

Get insight, Analysis &
News Straight to Your
Inbox

By submitting this form, you agree to our Privacy Policy

Latest News