EU Cyber Resilience Act: Your Sept 2026 Disclosure Deadline

From 11 September 2026, the EU Cyber Resilience Act requires manufacturers of products with digital elements to report actively exploited vulnerabilities to their national CSIRT and ENISA on a three-stage clock: an early warning within 24 hours, a full notification within 72 hours, and a final report within 14 days of a fix being available. Standing alongside it, the regulation requires a coordinated vulnerability disclosure (CVD) policy with a public point of contact so researchers can report bugs directly. Miss it and the fines reach up to €15,000,000 or 2.5% of worldwide annual turnover, whichever is higher.

If you ship software into the EU, the word “manufacturer” almost certainly includes you, the date is closer than you think, and “we don’t have a process for that yet” is no longer a defensible answer. Here is what the law actually requires, the two deadlines everyone confuses, and the minimum operational layer a small team needs to be ready.

The clock you didn’t know was running: 11 September 2026

The headline date is 11 September 2026, when the CRA’s reporting obligation enters application. From that day, manufacturers must report actively exploited vulnerabilities and severe incidents through the ENISA Single Reporting Platform. This is the first substantive deadline of Regulation (EU) 2024/2847, ahead of the rest of the regulation, and it is the one most likely to catch small vendors flat-footed.

Most CRA coverage targets enterprise hardware makers and large product-security teams: SBOMs, CE marking, conformity assessment. That framing has convinced a lot of founders the CRA is somebody else’s problem. It is not. The reporting clock starts for everyone in scope on the same day, and a 20-person SaaS company with a downloadable agent is just as bound as a device manufacturer.

The practical consequence is uncomfortable. If a vulnerability in your product is actively exploited the week after the deadline, you have 24 hours to file an early warning. If you have no intake, no triage, and no idea who at your company owns that filing, you find all of that out under the worst possible time pressure.

Are you a “manufacturer of a product with digital elements”?

You probably are. The CRA defines a product with digital elements as essentially any software or hardware that connects to a device or network, and it places the core obligations on the manufacturer, a term that explicitly includes software developers who commercialize a product.

That sweeps in far more than connected gadgets. Consider whether any of these describe you:

• A SaaS product with a downloadable desktop app, browser extension, or local agent.
• A connected device or any hardware with firmware.
• A commercial software library, SDK, or self-hosted product sold or licensed into the EU.
• A solo founder or maintainer who commercially supports software used in the EU.

Importers and distributors carry lighter duties, but if you build and sell the thing, you are the manufacturer. The open-source nuance matters here too: purely non-commercial open source generally sits outside the manufacturer obligations, but the moment you monetize it (paid support, a commercial edition, a hosted version) you step into scope.

The CRA is not legal advice territory you can hand-wave. If you are unsure whether a specific product is in scope, that is a conversation for counsel. But the default assumption for a software company selling into the EU should be “in scope until proven otherwise,” not the reverse.

What the CRA actually requires for vulnerability disclosure

The EU Cyber Resilience Act requires manufacturers to operate a coordinated vulnerability disclosure policy with a public point of contact, and from 11 September 2026 to report actively exploited vulnerabilities to their CSIRT and ENISA within 24 hours (early warning), 72 hours (full notification), and 14 days (final report after a fix is available). Two distinct obligations sit underneath that summary, and they come from two different articles.

The CVD policy and point of contact (Article 13). Article 13(8) requires manufacturers to “have appropriate policies and procedures, including coordinated vulnerability disclosure policies … to process and remediate potential vulnerabilities … reported from internal or external sources.” Article 13(17) requires a single point of contact so that anyone, including security researchers, can report a vulnerability directly. Crucially, it must let reporters choose their communication channel; you cannot force everyone through a single automated tool.

The reporting obligation (Article 14). This is the 24 / 72 / 14 clock to regulators, and it is where the fixed-hour deadlines live.

One myth needs killing here. Several vendor blogs claim the CRA imposes a 48-hour deadline to acknowledge a researcher’s report. It does not. The statutory text of Article 13 contains no fixed-hour acknowledgment deadline at all. The only fixed-hour clocks in the regulation are the regulator-reporting ones under Article 14. Treat an acknowledgment SLA as a best practice your policy should define, not a number to attribute to the law.

The 24 / 72 / 14 reporting cadence, and what triggers it

For an actively exploited vulnerability or a severe incident, the reporting cadence is a three-stage clock, all measured from when you become aware:

You file once. The Single Reporting Platform, established, managed, and operated by ENISA, routes your notification simultaneously to the CSIRT designated as coordinator in your main-establishment member state and to ENISA. That receiving CSIRT then disseminates to other relevant national CSIRTs without delay. The platform also accepts voluntary reports of vulnerabilities, threats, incidents, and near misses from anyone.

The trigger is narrow, and getting this right matters as much as the deadlines. The 24-hour clock starts only for an actively exploited vulnerability, meaning there is reliable evidence a malicious actor has exploited it, or for a severe incident, meaning a severe impact on the product’s availability, authenticity, integrity, or confidentiality. Not every bug a researcher reports trips the regulator clock. Most will not. But you cannot tell the difference without a triage step that can quickly classify what just landed in your inbox, which is precisely why a running intake-to-triage pipeline is the operational core of CRA readiness.

