Since 11 September, any company that sells software or connected products in the EU has had 24 hours to warn the authorities when a flaw in one of its products is actively exploited. The clock starts when you find out, not when you have a fix. For products built on components that have gone out of support, hour one is the hardest hour, and most manufacturers haven’t rehearsed it.
The EU’s Cyber Resilience Act won’t fully apply until 11 December 2027, but its reporting duties started early. Since 11 September 2026, Article 14 has required manufacturers to report actively exploited vulnerabilities and severe incidents affecting the security of their products. Reports go through a Single Reporting Platform that ENISA, the EU’s cybersecurity agency, switched on the same day, to the national CSIRT acting as coordinator and to ENISA itself.
The deadlines are tight. An early warning is due “without undue delay and in any event within 24 hours” of the manufacturer becoming aware. A fuller notification follows within 72 hours, covering the nature of the exploit and the “corrective or mitigating measures that users can take”. A final report is due no later than 14 days after a fix or mitigation is available for an exploited vulnerability, or within a month of the notification for a severe incident.
And the duty reaches back. Article 69(3) applies the reporting obligations to every product in scope placed on the market before 11 December 2027. That includes everything you’ve already sold. ENISA has confirmed there’s no duty to report, after the fact, exploitation a manufacturer knew about before 11 September, but anything you learn about now counts.
The duty to report doesn’t wait for a patch, and it doesn’t care how old the product is.
Who the Clock Applies To
The Act covers products with digital elements: software and hardware with a data connection to a device or a network, from installable applications and firmware to connected devices and appliances. A manufacturer is whoever places the product on the EU market under its own name or trademark, wherever it’s based. A UK software house or device maker with EU customers is in scope. Without an EU establishment, it reports to the CSIRT in the Member State of its authorised representative, then its importer, then its distributor, and failing those, wherever most of its users are.
It’s narrower than it sounds in one respect. The Commission’s guidance says websites that don’t support the functionality of a product aren’t products with digital elements, and standalone software-as-a-service generally sits outside the Act unless it’s the remote data processing behind a product. So the council websites that went offline for PHP2Shell in October weren’t a CRA matter. A vendor whose self-hosted product, appliance or device admin console runs on PHP would have been.
PHP2Shell Shows Where It Bites
In October, PHP2Shell put two critical flaws in PHP itself into the open. Exploitation attempts were seen four days before disclosure, and the fixes only shipped for PHP’s supported branches, 8.2 to 8.5. Most PHP installations that reveal their version run something older.
Now picture a manufacturer whose product ships with PHP inside. If the flaw is actively exploited in that product, the clock starts when the manufacturer becomes aware, even though the vulnerable code belongs to someone else. The Commission’s guidance is explicit: where an actively exploited vulnerability in an integrated component affects your product, you must notify it. Where it can’t be exploited in your product, it isn’t subject to mandatory reporting, but you’ll want the evidence to show that. Separately, Article 13(6) requires manufacturers to report vulnerabilities they find in a component, “including in an open source-component”, to whoever maintains it.
End of life is where it gets hard. PHP 8.1 reached end of life on 31 December 2025, and PHP 8.2 loses security support on 31 December 2026, at the end of this month. For products placed on the market from December 2027, the Commission’s guidance says that when a component is out of support and a flaw can’t be mitigated, the manufacturer “is required to remediate the vulnerability via other means, for example by switching out the integrated component or developing a patch autonomously.” For products already sold, the reporting duty applies now, and the 72-hour notification still has to tell users what they can do.
If a component can’t be patched, your report still has to tell customers what to do instead.
What You’d Need to Know in Hour One
The 24-hour early warning is short by design, but it isn’t empty. It has to say, where applicable, which Member States the product is available in. To file it, and the 72-hour notification after it, you’ll need answers to six questions fast.
Which products and versions contain the component? You need a software bill of materials for every release you support, searchable in minutes. A spreadsheet updated at release time won’t tell you which version a customer is actually running.
Is it being exploited in your product? That takes threat intelligence, your own telemetry, customer reports and CSIRT alerts, and a named person who decides when the evidence means “actively exploited”.
Where is the product sold? The early warning names the Member States affected, so sales and distribution data has to be at hand, not in a quarterly report.
Who files, and where? Someone needs an account on ENISA’s platform and to know which CSIRT is your coordinator before the day comes. The platform launched without an API, so filing is a manual job for now.
What can customers do today? You need a mitigation you can publish within 72 hours, even if the fix is weeks away, and a way to reach affected users. Article 14(8) requires you to inform them, where appropriate in a structured, machine-readable format.
What’s the support status of every component? Know which components are out of support, who maintains them, and what you’d ship if their maintainers can’t.
Rehearse It Before It’s Real
Run the clock on last month’s flaw. Take PHP2Shell, or any critical flaw in a component you ship, and run a tabletop exercise against your real products. Time how long each of the six answers takes. Most teams find the gaps in the first hour, which is the point.
Decide in advance who can switch things off. If the only mitigation is disabling a feature or taking a service offline, someone needs the authority to do it at two in the morning. We set out the decisions to make before the next flaw in Taking the Website Offline Was the Plan.
Make upgrades routine. The products that cope best are the ones where shipping a new runtime is an ordinary change. Upgrading platform debt in small, tested slices beats waiting for a programme big enough to fund. AI can help with the fixing as well as the finding, as we argued when the Budget funded AI to find flaws.
Make the support period a design decision. For products placed on the market from December 2027, Article 13(8) requires a support period of at least five years unless the product’s expected use is shorter. Choose components whose own support outlasts the period you promise, or budget for replacing them.
The stakes are real. The Act sets fines for breaching Articles 13 and 14 of up to €15m or 2.5% of worldwide annual turnover, whichever is higher, though micro and small enterprises can’t be fined for missing the 24-hour early warning deadline. The fine isn’t the main risk. Discovering your gaps with the clock already running is.
Q&A: The Cyber Resilience Act’s Reporting Duties
What does the Cyber Resilience Act require manufacturers to report?
Actively exploited vulnerabilities and severe incidents affecting the security of their products. An early warning is due within 24 hours of becoming aware, a notification within 72 hours, and a final report within 14 days of a fix being available for a vulnerability, or within a month of the notification for an incident.
When did the CRA reporting obligations start?
On 11 September 2026, when ENISA’s Single Reporting Platform went live. The rest of the Cyber Resilience Act applies from 11 December 2027.
Does the CRA apply to products already on the market?
Yes, for reporting. Article 69(3) applies the reporting obligations to all products in scope placed on the market before 11 December 2027. Most other obligations, such as vulnerability handling, apply only to products placed on the market from that date.
Does the Cyber Resilience Act apply to UK companies?
Yes, if they place products with digital elements on the EU market under their own name or trademark. A UK manufacturer without an EU establishment reports to the CSIRT in the Member State of its authorised representative, importer or distributor, or where most of its users are.
Do vulnerabilities in open-source components have to be reported?
If an actively exploited vulnerability in an integrated component affects your product, you must notify it under Article 14. If it can’t be exploited in your product, it isn’t subject to mandatory reporting. Article 13(6) also requires manufacturers to report vulnerabilities they find in components, including open-source ones, to the component’s maintainer.
Working Through This With Vertex Agility
As an AI-native transformation consultancy, we help software and product teams make security a delivery capability rather than a scramble. Our Modern App Discovery Quickstart maps your applications, runtimes and dependencies and gives you a risk register with the business impact of each. Our Security Healthcheck tests how quickly you’d find and fix exposure, and our Compliance & Governance Framework builds the evidence and ownership a regulator will ask for.
If you’d like a quick read on where you stand, our free Downtime Defence Audit scores your incident response, monitoring, backups, resilience and disaster recovery in minutes. It’ll show you which parts of hour one you’d struggle with first.