Resources
A CRA compliance tool has to do five things: know which of your products are in scope and how they are classified, hold the evidence that each meets the Annex I essential requirements, produce and keep a software bill of materials, run the 24 hour and 72 hour reporting clocks when something is actively exploited, and assemble the technical documentation that supports the CE marking. If a tool cannot do all five, you will end up doing the remainder somewhere else, which is usually a spreadsheet and a shared drive.
The one that decides the purchase is the reporting clock. Everything else on that list can be survived, badly, with a well kept spreadsheet. A 24 hour regulatory deadline that starts when you become aware of an exploited vulnerability cannot be, because a spreadsheet has no idea what time it is.
What you are actually buying against
Requirements come from dates and duties, not from feature lists. Three numbers set the shape of what you need.
| Date | What starts | What a tool has to do about it |
|---|---|---|
| 11 June 2026 | Member States may designate conformity assessment bodies. | Nothing directly. It is when notified body capacity starts to exist, so it is when queueing begins. |
| 11 September 2026 | Article 14 reporting duties apply, including for products already on the market. | Run the 24h and 72h clocks, hold the evidence of what was reported and when. |
| 11 December 2027 | The CRA applies in full: essential requirements, conformity assessment, CE marking, EU declaration of conformity. | Hold the technical file, the risk assessment, the SBOM and the conformity route per product. |
The middle date is the one buyers miss. It attaches to products you have already shipped, so there is no grace period earned by being early to market. Our guide to CRA deadlines for 2026 and 2027 sets out the full sequence.
The five jobs, and how to tell whether a tool really does them
Every vendor will say yes to all five. These are the questions that separate a real capability from a field on a form.
| Job | CRA basis | The question that exposes a weak answer |
|---|---|---|
| Scope and classify products | Annex III and IV | Can it hold a product that is out of scope, with the reasoning recorded? A tool that only models in-scope products cannot evidence why the others were excluded. |
| Evidence against Annex I | Annex I Parts I and II | Does it separate Part I (product properties) from Part II (vulnerability handling)? Tools that flatten these into one checklist usually under-cover Part II. |
| Software bill of materials | Annex I Part II | Is the SBOM regenerated per release and kept, or produced once for an audit? A point-in-time SBOM is a document, not a control. |
| The reporting clock | Article 14 | When does the 24 hour clock start in the tool, and who is notified? If the answer is "when someone creates a ticket", the clock is decorative. |
| Technical documentation | Annex VII | Can it export the file as a coherent pack, or does it export a folder of attachments? A notified body reads a document, not a database. |
Do you actually need a tool?
Sometimes not, and it is worth saying so plainly. If you place one or two default-category products on the market, have a single engineering team, and already generate an SBOM in your build pipeline, a spreadsheet plus a rehearsed reporting runbook will get you through 2026. What it will not get you through is scale, staff turnover, or a supervisor asking you to prove what you knew and when.
| Approach | Works when | Fails when | Real cost |
|---|---|---|---|
| Spreadsheet and shared drive | 1 to 3 products, one team, low classification | The 24h clock starts at 2am on a Sunday, or the person who maintained it leaves | Free until the first incident, then very expensive |
| Product security platform | You need SBOM and vulnerability management above all | You reach CE marking and there is nowhere to assemble the technical file | Real, and usually a second tool follows |
| GRC platform with CRA support | Multiple products, mixed classification, an audit trail is required | You expected it to scan code. It governs; it does not test | Subscription, plus the effort to populate it honestly |
| Consultant only | A one-off gap assessment or a specific conformity question | The obligation is continuous and the report is a snapshot | High per engagement, and nothing accrues |
Why the reporting clock is the deciding feature
Article 14 is short and unforgiving. It requires an early warning within 24 hours of becoming aware of an actively exploited vulnerability, and a fuller notification within 72 hours. Both go to the CSIRT designated as coordinator and to ENISA.
The clock does not start when you open a ticket, when you finish triage, or when you decide the vulnerability is serious. It starts when you become aware. Every hour spent deciding whether the clock has started is an hour spent on the clock.
This is why a tool earns its price. Awareness has to be captured the moment it happens, from wherever it arrives: a researcher email, a vendor advisory, a monitoring alert. Then the deadline has to be visible to somebody with authority, out of hours, with a pre-drafted notification ready to send. That is a workflow with owners and escalation, and a spreadsheet cannot hold one.
One narrow relief worth knowing: Article 64(10)(a) removes fines for microenterprises and small enterprises that miss the specific deadlines in Article 14(2)(a) or 14(4)(a). The duty to report remains. The penalty for lateness does not apply.
What the other results get wrong
Three claims recur in vendor content and in the guidance that repeats it.
That a scanner is a CRA tool. SBOM generation and dependency scanning cover part of Annex I Part II and nothing else. They do not classify products, do not hold a conformity route, and cannot produce a technical file. They are a component of the answer sold as the whole of it.
That CRA compliance is a project with an end date. Article 13 requires the product to remain compliant across its support period, and Article 14 runs continuously. A tool that models compliance as a one-off assessment will be wrong the day after you finish.
That the December 2027 date is the deadline. It is the last one, not the first. Buying against 2027 and discovering the reporting duty started in September 2026 is the most expensive way to read the timeline.
Twelve questions to put to any vendor
Ask these in a demo, not in an RFP response. The interesting part is how quickly they can show you rather than tell you.
| # | Question | What a good answer looks like |
|---|---|---|
| 1 | Show me a product classified as Annex III important, class II. | The classification is a field with a reasoning trail, not a label. |
| 2 | Where is the Annex I Part II evidence, separate from Part I? | Two distinct sets, not one merged checklist. |
| 3 | Generate the SBOM for the last release of this product. | It comes from the pipeline, with a date. Not an upload. |
| 4 | Start the 24 hour clock now. Who gets notified? | A named person and an escalation path, out of hours included. |
| 5 | It is hour 20 and nobody has acted. What happens? | Escalation fires automatically. If the answer is a dashboard, nobody is watching it at 2am. |
| 6 | Export the technical documentation pack. | One coherent document set, in the Annex VII order. |
| 7 | Show the audit trail for a change made six months ago. | Immutable, attributable, with the before value. |
| 8 | How does this handle a product going end of support? | Support period is modelled, and the obligations end with it. |
| 9 | What happens when the harmonised standards change? | A stated update process, not "we will email you". |
| 10 | Which of these obligations does the tool NOT cover? | A straight answer. Every tool has gaps; only some vendors will name them. |
| 11 | Show me the same view a notified body would be given. | A read-only, evidenced view that is not the sales demo. |
| 12 | What does this cost at 40 products rather than 4? | Published, or at least a formula. Per-product pricing bites late. |
Question 10 is the one worth watching. A vendor who names their gaps is describing a product they understand. A vendor who claims full coverage of a regulation that does not fully apply until December 2027 is describing a roadmap.
Build versus buy
Building is defensible when your product portfolio is narrow and your engineering culture already treats security evidence as a build artefact. You will spend most of the effort not on the tracking but on the parts that are boring and unavoidable: the retention, the audit trail, the out-of-hours escalation, and keeping the whole thing current as the standards land.
The honest test is whether you would still maintain it in year three, when the person who built it has moved on and the CRA is no longer new. Most in-house compliance trackers fail that test. That is not an argument against building; it is an argument for being clear about what you are signing up to.
Frequently asked questions
Is there a certified or approved CRA tool?
No. The CRA certifies products with digital elements, not the software used to manage compliance. Any vendor claiming their tool is CRA certified is describing something that does not exist.
Can one tool cover CRA, NIS2 and DORA together?
Partly, and the overlap is real: secure development, asset inventory and incident processes are shared. The CRA-specific parts, which are the product level essential requirements, the SBOM, CE marking and the technical file, are not. Expect overlap on the governance layer and separate work at the product layer.
When should we buy?
Before the reporting duty rather than before full application. If the tool is not in place and rehearsed by 11 September 2026, the first real test of your process will be an actual exploited vulnerability, which is a poor time to discover who holds the pager.
How much should this cost?
It varies with product count and classification more than with company size. We set out the wider programme cost in Cyber Resilience Act compliance cost, and compare the market in our guide to the best CRA compliance software.
What if we only distribute, not manufacture?
Your duties are lighter but they exist, and they sit in the 10 million euro penalty tier rather than the 15 million one. Who must comply with the CRA sets out the three economic operator roles.
Primary sources
Obligations, dates and penalty tiers are taken from Regulation (EU) 2024/2847 (Articles 13, 14 and 64, and Annexes I, III, IV and VII), and context from the European Commission's Cyber Resilience Act policy pages. Evaluation criteria and cost commentary are our own, drawn from implementation work, and are not from the Regulation. Confirm the current text before relying on a specific date or figure.
