Provability
Cyber Resilience Act: what your software has to prove from September 2026.
The CRA states what manufacturers must report and document. It does not state how software must be built so a 24-hour deadline holds. This page translates the duties into architecture requirements — and says clearly who is not in scope.
The deadline starts at knowledge. The answer has to come from the system.
On 11 September 2026 the first tangible part of the Cyber Resilience Act takes effect: manufacturers of products with digital elements report actively exploited vulnerabilities within 24 hours as an early warning and within 72 hours as a full notification. The same applies to severe security incidents.
These deadlines are not an organisational challenge but an architectural one. If you cannot query which product versions run at which customers, since when a vulnerability has been known and which data is affected, you report estimates. And every corrected estimate is itself an event you have to evidence.
The rest of the regulation follows from 11 December 2027: security by design, vulnerability handling over at least five years, technical documentation, conformity assessment. The common denominator of all stages: the evidence is produced by the system — or not at all.
From duty to architecture requirement.
The left column is in the regulation. The middle one is what your system has to be able to do. The right one is what you produce when it matters.
| CRA duty | What the system must do | What you produce |
|---|---|---|
| Reporting of actively exploited vulnerabilities: 24h early warning, 72h notification (Art. 14) | Impact is queryable: which versions, which installations, which tenants, from which point in time. | A notification with a defensible impact statement — derived from the system, not estimated. |
| Reporting of severe security incidents (Art. 14) | The incident is reconstructable: what happened, in which order, with which consequences. | A reconstructed timeline from history — timestamp, trigger, affected data and functions. |
| Security by design across the lifecycle (Art. 13, Annex I) | Security-relevant changes to code, configuration and permissions are recorded as events with trigger and approval. | Provenance of every change: what, when, triggered by whom, rolled out in which version. |
| Vulnerability handling across the support period (Art. 13, at least five years) | Versions, build states and their distribution stay traceable for years, not only the current state. | Which installation runs which build, and which update was offered at which point. |
| Technical documentation and component bill of materials (Annex I and IV) | Dependencies and their versions are recorded per shipped release — not only in the current repository state. | The bill of materials for a specific release — including the one from two years ago. |
| Conformity assessment and EU declaration of conformity (Art. 31, 32) | Development, testing and release processes are demonstrable rather than merely described. | Proof that the declared processes actually ran that way in the specific case. |
Implementation view, not legal advice. Whether and in which role you are in scope — manufacturer, importer, distributor — is a question for your legal counsel. Pure SaaS and cloud services are generally out of CRA scope; NIS2 is the relevant framework for them.
The four gaps that get expensive in September.
Not at manufacturers without a security process. At products whose history was never designed as evidence.
Impact as an estimate
Nobody can query which customer installations run which version. The 24-hour deadline starts when the vulnerability becomes known — anyone doing inventory at that point reports late or wrong.
Vulnerability management as a ticket list
A tracker says a vulnerability is closed. It cannot prove when it became known, who classified it and which versions were affected. Those exact timestamps trigger the deadlines.
A support promise without a build state
Five years of security updates are promised. But the build, release and delivery state from three years ago can no longer be reproduced. The promise exists; the evidence does not.
Bill of materials as a snapshot
Dependencies can be generated from the current repository. An auditor's question is different: which components were in the version the incident affects?
How we close the gap.
Not as a certification project. At the one question that comes first when it matters: what exactly is affected?
1 — Assess reporting readiness
We walk through the questions a 24-hour notification demands: version, distribution, time of knowledge, affected data. We mark what your system answers today — and what would be guessed in an emergency.
2 — Make impact queryable
Product versions, installations and tenants get linked so the blast radius of a vulnerability is narrowed down in minutes, not days.
3 — Immutable history for what is security-relevant
Vulnerabilities, classifications, approvals and releases are kept as domain events — not alterable afterwards, queryable at any time.
4 — A handover with a name on it
Someone internal owns it afterwards. We document for the person who sends the first notification without us.
When this fits — and when it does not.
Fits when
- you place software on the market as a product — as a download, embedded or as a licensed component
- buyers demand CRA evidence from you across the supply chain
- the reporting deadlines from September 2026 are not covered today
- a new product is being built and the duties should be designed in, not retrofitted
Does not fit when
- you run a pure SaaS/cloud service with no product character — then NIS2 is your topic, not the CRA
- you need a conformity assessment or CE advice — that is what notified bodies and consultants do
- you are looking for legal advice on scope
- you just want to buy a tool — the actual question is what your system can prove
Frequently asked
- Does the CRA apply to our SaaS offering?
- Generally no: pure cloud and SaaS services are out of CRA scope; NIS2 is the relevant framework for them. There is one exception — remote data processing that is necessary for a product's function counts as part of the product. Whether that applies to you is a legal question. What we can assess is whether your systems could deliver the evidence if it does.
- What exactly changes on 11 September 2026?
- The reporting duties under Art. 14 begin: actively exploited vulnerabilities must be reported within 24 hours as an early warning and within 72 hours as a notification, severe security incidents likewise within 72 hours. Reports go through the single reporting platform to the designated CSIRT and ENISA. The remaining duties — security by design, documentation, conformity assessment — follow on 11 December 2027.
- What are the consequences of violations?
- For breaches of the essential requirements and reporting duties, the regulation provides fines of up to 15 million euros or 2.5% of global annual turnover. The more practical lever is the market: products without conformity may no longer be made available, and buyers increasingly ask for the evidence across the supply chain.
- Is our existing vulnerability management enough?
- As a process, maybe. What is new is the provability of timestamps: when did the vulnerability become known, when was it classified, when reported, which versions were affected? A ticket system rarely answers that in an audit-proof way — the deadlines run from knowledge, and knowledge must be dated.
- We are a supplier, not a manufacturer. Does this concern us?
- Very likely, via the supply chain. Manufacturers must document the security of their components and will pass these requirements on to suppliers — similar to today's security questionnaires, but with legal form behind them.
Sources
We cite the published regulation text so you can verify every statement yourself.
Could you file a 24-hour notification tomorrow?
The provability check tests in ten questions whether your system delivers what a notification demands: impact, timestamp, history. Ten minutes, no sign-up, result right away.