Most conversations about the EU Cyber Resilience Act treat December 2027 as the deadline. It is not the first one. On September 11, 2026 - less than four months away - the CRA's mandatory vulnerability and incident reporting obligations enter into force. From that date, if an actively exploited vulnerability is discovered in a connected product you sell in the EU, you have 24 hours to notify the authorities.
This obligation applies to products already on the market. Not just new releases. Not just products launched after December 2027. If your device is for sale in the EU today, this deadline applies to you now.
If you are not yet familiar with CRA and the full compliance picture, our complete guide to the EU Cyber Resilience Act is the right starting point. This article focuses specifically on the September 2026 reporting obligations and how to build the operational capability to meet them.
What Article 14 actually requires
The reporting obligations come from Article 14 of the CRA regulation. The structure is precise and the timelines are not suggestions.
| Trigger | Deadline | What to report |
|---|---|---|
| Awareness of actively exploited vulnerability | 24 hours | Early warning: confirm the vulnerability exists and is being exploited |
| Same | 72 hours | Full notification: nature, impact, affected products, interim mitigations |
| Fix available | 14 days after fix | Final report: root cause, CVE reference, fix details, user recommendations |
| Severe security incident (active breach) | 24 hours / 72 hours / 1 month | Same three-stage structure |
These reports go through ENISA's Single Reporting Platform (SRP), which will be operational before September 11. You report once; the platform routes the notification to your national CSIRT and to ENISA simultaneously. You do not need to identify and contact your national CSIRT separately.
The part that makes this hard in practice
Reading those timelines, a reasonable response is: "24 hours seems manageable. We find a vulnerability, we send an email."
That is not how it works.
First, you need to know a vulnerability is being actively exploited. That means you need monitoring - not "we check the CVE database occasionally" monitoring, but active tracking of your component versions against new vulnerability disclosures. If your product uses a library that gets a critical CVE on a Tuesday morning, you need to know about it before Tuesday afternoon, not when a customer or researcher tells you a month later.
Second, you need an internal process to escalate and make a reporting decision quickly. Who decides that a vulnerability qualifies for mandatory reporting? Who has the authority to submit a government notification? If that decision requires a meeting that can only happen on Thursdays, you will miss the 24-hour window.
Third, you need to know what to report. The notification goes to a government authority and contains specific information about your product, the vulnerability, affected versions, and interim mitigations. Writing that clearly and accurately in under 24 hours requires having the information readily available and having done this enough times that the format is not unfamiliar.
Most SME manufacturers have none of these three elements in place. The vulnerability reporting obligation is not a documentation requirement - it is an operational capability. Building it takes time.
What "actively exploited" means - and why it matters for your monitoring
The 24-hour clock starts specifically for vulnerabilities that are actively exploited - meaning there is evidence of exploitation in the wild, not just theoretical risk. A proof-of-concept published on GitHub does not necessarily trigger the 24-hour obligation. A vulnerability being used in actual attacks against deployed products does.
This distinction matters for how you build your monitoring. You need to track not just new CVEs for your components, but also exploit activity - whether specific vulnerabilities are moving from "disclosed" to "actively exploited." Sources like CISA's Known Exploited Vulnerabilities catalogue, threat intelligence feeds, and vendor security advisories are part of this picture.
For severe security incidents - where your product is actively compromised in a way that significantly impacts users - the trigger is the incident itself, not just a specific vulnerability.
What a functional CVD process looks like for an SME
Coordinated Vulnerability Disclosure (CVD) is both a process and a public commitment. CRA requires you to have both.
The public part: A published contact point where security researchers, customers, and other parties can report vulnerabilities to you. In practice this is a dedicated email address (security@yourdomain.com) and a basic vulnerability disclosure policy on your website. The policy should state that you accept reports, what information you need, what reporters can expect in terms of response time, and your commitment to addressing genuine findings. This is not a legal document - it should be short, clear, and human.
The internal part: A defined workflow for what happens after a report comes in. Who receives it, who assesses it technically, who makes the reporting decision if it qualifies under Article 14, who communicates back to the reporter, and who manages the patch and advisory cycle. For a team of five people, this does not need to be a formal ISMS - it needs to be documented and understood.
The monitoring part: Proactive tracking of known vulnerabilities in your component stack. You should not be learning about critical CVEs in your dependencies from security researchers or customers. You should know about them before they do. This means maintaining an accurate SBOM - a complete inventory of software components and their versions - and running that against vulnerability databases regularly.
Without the SBOM, the monitoring is impossible. Without the monitoring, the 24-hour timeline is not achievable. This is why SBOM is not just a documentation requirement - it is foundational infrastructure for the vulnerability management obligations that matter operationally.
What the penalties look like for missing the September deadline
Article 64 of the CRA establishes the penalty framework. Missing the 24-hour early warning notification or the 72-hour full notification falls under the category of failing to comply with obligations - penalties up to €10 million or 2% of global annual turnover, whichever is higher.
There is a specific carve-out: microenterprises and small enterprises (fewer than 50 employees, turnover under €10 million) cannot be fined for missing the 24-hour early warning deadline specifically. The reporting obligation still applies - they simply face reduced financial exposure for the 24-hour window.
This carve-out does not extend to the 72-hour notification or the final report. And it does not protect against other enforcement actions - market surveillance authorities can still require corrective measures, product withdrawals, or public notices even where financial penalties are capped.
The interaction with product architecture
There is a direct connection between your product's technical architecture and your ability to meet the September 2026 obligations.
If your devices have no mechanism for you to identify which version of firmware is running in the field, you cannot accurately scope an incident. If you have no telemetry or update mechanism, you cannot verify that a patch was successfully deployed to affected devices. If every device in a production batch is cryptographically identical - no unique device identity - you cannot selectively revoke or remediate compromised units.
These architectural gaps do not prevent you from filing a report. But they make the report incomplete and the remediation slow. The manufacturers who handle the September 2026 reporting obligation well are the ones who have already invested in the architectural foundation: unique device identity, signed firmware with version tracking, a functioning update mechanism, and SBOM-backed component monitoring. These are not separate projects - they are the same investment.
The compliance path your product is on also matters here. Your CRA product category does not change the September 2026 reporting obligation - it applies to Default, Class I, and Class II products equally - but it does affect the depth of your required technical documentation and the scrutiny a regulator will apply when reviewing your incident response.
A concrete preparation checklist for September 2026
With under 120 days to the deadline, here is what to prioritise:
This week:
- Set up security@yourdomain.com and a basic vulnerability disclosure page. Takes one hour. No reason not to have this done.
- Generate or update your SBOM. List every software component and version in your shipping product. If you do not know your component list, you cannot monitor it.
In the next 30 days:
- Subscribe to vulnerability feeds relevant to your component stack (NVD, vendor advisories, CISA KEV catalogue).
- Document your internal escalation process. Who receives reports, who makes reporting decisions, who contacts ENISA. Write it down - even one page is better than nothing.
- Review ENISA's Single Reporting Platform documentation so the submission process is not unfamiliar when you actually need it.
In the next 60-90 days:
- Run a tabletop exercise. Simulate discovering a critical vulnerability on a Monday morning and walk through the 24-hour process. Where does it break down? Fix those gaps before they matter in a real incident.
- Assess whether your current firmware version tracking gives you enough information to scope an incident accurately. If every device in the field reports the same version string regardless of actual build, that is a problem.
FAQ
Does the September 2026 deadline apply to my product if it was released before CRA passed? Yes. The reporting obligation in Article 14 applies to products with digital elements already on the EU market, not just products released after December 2027. If your product is available in the EU today, this deadline applies.
What counts as an "actively exploited vulnerability"? A vulnerability where there is evidence of real-world exploitation - attackers are using it in active campaigns against deployed products. Theoretical risk or a published proof-of-concept without observed exploitation typically does not trigger the 24-hour obligation, though it may still require a patch under the CRA's general vulnerability management requirements.
Do I need to report every security bug in my product? No. The mandatory reporting obligation specifically covers actively exploited vulnerabilities and severe security incidents. Routine bugs, minor security issues, and vulnerabilities with no evidence of active exploitation do not trigger Article 14 reporting, though they still need to be addressed under your general CRA obligations.
Where do I actually submit the report? Through ENISA's Single Reporting Platform (SRP), which will be live before September 11, 2026. You report once; the platform routes to your national CSIRT and to ENISA. You do not need to identify and contact your national CSIRT separately.
What if I discover a vulnerability but my investigation is not complete by the 24-hour mark? The early warning within 24 hours does not require a complete analysis - it requires notification that a vulnerability exists and is being actively exploited. You report what you know, note that investigation is ongoing, and submit the full notification within 72 hours. The system is designed to allow preliminary reporting with follow-up.
We are a small team. Is this really achievable? Yes, with the right preparation. The process does not need to be complex - it needs to be documented, practiced, and have clear ownership. A two-person security function that has a written process, an accurate SBOM, and has run through the scenario once is more capable of meeting the 24-hour deadline than a larger team with no defined process and no component inventory.
Valentyna Shulga is the CEO of Platanor Technologies. Platanor works with IoT and hardware manufacturers on the embedded security architecture and documentation required to meet CRA obligations - including the September 2026 reporting requirements. Reach us at platanor.com/contact.