What changed on 11 September 2026
Manufacturers of products with digital elements must now report actively exploited vulnerabilities and severe incidents to the CSIRT of their main establishment, with the information made available to ENISA at the same time. An early warning within 24 hours of becoming aware, a full notification within 72 hours, and a final report no later than 14 days after a corrective measure is available for an actively exploited vulnerability, or within a month of the 72-hour notification for a severe incident. Reporting goes through the ENISA Single Reporting Platform, which the Commission describes as operational as of the same date, and which ENISA launched at what it calls initial operating capability.
It does mean the clock is real. Of the three dated instruments this site tracks for a robot builder, this is the one that has already started: the EU Machinery Regulation 2023/1230 applies from 20 January 2027, and the AI Act’s robustness requirements reach machinery through that Regulation’s delegated acts, which apply by 2 August 2028. The CRA reporting duty was the first of the three to apply, on 11 September 2026.
It does not mean a VLA policy is in scope today. The duty falls on manufacturers of products with digital elements placed on the EU market. Open-source software stewards are subject to their own reporting obligation under Article 24(3) only from 11 December 2027, per Article 71(2). If you ship an open-source policy and nothing else, that is the date that applies to you.
What a 24-hour clock actually asks of you is a measurement before it is a legal question: knowing within a day whether an observed robot behaviour is an exploited vulnerability or an ordinary failure. If you cannot state your policy’s benign failure rate on the same task and the same seed, you cannot tell those two apart, and the 24 hours go on arguing rather than reporting.
Provael’s free CLI reports an Attack Success Rate against a matched benign control per task and seed, with a 95% Wilson interval on both. That is the number worth having before a clock starts rather than during one. It is evidence, not a conformity position, and running it makes nobody CRA compliant.
Source: European Commission, Cyber Resilience Act reporting obligations. Verified 12 September 2026.
At a glance
Read from the site’s regulatory clock, the record that is re-verified against primary law, as of 19 September 2026.
- Instrument
- Regulation (EU) 2024/2847 — Binding law (for the actor it names)
- Applies?
- Applies from 11 December 2027 — upcoming as of 19 September 2026
- Responsible actor
- Manufacturer / economic operator placing the product on the EU market.
- What Provael measures toward it
- SBOM per release, a coordinated vulnerability-disclosure policy, and an RFC 9116 security.txt.
- What that does not establish
- A policy-attack result is not a vulnerability-handling process, and Article 14 is about the process. Article 14 obliges the manufacturer to NOTIFY actively exploited vulnerabilities and severe incidents to ENISA and the coordinating CSIRT on a fixed clock (24h / 72h / 14 days); a Provael run produces neither that process nor those notifications, and cannot start, satisfy or evidence that clock. CRA compliance remains a product-level obligation on the responsible economic operator.
- Source and review
- Primary source · verified 19 September 2026
What a Provael report can be used for
Vulnerability handling
A coordinated vulnerability-disclosure process and an SBOM are baseline expectations - Provael ships both, and publishes a security.txt.
The evidence
- An SBOM published with each release.
- A coordinated vulnerability-disclosure policy and RFC 9116 security.txt.
- Secure-by-default posture: no telemetry and no network egress by default.
What it cannot be used for
A mapping identifies possible relevance. It does not establish that this framework applies to your product, that anything here is compliance, that an assessor or insurer will accept it, or a real-world risk probability. Whether it applies to your product depends on your role, market and product class: a question for your counsel, not a determination this page makes.
- No defined support period: only the latest release is supported, and fixes land there (the product’s SECURITY.md).
- Simulation evidence for the tested checkpoint and protocol. Physical safety and conformity require separate assessment.
- Provael measures adversarial robustness - susceptibility to manipulation - not general accuracy, reliability, or functional safety.
- The measured result uses templated, auditable attacks; the search-based families (optimized, universal_patch, gradient_patch) have no real-policy rate. Results are a floor on susceptibility - a behavioural lower bound, not a certified worst-case bound.
Running Provael does not make a system compliant or certified - it generates measurements you can put into a conformity or assurance file. Provael is not a notified body, a lab, or a certification scheme.
Independent project. Not affiliated with or endorsed by ISO, the EU, NIST, IEC, OWASP, or MITRE. Not legal advice.
Clause references are indicative: check each against the text you hold before you cite it.
The framework
- Regulation (EU) 2024/2847 imposes security-by-design, vulnerability handling and reporting duties on products with digital elements placed on the EU market.
- It requires an SBOM, coordinated vulnerability disclosure, and security updates over a defined support period.
- Reporting duties phase in ahead of full application.
Who it binds
Does this apply to Provael itself? We do not publish an answer, because we have not taken advice and a compliance page that guesses is worth less than one that says where the line is. Manufacturer obligations turn on whether a product with digital elements is made available on the EU market in the course of a commercial activity. Provael’s core is Apache-2.0 and free, paid assessments are offered against it at listed prices, none has sold, and there is no legal entity. Whether that combination is commercial activity for the purposes of the Regulation is genuinely arguable, and we would rather say so than pick the reading that suits us.
One part is not arguable. An open-source software steward under Article 3(14) must be a legal person. There is no entity here, so the Article 24 steward obligations, whose reporting duty under Article 24(3) starts on 11 December 2027 per Article 71(2), do not attach on that basis. If an entity is incorporated, this changes with it.
Does it apply to you? If you integrate Provael into a product that is itself in CRA scope, the reporting duty is yours. Provael evidences one narrow thing — whether a learned policy behaves unsafely under adversarial instruction or observation, measured with a control arm — and it does not discharge any reporting obligation or produce a CRA notification.
Dates (verified 19 September 2026)
- Reporting obligations (Art. 14) apply
- 11 September 2026
- Annex I essential requirements and the rest of the Regulation apply
- 11 December 2027
Check the live EUR-Lex or ISO text before relying on a date.
Primary references
See what a report contains.
The sample report comes from a public run and is published in full, nothing redacted. To have this mapping filled in for your own policy, request a scoping call.