Regulation

Since September 11, 2026, any company that sells hardware or software with digital elements in the EU has had to report two kinds of event under the Cyber Resilience Act (CRA, Regulation (EU) 2024/2847): a vulnerability in its product that attackers are actively exploiting, and a severe incident affecting the product's security. The first notice is due within 24 hours of becoming aware. Most of the CRA's product rules only start on December 11, 2027, but Article 14, the reporting duty, applies now.

It covers products already on the market, including ones sold years ago, and the fines reach 15 million euros or 2.5% of worldwide annual turnover, whichever is higher. Buyers are affected too, because the rules decide how fast a supplier has to tell them what to do.

Who counts as a manufacturer

The CRA defines a manufacturer as anyone who develops or manufactures a product with digital elements, or has one made, and markets it under their own name or trademark, whether for payment, monetisation or free of charge. Firmware in a router, a desktop application and an industrial controller all qualify. An importer or distributor becomes the manufacturer if it puts its own brand on the product or makes a substantial modification, meaning a change that affects the product's compliance with the CRA's security requirements or changes its intended purpose. Anyone else who substantially modifies a product and sells it takes on the same role.

The Commission's guidance of July 27, 2026 (reference C(2026) 5252) narrows the edges. Software that runs remotely and is reached by users, such as most SaaS, generally falls outside the CRA unless it is a remote data processing solution a product needs to work. Free and open source software is placed on the market only when it is supplied for a price or otherwise monetised. Open source stewards, the foundations that support such projects, have until December 11, 2027 before they have to report.

What starts the clock

An actively exploited vulnerability. The test is reliable evidence that a malicious actor has exploited the flaw in a system without the owner's permission. A published proof of concept, a researcher's demo or a disclosed CVE with no sign of real abuse does not start the clock on its own. A threat intelligence report of exploitation, a customer's forensic finding or your own telemetry showing abuse does.

A severe incident. Article 14(5) calls an incident severe if it harms, or can harm, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or if it has led or can lead to malicious code running in the product or in users' systems. A compromised build server that shipped a tampered update is the obvious case.

The 24 hours run from awareness, which the guidance ties to the same idea used for GDPR breach notification: the point at which an initial assessment gives you reasonable certainty. Exploitation that you knew about in full before September 11 does not have to be reported. A flaw known earlier whose exploitation you learn of after that date does.

Where and how you file

Reports go through ENISA's Single Reporting Platform (SRP), which opened on September 11 at portal.cra-srp.enisa.europa.eu. One submission reaches both ENISA and the CSIRT (Computer Security Incident Response Team) designated as your coordinator, which passes it to CSIRTs in other member states where the product is sold. A group with several EU subsidiaries files once per event.

Your coordinator is the CSIRT of the member state where cybersecurity decisions about your products are mainly taken. If that is unclear, it is the EU site with the most staff. Manufacturers outside the EU follow a cascade: the member state of their authorised representative, then of the importer placing the most units, then of the distributor, then of the most users. ENISA warns that a notification sent to the wrong coordinator may be invalidated and have to be filed again.

Access needs a personal EU Login account with multi-factor authentication. Each manufacturer has one Primary Assigned Representative, who can invite up to 20 Secondary representatives. At launch there is no API and the portal is English only, so filing is manual.

A 24-hour runbook for vendors

Do the set-up work before the first incident. Register the Primary representative and at least two Secondary ones now, so a holiday or a lost phone does not block a filing. Write down which CSIRT is your coordinator and why, in one sentence your legal team has agreed to. Keep a list of which products are sold in which member states, because the early warning asks for it.

Record the awareness time yourself. The early warning form captures when you detected the issue, but your own ticket should show when triage reached reasonable certainty, who decided and on what evidence. That timestamp is what a regulator will measure you against.

Keep the early warning short. It needs the notification type, your name, the product and version, a title and the member states concerned. For an incident, it also says whether you suspect a malicious act. Do not hold it back while the root cause is still unknown.

The 72-hour notification describes the general nature of the flaw and the exploit, what you have done and what users can do. The final report comes 14 days after a fix or mitigation is available for a vulnerability, or one month after the 72-hour notification for a severe incident, and covers severity, impact, any known attacker and the update, or for an incident the likely root cause.

Article 14(8) also requires you to tell affected users about the flaw or incident and the steps they can take, in a structured, machine-readable format where appropriate. A CSAF (Common Security Advisory Framework) advisory or a VEX (Vulnerability Exploitability eXchange) statement is the usual way to publish advice in that form. If you do not inform users in time, the coordinating CSIRT can do it for you.

Micro and small enterprises cannot be fined for missing the 24-hour early warning deadline. The reporting duty itself still applies, as do the 72-hour and final deadlines.

What buyers should ask suppliers

If you buy firewalls, VPN appliances, OT (operational technology) equipment or commercial software for EU operations, ask suppliers:

• Which entity is the CRA manufacturer for this product, and which CSIRT is its coordinator?
• Who is on call to make the 24-hour decision, and how will we hear about an exploited flaw?
• Will advisories come in a machine-readable format such as CSAF, and where are they published?
• Which of the products we run today are covered, including older models still in service?

Then write the answers into renewals, and point your own vulnerability intake at the supplier's advisory feed so an alert reaches the team that patches.

The US side

In the United States, CISA has said it expects to finalise the CIRCIA (Cyber Incident Reporting for Critical Infrastructure Act) rule in September 2026. The 2024 proposal would require covered critical infrastructure entities to report covered cyber incidents within 72 hours and ransom payments within 24 hours. At the time of writing we could find no final rule in the Federal Register, so its scope and start date are still open.

If you want help mapping your products to the CRA or rehearsing the first 24 hours, see our compliance and audit readiness and security operations work. Open the chat and Yaali, our AI agent, will pass your question to an engineer.

---

Sources: ENISA: The CRA Single Reporting Platform is launched, ENISA SRP FAQ, European Commission: CRA reporting obligations, CRA Article 14 text, Help Net Security, Crowell & Moring, Orrick on the Commission guidance, Hunton on the Commission guidance, cyberresilienceact.eu reporting guide, Sbomify, Hunton on CIRCIA, CISA CIRCIA.