From 11 September 2026, a manufacturer that becomes aware of an actively exploited vulnerability in a product with digital elements has 24 hours to file an early warning with EU authorities. The obligation reaches backwards: it covers products already on the market, including ones shipped years ago and no longer under active development.
The obligation to have a vulnerability-handling process does not start until 11 December 2027. For fifteen months, manufacturers are legally required to report what they are not yet legally required to be looking for.
What the September obligation actually is
The Cyber Resilience Act, Regulation (EU) 2024/2847, entered into force on 10 December 2024. Its main obligations apply from 11 December 2027, which is the date most planning has been built around. Article 14 runs on a separate clock, and that clock starts first.
Two things trigger it: an actively exploited vulnerability contained in the product, and a severe incident having an impact on the product’s security. The timeline is staged — an early warning within 24 hours of becoming aware, a full notification within 72 hours, and a final report no later than 14 days after a corrective measure is available for an exploited vulnerability, or within a month for a severe incident.
“Actively exploited” is narrower than it sounds. It means evidence of real attacks against the product, not theoretical exploitability. A proof of concept or a research finding does not start the clock.
What “aware” means is the operationally difficult part. The Commission’s March 2026 draft guidance set the threshold at a reasonable degree of certainty that a vulnerability is being actively exploited or that a severe incident has compromised the product’s security. In practice that certainty often arrives only after an initial assessment, and manufacturers may hold off notifying until that assessment is complete. An ongoing investigation aimed at full forensic confirmation, however, is in principle no defence for missing the deadline.
Reports go in once, through the CRA Single Reporting Platform that ENISA is required to establish under Article 16. The notification is addressed to the CSIRT designated as coordinator where the manufacturer has its main establishment, and — absent particularly exceptional circumstances — reaches ENISA at the same time. That CSIRT then passes it to CSIRTs in every member state where the product has been made available.
The part that catches people
Article 69(3) is the provision to read before planning around December 2027. It applies Article 14 to products with digital elements that were placed on the EU market before 11 December 2027. A product shipped in 2015 and still on the market is in scope for reporting from September, regardless of what it predates.
Set that against the timing of everything else, and the shape of the gap becomes clear:
- Reporting duty: 11 September 2026, covering the installed base.
- Vulnerability-handling requirements in Annex I: not legally binding until 11 December 2027.
- Essential cybersecurity requirements and conformity assessment: also 11 December 2027.
The practical consequence is that a manufacturer’s September exposure is determined by how quickly it learns things, not by how compliant its products are. Nothing in the Act obliges you to run threat intelligence, monitor exploitation of your own installed base, or maintain intake for third-party reports until the end of 2027. But once something reaches you through any route — a customer, a researcher, a vendor advisory, a news report — the 24-hour clock is running.
One more asymmetry worth noting: where the actively exploited vulnerability sits in an integrated component rather than the manufacturer’s own code, the obligation to notify still falls on the manufacturer of the product.
Whether the reporting channel itself is safe: an argument that has not been settled
The design requires manufacturers to hand governments detailed information about vulnerabilities that are being exploited and, by definition, may not yet be fixed. That has been contested since the legislative stage, and the disagreement is worth understanding on its own terms rather than as a settled question.
The objection during the negotiations, raised by the Electronic Frontier Foundation among others, was directed at what was then Article 11 of the proposal. EFF’s concern was that a reporting duty of this kind raises the risk of a vulnerability being “added to the offensive arsenal of government intelligence agencies.” A separate open letter from security researchers made a related argument: that dozens of agencies holding a live register of unmitigated vulnerabilities creates both a surveillance risk and an attractive target, and urged that only vulnerabilities with available mitigations be reportable.
The final regulation answers part of this through Article 16(2), which lets a manufacturer flag one of three narrow conditions in its 72-hour notification: that exploitation is confined to the member state of its own CSIRT, that wider dissemination would run against that state’s essential interests, or that dissemination poses an imminent high cybersecurity risk. Where a condition is flagged, ENISA initially receives only limited information — that a notification exists, general detail about the product, the general nature of the exploit — until the CSIRT releases the full text. A CSIRT may also delay dissemination where a coordinated vulnerability disclosure procedure is under way. On 11 December 2025 the Commission adopted a delegated act specifying the terms and conditions for applying those cybersecurity-related grounds.
Two points survive that machinery. The first is structural: flagging sensitivity limits who sees the content, but nothing pauses the filing itself. The 24-hour, 72-hour and final-report windows all run from awareness, and the decision to hold back dissemination belongs to the receiving CSIRT, not to the manufacturer.
The second came from the Cybersecurity Coalition and the Hacking Policy Council in their comments on the draft delegated act. Their argument is that the act addresses risk in sharing between CSIRTs but not in the leg before it — between manufacturer and CSIRT. They point to a specific case: a CSIRT may delay reporting via the Single Reporting Platform where the platform has itself been compromised, yet manufacturers are still required to submit through that same platform, and nothing requires ENISA to tell them about such an incident. On their reading, “manufacturers could unknowingly report vulnerabilities through a compromised or insecure channel.”
Reading the delegated act does not dissolve the disagreement. The Commission’s position is that Article 16 and the delegated act provide proportionate safeguards; the industry groups’ position is that the safeguards sit one link further down the chain than the risk. Both readings are available on the text. If your reporting process depends on how this resolves — because you ship security products, or operate in a sector where an unpatched-vulnerability disclosure carries second-order risk — this is a question for security counsel, not for a checklist.
Scope guidance arrived seven weeks before the deadline
Article 26 obliges the Commission to publish guidance helping economic operators apply the CRA, with particular attention to smaller businesses. It approved that guidance on 27 July 2026, document reference C(2026) 5252 — roughly 80 pages, with worked examples and flowcharts, following a consultation draft issued on 3 March 2026. It is not legally binding, but it is the reading that market surveillance authorities and notified bodies will work from.
Most of it addresses scope, which is where the genuine uncertainty has been. For free and open-source software, the guidance confirms that software published without being placed on the market generally falls outside the CRA. Where the publisher is a legal person meeting the definition of an open-source software steward under Article 3(14), only the obligations in Article 24 apply, with steward reporting duties calibrated to the support actually provided.
The line the guidance draws around commercial activity is the operative one. Selling the software, offering a paid enterprise edition, monetising services through it, requiring personal data beyond security or interoperability purposes, or making donations effectively mandatory for access or essential updates all bring a project into scope. Voluntary donations, sponsorships, public funding, and paid consulting, training or support do not, provided the software itself stays freely available. A contributor submitting patches or fixing bugs generally carries no CRA responsibility; obligations attach to whoever controls releases, roadmap and governance. An organisation publishing both a free community edition and a paid enterprise edition is steward of the first and manufacturer of the second — two regimes, same codebase.
If you are not established in the EU
Article 14 sets a sequence for determining which CSIRT receives the notification when the manufacturer has no main establishment in the Union: the authorised representative, then the importer, then the distributor, then the location of users. Working out that answer at the moment a 24-hour clock starts is the wrong time to do it. It is a question to settle in advance and write into the incident procedure, alongside who inside the organisation is authorised to decide that the awareness threshold has been met.
Frequently asked questions
Do I need a full vulnerability-handling process by 11 September 2026?
Not as a legal matter. The vulnerability-handling requirements in Annex I are not binding until 11 December 2027. From September 2026 the only obligation is to report actively exploited vulnerabilities and severe incidents. In practice the two are hard to separate — you cannot report reliably what no process is built to detect — but the deadlines are distinct and require different preparation.
Does this apply to products I shipped before the CRA existed?
Yes. Article 69(3) extends the Article 14 reporting obligations to in-scope products placed on the EU market before 11 December 2027. Age of the product is not a defence, and the practical work is inventorying what you still have on the market.
Can I delay reporting while I investigate?
Only up to a point. The clock starts at a reasonable degree of certainty, and the Commission’s guidance accepts that certainty may require an initial assessment. Continuing to investigate toward full forensic confirmation is in principle not a defence for missing the window. Separately, flagging sensitivity under Article 16(2) limits who sees the content — it does not pause the filing.
Does my open-source project fall under the CRA?
It depends on whether it is placed on the market in the course of a commercial activity. Free availability with voluntary donations, sponsorship or public funding generally stays outside scope; paid editions, monetised services, or donations that are effectively required for access bring it in. The Commission’s July 2026 guidance works through the borderline cases in detail and is the right document to check a specific project against.
What happens if I miss a deadline?
Enforcement sits with national market surveillance authorities, and the CRA’s enforcement model runs primarily through corrective measures rather than immediate financial penalties. That is a weaker deterrent than the AI Act’s or the GDPR’s, and it is also a reason not to treat September as soft: a corrective-measures process aimed at your product line is disruptive in ways a fine is not.