The EU’s Cyber Resilience Act (CRA) requires that products with digital elements be secure from the outset. But the law doesn’t stop there. It also sets requirements for what should happen after a product has been placed on the market, when a vulnerability is discovered, or when something actually goes wrong.
We met with Peter Jonegård and Martin Snygg to find out how incident and vulnerability reporting under the CRA works in practice. Peter is an advisor at CERT-SE, Sweden’s national CSIRT (Computer Security Incident Response Team), and Martin is a Senior Advisor at NCC-SE, Sweden’s national coordination centre for cybersecurity research and innovation. Since 1 July 2026, both functions have moved from the Swedish Civil Defence and Resilience Agency (MCF) to the National Cybersecurity Centre (NCSC), which is part of the National Defence Radio Establishment (FRA).
Reporting is not just an administrative formality. It gives authorities and the EU a shared picture of the situation, makes it possible to warn others who may be affected, and can trigger coordinated action. A vulnerability is rarely unique to a single manufacturer.
In brief:
- What triggers a reporting obligation under the CRA, and where the line is drawn for what counts as “severe enough”
- The reporting deadlines – and why they’re so tight
- What happens to a report after it’s submitted, and who uses the information
- How uncertainty around reporting cuts both ways. Under-reporting driven by fear, and over-reporting driven by caution
- The support available to manufacturers, and what smaller companies often miss
- Why the ability to handle incidents matters more than reporting itself
What triggers the reporting obligation under the CRA?
Article 14 of the CRA, “Reporting obligations of manufacturers“, comes into force on 11 September 2026. The requirement means that a manufacturer must not only build a secure product, but also actively monitor it after it has been placed on the market, and report if the product’s security is threatened.
The provision distinguishes between two types of events that activate the reporting obligation. The first is when a vulnerability in the product is discovered and actively exploited by an attacker, even if it hasn’t yet caused any harm. The second is a severe incident: something has already happened, and it has had an actual impact on the product’s security.
– The event needs to affect one of the information security properties: confidentiality, integrity or availability, says Peter Jonegård.
Martin Snygg and Peter Jonegård, National Cybersecurity Centre (NCSC)
A typical example he describes is a breach of a manufacturer’s development environment for a specific product. If the attacker introduces a vulnerability, backdoor or other malicious code into the product, every customer who then uses it risks being attacked.
CERT-SE already handles vulnerability reporting today, outside the scope of the CRA. When a new vulnerability is discovered, they assess which product is affected and how many affected systems in Sweden are accessible via the internet, in order to draw attention to security updates where the consequences for society would be greatest.
Where is the line drawn for what should be reported?
The existence of a vulnerability, or something going wrong, isn’t always enough for the reporting requirement to apply. Article 14 states that the vulnerability or incident must have a “severe impact” to count as reportable. But it isn’t always obvious exactly where the line is drawn.
A service that’s down for a few minutes is rarely critical, most people barely notice. But if the same service is down for a week, and it starts affecting people’s lives, the severity increases dramatically. It’s that kind of assessment of the impact on society, not just technical severity, that determines whether something should be reported.
– It’s difficult to set an exact threshold, because this is a European regulation that has to work across all member states. What affects society in Sweden isn’t necessarily the same as in Poland, says Martin Snygg.
That flexibility is deliberate. A strictly defined threshold that works in one country might not fit at all in another. The European Commission has published an FAQ with further guidance, where the section on reporting obligations is particularly relevant here. It’s worth knowing that the FAQ is intended as a living document that’s updated on an ongoing basis, rather than a fixed answer key.
The deadlines – and why they’re so tight
The CRA sets clear deadlines for reporting.
Reporting for a vulnerability:
- Early warning: within 24 hours of becoming aware
- Notification: within 72 hours
- Final report: within 14 days of a fix becoming available
Reporting for an incident:
- Early warning: within 24 hours of becoming aware
- Incident notification: within 72 hours
- Final report: within 1 month of the incident notification
The tight timing is no accident. Vulnerabilities are exploited considerably faster today than they were a few years ago, in many cases on the very same day they become known. It’s this reality that the CRA’s deadlines are designed to meet.
Where does the report go? And what happens next?
The report is submitted via the Single Reporting Platform, the shared reporting platform that ENISA operates for all EU countries. The platform automatically forwards the information to the relevant CSIRT – in Sweden’s case, CERT-SE – and to ENISA. If the manufacturer has indicated that the product is available in other EU countries, CERT-SE shares the report onward with the CSIRT in those countries. The idea is that a manufacturer should only need to report once, regardless of which EU countries the product is sold in.
From there, the information travels onward in several directions at once. Sweden’s market surveillance authority – expected to be the Swedish Post and Telecom Authority, PTS – is also informed, since that authority has the mandate to act if a manufacturer fails to meet the requirements. Once a security update or other remedy is available, details of the vulnerability are also published in ENISA’s vulnerability database, EUVD, so that the information is collected in one place and accessible to other stakeholders.
Manufacturers are responsible for informing users. If they fail to do so for any reason, the CSIRT or the market surveillance authority can step in and inform users directly, if this is considered proportionate and necessary to prevent or limit harm.
For incidents assessed as being linked to a broader crisis, EU CyCLONe (the EU Cyber Crisis Liaison Organisation Network) is brought in.
Information is also compiled over time. Every other year, a trend report is compiled and shared with the EU’s Network and Information Security Cooperation Group, to give a picture of how the threat landscape is evolving.
Uncertainty about reporting cuts both ways
The Cyber Resilience Act’s reporting obligation doesn’t come into force until 11 September 2026. But experience from incident reporting more broadly, not least from the Swedish Cybersecurity Act (NIS2), shows that uncertainty about reporting has two completely opposite effects.
The first is fear, which leads to under-reporting.
Some companies avoid reporting altogether, out of fear of the consequences. This means real incidents never become known to the authorities, because those affected choose not to come forward.
– We’ve noticed that companies ask themselves questions like “Have we done something wrong?” or “Will we be punished?” and then avoid reporting. They think reporting will work against them, rather than provide support, says Peter Jonegård.
The second is uncertainty about where the line is, which leads to over-reporting.
Other companies choose to report just to be safe, even when it’s unclear whether the event triggers the reporting obligation. CERT-SE already receives reports under NIS2 about relatively minor events, such as a company’s intranet being down for a couple of hours with no actual impact on the service delivered.
Both behaviours come down to the same difficulty we’ve already touched on: in the moment, it isn’t always obvious what counts as severe enough to report.
What smaller companies miss
Right now, the biggest problem is a lack of awareness: many companies simply don’t know what the CRA requires of them. Particularly exposed are companies that don’t develop their own products, but instead buy in ready-made solutions and sell them on under their own brand.
– They don’t always realise that they take on manufacturer responsibility when they place a product on the market, even if the product was put together by someone else, says Martin Snygg.
But help is available. A national support ecosystem is being built up, and can be divided into four phases: orient, prepare, implement and maintain. It exists to make the CRA manageable even for smaller players.
NCC-SE coordinates the state’s overall CRA support and targeted funding calls (orient)
NCSC offers cybersecurity advice and exercises (prepare)
PTS will likely be responsible for market surveillance and guidance (implement)
CERT-SE acts as the helpdesk for reporting itself (maintain)
Handling matters more than reporting
Being able to report isn’t enough on its own. Companies also need to be able to detect and handle incidents. To be reachable, with a clear point of contact for anyone who discovers a vulnerability, and to have designated staff who know what to do when something happens.
– The most important thing is the ability to detect and handle incidents, not just to report them, says Peter Jonegård.
A report requires answers to questions like what happened, how severe it is, and what the root cause was. But those questions aren’t just there for the report. A company should want to be able to answer them regardless, in order to handle the incident well. Reporting and handling go hand in hand: if you handle things properly, the report is, in practice, already half-written.
The CRA is about building security in from the start. But even the most secure products can be hit by something unexpected. That’s when a company’s preparation makes the difference.
Read more articles in the same series:
Inside ETSI TC CYBER – Kim Nordström on turning CRA law into finished standards
CRA standards play different roles – Angelo D’Amato explains which one will be decisive
Approved product under the CRA – Ted Strandberg on how companies can start preparing now
