The CRA Reporting Clock Starts Friday. What Does It Actually Cover?
On 11 September 2026 the Cyber Resilience Act's reporting duties begin, and a robot maker becomes obliged to notify an actively exploited vulnerability within 24 hours 1. The obligation is real and the preparation advice is sound. It is also worth reading what the trigger actually says, because the definition requires a malicious actor acting without permission 1, and several of the robot failure modes most likely to hurt someone involve no attacker at all.
Key takeaways
- From 11 September 2026, manufacturers must notify an actively exploited vulnerability to the coordinating CSIRT and ENISA: early warning within 24 hours, notification within 72 hours, final report within 14 days of a fix being available 1.
- An "actively exploited vulnerability" requires reliable evidence that a malicious actor exploited it "without permission of the system owner" 1. Two conditions, both of which exclude an authorized insider.
- The other trigger is an incident affecting the ability to protect "the availability, authenticity, integrity or confidentiality of data or functions" 1. That is a security test, not a safety one.
- A robot that moves wrongly because its own model misread a scene may satisfy neither. Nobody attacked it, and its data and functions were protected throughout.
- That harm is not unregulated. AI Act Article 73 covers an "incident or malfunctioning" leading to death or serious harm 3, on a different clock and to a different authority 2.
What starts on 11 September?
The reporting half of the Cyber Resilience Act. Article 14(1) requires a manufacturer to notify "any actively exploited vulnerability contained in the product with digital elements that it becomes aware of" simultaneously to the CSIRT designated as coordinator and to ENISA, through the single reporting platform established under Article 16 1.
The cadence is the part with operational consequences. Article 14(2) requires an early warning "without undue delay and in any event within 24 hours" of becoming aware; a fuller vulnerability notification within 72 hours covering the product, the general nature of the exploit and the vulnerability, and any corrective or mitigating measures; and a final report "no later than 14 days after a corrective or mitigating measure is available" 1.
Article 14(3) adds the second trigger: a manufacturer must likewise notify "any severe incident having an impact on the security of the product with digital elements" 1. Both triggers, one platform, one set of clocks. Our secure-by-design and CRA guide covers the wider obligations and the December 2027 date; this article is about what these two triggers do and do not reach.
What counts as an actively exploited vulnerability?
Less than people assume, and the definition is worth reading slowly. The CRA defines it as "a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner" 1.
There are two independent conditions in that sentence, and both must hold. There must be a malicious actor, which excludes a component behaving badly on its own. And that actor must have acted without permission of the system owner, which excludes someone who had permission.
The second condition is the one that catches people out. We wrote recently about insider risk on robot fleets, where the operator is genuine and the command is one they are entitled to issue. Whatever else that is, it is not an actively exploited vulnerability under this definition, because permission is exactly what the insider has. There is also the word "reliable evidence", which sets a threshold: suspicion that something was exploited is not the same as evidence that it was.
What counts as an incident affecting the security of the product?
Something that degrades the product's protective properties. The CRA defines an "incident having an impact on the security of the product with digital elements" as one "that negatively affects or is capable of negatively affecting the ability of a product with digital elements to protect the availability, authenticity, integrity or confidentiality of data or functions" 1.
That is a classic information-security formulation, and it is broad within its own frame. Note what the frame is: the ability to protect data or functions. It asks whether the product's protective properties held, not whether the product did the right thing.
For most products with digital elements those two questions collapse into each other, because the harm a router or a password manager causes runs through data. For a robot they come apart, because a robot can do something harmful while every protective property it has is working exactly as designed.
Would the failures we have documented actually trigger it?
Several would not, and the pattern is consistent enough to be worth tabulating. This site has spent a year documenting robot failure modes; applying the two statutory tests to them is a useful exercise for anyone writing a reporting procedure this week.
| Failure mode | Malicious actor without permission? | Ability to protect data or functions degraded? | CRA trigger |
|---|---|---|---|
| Unauthenticated root chain exploited by an attacker | Yes | Yes | Clearly |
| A skill that exceeds its declaration through developer oversight | No | Arguable at best | Doubtful |
| Telemetry sent by design without clear notification | No | No, it is functioning as built | No |
| An authorized operator issuing a harmful permitted command | No, they have permission | No | No |
| A perception model misreading a scene and the robot moving wrongly | No | No | No |
The last row is the uncomfortable one, because it is the failure mode with the most direct path to a person being hurt. A vision-language-action model that misinterprets what it sees produces a wrong movement through an entirely intact security posture. Nothing was exploited, no credential was misused, and the product protected its data and functions throughout.
One qualification worth making explicitly. Adversarial input is different: text placed in a scene deliberately to change a robot's behaviour, which we covered under prompt injection against VLA models, does involve a malicious actor acting without permission, and would sit far closer to the first row. The distinction is not whether AI was involved. It is whether anybody attacked.
So is behavioural harm simply unreported?
No, and it would be wrong to leave that impression. A different instrument covers it directly. AI Act Article 73(1) requires providers of high-risk AI systems to report any serious incident to the market surveillance authorities of the Member States where it occurred 2.
The definition is the mirror image of the CRA's. A serious incident means "an incident or malfunctioning of an AI system that directly or indirectly leads to" the death of a person or serious harm to health, serious and irreversible disruption of critical infrastructure, infringement of obligations protecting fundamental rights, or serious harm to property or the environment 3. The words "or malfunctioning" do the work: no attacker is required.
The clocks differ too. Article 73(2) sets 15 days from awareness as the outer limit, with the report due immediately once a causal link or its reasonable likelihood is established; Article 73(3) requires two days for a widespread infringement or a critical-infrastructure incident; and Article 73(4) requires reporting in the event of a death immediately on establishing or suspecting a causal relationship, and no later than 10 days 2.
So the honest summary is not that behavioural harm escapes reporting. It is that the two regimes ask different questions, and a robot can answer no to the security question and yes to the harm question.
If another regime covers it, why does the gap matter?
Three reasons, and none of them is that anybody escapes anything. The first is timing. Article 73 obliges providers of high-risk AI systems 2, and whether a robot's AI is a high-risk AI system is decided by Article 6, whose route for AI embedded in products covered by existing product legislation applies from 2 August 2028, as we set out in the piece on AI Act scope. The CRA duty starts this Friday. Confirm your own position with counsel, because the interaction of the two timetables is exactly the sort of question that turns on your specific product.
The second is that they report to different places. CRA notifications go to the coordinating CSIRT and ENISA through the single reporting platform 1. AI Act serious incidents go to market surveillance authorities 2. A procedure built to satisfy one does not automatically satisfy the other, and the team who would receive the call is usually not the same team.
The third is internal. If the only reporting drill your organization has rehearsed is the security one, then the events that trigger it are the events that get escalated fast, and the events that do not trigger it get handled as engineering matters at engineering speed. That is a reasonable response to the incentives and a poor response to the risk.
What do you actually need in place by Friday?
The capability to answer three questions inside a day, which is a different thing from the intention to answer them. Which units run which software version right now. Whether there is reliable evidence that a malicious actor exploited something without permission 1. And what corrective or mitigating measures exist, since the 72-hour notification asks for them and the final report is pegged to their availability 1.
Version inventory is the one most robotics organizations are weakest on, and it is upstream of everything else. You cannot scope an exploited vulnerability across a fleet you cannot enumerate, and attestation answers that question with what is actually running rather than what the deployment record says should be.
The evidence question is the second gap. Establishing that something was exploited, rather than suspecting it, needs a record of what the robot was asked to do and what it did. A fleet without that will spend its first 24 hours trying to work out whether the clock is even running, which is the worst possible use of the first 24 hours.
What should a robot maker check before the weekend?
Read your draft reporting procedure and find the sentence that defines what triggers it. If that sentence says something like "a security incident" without reproducing the statutory tests, it will be interpreted by whoever is on call at the time, and different people will interpret it differently under pressure. Write both triggers out in full, and write out what does not trigger it.
Then run one real event through it. Take an actual thing that happened to your fleet in the last year, and walk it through the tests. The tool below does that against the wording in the two regimes and produces a dated reading you can put in front of counsel. It applies statutory tests rather than giving advice, other regimes may apply besides these two, and everything runs in your browser.
Reportability Triage
Applies the tests in CRA Article 14 and AI Act Article 73 to an event that actually happened. Nothing you enter leaves your browser.
Describe an event that has actually happened. This applies the statutory tests; it does not replace counsel, and other regimes may apply besides these two.
Frequently asked questions about CRA reporting obligations for robots
When exactly do CRA reporting obligations start?
The reporting duties apply from 11 September 2026. Article 14(1) requires manufacturers to notify any actively exploited vulnerability in a product with digital elements to the CSIRT designated as coordinator and to ENISA simultaneously, through the single reporting platform under Article 16 1. Article 14(2) sets an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available 1. The CRA main obligations follow on 11 December 2027.
Does an insider incident trigger CRA reporting?
Not as an actively exploited vulnerability. The CRA defines that as a vulnerability for which there is reliable evidence that a malicious actor exploited it "without permission of the system owner" 1. An authorized operator has permission, which is what makes them an insider rather than an intruder. Whether the event separately amounts to an incident affecting the ability of the product to protect availability, authenticity, integrity or confidentiality of data or functions 1 is a fact-specific question worth putting to counsel, and it is a different test from the vulnerability one.
What if a robot injures someone and nothing was hacked?
On the CRA tests, that may trigger nothing. There is no actively exploited vulnerability without a malicious actor 1, and a robot that moves wrongly through an intact security posture has not necessarily failed to protect data or functions 1. The harm is addressed by a different instrument: AI Act Article 73 requires providers of high-risk AI systems to report serious incidents, defined to include an incident or malfunctioning leading to death or serious harm to health 23. The Machinery Regulation, market surveillance and national accident rules may also apply.
What is the difference between the CRA and AI Act reporting triggers?
The CRA asks whether security failed: an actively exploited vulnerability requiring a malicious actor without permission, or an incident affecting the ability to protect availability, authenticity, integrity or confidentiality of data or functions 1. The AI Act asks what happened as a consequence: an incident or malfunctioning leading to death or serious harm to health, serious disruption of critical infrastructure, infringement of fundamental rights obligations, or serious harm to property or the environment 3. The clocks also differ: 24 hours, 72 hours and 14 days under the CRA 1, against 15 days generally, 10 for a death and 2 for critical infrastructure or widespread infringement under Article 73 2.
Does prompt injection against a robot count as an exploited vulnerability?
It sits much closer to one than an ordinary model error does, because adversarial input involves someone deliberately manipulating behaviour. The CRA definition turns on a malicious actor exploiting a vulnerability without the system owner's permission 1, and text placed in a scene specifically to change what a robot does is an act by an actor rather than a spontaneous failure. Whether a given case meets the definition depends on the evidence available and is a question for counsel; the useful distinction is not whether AI was involved but whether anybody attacked.
What do we need operationally to meet the 24-hour clock?
Three capabilities. Knowing which units run which software version right now, which attestation answers more reliably than a deployment record. Being able to establish, rather than suspect, that something was exploited, which needs a record of what each robot was asked to do and what it did. And knowing what corrective or mitigating measures exist, since the 72-hour notification asks for them and the final report is pegged to their availability 1. A fleet lacking the first two spends the first day working out whether the clock is running.
Does RankShield Robotics handle CRA reporting?
No. We do not file notifications, determine reportability, or provide legal advice, and reportability is a legal judgement about a specific event. What we provide is the evidence those judgements rest on: attestation establishing which firmware, policy and model version a specific unit was running, authorization decided off-robot so a permit or refusal exists as a record, and tamper-evident provenance of what each robot was asked to do and what it did. That is what turns "we think something happened" into a determination you can make inside 24 hours.
References
- European Union. Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 14 and Article 3, points (42) and (44). 2024. eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402
- EU Artificial Intelligence Act (Regulation (EU) 2024/1689). Article 73, Reporting of Serious Incidents, via the AI Act Explorer. 2024. artificialintelligenceact.eu/article/73/
- EU Artificial Intelligence Act (Regulation (EU) 2024/1689). Article 3, point (49), definition of serious incident, via the AI Act Explorer. 2024. artificialintelligenceact.eu/article/3/
Keep exploring
Answer the question inside the day.
Attested versions and a record of what was commanded, so reportability is a determination rather than a guess.
This article is for general information and does not constitute legal advice. It quotes Regulation (EU) 2024/2847 and the EU Artificial Intelligence Act as published, and applying those tests to a specific event, product or organization is a question for qualified counsel. Regimes other than the two discussed here may impose their own reporting duties, including the Machinery Regulation, market surveillance rules, sectoral requirements and national accident reporting. The AI Act provisions referenced bind providers of high-risk AI systems, and whether a particular robot falls within that classification depends on Article 6 and its application timetable.