Cyber incident reporting is entering a new phase on both sides of the Atlantic. In the European Union, mandatory vulnerability reporting obligations under the Cyber Resilience Act (CRA) are scheduled to begin on 11 September 2026. In the United States, the Cybersecurity and Infrastructure Security Agency (CISA) identifies the Cyber Incident Reporting for Critical Infrastructure Act (CIRCIA) as a priority, and they are working as quickly as possible to finalize and implement.
The two sides of the Atlantic are approaching cyber incidents in different parts of the technology ecosystem. The EU Cyber Resilience Act (CRA) focuses primarily on the security of hardware and software products with digital elements used and distributed in and through the EU. CIRCIA focuses on substantial cyber incidents experienced by organizations operating in US critical infrastructure sectors.
For industrial organizations, product suppliers and operational technology (OT) professionals, understanding both approaches will be important.
The EU Cyber Resilience Act vulnerability reporting requirements
ENISA has maintained that 11 September 2026 is the go-live date for worldwide manufacturers with EU products with digital elements to be required to report to two categories of events:
- Actively exploited vulnerabilities
- Severe incidents affecting the security of a product
In an actively exploited vulnerability, there is reliable evidence that a malicious actor has exploited the weakness. A severe incident may have a significant impact on the product in question in a variety of ways.
Manufacturers must submit an early warning within 24 hours of becoming aware of a reportable event, and a more detailed notification within 72 hours. For an actively exploited vulnerability, a final report is due no later than 14 days after a corrective or mitigating measure becomes available.
For a severe incident, the final report is due within one month after submission of the 72-hour incident notification. Reports will be submitted through the ENISA Single Reporting Platform (SRP), as outlined in Article 16 of the CRA. It is important that you review the EU’s CRA information on the exact reporting process. Additionally, manufacturers must inform impacted users of the vulnerability or incident and, where necessary, of the mitigation and corrective measures they can deploy.
What falls into the CRA’s definition of products with digital elements?
The reporting obligations apply broadly to manufacturers placing products with digital elements on the EU market this pertains to both existing products on the market and newly introduced products after the EU’s implementation. This may include suppliers of industrial controllers, gateways, embedded software, SCADA applications, network equipment, cybersecurity products and other hardware or software used in industrial environments. Certain open-source software stewards are also subject to tailored reporting obligations.
Remote data-processing solutions that are necessary for a product to perform its functionality would also be covered. Three elements in understanding if a product with digital elements falls under CRA are:
- Whether it meets the definition of a product with digital elements;
- Whether it is made available on the market, either within a finished product or as a component placed separately on the EU market, including products from outside of the EU but coming into the EU market;
- Whether its intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network.
How CIRCIA is expected to work
The Cyber Incident Reporting for Critical Infrastructure Act of 2022 (CIRCIA) takes a different approach to the EU. A requirement in CIRCIA stipulates that the Cybersecurity and Infrastructure Security Agency (CISA) develop and implement regulations requiring covered entitles to report to CISA covered cyber incidents and ransom payments. Under the proposed rule, qualifying entities in US critical infrastructure sectors would be required to report covered cyber incidents to CISA no later than 72 hours after the entity reasonably believes the incident has occurred. Ransom payments would need to be reported within 24 hours after payment is made. Supplemental reports would also be required as new information becomes available during and post-incident.
Potentially qualifying organizations currently appear to be those in one of the 16 critical-infrastructure sectors. But, under the proposed rule, CISA will also use business-size and sector-specific criteria to determine whether an organization would qualify as a covered entity.
A final CIRCIA rule is a priority for CISA, and they are working as quickly as possible to finalize. The full scope, definitions and compliance dates will not be certain until the rule is officially published.
Reporting mechanisms already available through CISA, including a 24/7 online ”report a cyber issue” process. Note that these existing voluntary processes will likely change with the final mandatory CIRCIA report process. The thought at the time of writing is that the final plan will also require notification outside of the government, with manufacturers informing impacted users.
Similar goals, different perspectives
The most important similarity to CRA’s mandatory vulnerability reporting and CIRCIA’s proposed reporting requirements is that both frameworks are designed to give government cybersecurity authorities earlier awareness of cyber activity that may affect more than one organization. Both seek:
- Faster identification of coordinated attacks
- Earlier warnings to other potential victims
- Improved threat intelligence
- Stronger public-private coordination
- Reduced cascading or systemic risk
The central difference is who reports and what is being reported.
| Area | CRA's Vulnerability Reporting | US CIRCIA Reporting |
| Primary Focus | Security of hardware and software products with digital elements on the EU market | Cyber incidents affecting critical infrastructure entities |
| Trigger and primary reporting party | Triggered by an actively exploited vulnerability impacting security. The product manufacturer, and in some cases, open-source software stewards. | Triggered by a covered CIRCIA cyber incident and ransom payment demands. The covered entity would report. |
| Initial timeline | 24-hour early warning after being aware | 72-hour incident report is proposed |
| Detailed notification | Within 72 hours | Proposed in CIRCIA bill, within 72 hours |
| Ransom payment report | No separate CRA ransom-payment report requirement | Proposed in CIRCIA bill, within 24 hours |
| Reporting destination | ENISA Single Reporting Platform (SRP)* | CISA, but platform is unknown |
| Current status | Reporting begins 11 September 2026 | Compliance dates remain pending |
* The plan is for the SRP to provide a single electronic reporting point through which the reporting notification is submitted to the designated national CSIRT coordinator and made available to ENISA. As of this writing, we have not been able to view the reporting system.
A dual-reporting scenario
The relationship becomes especially clear when an industrial product is exploited. Consider an industrial controller manufacturer that discovers reliable evidence that a vulnerability in its product is being used against customers. The manufacturer may need to report the actively exploited vulnerability under the CRA Vulnerability Reporting requirements if the product has been placed on the EU market.
At the same time, a US water utility or energy operator using that controller may experience operational disruption. If the organization falls within CIRCIA’s final definition of a covered entity and the event meets the reporting threshold, it may have a separate obligation to report the incident to CISA. The same cyber event could therefore produce two different reports:
- A product-level report from the manufacturer
- An operational incident report from the affected asset owner These reports would provide different but complementary information. The manufacturer may be best positioned to explain the affected versions, vulnerability, mitigation and product lifecycle. The operator may be best positioned to describe the operational impact, affected facilities, safety implications and recovery process.
Why this matters for OT and industrial organizations
Both reporting activities are relevant to operational technology because industrial cybersecurity depends on close coordination among product suppliers, system integrators, service providers and asset owners. A manufacturer may detect exploitation through customer reports, vulnerability research, product telemetry or security monitoring. An asset owner may first observe unusual operational behavior, loss of availability, unauthorized access or disruption to a physical process.
Preparing for a more connected reporting environment
The EU is approaching the challenge through the security of products placed on its market. The United States is approaching it through the operational experience of critical infrastructure entities.
Together, they reflect the same underlying principle: a cyber event affecting one product, supplier or operator may create risk across an entire sector. For industrial organizations operating internationally, the most practical response will be to establish a coordinated global incident-intake process that can support multiple reporting obligations. Product security, OT cybersecurity, legal, compliance, engineering and executive leadership will all need defined roles.
Different questions, different reporting parties, but one shared goal: improving collective visibility and reducing the wider impact of cyberattacks.
PLEASE NOTE: The information from both EU and CISA could change, as both implementations are very fluid at the time of this writing.
Additional Resources:
