Cyber Resilience Act (CRA): the reporting obligations are live. What manufacturers must do now

It is a Friday evening in October. A customer’s security team sends a short message to your support address: they are seeing attacks against the web interface of a gateway you sell, and the attackers seem to know exactly which request to send. Your engineers look at the logs the customer shared and recognise a known flaw in a library your firmware bundles.

Until recently, what happened next was an internal matter. You would fix the flaw, ship an update and perhaps tell your customers. Since 11 September 2026, that is no longer enough. Under the Cyber Resilience Act, the moment you become aware of this exploitation, a 24-hour clock starts. Before Saturday evening, you have to send an early warning to EU authorities.

This guide explains what the new reporting duty covers, who it applies to, how the three reporting stages work, how the EU’s new reporting platform works in practice and what you should set up now, so that a Friday evening like this one does not turn into a crisis.

What changed on 11 September 2026

The Cyber Resilience Act, Regulation (EU) 2024/2847, is the EU’s first horizontal law on the cybersecurity of products. It covers almost every product with digital elements sold in the EU: software, connected devices and components, from industrial controllers and routers to mobile apps, firmware and smart home devices. It entered into force on 10 December 2024 and applies in stages.

Most of the law is still ahead. The essential cybersecurity requirements for product design, the duty to handle vulnerabilities throughout a product’s support period and the CE marking only apply from 11 December 2027. But one part applies already: Article 14, the duty to report actively exploited vulnerabilities and severe incidents. It has applied since 11 September 2026, and on the same day ENISA, the EU cybersecurity agency, switched on the platform through which those reports are made.

You do not need to be compliant with the rest of the Cyber Resilience Act to be bound by its reporting duty. It applies now, and it covers products that have been on the market for years, not only new launches.

The key dates in one place:

• 10 December 2024: the Cyber Resilience Act entered into force.
• 11 June 2026: the rules on notifying conformity assessment bodies started to apply.
• 11 September 2026: the reporting obligations in Article 14 apply, and ENISA’s Single Reporting Platform went live.
• 11 December 2027: the regulation applies in full, including the essential requirements, vulnerability handling under Article 13 and CE marking.

Who has to report

The duty sits with the manufacturer. Under the Cyber Resilience Act, that is the company that develops a product with digital elements, or has it developed, and places it on the EU market under its own name or brand. If you sell a device with your logo on it that runs firmware someone else wrote, you are the manufacturer for that product.

A few groups need a closer look:

• Manufacturers outside the EU are in scope as soon as they sell into the single market. If they have appointed an authorised representative in the EU, the report goes to the CSIRT of the member state where that representative is established.
• Importers and distributors do not file reports themselves when the manufacturer is known, but they must inform the manufacturer without delay when they learn about a vulnerability.
• Companies that substantially modify a product and put it on the market can become manufacturers themselves, with all the duties that come with it.
• Open-source software stewards, such as foundations that support projects used commercially, have a lighter regime. Their reporting duties start later.

Pure software as a service, without a product placed on the market, is generally outside the Cyber Resilience Act. That changes when a cloud backend is needed for a product to perform its functions. The regulation treats such a backend as part of the product, which means an incident on your update server or device management platform can fall under Article 14.

What has to be reported

Article 14 creates two separate reporting duties. The distinction matters, because the thresholds and the final report are different.

Actively exploited vulnerabilities

A vulnerability counts as actively exploited when there is reliable evidence that a malicious actor has exploited it in a system without the permission of the system’s owner. In the Friday evening example, the customer’s logs are that evidence.

Just as important is what does not trigger a report. A flaw your own team finds in testing, or one a security researcher discloses to you responsibly, is not reportable under this rule as long as nobody has exploited it. You still have to fix it, and from December 2027 you will have to handle it under Article 13, but the 24-hour clock does not start.

Severe incidents affecting the security of the product

The second duty covers incidents. An incident is severe when it has, or could have, a negative effect on the product’s ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions. It is also severe when it has led, or could lead, to malicious code being introduced or executed in the product or in a user’s systems.

The textbook case is a compromised build pipeline or update server. If an attacker gets into the system that signs and distributes your firmware and ships a tampered update to customers, that is a severe incident, even if no single vulnerability in the product itself was exploited.

The reporting clock

All deadlines run from the moment you become aware of the exploitation or the incident. Not from the moment the analysis is finished, and not from the next working day. In practice, this means the clock can start in a support inbox, a security mailbox or a customer call, long before the security team has looked at anything.

Within 24 hours: the early warning

The early warning is deliberately short. For an actively exploited vulnerability, it says that you consider the vulnerability actively exploited and, where you know it, in which member states the product is available. For a severe incident, it says whether you suspect the incident was caused by unlawful or malicious acts. The point is speed, not completeness.

Within 72 hours: the notification

The notification is the fuller picture. It describes the affected product, the general nature of the exploitation or incident, your initial assessment and the corrective or mitigating measures you have taken or that users can take. You report what you know at that point. If the picture changes, you update it.

The final report

For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective or mitigating measure is available. It describes the vulnerability, its severity and impact, what you know about the actor who exploited it, and the security update or other fix you made available.

For a severe incident, the final report is due within one month of the 72-hour notification. It covers the severity and impact of the incident, the likely root cause and the mitigation you applied.

Telling your users

