A CRA readiness checklist you can actually work through
Six checks behind the 11 September 2026 reporting duty, each with the first concrete thing to do about it — and what the Regulation actually requires.
Most CRA checklists are a restatement of the Regulation with tick boxes down the side. They tell you that you need a coordinated vulnerability disclosure policy. They do not tell you what to do on Monday.
This one is organised the other way round: six checks, each with the smallest concrete action that closes it, and the provision it comes from so you can verify rather than trust.
Two of the six are load-bearing for 11 September 2026 — the date the Article 14 reporting duty starts, fifteen months before the rest of the Regulation. Those two are marked. If you only have time for part of this list, do those.
1. Can you find out that a vulnerability is being exploited?
September-critical. Article 14(1)
The duty is triggered by awareness: a manufacturer must notify an actively exploited vulnerability it becomes aware of, simultaneously to the CSIRT designated as coordinator and to ENISA. Without a process that produces that awareness, the obligation does not disappear — it fails silently, and the first you hear of it is from a customer or a regulator.
First action. Wire one alert into a channel a human already reads every day — your dependency scanner, your distribution’s security list, or a CVE feed for the components you ship. One alert that lands somewhere people look beats three subscriptions nobody opens.
The 24-hour clock cannot start if nothing starts it.
2. Could you actually file within 24 hours?
September-critical. Article 14(2), (4) and (7)
Three clocks, not one:
- an early warning within 24 hours of becoming aware
- a fuller notification within 72 hours
- a final report within 14 days of a fix being available — one month for a severe incident
All three go through the single reporting platform, to the coordinator CSIRT of the Member State where your main establishment sits: where your cybersecurity decisions are predominantly taken, or failing that where you have the most employees in the Union.
Work that out now. Twenty-four hours is not enough time to discover which Member State you report to.
First action. Draft the early-warning text before you need it: what happened, which product and version, what you know so far, and what you do not yet know. At twenty-four hours the scarce resource is not information — it is the time to sit down and write it.
3. Is there a published way to report a vulnerability to you?
Annex I, Part II, points (5) and (6)
The Regulation requires manufacturers to put in place and enforce a policy on coordinated vulnerability disclosure, and separately to provide a contact address for reporting vulnerabilities found in the product.
A policy nobody outside your company can find satisfies neither in practice: researchers reach the press instead of you.
First action. Pick a response window you can still honour in a bad week — acknowledging within five working days is a promise you can keep, twenty-four hours usually is not — and make sure the address you publish reaches more than one person.
This is the cheapest item on the list to close and the one that most often decides whether a researcher contacts you or someone else.
4. Do you have a software bill of materials?
Annex I, Part II, point (1)
Manufacturers must identify and document the vulnerabilities and components in their products, including by drawing up a software bill of materials in a commonly used, machine-readable format covering at the very least the top-level dependencies.
Beyond the legal requirement it is the practical prerequisite for check 1. When the next widely-used library turns out to be exploited, an SBOM is what tells you in minutes — rather than days — whether your product is affected.
First action. Generate an SBOM for your top-level dependencies from the build you already run — CycloneDX and SPDX are both commonly used machine-readable formats — and publish or retain it alongside the release it describes.
5. Is there a named person accountable for reporting?
No separate provision — a practical prerequisite for Article 14
No article mandates a named individual. This is on the list because every other item on it fails without one.
Name someone accountable for filing, name a deputy for when the first person is on a plane, and make sure both can reach the reporting platform at 2am.
First action. Test it rather than document it: ask the person you have in mind, with no warning, what they would do if an exploited vulnerability surfaced tonight. If the answer starts with finding out who to ask, the gap is still open.
A duty that belongs to everybody belongs to nobody on a Sunday, which is when it will land.
6. Do you have a stated support period, and can you honour it?
Article 13(8), (9) and (19), and Annex I, Part II(2)
Security updates have to be provided for the support period, and every security update you issue has to stay available for at least ten years after it is issued, or the rest of the support period, whichever is longer.
An ad-hoc practice satisfies none of that and cannot be evidenced to a market surveillance authority.
First action. State the support period you will actually honour, publish it with the product, and confirm your release process can still build and ship a fix for the oldest version inside it.
That last clause is the one that surprises teams. A five-year support period means a five-year-old build has to be buildable.
How to sequence this
If all six are open, the order is not the order above.
- Checks 1, 2 and 5 first. They are the September 2026 duty, and they are mostly decisions rather than engineering — who watches, who files, what the text says. A week of attention closes them.
- Check 3 next. An afternoon, and it changes who contacts you when something goes wrong.
- Checks 4 and 6 are engineering work with a longer runway. They are due for 11 December 2027 along with the essential requirements, conformity assessment and CE marking.
The two deadlines are the thing most people get wrong about the CRA. Fifteen months separate them, and the earlier one applies to products that will not need CE marking for another year after that.
What this checklist does not cover
This is the readiness list for the reporting duty and the vulnerability-handling requirements. It is not the whole Regulation.
It does not cover the essential cybersecurity requirements in Annex I, Part I — secure default configuration, protection from unauthorised access, data minimisation, attack surface reduction and the rest. It does not cover conformity assessment, which depends on your product class and, for Important Class II and critical products, requires a notified body with a queue in front of it. And it does not cover technical documentation and CE marking.
Those are the December 2027 workstream. This list is what has to be true fifteen months earlier.
Check where you stand
The free CRA readiness scan walks these same six checks and applies them to your answers, along with the scope and classification questions. It takes about two minutes, needs no account, and the result is on screen — no email required to see it.
If you would rather not answer questions first, start with whether the CRA applies to you at all.