CRA Reporting Requirements: What Article 14 Means for US and Canadian OT Manufacturers

Since 11 September 2026, any manufacturer placing a product with digital elements on the European market has had a legal duty to report actively exploited vulnerabilities and severe security incidents inside 24 hours. Full compliance with the rest of the EU Cyber Resilience Act does not arrive until 11 December 2027, but Article 14 is already live and already enforceable. For a control system vendor in Houston or a safety instrumented system integrator in Calgary, that gap matters: the reporting clock is running well before the design requirements bite.

This is not a European problem with a European solution. The obligation attaches to the product on the EU market, not to the address of the company that built it. If your PLCs, HMIs, RTUs, protocol gateways or engineering software reach an EU customer through a distributor, a system integrator or an OEM skid package, you are inside the scope of Article 14. The practical question is whether your OT incident response process can produce a defensible filing in a single working day.

What actually triggers a report

Article 14 creates two separate duties, and they are often confused. They have different triggers, different content and different final deadlines.

Actively exploited vulnerability. A vulnerability in your product where there is reliable evidence that a malicious actor has exploited it in a system without the owner's permission. A published proof of concept is not enough. Evidence of real exploitation is.

Severe incident. An event affecting, or capable of affecting, your product's ability to protect the availability, authenticity, integrity or confidentiality of data. Note the phrasing: capable of affecting. A compromise of your own build or update infrastructure can qualify even before a customer is harmed.

The distinction that catches vendors out A researcher disclosing a flaw in your firmware does not start the clock. Evidence that someone is using that flaw against a customer does. Your triage process needs to separate those two states quickly and record why it reached its conclusion, because that judgment is what you will be asked to defend.

 

The three deadlines

Stage	Deadline	What it must contain
Early warning	24 hours from awareness	Notification type and level, manufacturer name, product identification, a title. For incidents, whether unlawful or malicious acts are suspected.
Notification	72 hours from awareness	General nature of the vulnerability or incident, exploit details, initial assessment, corrective or mitigating measures already applied, actions users can take. For incidents, when it was detected and when it occurred.
Final report	Vulnerabilities: 14 days after a corrective or mitigating measure becomes available. Incidents: one month after the 72-hour notification.	The complete account, including root cause and the measures delivered.

 

The two final report deadlines work differently and this is worth reading twice. For a vulnerability, the 14 days do not start when you discover the problem. They start when a fix or mitigation becomes available, which means a long remediation cycle does not put you in breach. For a severe incident, the month runs from the 72-hour filing regardless of where remediation stands.

Where the report goes

Filings route through the EU Single Reporting Platform. From there they reach ENISA automatically and the CSIRT designated as coordinator for your jurisdiction. For a manufacturer with no EU establishment, which describes most North American vendors, the coordinating CSIRT is determined by the main establishment rules in Article 14(7). That CSIRT then passes the report to other affected member states.

Two things follow. Know in advance which CSIRT is yours, because 24 hours is not enough time to work it out. And note that narrative fields on the platform are capped at 4,000 characters, so pre-written templates beat a blank page at hour twenty-two.

Building a filing capability in an OT business

Most industrial manufacturers already have a product security process. Very few have one that can reach a regulator in a day. The gaps tend to be the same ones.

• No single owner. Article 14 needs a named person with authority to file without a committee. In practice that is usually a product security lead, not legal.
• No product inventory tied to markets. You cannot report on a product identification you cannot produce. Firmware versions, variants and which of them reached the EU all need to be answerable from a system rather than from memory.
• No evidence trail on triage. The decision not to report is as important as the decision to report, and it needs a record.
• No link to the support organization. Field engineers see exploitation first. If their escalation path is a ticket queue reviewed weekly, the window closes before anyone senior knows.

A software bill of materials makes all of this faster, because it turns "is this component in our product" into a query rather than an investigation. Our guide to SBOM for OT supply chain and procurement covers how to build one on industrial products.

How this sits alongside NIS2 and North American rules

CRA reporting is a manufacturer duty on a product. The NIS2 duty is different: an in-scope entity reporting incidents affecting its own services. A vendor can owe both. Our NIS2 compliance playbook for OT and ICS sets out the operator side, and our NIS2 guide for energy and utility operators covers sector specifics.

Against CISA reporting or NERC CIP, the CRA timelines are tighter and the trigger is broader, because a product merely capable of being affected counts. Teams with domestic reporting experience find the process familiar and the clock unfamiliar.

Why Choose Arista Cyber

We work inside live industrial environments rather than on policy in the abstract, so our reporting frameworks account for what field teams can actually do on a running plant. Our consultants hold functional safety and OT security credentials and work to IEC 62443 across North America and the Gulf. Our case studies show the pattern.

Next Steps

If you sell into Europe, start with a scope check and a dry run: which products reached the EU market, who your coordinating CSIRT is, and whether a simulated exploitation report can be filed inside 24 hours with the people you have. Pair it with an OT risk assessment if your product security baseline has not been reviewed recently.

Common Questions

Does the CRA apply to a manufacturer with no office in the EU?

Yes. The obligation follows the product onto the EU market, not the manufacturer's location. Non-EU manufacturers are generally expected to have an authorised representative in the EU, and the importer carries its own verification duties.

Is a disclosed vulnerability reportable even if nobody has used it?

No. The trigger for Article 14 is active exploitation with reliable evidence. Ordinary coordinated disclosure does not create a reporting duty, though it does feed your vulnerability handling obligations.

What happens if we miss the 24-hour window?

Article 14 is already enforceable, and penalties under the regulation are significant. In practice, a late filing with a clear record of when you became aware and why triage took the time it did is a far better position than a silent one.

Do we report to one authority or several?

One. You file through the Single Reporting Platform, and it distributes to ENISA and the coordinating CSIRT, which then informs other affected member states.

Does this replace our existing CISA or NERC CIP reporting?

No. The duties sit alongside each other. A single event can require separate filings on separate timelines, which is why a consolidated incident record is worth building once.

Can your team file an Article 14 report in 24 hours? Arista Cyber runs CRA reporting readiness reviews for industrial manufacturers in the US and Canada, covering scope, triage criteria, product identification and a timed dry run against a simulated exploitation event. Book a CRA readiness review