An incident process manager’s view of the people, decisions and communication needed to make the CRA work.
The Cyber Resilience Act brings a question into focus that reaches well beyond legislation: how do we turn responsibility for digital products into something an organisation can carry out when a security problem occurs?
The Act aims to improve the security of software and connected hardware sold in the EU. Its requirements cover product design, development and maintenance, including the handling of vulnerabilities. Most of its obligations apply from 11 December 2027. Manufacturers’ reporting duties began earlier, on 11 September 2026. European Commission: the Cyber Resilience Act.
That earlier deadline is what caught my attention. It brings the Act directly into the work of assessing a security problem, gathering information and deciding who needs to know.
I’m not one of the leading experts on the Cyber Resilience Act, and I’m still learning its details. But I’ve spent enough time in cybersecurity and incident coordination to have an opinion about how requirements like these meet everyday work. From an incident process manager’s perspective, I can see reasons to welcome them, alongside a few things that worry me.
Under the CRA, manufacturers must report actively exploited vulnerabilities and severe incidents affecting the security of products within its scope. The reporting timetable includes an early warning without undue delay, at the latest within 24 hours of awareness, and a more detailed notification within 72 hours of awareness. Reports go through ENISA’s Single Reporting Platform. European Commission: CRA reporting obligations.
Those are reporting deadlines. The investigation and the work to reduce the risk may still be continuing. The duty also has defined triggers: an ordinary IT outage does not automatically become a reportable CRA incident.
In The Human Side of an Incident, I wrote about coordinating the investigation, the incident log and the communication while the situation is changing. Reading the CRA brings me back to that work. For a manufacturer carrying these obligations, the quality of that coordination helps determine whether useful information reaches the right people in time.
My first worry is whether organisations know how a security finding becomes a CRA reporting decision.
A customer might report unusual behaviour in a product. Support may recognise a pattern across several cases. Developers may identify a vulnerable component. The security team may hold evidence that changes the assessment again.
Those observations need to come together. Someone has to assess the reporting criteria, identify the affected product and establish what the organisation knows. A ticket moving through several queues can look like progress while the key decision still has no owner.
For me, preparing for the CRA means agreeing how that assessment happens, who leads it, and how new evidence reaches them. I would want a record of what became known and when, including the reasons behind decisions. A reporting procedure becomes much more useful when it connects to the channels through which problems actually arrive.
The next concern is how we handle uncertainty under the CRA’s deadlines.
The Act uses reporting stages for a reason. An early warning begins the notification process; later stages provide more information. ENISA’s guidance explains that the required fields differ between the early warning, the 72-hour notification and the final report. ENISA: reporting guidance.
I worry about organisations interpreting the first deadline as a demand for a complete explanation.
During an investigation, a suspected cause can change. The affected versions may take time to establish. A workaround may still need testing. If people feel pressured to make their assessment sound final, the resulting communication can become less reliable.
I would want CRA reporting to preserve those distinctions: confirmed findings, current assessments and unanswered questions. That takes a working culture in which updating an assessment is accepted as part of the investigation.
There is also a practical question behind the Single Reporting Platform: who can act on the manufacturer’s behalf?
A central platform provides a common route for reporting. Internally, an organisation still needs to decide who gathers the information, who checks it, who submits it and who provides cover. A coordinator cannot resolve an approval delay simply by feeling more responsible for the deadline.
Imagine a reportable product-security issue arising late on a Friday, with the usual decision-maker unavailable. That is the kind of scenario I would want a CRA readiness exercise to include. The escalation route needs to work when the usual arrangement breaks down.
Then there is the workload of keeping all of this moving.
For a smaller manufacturer, the people investigating a vulnerability may also be developing the fix, answering customer questions and supplying the information for the CRA notification. Every request draws on the same limited attention.
My concern is that organisations will add the reporting task without making room for it. I would want preparation to include protected investigation time, a shared incident record, clear update moments and cover for the person coordinating the response. These arrangements help turn a legal obligation into work a team can sustain.
The CRA also makes communication with affected users part of the response. Article 14 requires manufacturers to inform impacted users about the vulnerability or incident and, where necessary, the measures users can take to reduce its impact. Cyber Resilience Act, Article 14(8).
This is where the Act connects directly with IT teams using those products.
A warning needs to help someone determine whether they are affected. Which versions are involved? What can they do now? Does the proposed measure interrupt a service? When will further information follow?
Those are the questions I would ask while coordinating a response. My worry is that a manufacturer could focus so heavily on its submission to the authorities that the practical needs of its customers receive too little attention. Useful communication requires technical findings to become information other people can act on.
That connection also matters after the first 24 hours. Further reporting, mitigation and investigation need owners. The people receiving the warnings may be coordinating incidents of their own.
I support the CRA’s aim of making product security a more consistent responsibility. Earlier visibility of serious problems can help others assess their exposure, and clear duties can strengthen the case for investing in preparation.
My concern is the gap between adopting a regulation and building the capacity to carry it out.
The CRA’s wider promise depends on decisions about product security, maintenance, staffing and communication. I would want organisations to use its implementation to examine those decisions together. A timely notification matters, and so does the work that makes the product safer afterwards.
A legal deadline can create urgency. Making that urgency useful is an organisational responsibility.