The first operational obligations under the EU Cyber Resilience Act (CRA) are now in effect. From 11 September, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe security incidents to European authorities.
Most of the rest of the CRA doesn't apply until 11 December, 2027. But the reporting obligation applies now, and it applies to products already on the market.
This post covers what the September 2026 requirements are, who they apply to, what triggers a report, how reports are submitted, and more.
Scope of the CRA’s Reporting Requirements
The CRA sets mandatory cybersecurity requirements for "products with digital elements" (hardware and software products, plus the remote data processing solutions they depend on) that are made available on the EU market. It applies regardless of where the manufacturer is based; for example, a U.S. company selling software into the EU is in scope.
The September 2026 requirement includes only a reporting obligation. It requires you to notify authorities when evidence of “any actively exploited vulnerability” or a severe security incident is discovered. Additional CRA requirements, such as maintaining an SBOM and running a coordinated vulnerability disclosure program, don’t take effect until December 2027.
Covered Products
Article 14 and its vulnerability reporting requirements apply to every in-scope product already on the EU market, including products placed on the market years before the CRA existed. Additionally, the vulnerability reporting requirements will persist even after the conclusion of the support period for a given product. In contrast, the December 2027 requirements generally apply to products placed on the market from that date onward; older products only come into scope if they're substantially modified.
Enforcement
Once the CRA is fully implemented, organisations that fail to comply with the vulnerability reporting requirements will be subject to steep penalties (up to €15 million or 2.5% of worldwide annual turnover). However, Article 64 (the CRA section that details penalties) isn't among the provisions that applies early. Still, the reporting obligation is legally binding in 2026, and reports you file (or don't) will form the record regulators look at later. (Related: We aren’t aware of any definitive guidance from the EU that states organisations that violate vulnerability reporting requirements even before December, 2027 will be exempt from fines at a later date.)
What Has to Be Reported
Article 14 has two independent triggers. One is the presence of an actively exploited vulnerability, the other is a severe security incident. An event can satisfy one, both, or neither, and each should be assessed separately.
Actively Exploited Vulnerabilities
The CRA defines an actively exploited vulnerability (in Article 3-42) as follows:
“A vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner.”
However, neither the CRA text nor subsequent guidance has identified a single, universal source of truth for vulnerabilities with evidence of exploitation. There also isn’t a standardised or recommended process for verifying that a vulnerability can be exploited in its production context.
While we certainly encourage every organisation to build a system based on its specific architecture and expertise, one workflow for identifying actively exploited vulnerabilities might include:
- Integrating an SCA tool (like FOSSA) or other scanner that continuously identifies new vulnerabilities in your codebase.
- Filtering and/or applying particular focus to any discovered vulnerabilities that are in the CISA KEV Catalog (a U.S.-government maintained list of vulnerabilities with evidence of exploitation) or EUVD.
- Running validation to determine whether your product is actually at risk from the vulnerability. This may not be the case if the affected version isn’t present in the component or the vulnerable code isn’t reachable, among other reasons.
Severe Incidents
The second trigger is "any severe incident having an impact on the security of the product with digital elements." The CRA provides the following definition in Article 15 (5):
“It negatively affects or is capable of negatively affecting the ability of a product with digital elements to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions; or
“It has led or is capable of leading to the introduction or execution of malicious code in a product with digital elements or in the network and information systems of a user of the product with digital elements.”
It’s certainly possible for an incident to meet this criteria without being associated to a vulnerability. For example, a compromised build pipeline, a stolen code-signing key, or a hijacked update server that pushes malicious code to users could all qualify even if no underlying flaw has been identified.
Elements of the CRA’s Reporting Requirements
The CRA’s reporting rules apply to manufacturers of products with digital elements made available on the EU market. Under the CRA, that means anyone who develops or manufactures a product (or has it developed) and markets it under their own name or trademark, whether for payment or free of charge.
A few other parties can end up with the same obligation:
- As per Articles 21 and 22, importers and distributors are treated as manufacturers if they place a product on the market under their own name or trademark, or substantially modify it.
- As per Article 24 (3), open source software stewards must report to the extent they're involved in development or run the development infrastructure. (The CRA defines “open source software stewards as a “legal person, other than a manufacturer, that has the purpose or objective of systematically providing support on a sustained basis for the development of specific products with digital elements, qualifying as free and open-source software and intended for commercial activities, and that ensures the viability of those products.”)
Note that while the process by which organizations achieve CRA compliance (and the associated CE marking) does vary depending on product classification, the vulnerability reporting obligation applies to all classes.
Who You Report To
Reports go through a single channel: ENISA's Single Reporting Platform (SRP). The official reporting platform portal was published on 11 September and is now available for use. When you submit, you select the CSIRT designated as coordinator for your Member State of main establishment, and the notification is made available to that CSIRT and to ENISA simultaneously. That CSIRT then disseminates it to the CSIRTs in other Member States where your product is available, and shares relevant information with market surveillance authorities, per ENISA's SRP FAQ.
Your "main establishment" is where decisions about your products' cybersecurity are predominantly made. If that can't be determined, it's the EU establishment with the most employees. Manufacturers with no EU establishment work down a fallback order: the Member State where your authorised representative acts for the most products, then where your importer places the most products, then where your distributor makes the most products available, and finally the Member State with the most users. ENISA published the list of CSIRTs designated as coordinators for all 27 Member States on September 4.
One notification per event is sufficient, even if you have multiple EU subsidiaries or a non-EU parent. Coordinating internally so the right entity files is your responsibility.
Reporting Timelines and Stages
There are three different stages to the reporting progress: an early warning, a fuller notification, and a final report. However, the deadlines for completing each stage are different depending on whether the issue is an actively exploited vulnerability or a severe incident.
The clock starts when you become aware of the event, and it doesn't pause for weekends or holidays.
Here’s a brief overview of the different stages:
Early warning
- Actively exploited vulnerability: Within 24 hours of awareness. Indicates the Member States where you know the product is available.
- Severe incident: Within 24 hours of awareness. Also indicates whether the incident is suspected to be caused by unlawful or malicious acts.
Notification
- Actively exploited vulnerability: Within 72 hours of awareness. General information about the product, the general nature of the exploit and vulnerability, corrective or mitigating measures taken, and measures users can take.
- Severe incident: Within 72 hours of awareness. Nature of the incident, an initial assessment, corrective measures taken, and measures users can take.
Final report
- Actively exploited vulnerability: No later than 14 days after a corrective or mitigating measure is available. Describes severity and impact, the malicious actor (where known), and the security update or fix.
- Severe incident: Within one month of the 72-hour notification. Describes severity and impact, the likely threat or root cause, and applied and ongoing mitigations.
Informing Users
Filing with authorities isn't the whole obligation. Article 14(8) also requires manufacturers to inform impacted users (or, where appropriate, all users) about the actively exploited vulnerability or severe incident, along with any mitigation or corrective measures they can take. Where appropriate, this should be in a structured, machine-readable format (such as a VEX statement).
How to Report to ENISA and CSIRTs
All mandatory Article 14 notificateions must go through ENISA's Single Reporting Platform (SRP). Email, national portals, and other channels don't satisfy the obligation. Here's what to know based on ENISA's September 4 FAQ update and supporting guidance.
Access and Registration
People who file on a manufacturer's behalf are called Assigned Representatives (ARs). Each AR needs a personal EU Login account with multi-factor authentication. Each manufacturer has one Primary AR, who can invite up to 20 Secondary ARs. The CSIRT validates the AR–manufacturer link, but validation runs in parallel and doesn't block you from filing. ENISA asks organizations to register on the SRP itself only when they need to submit a notification, to limit validation workload on CSIRTs.
Automation
There isn’t currently an API for submissions available, meaning notifications must be submitted manually through the web interface. (You can of course automate your internal workflows up to the point of filing, but a person has to submit the form.)
Reporting Form Details
If you haven’t already, we highly encourage organizations to view the SRP Glossary, which details form fields and at the stage at which each is required to be completed.
At the 24-hour stage, required fields include the notification type, title, summary, manufacturer name, product name and version, and the date and time you became aware. CVE and EUVD IDs are optional. Fields such as corrective measures, user mitigations, severity, and impact become required at the 72-hour or final stage.
Delayed Dissemination
In particularly exceptional circumstances, you can ask the coordinating CSIRT to delay sharing the notification with other Member States on cybersecurity grounds. This is assessed at the 72-hour stage, and the CSIRT decides. The conditions are set out in Article 16(2) and a Commission delegated act adopted December 11, 2025.
Get Support with CRA Compliance
FOSSA’s software security and compliance platform is a popular choice for organizations seeking to manage like the CRA. In addition to providing comprehensive vulnerability discovery and prioritization capabilities (important for the CRA’s reporting requirements), FOSSA offers solutions for SBOM management, open source license compliance, and more.
You can get in touch with our team to learn more or demo our CRA solutions.