The two deadlines people confuse: 2026 vs. 2027

A lot of secondary coverage blurs two dates into one, and the confusion creates a false sense of safety. Keep them separate:

• 11 September 2026 — the reporting obligation (Article 14) applies. The 24 / 72 / 14 clock to ENISA and your CSIRT is live.
• 11 December 2027 — the CRA’s main application date, when the standing manufacturer obligations, including the Article 13 CVD policy and single point of contact, apply to products placed on the market.

It is tempting to read the 2027 date and conclude you have eighteen months of breathing room. You do not. The reporting clock starts in 2026, and you cannot meet a 24-hour reporting obligation without already having the intake, triage, and ownership in place that the CVD policy describes. The 2027 obligation formalizes the process; the 2026 obligation assumes you can already run it. In practice, that means the disclosure infrastructure needs to exist this year.

What a compliant CVD flow must contain

Synthesizing the statute with practitioner guidance, including HackerOne’s CRA readiness guidance, a defensible coordinated disclosure flow has six parts:

1. Public, documented intake. A single point of contact, in practice an RFC 9116 security.txt file plus a published policy page, so a researcher who finds a bug knows exactly where to send it.
2. Declared scope. Which products and versions are covered, what is explicitly out of scope, and which vulnerability classes you do not accept.
3. Triage and validation. The step that decides whether a report is an actively exploited vulnerability or severe incident, the trigger for the 24-hour clock.
4. Coordination with the reporter. A real channel for dialogue with the researcher before public disclosure.
5. Remediation without undue delay and a public advisory once a fix ships.
6. Auditable records. Traceable ownership and a timeline you can hand to a market-surveillance authority on request.

That last point is the one teams skip and regret. “We coordinated responsibly” is a claim. A timestamped timeline showing when the report arrived, when it was triaged, when the reporter was updated, and when the fix shipped is evidence. Under a regulation with revenue-scaled fines, the difference between a claim and evidence is the entire game.

The price of getting it wrong

Non-compliance with the essential requirements and the Article 13/14 obligations is subject to administrative fines of up to €15,000,000 or up to 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher. Two lower tiers sit beneath it:

The “whichever is higher” construction is the part founders underestimate. For a small company the absolute euro figures look like enterprise problems, but the percentage tiers scale down with you and the structure of the regulation means the process failures (no CVD policy, a missed report, a misleading filing) are exactly the ones that are cheap to prevent and expensive to ignore.

Build a CRA-ready coordinated disclosure process with Kit

The CRA converts coordinated vulnerability disclosure from a maturity nice-to-have into a legal obligation with a hard date and a revenue-scaled downside. For most founders the gap is operational, not philosophical: you need an intake, a triage process, an SLA clock, a coordination channel, and an audit trail, and you need them before September. Standing that up from scratch under deadline pressure is the trap. Kit’s CSIRT vertical is that operational layer, and it maps almost one-to-one onto what the regulation asks for.

• Public VDP intake. A live security portal plus a generated RFC 9116 security.txt (with contact, policy, acknowledgments, and encryption fields) gives you the Article 13(17) single point of contact and the published CVD policy in one move. This is the same foundation we covered in how to set up a vulnerability disclosure program, now with a legal deadline attached.
• Scope validation. A configurable scope (in-scope targets, out-of-scope categories, excluded vulnerability types) plus automatic scope checking on intake gives you the documented policy the statute demands and the basis for validating reports as they arrive.
• Severity triage. Built-in severity suggestion, assessment, and duplicate detection are the triage step that identifies an actively exploited vulnerability or severe incident, the precise trigger for the regulator clock.
• SLA tracking. A live timer with severity-based targets and compliance metrics gives you the clock and the evidence that you hit it. Kit’s default acknowledgment and resolution SLAs deliberately echo the regulator cadence, though they are best practice, not statutory acknowledgment numbers.
• Researcher coordination. Threaded messaging keeps the coordinated, pre-public dialogue the statute calls for in one auditable place.
• Auditable report timeline. An exportable chronology turns “we coordinated responsibly” into the traceable record a market-surveillance authority can ask for.

The honest framing matters. Kit operationalizes the disclosure, coordination, and record-keeping layer. It is not legal advice, it does not file to the Single Reporting Platform for you, and it does not cover the CRA’s product-security and conformity duties like SBOMs and CE marking. For those, talk to counsel. What Kit gives you is the CVD backbone: the running process that means when a researcher finds a bug, or a vulnerability turns out to be exploited, you can intake it, triage it, coordinate it, and produce the timeline, instead of discovering on 11 September 2026 that you have no process the day a regulator clock starts.

Coordinated disclosure was always the right thing to do for the researchers who find your bugs. The CRA just made it the defensible thing to do for your business. The flow that makes you a good actor toward researchers is the same flow that makes you compliant, and the cheapest time to build it is before the deadline, not after the first exploited bug. Start your free trial and stand up a CRA-ready disclosure process while there is still slack in the clock.