EU Cyber Resilience Act vulnerability reporting begins 11 September 2026

Reporting rules take effect on 11 September 2026

On 11 September 2026, the vulnerability-reporting obligations of the EU's Cyber Resilience Act (CRA) enter into force. According to a practitioner article on dev.to by Jules Robineau, most teams that fall within scope are not yet aware the regulation concerns them, and existing commentary — largely from law firms and tool vendors — rarely answers the practical question of what a team should do once the deadlines apply.

Two events trigger a mandatory report: a vulnerability in the product that is being actively exploited, and a severe incident affecting the product's security. The deadlines run from the moment the manufacturer becomes aware:

• within 24 hours, an early warning identifying the product and the nature of the issue
• within 72 hours, a full notification with an assessment and the measures taken
• within 14 days, a final report, submitted once a fix is available
• within 30 days, the final report for a severe incident

Reports go to the manufacturer's national CSIRT (the national incident response team) and to ENISA, through a single entry point called the Single Reporting Platform.

Who is covered

The CRA targets "manufacturers": anyone placing a product with digital elements on the EU market, whether sold software, an app, firmware or a connected device. Pure SaaS sits primarily under a separate law, NIS2, but comes back into the CRA when the service is necessary for the product to function. Individual open source contributors are not targeted, and foundations that steward open source projects face a lighter regime without fines, the article notes. Full compliance, including CE marking, is not required until December 2027 — only the reporting duties begin this week.

The hard part is knowing fast

The article's central argument is that the challenge is operational rather than legal. Because the clock starts on awareness, teams need a written definition of what "becoming aware" means: which alerts count, on which channel they land, who reads them and within what delay.

Much of the detection machinery may already exist. Robineau lists the stack he installs for clients: govulncheck for Go, which only flags issues when the code actually calls the affected function; Renovate for dependency updates; syft to generate a software bill of materials (SBOM) on every build; Grype or Trivy to scan images; and gitleaks to catch leaked secrets. An SBOM turns "are we affected by this CVE?" into a lookup rather than an investigation, which is the difference between meeting a 24-hour deadline and missing it.

For Go in particular, go.mod lists declared dependencies, not what a static binary actually ships. Generating the SBOM from the built binary gives the real inventory, and pairing it with govulncheck answers the two questions an early warning needs: is the component shipped, and is it actually called.

What most teams have not built

Five preparation pieces are usually missing, according to the article: a written definition of awareness; a pre-filled report template so that day zero means filling in blanks rather than writing prose; access to the Single Reporting Platform created and tested before an incident happens; a published coordinated disclosure policy with a reachable security contact, which the CRA requires and which doubles as a free source of early warnings; and a timed dry run against a fake CVE to expose where the plan breaks.

The author is candid about the limits of this advice: nobody has filed a real CRA report yet, so the runbook is preparation rather than a tested incident debrief, even though the underlying tooling has run in production for years. He also states he is not a lawyer and points to European Commission and ENISA material as the authoritative sources for dates and scope.

Why it matters

These obligations apply to any organization selling software, apps, firmware or connected devices in the EU, wherever it is based. They reward teams that already know exactly what they ship: with a per-version SBOM and scheduled scanning, a 24-hour early warning is achievable; without them, the deadline is effectively lost before it starts. The date is also the first concrete milestone of a regulation whose full weight — CE marking and conformity requirements — arrives in December 2027, which makes this week a comparatively cheap moment to start building the processes that full compliance will eventually demand.