Reporting to the authorities is only half of the duty. After becoming aware of an actively exploited vulnerability or a severe incident, you also have to inform the affected users, and where appropriate all users, about the problem and about what they can do to protect themselves. If you can, use a structured, machine-readable format. If a manufacturer does not inform its users in time, the CSIRT can step in and do it instead.

In the Friday evening example, the user notification would tell customers to switch off the remote admin interface until the patched firmware is available. That one sentence may protect more customers than the report itself.

How the Single Reporting Platform works in practice

All mandatory reports go through ENISA’s Single Reporting Platform at portal.cra-srp.enisa.europa.eu. You submit once, and the platform passes the report at the same time to the CSIRT that acts as your coordinator and to ENISA.

A few practical details make a big difference when the clock is running:

• Access runs through EU Login, the European Commission’s identity service, with multi-factor authentication. There is no separate company account.
• Each manufacturer has assigned representatives: one primary representative and several secondary ones. The CSIRT validates that these people really act for your company, and that takes time.
• Your coordinator CSIRT is normally the one of the member state where your main establishment is. Choose deliberately, because a wrong choice can mean resubmitting.
• At launch, reports are submitted through web forms, not through an API. That means a person has to enter the report, and they need the facts at hand.
• If the platform is unavailable, national CSIRTs point to an emergency route by email using ENISA’s official templates. Find out now which address applies to you, rather than during an incident.

The practical consequence is simple: register before you need the platform. Creating EU Login accounts and waiting for validation during a live incident eats into the 24 hours.

One incident, three reports

The Cyber Resilience Act is not the only law with reporting duties, and one event can trigger several of them at once. Each has its own recipient, threshold and timeline:

• The Cyber Resilience Act, Article 14 is about the security of your product. Reports go through the Single Reporting Platform to your coordinator CSIRT and ENISA.
• NIS2, Article 23 is about significant incidents in your own services and operations, if your company is an essential or important entity. It has its own early warning within 24 hours, notification within 72 hours and final report within one month, sent to your national CSIRT or authority.
• GDPR, Article 33 is about personal data breaches. The data protection authority must be notified within 72 hours.

Take the compromised update server again. If your company is an important entity under NIS2, the attack on your own infrastructure may be a significant incident under NIS2. The tampered firmware on customer devices is a severe incident under the Cyber Resilience Act. And if the attacker reached customer account data on the same server, GDPR applies as well. Three duties, three recipients, overlapping deadlines.

The EU has proposed making ENISA’s platform a common entry point for incident reports under several of these laws. That is a proposal, not current law. Until it is adopted and in force, plan for separate reports and check each duty on its own.

What to set up now

None of the following is complicated. What makes it hard is that it has to work at 21:40 on a Friday, with the person who knows the most on holiday.

1. Name a decision-maker and a deputy. Someone has to decide, at any hour, whether an event meets the threshold. Both need to be reachable, and both need to know they are the ones deciding.
2. Register on the platform. Create EU Login accounts, appoint your primary and secondary representatives and choose your coordinator CSIRT. Make sure at least two people can actually log in.
3. Know which products are where. Keep an inventory of your products and versions on the EU market, and in which member states they are sold. The early warning asks for exactly this.
4. Bring every signal into one place. Vulnerability reports, threat intelligence, customer support and security monitoring must all feed one triage process. Otherwise you may become aware of something in a mailbox nobody reads, and the clock starts anyway.
5. Write down your threshold. What counts as reliable evidence of exploitation? What makes an incident severe for your products? Write it down with examples, so the decision does not depend on who happens to be on call.
6. Prepare the reports in advance. Pre-fill product data, contacts and standard wording for all three stages and for the user notification. The 24 hours should be spent on facts, not on formatting.
7. Connect it with NIS2 and GDPR. Add a step to the same playbook that checks the other reporting duties, so nobody assumes one report covers all of them.
8. Rehearse it. Run a tabletop exercise with a realistic scenario and time it. Most teams find their first gap within the first hour.

Mistakes we see most often

Waiting for certainty. Teams hold back the early warning until they understand the full picture. The early warning exists precisely because you will not have that picture in 24 hours. You can update it later.

Forgetting older products. A device sold in 2022 that is still available in the EU is in scope. The reporting duty does not care when the product was first placed on the market.

Only one person with access. If that person is on holiday or ill, you cannot file. Two people with working access is the minimum.

Treating the user notification as optional. It is a separate legal duty, and often the step that actually protects your customers.

The stakes are real. Breaches of the essential requirements and of the obligations in Articles 13 and 14 can lead to fines of up to 15 million euros or 2.5 percent of worldwide annual turnover, whichever is higher.

What comes next

Reporting is the first part of the Cyber Resilience Act to apply, and the work you do now carries straight into December 2027. From then on, manufacturers must design products against the essential requirements, handle vulnerabilities throughout the support period, keep a software bill of materials, provide security updates and document all of it for the CE marking.

A company that can already tell which products are affected by a vulnerability, in which versions and in which countries, has done a large part of that preparation. A company that cannot will find the reporting duty hard, and December 2027 harder.

Sources: Regulation (EU) 2024/2847 (Cyber Resilience Act), Articles 13, 14, 16 and 64; European Commission, Cyber Resilience Act reporting obligations and implementation FAQ; ENISA, Single Reporting Platform FAQ and registration guidance (September 2026); Directive (EU) 2022/2555 (NIS2), Article 23; Regulation (EU) 2016/679 (GDPR), Article 33.