By The EU Cyber Resilience Act’s most immediate obligation went live this morning. As of September 11, 2026, any manufacturer placing software or connected hardware on the EU market must report actively exploited vulnerabilities to ENISA within 24 hours of becoming aware — then file a full technical notification within 72. The full compliance deadline with CE marking, SBOMs, and secure-by-design mandates remains December 2027. But the reporting clock started today, and it applies to products already on the market.
Stop Panicking About Every CVE
Most of the coverage on this deadline has been alarmist in the wrong direction. The CRA does not require you to report every vulnerability in your dependency tree. The trigger is precise: an actively exploited vulnerability, defined as reliable evidence that a malicious actor has exploited a vulnerability in a system without the owner’s permission.
In practice, that means:
- A critical CVE sitting in your codebase with no known exploitation: not reportable
- A public proof-of-concept with no confirmed in-the-wild use: not reportable
- A CVE confirmed on CISA’s KEV list with active exploitation evidence: reportable
- A security incident that compromises the integrity or availability of your product: reportable
This distinction matters. If you’ve been dreading a firehose of daily CVE reports, you can stand down. What the regulation actually demands is that you have visibility into your product’s components — so that when active exploitation does occur, you know within hours, not days.
Where You Actually File: The ENISA Single Reporting Platform
ENISA operates the Single Reporting Platform (SRP), which goes live today alongside the obligation. One submission through the SRP simultaneously alerts ENISA and your national CSIRT, routed based on your main EU establishment. The platform is brand new. No one has used it in production. Expect a learning curve.
The three-step reporting sequence under Article 14:
- 24-hour early warning — Notify that you’re aware of an actively exploited vulnerability. Technical details, exploit mechanics, and completed remediation are not required at this stage.
- 72-hour full notification — Describe the vulnerability and the corrective or mitigating measures you’ve taken or are taking.
- 14-day final report — Complete picture: vulnerability details, actors if known, fix status, and any residual mitigations.
The SRP helpdesk is cra-srp-helpdesk@enisa.europa.eu. Register before you have an incident that forces a hurried onboarding — the platform is untested at scale and you don’t want your first interaction to be at 2 AM during a breach response.
You Need an SBOM Now, Not in 2027
The formal SBOM mandate doesn’t land until December 2027. But there’s a practical problem: you cannot file a credible 24-hour report if you don’t know what components are in your product and which deployed versions are affected by a given vulnerability.
The September reporting obligation is the de facto forcing function for SBOM tooling. If you don’t have dependency tracking in place, you’re blind. A known-exploited vulnerability in a transitive dependency could be hitting your users while you’re still manually grepping through your package-lock.json.
The two formats accepted under the CRA: CycloneDX (OWASP, preferred for security-focused use cases) and SPDX (ISO/IEC 5962:2021, stronger on license compliance). For tooling, Syft, FOSSA, and Anchore are the practical starting points. A minimal SBOM generation looks like this:
syft dir:. -o cyclonedx-json > sbom.jsonStart here. You can refine the pipeline later. The goal right now is component visibility.
Who’s Actually In Scope
If you sell downloadable software, mobile apps, desktop apps, IoT devices, network equipment, or firmware into the EU market — you’re in scope for the September reporting obligation. Products already on the market when the regulation entered into force are included.
What’s out: pure SaaS and cloud services (those fall under NIS2). Non-commercial open source — volunteer contributions without systematic commercial support — is explicitly exempt.
The grey zone is cloud-dependent hardware. If your SaaS component is necessary for a connected physical product to function, it may be in scope despite the “pure cloud” exclusion. The guidance here is still murky. If you’re in this situation, legal counsel with CRA experience is worth the fee.
Open Source Maintainers: You’re Mostly Safe
Individual developers and non-commercial contributors are exempt from CRA obligations. If you’re maintaining a library on your own time without systematic commercial backing, the regulation doesn’t touch you directly — though downstream manufacturers using your code in commercial products are responsible for their own compliance.
“Open source stewards” — foundations, commercial entities that systematically support open source development — face a lighter regime under Article 24: cybersecurity policies, vulnerability cooperation, and reporting. Importantly, Article 64(10) explicitly exempts stewards from administrative fines. The ambiguity around GitHub’s US jurisdiction and whether it qualifies as a steward remains unresolved.
Three Things to Do This Week
- Register on the ENISA SRP now. Don’t wait for an incident. Understand the platform before you need it.
- Start generating SBOMs. Pick a tool, automate it in CI, and store component manifests. You need this to meet the 24-hour rule in practice.
- Document your escalation path. Who gets paged when active exploitation is confirmed? How do you go from “aware of an issue” to “notification filed” in under 24 hours? Write that down.
The December 2027 deadline gets more press, but September 2026 is where enforcement starts. The window between now and 2027 is not dead time — it’s the runway to build the tooling and processes that make compliance operationally feasible. The EU CRA is also a template: the UK, Canada, and Australia are watching and will likely pass similar legislation. What you build for CRA compliance won’t be wasted.
