CRA software for reporting deadlines and vulnerabilities
The Cyber Resilience Act requires an early warning within 24 hours of becoming aware that a vulnerability in your product is being actively exploited. Our platform keeps your products, bills of materials and vulnerabilities in a shape that lets you meet that deadline — and prove afterwards that you met it.
The clock starts on awareness, not on confirmation
A customer calls on Friday afternoon. Their device is behaving oddly; someone appears to be inside. From that moment you have 24 hours — and nobody in the building knows offhand which products contain the same component.
Three deadlines, two event types, one person
Early warning after 24 hours, notification after 72, final report after 14 days or one month — depending on whether it is an exploited vulnerability or a severe incident. In most companies this sits with a single person who also handles the CE documentation.
The question is not the vulnerability, it is the reach
A report never concerns just one device. If the affected library sits in three product lines and seven variants, that belongs in the report. Reconstructing it from memory and spreadsheets costs half the deadline.
Fines up to 15 million euro or 2.5 per cent
That is the ceiling for breaches of the essential requirements and of the reporting and diligence obligations. When it matters, what counts is not that you were careful but that you can show it.
What a running deadline looks like
One case, three steps, a clock on each. The report text is already drafted from the recorded data — manufacturer, product, affected versions, time of awareness, legal basis.
- The clock starts at the moment you record as awareness. A case may be entered retrospectively; the assessment is then honestly red.
- Every step states its legal basis and lists what has to be in it.
- Once you confirm submission, the text becomes immutable and sits in the audit log with a timestamp.
How you find out that it concerns you
The platform matches the components of all your releases against public vulnerability databases every day. Every hit names the affected products, not just the affected library.
- CISA's KEV catalogue lists vulnerabilities known to be actively exploited. An entry triggers the reporting check — it is an indication, not a determination for your product.
- Every finding needs a decision: affected, not affected with a reason, or fixed. The reasons follow the VEX standard.
- One click turns a finding into a reporting case. The affected products come from the bills of materials, not from memory.
It all rests on the bill of materials
The CRA requires a software bill of materials in a commonly used machine-readable format. It is not paperwork for the file, it is the data basis: without it nobody knows which report concerns which product.
- CycloneDX and SPDX are read including the dependency graph — direct and transitive components are distinguishable.
- A SHA-256 checksum remains for every file read in, so it stays provable which bill of materials belongs to which release.
- Components without an identifier are marked "not checkable" rather than silently treated as clean.
What the platform does
Six building blocks covering the path from product classification to tamper-evident proof.
Classify products — and record the reasoning
Every product, per variant, is mapped to a category from Annex III or IV or classed as a default product. The conformity route follows: self-assessment, self-assessment only where harmonised standards are fully applied, or a notified body as a must. The reasoning is mandatory and logged — when it is disputed, that is exactly the question.
Keep a bill of materials per release
CycloneDX and SPDX as JSON, with dependency graph. Checksum, generating tool and contents are stored as components. The same library across five products is one row in the registry — so a hit is immediately visible for all five.
Match vulnerabilities automatically
Matching runs against OSV.dev for open-source components and against NIST's NVD for firmware parts with a CPE. CISA's KEV catalogue triggers the reporting check on top. If a source fails, the run continues and records the failure — instead of quietly reporting no hits.
Triage that survives
Every finding gets a VEX status: under investigation, affected, not affected with a justification code, fixed. A decision once made survives every further match. Otherwise a month of work would be gone at the press of a button.
Track deadlines and draft the reports
Three steps with their own deadline, for actively exploited vulnerabilities and for severe incidents alike. The report text is built from the case data and states the legal basis. Missing details appear as visible gaps in the text, so you see what the authority would be missing.
Prove that the deadline was met
Every action lands in an audit log where each entry carries the hash of its predecessor. Submitted reports are immutable and stored verbatim. A later change breaks the chain and is detectable at the press of a button.
The key dates
Two regulations, four dates. The platform holds them as configuration rather than program code — if the legislator moves one, that is an edited file.
- 11 Sep 2026
Reporting obligations under Art. 14 CRA
The 24- and 72-hour deadlines apply from this date, regardless of whether the remaining requirements are applicable yet.
- 20 Jan 2027
Machinery Regulation (EU) 2023/1230
No transition period: machinery placed on the market from this date must comply. Machinery placed earlier stays under the old directive.
- 11 Dec 2027
CRA fully applicable
Essential requirements under Annex I, conformity assessment, technical documentation, CE marking.
- ongoing
Support period
At least five years, shorter only where the expected lifetime is demonstrably shorter. Security updates stay available for at least ten years.
Who we built this for
The filter is not the industry but the shape: you place a product with digital elements on the market, you have between 30 and 500 employees, you maintain between 5 and 100 active variants — and you have no dedicated product security department.
Component manufacturers
Controllers, gateways, sensors, drive technology. Industrial gateways and network interfaces often fall under Annex III; class II requires a notified body.
Building and security technology
Access control, smart door locks and security cameras are named in Annex III, along with controls for heating, ventilation and lifts.
Special-purpose machinery with PLC and HMI
The volume segment. Most products are default products under self-assessment — where the manufacturer carries the documentation alone, and where software helps most.
Energy and charging infrastructure
Inverters, charge points, battery storage, metering. Connected, long-lived, hard to update in the field — exactly the combination the CRA targets.
Software vendors without CE routine
Anyone placing software on the market as a product in its own right is a manufacturer under the CRA. This case is often missed because there never was a CE marking before.
Businesses with machinery and digital elements
From 20 January 2027 the Machinery Regulation applies with no transition period and, for the first time, its own cybersecurity requirements. Same products, two legal acts, two deadlines back to back.
What the platform is not
- Not legal advice. Whether your product falls under Annex III, and whether a vulnerability is being actively exploited, is your call. The platform offers the categories, derives the conformity route and records your reasoning.
- Not automatic transmission to the authority. ENISA's single reporting platform has no public interface so far. We provide text, deadline and proof; you submit the report and confirm the time here.
- Not a substitute for vulnerability management in the development team. The platform finds and sorts, it does not fix. Anyone without update infrastructure needs that first.
- Not a tool that takes the classification off your hands. A program telling you your device is a default product would be worthless when challenged — the responsibility stays with the manufacturer, so the decision stays there too.
Frequently asked questions
From when do we have to report?
The reporting obligations under Art. 14 CRA apply from 11 September 2026. Once you become aware that a vulnerability in your product is being actively exploited, or of a severe security incident, you have 24 hours for the early warning and 72 hours for the notification itself. The final report follows 14 days after the corrective measure is available, or one month after the incident notification.
When exactly does the 24-hour clock start?
On awareness, not on confirmation. Waiting until exploitation is technically beyond doubt usually means the deadline is already gone. The early warning is explicitly allowed to be preliminary — it is a warning, not a final report. The platform is built so a case is recorded in two minutes and the rest is added later.
We build machines, not software. Does the CRA apply to us?
As soon as a product contains digital elements and can be connected to a device or network, it is in scope. A controller with an Ethernet interface is a product with digital elements, even if your business is mechanical engineering. From 20 January 2027 the Machinery Regulation adds its own cybersecurity requirements.
Do we need a notified body?
It depends on the classification. Default products, the large majority, may be assessed by the manufacturer. For important products of class I, self-assessment is only available where harmonised standards or common specifications are fully applied. For class II and for critical products under Annex IV a notified body is mandatory. The platform shows the consequence of your classification immediately.
What is an SBOM and do we really need one?
A software bill of materials lists the parts of your product with version and origin. The CRA requires it in a commonly used machine-readable format as part of the technical documentation; it need not be published but must be made available to market surveillance on request. In practice it is the prerequisite for knowing which report concerns which product at all.
Where does the vulnerability data come from?
From OSV.dev for components from open-source ecosystems, from NIST's National Vulnerability Database for parts with a CPE identifier, and from CISA's catalogue of known exploited vulnerabilities. ENISA's European vulnerability database is earmarked as soon as its interface is documented. All sources are configurable and interchangeable.
Could we not build this ourselves?
Technically yes. In practice it fails on three counts: the hard part is not the code but the classification and the data maintenance. An in-house match quickly produces two hundred alerts a day and is muted after four weeks. And developer time is the scarcest resource in mechanical engineering — an internal compliance registry loses every prioritisation against revenue-generating features. Which is why it usually is not built, but kept in a spreadsheet.
Where does our data sit?
The platform runs as a dedicated instance per company — in your own data centre if you prefer, or with an Austrian or European host. Details of vulnerabilities in your own product are sensitive before disclosure; they leave the building only as the report you submit yourself.
What happens when the law changes?
Everything that depends on the legal position sits in declarative configuration: deadlines, categories from Annex III and IV, conformity routes, mandatory content per reporting step, text templates, support period. A change is an edited file and a restart — no software release and no waiting on a vendor. Once the ENISA platform prescribes form fields, we align the templates with them.
At what point does this pay off?
Work it out with your own figures. Market estimates for CRA readiness at a manufacturer with five product lines sit in the mid five-figure range, with update infrastructure alone above that. Ongoing, ten to twenty per cent of the development budget goes into vulnerability management. With fewer than five variants a careful spreadsheet goes a long way. From around ten maintained variants the arithmetic tips.
The right moment is before the first phone call
A reporting case cannot be prepared while the clock is running. What has to exist beforehand is the product registry, the bill of materials, and the answer to who in the building submits the report. We will show you the platform on your own products: clarify scope, import one bill of materials, run the first match.