The Cyber Resilience Act's 24-hour reporting clock went live on September 11. Nothing about your security program is out of compliance because of it. Everything about the order in which you find things out has changed.
Last Friday, a reporting obligation switched on in Brussels that almost no American enterprise is directly subject to, and almost every American enterprise will feel. Article 14 of the EU Cyber Resilience Act became operative on September 11. From that date, any manufacturer placing a product with digital elements on the EU market — hardware, software, firmware, an operating system, a router, a mobile app, an industrial controller — has 24 hours to notify a regulator once it becomes aware that a vulnerability in its product is being actively exploited.
Not 24 hours to patch. Twenty-four hours to tell the authorities. A fuller assessment follows within 72 hours, and a final report within 14 days. Severe incidents affecting product security run on a parallel clock. Reports route through ENISA's single reporting platform to national CSIRTs, and the manufacturer also has to inform affected users about the flaw and what to do about it. Failure to report carries fines up to €15 million or 2.5% of global annual turnover, which is the number that makes legal departments answer the phone.
The compliance story here belongs to your suppliers. The operational story belongs to you.
Coordinated disclosure ran on the vendor's clock
For twenty-five years, the sequence was stable enough to build a process around. A researcher reports a flaw to the vendor. The vendor validates it, builds a fix, lines up a release, drafts an advisory, briefs its largest customers under embargo, and publishes the whole package on a Tuesday. Enterprises received the problem and the answer in the same email. Patch Tuesday is not a technical artifact; it is a disclosure-timing artifact.
That sequence was designed around a simple asymmetry: the vendor decided when the world found out, and it exercised that discretion to make sure a fix existed first. Everyone downstream — your patch windows, your change advisory board, your maintenance calendar, your customer notification templates — inherited the rhythm.
The CRA does not abolish coordinated disclosure. It inserts a mandatory, non-negotiable, extremely short reporting obligation at the front of it, triggered by active exploitation rather than by the vendor's readiness to respond.
The vendor no longer controls when the fact of the vulnerability starts moving. It only controls how fast it can build the fix that used to travel alongside it.
Those notifications are not published. ENISA and the CSIRTs are not running a public feed, and the regulation contains safeguards for reports that could compound the risk. But the number of institutions that know about an unpatched, actively exploited flaw in a product you run goes from one to several on day one — and the manufacturer's separate duty to tell affected users means your security operations team may hear about it before your account manager has been briefed, before an advisory exists, and possibly before a patch does.
What is in scope, and what quietly is not
The scope question matters more than usual, because the pattern of what is covered does not match how most organizations map their estate.
Figure 1
What you run | Covered by Article 14 reporting | What that means for your intake |
|---|---|---|
Operating systems, browsers, drivers, firmware | Yes, where sold or made available in the EU | Expect earlier, thinner notifications — fact first, fix later |
Network gear, IoT, building systems, industrial equipment | Yes | The category where the reporting party is often three tiers away from you |
Mobile and desktop applications | Yes | Notifications may arrive through an app-store or OEM channel nobody monitors |
Standalone SaaS | Excluded from the CRA | Your largest single class of dependency keeps its current disclosure behavior |
Medical devices and defense equipment | Excluded; governed by their own regimes | Unchanged, and the exclusion is frequently misread as blanket |
The split runs along product lines, not along risk. A cloud service you depend on entirely sits outside the regime; a $40 sensor sits inside it. Scope determinations are product-specific — this is a map of the pattern, not a compliance assessment.
The uncomfortable implication is that CRA-driven notifications will be loudest exactly where your asset inventory is weakest. Nobody struggles to know which operating systems they run. Plenty of organizations cannot produce a defensible list of the connected devices in their manufacturing plants, their retail estate, or the three buildings they acquired with the last company.
The window that did not exist before
Consider the new shape of a bad week. A component vendor discovers exploitation on Monday. It reports on Tuesday. It tells affected customers on Wednesday, because it must. The fix is not ready until the following week, because building, testing and shipping firmware takes longer than filing a form.
Your security team now holds something it has rarely had to hold before: confirmed active exploitation of a product in your environment, with no patch, and an obligation of its own to decide what to do about it. Compensating controls, segmentation, a service taken offline, a customer conversation. That decision used to be rare, reserved for the handful of vulnerabilities severe enough to break embargo. It is about to become ordinary.
There is a disclosure consequence attached. A US public company assessing whether a cybersecurity incident is material is working against a four-business-day filing clock once materiality is determined. The CRA does not change that standard. It changes when the facts arrive, which is the input the standard runs on — and it means a materiality assessment may now have to be made on a vendor's early notification rather than on a finished advisory.
Four things worth checking this quarter
Find out where these notifications will land.A vendor's regulatory-notification address is often the one on the purchase order. If a 24-hour-clock disclosure arrives in a procurement mailbox, it will be read on Monday.
Reread the notification clause, not the SLA.Most vendor security terms promise notification "without undue delay" after a fix is available. That language was written for the old sequence and now lags the vendor's own regulatory obligation by days or weeks.
Pre-agree the no-patch playbook.Decide now, in writing, who is authorized to isolate a system, disable a feature or take a service offline on the strength of a vendor notification with no fix attached. That authority is the whole difference between the new window being survivable and being chaotic.
Ask your top twenty suppliers one question.Are you in scope for CRA Article 14, and who do you consider the "affected user" you are obliged to notify — us, our reseller, or the end customer? The answers will be less consistent than you expect.
The part that lands in December 2027
Reporting is the first tranche. The CRA's substantive obligations — secure-by-design requirements, vulnerability handling, security update support periods, conformity assessment — apply from December 11, 2027. That is the deadline that will reshape what your vendors can sell you, and it is far enough out that it is currently being managed by product teams rather than by anyone you talk to.
Which is the reason to treat this month as the useful one. The reporting obligation is the first time the CRA produces something an enterprise buyer can observe: a vendor that notifies you inside the new rhythm is a vendor whose product organization is taking the rest of the regulation seriously. A vendor that goes quiet for three weeks and then sends a polished advisory is telling you something too.
Regulators wrote Article 14 to give European authorities visibility into exploitation they were not seeing. The side effect, which was not really the point, is that a large share of the world's technology buyers are about to learn about their own risk earlier, in worse shape, and without the answer attached. That is a better position than not knowing. It is not a more comfortable one.
Sources and notes. Regulation (EU) 2024/2847, the Cyber Resilience Act. Article 14 reporting obligations became applicable on September 11, 2026: 24-hour early warning for actively exploited vulnerabilities and severe incidents, followed by notification within 72 hours and a final report within 14 days for vulnerabilities (one month for incidents), submitted via the ENISA single reporting platform to the relevant CSIRT, with a parallel duty to inform affected users. The regulation applies to manufacturers inside and outside the EU placing products with digital elements on the EU market; standalone SaaS, medical devices and defense products are outside its scope. Administrative fines reach €15 million or 2.5% of worldwide annual turnover for reporting failures. Remaining obligations apply from December 11, 2027. These details are drawn from published law-firm guidance rather than from the regulation text, and scope determinations are product-specific — verify against the Regulation and with counsel before acting. The SEC's four-business-day Form 8-K cybersecurity disclosure requirement is referenced as context, not as CRA-derived. Journalism, not legal or compliance advice. Corrections welcome.
