The Cyber Resilience Act has been on the horizon long enough that a lot of device makers have stopped hearing it as a deadline and started hearing it as background noise. That changes as of September 11, 2026, when the CRA's first hard obligations take effect. Anyone placing a product with digital elements on the EU market must, as of that date, start reporting exploited vulnerabilities and security incidents affecting their products to a central reporting platform.
The good news is that the concrete obligations and the threshold for what counts as a reportable incident this first stage are narrower than you might initially think.
The obligation to report is triggered only by real-world exploitation, in your actual end product, not by the mere existence of a vulnerability. However, the bad news is that when you do have a reporting obligation, you have very short deadlines to meet.
Let's unpack what the requirements are, what you need to do to prepare, and what's coming next.
The obligation reporting only
Article 14 of the CRA lists exactly two things a manufacturer must notify:
1. An actively exploited vulnerability in the product.
2. A severe incident affecting the security of the product.
That is the whole scope of the September obligation.
Everything else (the secure-by-design requirements, the obligation to actually ship security updates, conformity assessments, CE marking against the CRA's essential requirements) arrives with the rest of the regulation in December 2027.
"Actively exploited" means exploited, in the field, for real
This is the point most worth understanding completely, because it's the most common misunderstanding I've seen talking to manufacturers over the last couple of years doing CRA work. You need to report "actively exploited vulnerabilities" and "severe incidents impacting the security of a product". "Actively exploited vulnerability" is explicitly defined in the text of the CRA itself:
‘actively exploited vulnerability’ means a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner.
You do not have to report to ENISA that your product contains a component with a published CVE. You do not have to report a vulnerability your security team found. You do not have to report a laboratory proof-of-concept, a theoretical attack path, or a scanner finding. None of those are reportable events under Article 14.
What is reportable is a vulnerability for which you have reliable evidence that a malicious actor has executed code, compromised a device, or otherwise exploited the flaw on a product in the field, without the knowledge of the user or the manufacturer.
The same logic applies for severe incidents: the bar is a production event that either actually compromised, or realistically could have compromised, the security of the product. The kind of incident the CRA targets would be if your cloud backend where devices ship telemetry data was compromised, and user account info was breached.
Two clarifications from the European Commission's CRA guidance are worth knowing about when creating your internal policies and procedures:
- You have a duty to investigate. If you detect or receive a report of suspected exploitation, you have to look into it well enough to determine whether it is real. You cannot avoid the reporting clock by declining to find out. The clock starts when you become aware, and your incident response process has to support that discovery, not subvert it.
- Third-party components are your problem once they're exploited. If a vulnerability in an upstream library in your product is actively exploited, you report it — the fact that you didn't write the code is irrelevant. If you merely learn that a component you ship has a vulnerability that has not been exploited in your product, you don't report.
One more piece of relief: incidents and actively exploited vulnerabilities that you became aware of before September 11, 2026, don't need to be reported. You are not inheriting a backlog.
The deadlines
Now let's look at the most concrete part of the reporting requirement: the deadlines.
Remember that these are deadlines for reporting to ENISA, and the reports are confidential. You don't have to produce public, polished responses on these time scales.
| Stage | Deadline | Content |
|---|---|---|
| Early warning | 24 hours from awareness | For an incident: whether you suspect malicious action. For a vulnerability: which member states the product is known to be used in. |
| Notification | 72 hours from awareness | Initial assessment, including severity, impact and any mitigations available or applied. |
| Final report | 1 month after the 72-hour notification (incidents); 14 days after a corrective measure is available (vulnerabilities) |
Full description, impact, root cause, mitigations applied. For vulnerabilities, also what you know about the actor exploiting it. |
Twenty-four hours is a single business day if you are lucky and a weekend if you are not. If you don't have policies, procedures, and personnel in place by September, it will be very difficult to meet that deadline.
The Single Reporting Platform
Article 16 establishes a Single Reporting Platform (SRP), operated by ENISA, as the entry point for these notifications. Reports are then routed to the relevant national CSIRT (Computer Security Incident Response Team). This is deliberate design: the alternative would have been asking every manufacturer to file separately with thirty-plus national CSIRTs, which nobody wanted.
Concretely, before September:
- Name the humans who will be your Assigned Representatives. Decide who is authorized to file on your behalf, and who their backup is. A 24-hour clock does not care that your security lead is on holiday.
- Get ready to register for the platform. The platform itself isn't available yet, but there is already documentation about what will be necessary to register as an AR. One step you can take in advance: make sure your ARs have a working EU Login account.
- Do a dry run or table exercise. Walk a fictitious exploited vulnerability through your entire chain: detection → triage → decision that it is reportable → 24-hour filing → 72-hour assessment.
- Write your responsible disclosure policy now. The CRA doesn't dictate when you go public, but your customers, your CSIRT, and possibly a researcher on a 90-day timer all will have views. Deciding your disclosure posture during a live incident is how you end up with a bad one. Having a responsible disclosure policy is also a CRA requirement, so it's good to start now.
What else should I do/prepare for?
The September 2026 obligation doesn't include an obligation to actually patch the vulnerabilities you report. The obligation to provide security updates only lands with the rest of the CRA's baseline requirements, in December 2027.
However, as a practical matter, it's not a great idea to report an incident that you have no way to patch. Your final report has to document mitigations, for example. If your answer after 14 days is "we don't have a patch for this, sorry", it's likely your customers won't be very happy with your response. More to the point, the entire reporting regime assumes you can credibly answer a set of questions that a lot of device makers currently cannot: Is this vulnerability in my product? If so, in which versions? How many devices are running those version, and which EU countries might they be in?
Those questions turn the 24-hour deadline from tight into impossible if you aren't well prepared. If a CSIRT, a customer, or a researcher tells you a CVE is being exploited against your device, the investigation you owe them starts with knowing your own bill of materials, and the deployment context of devices out in the field. Without that, you spend the first day of a 3-day process figuring out what you shipped.
The basic needs are:
- A maintained SBOM per released image. This is the first thing you need in your investigation into a potentially-exploited CVE. If you have accurate, actionable SBOMs corresponding to released products, you have a better baseline for determining the blast radius.
- Continuous CVE tracking against that SBOM. If the first time you learn about a potential vulnerability is when an exploit is discovered in the wild, reacting within 24 hours will be nearly impossible. Continuous CVE monitoring allows you to triage vulnerabilities on your schedule, instead of meeting them in a panic for the first time during an incident.
- Fleet visibility. If you have good fleet management and monitoring, you can know which devices are running which versions, in which countries. This is what the 24-hour early warning actually asks for in the vulnerability case.
- A secure, reliable update system. This is what converts a reportable event into a resolved one, and it is a hard requirement as of December 2027 anyway. Make sure it's in place early and your 2027 product security work will be much easier.
None of this is particularly exotic. If you’ve been following best practices for secure product development and have the basic tools and processes in place, you likely already have most of this.
How Torizon can help you get CRA-ready
Torizon provides you with a reliable, secure, and easy-to-use solution for all of these problems. Torizon OS ships with a maintained software bill of materials for the image you actually deployed, and Torizon Vulnerability Manager continuously tracks published vulnerabilities against it — so the question "does this CVE affect my fleet?" has an answer before someone asks it under a 24-hour clock, not after. We also offer vulnerability monitoring and triage against your actual deployed device, using your real threat model.
Paired with Torizon Cloud's secure over-the-air update system, with Uptane under the hood giving you signed manifests from every device, you have the two halves of the problem solved in one place: you have evidence of exactly what you shipped, and you are able to change it in the field. The first half is what the September 2026 reporting obligation depends on. The second half is what December 2027 makes mandatory.
Compliance is a useful forcing function here, but it isn't really the reason to do this. The reason is that the alternative-finding out what's in your product at the same time you find out it's being exploited-is a very bad day (or week, really) that you can decline to have.
