The EU Cyber Resilience Act reporting obligation for manufacturers starts on 11 September 2026: early warning within 24 hours of becoming aware of an actively exploited vulnerability or severe incident, and full notification within 72 hours, through the ENISA Single Reporting Platform. Open-source stewards are covered from 11 December 2027 under Article 24(3). Source: Cyber Resilience Act - Reporting obligations | Shaping Europe’s digital future
I am not posting this as a compliance warning. Most of us here are not manufacturers placing a product on the EU market, and nothing changes for an open-source stack tomorrow.
The engineering question underneath it is the one I would like to ask this group, because it applies whether or not the regulation touches you.
When a fielded robot does something wrong, how do you currently decide, quickly, whether that was an induced failure or the system’s own baseline failure rate showing up?
On my own bench, I can only answer it because I keep a clean control run at the same task and seed. Without that, a single bad rollout is uninterpretable in either direction: I cannot call it an attack, and I cannot call it noise.
What do people do in the field, where you do not get to re-run the same seed? Is there prior practice in the ROS world for baseline-rate logging that I should be reading instead of inventing?