Cyber Resilience Act: The Reporting Clock Starts on September 11

On Friday, a regulatory clock arms itself across the European Union. It comes from the Cyber Resilience Act, the EU regulation on the cybersecurity of digital products. CRA for short, and no, not the tax agency. Most teams do not know yet that it concerns them.

TL;DR: from 11 September 2026, the Cyber Resilience Act makes reporting mandatory. An actively exploited vulnerability in your product leaves you 24 hours for the early warning. Then 72 hours for the notification, and 14 days for the final report. The real subject is not legal. It is your ability to know fast, qualify fast and write fast. Here is the pipeline-side runbook.

This article is for software makers selling in the EU, especially small teams without in-house counsel. I am not a lawyer: dates and scope come from the primary sources listed at the bottom.

Are you in scope?

The CRA targets "manufacturers": anyone placing a product with digital elements on the EU market. Sold software, an app, firmware, a connected device.

Pure SaaS is in principle covered by another law, NIS2. It falls back into the CRA when the service is necessary for a product to work.

Individual open source contributors are not targeted. Foundations supporting projects, called stewards, get a lighter regime, without fines.

Full compliance, CE marking included, waits until December 2027. Reporting starts this Friday.

The clock, concretely

Two events trigger a report. A vulnerability in your product that is actively exploited, meaning someone is really using it. Or a severe incident affecting the product's security.

The report goes to your national CSIRT and to ENISA, through one portal, the Single Reporting Platform. A CSIRT is the national incident response team. In France, that is ANSSI.

And the clock starts the moment you become aware:

D0      : you learn about active exploitation
< 24 h  : early warning (product, nature of the issue)
< 72 h  : full notification (assessment, measures taken)
< 14 d  : final report, once the fix is available
< 30 d  : final report for a severe incident

Read the first line again. "The moment you become aware." The whole game is becoming aware early, and being able to prove it.

What your pipeline already covers

The good news: if you run a serious security pipeline, half the work exists. Here is what I have installed for clients for years, and what it buys you.

govulncheck watches Go vulnerabilities, and only alerts when your code actually calls the affected function. Renovate keeps dependencies current. syft generates an SBOM on every build. Grype or Trivy scan images. gitleaks catches secrets.

An SBOM is the machine-readable inventory of everything your product ships. Without it, you cannot answer "are you affected by CVE X?" in 24 hours. With it, it is a lookup.

That part covers "detect fast" and "know what you ship". Necessary. Not sufficient.

What almost nobody has

Existing CRA content comes from law firms and tool vendors. None of it answers the team question: what do we do on Monday morning? Here are the five missing pieces.

A written definition of "becoming aware": which alerts count, on which channel they land, who reads them, within what delay.

A pre-filled report template: product, version, CVE, nature of exploitation, measures. On day zero you fill blanks, you do not write prose.

Access to the reporting platform, created before the incident. Discovering a portal at hour 20 of 24 is a real, avoidable scenario.

A published coordinated disclosure policy: a reachable security contact and a response promise. The CRA requires it, and it is your free alert source.

And a dry run, stopwatch in hand. A fake CVE, the team walks the runbook, you measure. That is where the theoretical plan breaks, and that is the point.

The runbook I install

BEFORE (this week)
- SBOM generated on every build, archived per version
- scheduled vulnerability scans, not only on push
- disclosure page + security contact published
- reporting platform access created and tested
- pre-filled report template, written roles

AT D0 (awareness)
- qualify: active exploitation? product in scope?
- open the incident, written timeline from minute one

THEN
- early warning within 24 h
- full notification within 72 h
- fix, final report within 14 days, post-mortem

Nothing exotic. It is an incident response plan, with imposed deadlines and a single counter. The difficulty is not ambition, it is phase: everything is prepared beforehand.

The Go part nobody covers

A static Go binary ships everything. Your go.mod is not your SBOM: it lists what you declare, not what you deliver.

# SBOM of what actually ships (CycloneDX format)
syft scan ./bin/app -o cyclonedx-json > sbom.json

# does this CVE actually concern you?
govulncheck ./...

The duo does the first-24-hours triage. The SBOM answers "is it shipped?". govulncheck answers "is it called?". Two answers in minutes, documented, ready to paste into the early warning.

Full honesty: I have never filed a real CRA report, nobody has before Friday. This runbook is the one I install, not an incident debrief. The tooling under it has run in production for years.

The checklist before Friday

Half a day covers the essentials. It is a well-spent half day.

• [ ] You can say whether your product is in CRA scope, and why
• [ ] A machine-readable SBOM comes out of CI on every build
• [ ] govulncheck or equivalent runs on a schedule, with a human recipient
• [ ] "Becoming aware" has a written definition: channel, reader, delay
• [ ] The security contact and disclosure policy are published
• [ ] Access to the reporting platform already exists
• [ ] The report template is pre-filled, roles are named
• [ ] A dry run is on the calendar, stopwatch in hand

What to remember

The CRA does not ask you to be perfect. It asks you to be fast and documented.

A pipeline that can say within an hour "here is what we ship, here is whether we are hit" makes the deadlines workable. Without it, 24 hours is a sprint you already lost.

The best time to prepare a report is when you have none to file.

Want a CRA-ready pipeline and runbook? Let's talk.

---

Sources: European Commission, CRA reporting obligations · ENISA, Single Reporting Platform · Commission guidance (27 July 2026) · OpenSSF, CRA brief guide for OSS developers · My article: securing a Go supply chain