Two dates, and only one of them is close
Reporting begins. Actively exploited vulnerabilities and severe incidents must be notified to ENISA and the national CSIRT, on a 24-hour clock.
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. If a single byte of the component list changed after the fact, the digest does not match and the pack fails its own check.
That is the property worth designing for — a third party can verify the pack without trusting the machine that produced it, or the people who ran it. Everything else in a compliance conversation is easier once that holds.
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.
What we will not tell you
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.
If you have fifteen days
Not much can be built in fifteen days, so spend them 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.
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.