By ByteBot
As of September 11, 2026, the EU Cyber Resilience Act’s vulnerability reporting obligations are live. If your product is actively exploited and sells to EU customers, you now have 24 hours to file a report with European authorities. ENISA launched its Single Reporting Platform the same day. There is no grace period, and the fines go up to €15 million.
The Clock Started September 11
The CRA entered force in December 2024 but rolled out in phases. September 11 was the first hard deadline that actually lands on engineering teams: Article 14 vulnerability reporting obligations. ENISA’s Single Reporting Platform (SRP) went live simultaneously at portal.cra-srp.enisa.europa.eu.
Two triggers activate the 24-hour clock: credible evidence that a vulnerability in your product is being actively exploited in the wild, or a severe incident that meaningfully impacts product security. You report once via the SRP; it routes the notification to your national CSIRT and ENISA automatically.
The 3-Stage Reporting Timeline
Most teams fixate on the 24-hour window and miss the full structure. There are three stages:
- 24 hours — Early warning: Signal to CSIRT and ENISA that an event is in progress. This is not a final report. File it even with incomplete information.
- 72 hours — Full notification: Product identification, vulnerability description, severity, impact scope, and corrective or mitigating measures taken so far.
- 14–30 days — Final report: Root cause analysis, full remediation status, and any ongoing risk.
The early warning exists precisely because you won’t have everything in 24 hours. The regulation says “without undue delay” — that leaves no room for waiting until Monday morning or until legal signs off. File early, refine later.
Who Is Actually Covered
The scope question trips up a lot of teams. Here is the honest breakdown:
Manufacturers — companies placing products with digital elements on the EU market — have full obligations. This applies regardless of where you are headquartered. A US-based developer tools company selling licenses into Germany is in scope.
Open source software stewards — legal entities like the Linux Foundation, Apache Foundation, Eclipse Foundation, or Red Hat for its supported projects — face a lighter regime. They must document a cybersecurity policy and report actively exploited vulnerabilities, but have no CE marking or conformity assessment requirement.
Individual open source contributors operating without commercial intent remain exempt. Accepting donations without profit intent does not make you a manufacturer. The final regulation explicitly protects unpaid maintainers.
Pure SaaS is generally excluded — it falls under NIS2 and DORA instead. The exception: a cloud component that is essential to a locally installed product’s core functionality may be pulled into scope along with the product.
Why You Need an SBOM Before December 2027
The formal SBOM mandate does not kick in until December 2027, but it is functionally required now. You cannot accurately identify whether an actively exploited library affects one of your shipped products within 24 hours if you do not already have component-level visibility. The CRA requires machine-readable SBOMs in SPDX, CycloneDX, or SWID format covering at least top-level dependencies including open-source components. Integrating SBOM generation into your CI/CD pipeline is not optional work you can schedule for next year.
Five Things to Do This Week
- Register on the ENISA SRP — ENISA’s SRP page has onboarding guidance and a tutorial video. Do not wait for an incident to discover you are not registered.
- Identify who files the 24-hour report — and document their backup. This needs to be a named person with authority to classify an event as “actively exploited” under time pressure, including at 2 AM on a Saturday.
- Map your EU product inventory — which products, which versions, which customers are in EU member states. The reporting obligation applies to existing products already on the market, not just new releases.
- Generate an SBOM for each covered product — use automated tools like
syftorcdxgenintegrated into your build pipeline. The Cloudsmith engineering guide covers CI/CD integration specifics. - Run a timed tabletop drill — simulate receiving a credible exploit report on a Friday evening. Walk through detection, escalation, classification, and SRP submission. Most teams discover their gap during the drill, not during a real incident.
December 2027 Is the Bigger Deadline
Full compliance lands in 15 months. CE marking, formal conformity assessments, 10-year technical documentation retention, coordinated vulnerability disclosure policies — these are the heavier lifts. The EU’s CRA reporting page and the GitHub Blog’s open source guide are good starting points for that planning work. For now, get the September obligations right first — because you are already subject to them.
