Since September 11, 2026, any company selling connected hardware or software into the European Union has had 24 hours to alert the authorities once it learns that a flaw in one of its products is being exploited. The duty comes from Article 14 of the Cyber Resilience Act, Regulation (EU) 2024/2847, and it is the first obligation the law places on manufacturers. Most of the rest of the regulation applies from December 11, 2027.
Until then, horizontal EU cybersecurity law had reached the operators of networks and services, while product makers were covered only by sector rules such as those for medical devices and vehicles. The fines behind the new rule sit in Article 64, which like most of the regulation applies from December 11, 2027; from then, breaches of the security requirements or of the reporting duty can draw fines of up to 15 million euros or 2.5 percent of worldwide annual turnover, whichever is higher.
Three deadlines and a single portal
Two kinds of event trigger a report. One is an actively exploited vulnerability, meaning there is reliable evidence of exploitation in a system without the owner's permission. The other is a severe incident affecting the product's security: one that hits its ability to protect important or sensitive data or functions, or that has led or could lead to malicious code running in the product or in a customer's network.
Both follow three steps. The early warning must arrive within 24 hours of the company learning of the problem, and for incidents it must say whether unlawful or malicious acts are suspected. A fuller notification follows within 72 hours, with details of the product, the exploit or incident, and any mitigations. The final report falls due 14 days after a fix or workaround becomes available for a vulnerability, or, for an incident, one month after the second notification. Affected users must be told as well.
Everything goes through the single reporting platform that ENISA built under Article 16 and brought online on September 11, 2026. A manufacturer files once, to the national CSIRT of the member state where its product security decisions are mainly taken; ENISA sees the filing at the same moment, and the receiving CSIRT forwards it to its counterparts in every country where the product is sold. At launch the platform was a web form in English with no API, reached through an EU Login account with multifactor authentication.
Who is covered, and who is not
The regulation reaches any software or hardware product, including components sold separately, whose intended or reasonably foreseeable use involves a direct or indirect link to a device or a network. Where the maker sits is irrelevant; placing the product on the EU market is what counts, and an importer or distributor that rebrands or substantially modifies a product takes on the manufacturer's duties.
The exclusions are sectoral. Medical devices and in vitro diagnostics, vehicles under EU type approval, certified aircraft, marine equipment, and products developed solely for national security or defense are all outside. So are websites that do not support a product's functionality and cloud services designed outside the manufacturer's responsibility; software sold as a service is a matter for the NIS2 directive instead.
Open source gets its own treatment. It is in scope only when supplied as part of a commercial activity. For organizations that sustain such projects without selling them, the law creates the open source software steward: a legal person, not itself a manufacturer, that gives sustained support to particular open source products intended for commercial use. Stewards must document a security policy covering vulnerability handling, assist market surveillance authorities on request and, from December 11, 2027, report exploited vulnerabilities to the extent they take part in development.
What arrives in December 2027
The reporting duty is the advance party for a much longer list. From December 11, 2027, manufacturers must handle vulnerabilities throughout a support period of at least five years, or the product's expected lifetime if that is shorter, and keep each security update available for at least 10 years. Annex I also demands a machine readable software bill of materials listing at least the top level dependencies, a coordinated vulnerability disclosure policy, security updates shipped separately from feature updates where feasible, and Article 13 adds a single point of contact for users.
Article 64 sets three tiers of fines. Breaches of Annex I or of the manufacturer duties in Articles 13 and 14 carry the top tier; most other operator obligations carry 10 million euros or 2 percent of turnover; supplying incorrect or misleading information to a notified body or market surveillance authority carries 5 million euros or 1 percent. Two carve outs are fixed in the text: micro and small enterprises cannot be fined for missing the 24 hour early warning deadline, and open source stewards cannot be fined at all.
The CRA is built to sit beside the NIS2 directive rather than replace it. NIS2 governs the operators of critical services; the CRA governs the products those operators buy. The two meet in the plumbing: the CSIRTs that receive CRA notifications are the coordinators designated under NIS2, and member states are encouraged to set up single national entry points so that one event is reported once under the GDPR, NIS2 and the CRA. For a vendor that is itself a NIS2 operator, the practical task ahead of December 2027 is one triage procedure that decides, within hours, which regime an event falls under and who files what.
