What happens on 11 September 2026 under the Cyber Resilience Act?

The reporting obligations in Article 14 begin to apply. Manufacturers of products with digital elements placed on the EU market must notify ENISA and the relevant national CSIRT of actively exploited vulnerabilities and severe incidents: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report within 14 days of a corrective measure being available for a vulnerability, or within one month for a severe incident.

Does the CRA require an SBOM from 11 September 2026?

No. The software bill of materials is part of the essential requirements in Annex I, Part II, point 1, which apply from 11 December 2027. It must be machine-readable and cover at least the top-level dependencies. It does not have to be published; it belongs to the technical documentation and is provided to market surveillance authorities on a reasoned request.

Does every CVE have to be reported under the CRA?

No. The reporting duty is triggered by a vulnerability that is being actively exploited, or by a severe incident affecting the security of the product. An unexploited advisory in a dependency is not, by itself, a reportable event.

Why does the 24-hour reporting clock require component visibility before 2027?

Because the clock starts when you become aware, and the first question is whether the exploited component is in your product at all. A team that needs two days to answer that has already missed the 24-hour early warning, regardless of what its paperwork will be required to contain in 2027.

What the Cyber Resilience Act asks for on 11 September

Two dates, and only one of them is close

11 Sep 2026

Reporting begins. Actively exploited vulnerabilities and severe incidents must be notified to ENISA and the national CSIRT, on a 24-hour clock.

11 Dec 2027

The essential requirements apply. Among them, a machine-readable SBOM covering at least the top-level dependencies, held in the technical documentation.

Both dates come from the same regulation, and the order surprises people. The obligation that arrives first is not a document you can prepare in a quiet week. It is a response time.

What the clock actually demands

Article 14 sets three deadlines, and they run from the moment you become aware — not from the moment you finish investigating.

Early warning
To ENISA and the CSIRT of the member state where you are established. It does not have to be complete. It has to exist.
Notification
The vulnerability or incident described, with whatever corrective or mitigating measures you have taken.
Final report
Within fourteen days of a corrective measure being available for an actively exploited vulnerability; within one month for a severe incident.

Two limits are worth stating plainly, because a good deal of vendor material blurs them. This is not a duty to report every CVE: the trigger is active exploitation, or an incident severe enough to affect the security of the product. And it applies to manufacturers placing products with digital elements on the EU market — which includes software shipped years ago, still supported.

Whether an open-source project falls under the lighter regime the regulation provides for stewards is a question about your organisation and your revenue, not one a page like this can answer for you.

The 2027 document is a prerequisite for the 2026 clock

Here is the part that makes the ordering matter. When a component you ship turns out to be under active exploitation, the first question is not how to write the notification. It is whether that component is in your product at all — and in which of your services, and at which version, and whether the vulnerable path is one you actually call.

A team that needs two days to answer that has already missed the early warning. It will miss it in September 2026, a year and three months before anyone is required to hold the document that would have answered it.

So the SBOM deadline is the wrong thing to plan around. The capability the SBOM describes is needed fifteen months earlier than the document is. That is the whole practical point of this piece.

What separates evidence from a folder of files

Suppose you do assemble the material — a component list, the findings against it, a record of when you knew what. You now have an archive. An archive is not yet evidence, because nothing in it stops the contents from having been edited afterwards.

What turns it into evidence is a manifest: a list of every file in the pack with a cryptographic digest of its contents. The recipient recomputes the digests. If they match, the files are the ones the manifest describes.

That is worth having, and it is worth being exact about what it buys, because the obvious next sentence — change one byte and the pack fails its own check — is false, and it is false in most manifest formats, not just ours. The manifest is a file in the archive like any other, and it carries no digest of itself. Someone who edits findings.json to drop an inconvenient vulnerability rewrites the one line in MANIFEST.json that describes it, and the pack verifies clean. We only know this because we tried it against a real export: the forged pack came back OK, exit code 0.

So the digests prove the archive is internally consistent — that these files match this manifest. Standing alone, they do not prove it is the archive that was exported, and a compliance conversation that treats the two as the same thing is resting on nothing.

The gap closes with one more move, and it is a cheap one: the digest of the manifest has to reach the recipient by a route the archive did not travel. Celmis returns it in an X-Celmis-Manifest-SHA256 header at export and writes it to the log. Put that value somewhere the pack is not — the audit ticket, a release note, the email that says the pack is coming — and the recipient checks against a number nobody handed them along with the file. Then, and only then, does a third party verify the pack without trusting the machine that produced it, or the people who ran it.

Publishing the digest is the part that requires a person to have thought about it. A tool cannot do it for you, which is presumably why so few packs come with one.

A worked example

Celmis emits exactly that shape. It is not the only way to build one; it is the one we can show:

sbom/<repo>.cdx.json   — CycloneDX, one per repository
findings.json          — what was found against those components
timeline.jsonl         — when each fact entered the record
MANIFEST.json          — sha256 of every file above

The timeline is the one people leave out, and it is the one a regulator's question lands on. When did you become aware? is a question about a record, not about memory. A line appended when the finding first appeared answers it; a recollection does not.

An evidence pack: CycloneDX SBOM, findings, timeline and a manifest of sha256 digests — The pack as it comes out. The manifest is what a recipient checks first.

A real one, so this is not a claim you have to take on trust. Celmis's own dependency audit, exported the way the pack above describes:

evidence-pack.zip — SBOM, findings, timeline, and MANIFEST.json, 16.9 KB.

Its own manifest, published on this page rather than inside the archive:

X-Celmis-Manifest-SHA256: 64cff1226bfdb7cbe6931c4ff67f84cab0fd95bb6eee5c41877c358943c88bbd

Download the pack, unzip it, and hash MANIFEST.json on its own — sha256sum MANIFEST.json — then compare that against the line above, which came from this page rather than from inside the zip. If they match, the manifest is the one that was generated for this pack; recomputing the digests it lists then checks every other file against it. If the manifest is edited after the fact, this number changes and the two will not agree.

What we will not tell you

from the tool's own output

Celmis does not claim that using it makes a product compliant with the Cyber Resilience Act, and it says so in the pack it generates. Compliance is a judgement about an organisation — its processes, its support commitments, its conformity assessment — not an artefact a program can emit.

A tool that implies otherwise is selling a feeling of safety, and the feeling arrives before the audit does.

What a tool can honestly do is narrow the gap between a question and an answer: make the component list current, keep the findings attached to it, stamp the record, and make the whole thing checkable by someone who has no reason to trust you. On a 24-hour clock, that is most of the work.

With two weeks left

Not much can be built in a fortnight, so spend it on the things that are cheap and load-bearing:

Answer the question once, by hand. Pick a real component — something in your dependency tree with a recent advisory — and time how long it takes to say which of your services ship it, at what version. That number is your actual readiness, and nobody else can measure it for you.
Decide who receives the alert. The 24-hour clock starts when your organisation becomes aware, which means it starts at whoever reads the mailing list, not at whoever writes the notification.
Find your CSIRT before you need it. The early warning goes to the one in the member state where you are established, alongside ENISA. Looking that up during the first hour is a bad use of the first hour.
Start the timeline now. An append-only record that begins in August is worth more in a conversation than a complete one assembled in September.

None of this requires our software, and the first three do not require any software at all.

← Celmis How the pack is built →

Dates and obligations here are drawn from Regulation (EU) 2024/2847 and the European Commission's published guidance on CRA reporting. This is a description of what the regulation says, written by people who build a tool in the area — not legal advice, and no substitute for reading the text or asking someone qualified.