Cyber Magazine flagged the milestone in its weekly cybersecurity roundup, but the practical change is narrower—and more urgent—than a broad new duty to disclose every software flaw. The new rule targets vulnerabilities under active malicious exploitation and severe incidents that affect the security of a product with digital elements. For Windows developers, device makers, enterprise software vendors, and organizations shipping firmware or management tools into the EU, the key work now is operational: determine who can declare an incident reportable, who can file it, and how the company will do that over a weekend.
The deadline began more than a year before the CRA’s broader product-security requirements take effect on December 11, 2027. That staggered rollout means a vendor can face an Article 14 reporting duty now even though the full conformity, documentation, and CE-marking regime has not yet arrived.
The 24-hour clock covers exploitation, not every CVE
The reporting trigger is important. A vulnerability does not become reportable merely because it receives a CVE identifier, a high CVSS score, or a proof-of-concept on GitHub. The CRA’s mandatory reporting provision applies when a manufacturer becomes aware that a vulnerability in its product is being actively exploited, or when a severe incident affects the product’s security.
The distinction is consequential for security teams already overwhelmed by vulnerability feeds. A newly disclosed remote-code-execution flaw in a Windows application may demand triage and patch development, but Article 14 does not make every such disclosure a 24-hour ENISA filing. Evidence of exploitation changes the legal response.
The underlying CRA text describes active exploitation as a malicious actor using a product flaw in a way that results in a security breach affecting users or other people or organizations. It also distinguishes ordinary good-faith testing, investigation, correction, and coordinated disclosure from reportable malicious exploitation. In plain terms, a responsible researcher’s report is not itself the reportable event; credible evidence that attackers are abusing the flaw is.
That creates a difficult but familiar detection problem. Vendors will need a defined route from threat intelligence, customer escalations, bug-bounty submissions, endpoint telemetry, and incident-response findings to a legal and security decision. A product security team that identifies exploitation on Friday evening cannot wait for a weekly vulnerability review or a board-level risk committee to decide whether the clock has started.
The report proceeds in stages through ENISA’s portal
The European Commission and ENISA have set up the CRA Single Reporting Platform as the route for mandatory notifications. A manufacturer submits one notification through the platform; it is routed to the CSIRT designated in the country of the manufacturer’s main EU establishment and, barring exceptional circumstances, made available to ENISA at the same time.
The first submission is deliberately an early warning, not a complete forensic report. Within 24 hours, the manufacturer must provide available information on the affected product and whether the event may involve malicious action. Within 72 hours, it must provide a notification with more detail, including an initial assessment of severity and impact, the vulnerability or incident type, mitigation measures, and recommended action for users where appropriate.
The final deadlines differ by event type:
- An actively exploited vulnerability requires a final report no later than 14 days after a corrective or mitigating measure becomes available.
- A severe incident requires a final report within one month of the 72-hour notification.
That sequence recognizes the reality that an organization rarely has definitive facts on day one. But it does not permit a manufacturer to wait for certainty before escalating a credible exploited-vulnerability signal. The Commission’s guidance expects reports to be updated as the investigation develops.
ENISA’s current platform guidance also exposes a practical limitation: there is no API in the platform’s initial release. Companies may automate their internal intake, enrichment, approval, and evidence gathering, but the notification itself must currently be submitted through the portal interface. For a large vendor handling many products and regions, that makes named human ownership and tested credentials part of incident preparedness—not administrative cleanup.
Older products are already in scope
The most easily missed feature of the new duty is its reach into existing product lines. The law explicitly applies Article 14 reporting obligations to products with digital elements that were placed on the EU market before December 11, 2027. A vendor cannot assume that an application, appliance, driver, or connected peripheral shipped years ago is outside the reporting regime simply because the CRA is not yet fully applicable.
ENISA’s FAQ makes the boundary more precise. A manufacturer does not have to retrospectively file a report for exploitation it already knew about before September 11, 2026. But if it becomes aware after that date that an older or previously known vulnerability is actively being exploited, the notification obligation can apply.
That distinction will matter most to firms with long support tails: Windows line-of-business software vendors, makers of VPN appliances and endpoint agents, industrial-control suppliers, network hardware manufacturers, and SaaS operators that distribute on-premises components. The question is no longer solely whether a product is still marketed. It is whether the product remains within the CRA’s scope and whether a new awareness event has occurred.
A severe incident can also arise from the vendor’s own development, production, or maintenance environment when it raises user risk. The CRA specifically contemplates an attacker inserting malicious code into a release channel used to distribute security updates. The SolarWinds lesson is embedded in the regulation’s architecture: compromise of a build or update path can become a product-security incident even when the flaw is not a conventional product bug.
Open-source reporting is later, despite early confusion
One point in early coverage needs correcting. TechTarget’s pre-deadline explainer described open-source software stewards alongside manufacturers in the September 2026 reporting milestone. The European Commission’s implementation page and ENISA’s FAQ say the reporting obligation for open-source software stewards under Article 24(3) begins on December 11, 2027, when the CRA applies more broadly.
That does not mean free and open-source software is irrelevant to the current phase. A commercial manufacturer that integrates an affected open-source component into its own product can still have an Article 14 obligation. The manufacturer placing the finished product on the EU market cannot treat upstream open source as a reporting escape hatch.
The later date matters for maintainers, foundations, and companies trying to map their compliance obligations accurately. It also prevents an unhelpful assumption that every independent project maintainer now has to use ENISA’s mandatory reporting portal. ENISA says the platform currently supports mandatory manufacturer notifications; people who are not manufacturers and want to report a vulnerability are directed to the relevant national CSIRT.
For companies commercializing open-source software, the more immediate issue is product ownership. A company that bundles, brands, materially modifies, or markets software under its own name may be treated differently from a community project that develops software outside a commercial activity. That analysis belongs in the product’s legal and supply-chain records before a security incident makes it urgent.
Reporting is a security workflow, not a compliance mailbox
The CRA’s immediate effect is to compress the handoff between detection and disclosure. An organization with a mature security operations center can still fail if its SOC sees exploitation evidence but has no product-security escalation path, no inventory that maps a component to customer-facing products, and no designated EU reporting owner.
For Windows and enterprise IT vendors, a workable response plan should include a short, rehearsed chain of decisions:
- The company should identify every product line sold or made available in the EU, including legacy supported releases, firmware, agents, plugins, and bundled third-party components.
- The security team should define the threshold for “awareness” of active exploitation and preserve the evidence behind both reporting and non-reporting decisions.
- Product security, legal, incident response, customer support, and communications teams should agree on a 24-hour escalation channel with named alternates.
- The designated reporting representative should confirm EU Login access to the CRA Single Reporting Platform before an incident occurs.
- Customer-notification procedures should be prepared alongside regulatory reporting, because the CRA expects users to be informed about severe incidents and available corrective measures.
The financial stakes are material. The CRA allows administrative fines of up to €15 million or 2.5% of worldwide annual turnover, whichever is higher, for violations of the relevant core obligations. Enforcement will depend on national market-surveillance authorities, and the regulation includes support measures for smaller businesses. But a small vendor should not read that as a grace period from the reporting clock.
The immediate test is less about whether a company has completed a 2027 CRA roadmap than whether it can recognize an exploited flaw in a shipped product, make a defensible decision quickly, and file an initial warning inside 24 hours. As of September 11, that is no longer an exercise for next year’s compliance calendar.