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 instruments this site tracks for a robot builder, this is the one that has already started: EU Machinery Regulation 2023/1230 applies from 20 January 2027, and EU AI Act Article 15 for embedded high-risk AI from 2 August 2028. The CRA reporting duty is the first of those three to bite, and it bit 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 fifteen months away.
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, https://digital-strategy.ec.europa.eu/en/policies/cra-reporting. Verified 12 September 2026.
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 mandates an SBOM, coordinated vulnerability disclosure, and security updates over a defined support period.
- Reporting duties phase in ahead of full application.
Where a red-team result fits
Vulnerability handling
A coordinated vulnerability-disclosure process and an SBOM are baseline expectations - Provael ships both, and publishes a security.txt.
Evidence produced
- 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.
Who this 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 Aug 2026)
- Reporting obligations (Art. 14) apply
- 11 September 2026
- Full application
- 11 December 2027
Not legal advice; verify the live EUR-Lex/ISO text at launch before relying on these dates.
Primary references
What it is - and isn’t
- adversarial-only - Provael measures adversarial robustness - susceptibility to manipulation - not general accuracy, reliability, or functional safety.
- evidence-not-certification - The output is evidence you file, not a certificate. Provael is not a notified body, a lab, or a certification scheme.
- behavioural-not-worst-case - The measured result uses templated, auditable attacks; the search-based families (optimized, universal_patch, gradient_patch) have only met the CPU fixture. 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.
Independent project. Not affiliated with or endorsed by ISO, the EU, NIST, IEC, OWASP, or MITRE. Not legal advice.
Clause references are indicative; a wrong clause citation is worse than a missing one.
Turn this into filed evidence.
Download the redacted sample pack, or book an assessment to get the crosswalk filled in for your policy.