EU Cyber Resilience Act's vulnerability reporting duty has applied since 11 September 2026

A compliance deadline that many small software vendors may have missed has already passed. The EU Cyber Resilience Act (Regulation (EU) 2024/2847) does not apply in full until 11 December 2027, but according to a checklist for small vendors published on dev.to, its reporting duty for manufacturers has been in force since 11 September 2026 — and it reaches products with digital elements on the EU market, including products placed there before 2027.

The dev.to post summarises legal commentary from firms including McCann FitzGerald, Jones Day and Matheson, together with ENISA guidance. Its author frames it as a summary rather than legal advice and points readers back to the regulation and ENISA's own materials for their specific case.

What must be reported

Two categories trigger the duty, according to the post. One is an actively exploited vulnerability, meaning there is reliable evidence that a malicious actor has used the flaw without the permission of the system's owner. A vulnerability surfaced through good-faith research does not, on its own, require a report. The other is a severe incident that affects the security of the product.

The legal commentary cited in the post also takes the view that there is no duty to report, retroactively, exploitation the manufacturer already knew about before 11 September 2026.

How fast the clock runs

The deadlines run from the moment the manufacturer becomes aware, which the post defines as an initial assessment that gives reasonable certainty exploitation is under way:

• 24 hours for an early warning.
• 72 hours for a notification carrying more detail.
• A final report within 14 days after a fix or mitigation becomes available, for an exploited vulnerability; for a severe incident, within one month of the 72-hour notification.

Where reports go

ENISA's Single Reporting Platform is live for these duties, and a single submission goes to both ENISA and the CSIRT designated as coordinator — normally the one in the country of the manufacturer's main EU establishment. Manufacturers based outside the EU report through their EU authorised representative. Secondary sources described in the post say access runs through EU Login with multi-factor authentication.

The practical warning the post makes: register before an incident. A 24-hour deadline leaves no room to provision accounts while the clock is running.

Preparing a small team

The checklist suggests a lightweight setup:

• A monitored reporting inbox and contact point. Annex I of the regulation expects vendors to publish a way for outsiders to report vulnerabilities and to run a process for fixing them; a /.well-known/security.txt file (RFC 9116) is the common way to publish the contact, recommended by practitioners even though the regulation does not name it.
• A written coordinated vulnerability disclosure policy covering how reports are received, acknowledged and fixed.
• An on-call rule for the 24-hour clock: who decides exploitation meets the reasonable-certainty bar, and who files the report.
• A software bill of materials (SBOM) for each product, so the team can establish within hours whether a newly exploited library ships in the product.
• Monitoring of exploitation signals, such as known-exploited vulnerability catalogues, for the components being shipped, so awareness does not depend on a customer getting in touch.

The penalty exposure

For the most serious breaches of the regulation's essential requirements, fines can reach EUR 15 million or 2.5% of worldwide annual turnover, whichever figure is higher.

Why it matters

The CRA is widely treated as a December 2027 problem, but its reporting regime is live now and covers products already sold into the EU, not just new releases. For a small vendor, the binding constraint is the 24-hour early warning: without a pre-registered ENISA account, an SBOM to check affected components, and someone designated to make the reasonable-certainty call, the deadline can expire while the team is still triaging. The dev.to checklist is one practitioner's summary rather than legal advice, but the underlying point stands on its own — the reporting duty started on 11 September 2026, and a vendor that has done nothing about it is already exposed if an exploited vulnerability lands in its product today.