Reporting vulnerabilities under the CRA: what it requires, and how fast

On 11 September 2026 the part of Regulation (EU) 2024/2847 — the Cyber Resilience Act — that changes daily life for anyone shipping software in Europe came into force. It is not the part everyone discussed at the time, the CE marking and the essential requirements, which is still some way off. It is the reporting part, and the clock is already running.

What changed

From that date, a manufacturer who learns that a vulnerability in their product is being actively exploited has to report it. Not to their customers — that too, but that is a different conversation — but to the authorities: the CSIRT designated as coordinator, and ENISA. The same applies to a severe incident affecting the security of the product.

The report does not go out by email, and there is no hunting for the right national form. ENISA switched on the single reporting platform foreseen in Article 16 that same day, and one submission reaches the coordinating CSIRT and the agency at once. That is probably the best news in the package: the administrative part is solved.

Why this likely includes you

The word “manufacturer” suggests a company with a factory floor. In the regulation it means something else: whoever places a product with digital elements on the Union market. A mobile app in a store, a downloadable executable, a widget, a device with firmware. Company size does not change the category.

Two details are worth pinning down before assuming this does or does not reach you. First: the obligations also cover products already on the market, not only what ships from now on. Second: entities that steward open-source software in a structured way have their own version of the obligation, on a different timetable starting in December 2027. Anything outside both figures — a personal project published with no commercial activity behind it — is a different story, and that is exactly the point where you read the text rather than trust a summary, this one included.

The three deadlines

The regulation splits reporting into three moments, each asking for a different level of detail:

An early warning within 24 hours of the manufacturer becoming aware of active exploitation. It is deliberately short: identify the manufacturer and the product, say what happened and when, and note the initial impact and any mitigation that already exists. You do not need the answer; you need to raise your hand.

A notification within 72 hours carrying the initial assessment: what is known about the vulnerability or incident, its scope, and where the fix is heading.

A final report within 14 days of a corrective or mitigating measure becoming available. This is where the full account is expected.

Seen all at once it looks like a lot. Seen from inside an organisation that already handles incidents, the hard part is not the deadlines: it is the first one. Twenty-four hours burn down on their own while someone works out whether the email that arrived is real, who owns that product, and whether “actively exploited” means what it appears to mean.

What has to exist beforehand

The usual misreading is to treat this as paperwork and leave it for the day it happens. Deadlines are not met with a written procedure; they are met with three things that exist before the incident.

Knowing what you ship. When a vulnerability lands in a dependency, the operational question is not whether it is severe, but whether it is in any of your products and in which versions. Without a dependency inventory per release — an SBOM generated from the lockfile, not from what your build files declare — that question gets answered by hand, repository by repository, with the clock running. How we solved that on our side is further down.

Having a way to find out. A published contact channel, with a policy that says where to write and what to expect, and that somebody actually reads. If the security mailbox is checked on Mondays, the 24-hour window is compromised before it starts.

Knowing who decides. Someone signs the notification. Better to settle who that is before you need them, and to make sure that person knows where the ENISA platform is and which credentials get them in.

How we built ours

Showing beats telling, so the pipeline we are describing is in the open: the Android widget we publish under MIT carries the whole thing in .github/workflows/supply-chain.yml. It runs on every push to the main branch, on every pull request, once a day and on demand, and it does five things:

• Generates a CycloneDX SBOM from the Gradle lockfile, not from what the build files declare. The difference is not cosmetic: what you declare is an intention, the lockfile is the resolved tree that ends up inside the APK.
• Scans dependencies against OSV and files the report next to the inventory.
• Verifies the lockfile matches what is declared, which is what catches the change someone made without updating the lock.
• Scans the full history for secrets, not just the latest commit.
• Audits the workflows themselves and keeps every GitHub Action pinned to a commit SHA rather than a moving tag. That last one is the one that bites: a tag can be rewritten, and that is precisely the route a supply-chain worm takes into someone else’s build.

Reports are kept as artifacts for ninety days. And since the latest release the .cdx.json ships attached to the release, next to the signed APK, with the SHA-256 digests GitHub publishes for both. That was the change that took us longest to see: for a while we generated the inventory religiously and left it to die in CI, where it is no use to anyone downloading the binary six months later.

What we do not have yet, and we say so because the gap is as informative as the rest: provenance and attestations. The inventory says what is inside; provenance proves that this binary came out of that code and that pipeline, and not off someone’s laptop. It is next on the list.

What it does not solve

Worth saying, because compliance talk tends to sell reassurance: reporting protects nobody. It is a mechanism for information to circulate and for authorities to see the shape of the problem. Protection comes from what happens earlier — watched dependencies, verifiable artifacts, the ability to ship a fix quickly — and from what happens later, which is the patch actually reaching the people running the software.

There is also an honest tension in the design: telling the authorities about an exploited vulnerability before a fix exists concentrates sensitive information in one place. The regulation handles it with restrictions on use and dissemination, but it is a legitimate debate, not paranoia to be waved away.

What we would do starting today

In order, and with none of the three being a project in its own right: generate the dependency inventory in the pipeline and attach it to every release; publish a security contact channel with a written, realistic policy; and put in writing who reports, with which account, and within what internal deadline — an internal deadline shorter than the legal one, because the legal one is the limit, not the target.

With that in place, the day the report arrives, 24 hours is plenty. Without it, 24 hours is just enough to discover that nobody knew which versions were affected.