7 Steps to Take Now: How to Address the EU CRA Reporting Requirements
by Colin Duggan, BG Networks co-founder and CEO
The EU Cyber Resilience Act (CRA) is often discussed as a December 2027 product-conformity project. But manufacturers face an earlier operational deadline; on September 11, 2026, the CRA’s mandatory reporting obligations began. From that date, manufacturers must report actively exploited vulnerabilities and severe incidents affecting the security of their products with digital elements through ENISA’s Single Reporting Platform (SRP).
This blog will bring you up to speed on EU CRA reporting requirements and outlines 7 steps to identify resources and implement processes so that your organization has a robust process to meet these obligations, not just respond.
Products that are in-scope for the EU CRA are ones that are sold in the EU, have a network or data connection, and are not currently regulated, including software (desktop and mobile), consumer products, industrial and networking devices, and semiconductors. For more information on what products are in-scope for the EU CRA, check out our blog “EU CRA Frequently Asked Questions.”
What Must Be Reported?
The CRA establishes two specific mandatory reporting triggers:
- An actively exploited vulnerability, is a vulnerability for which there is reliable evidence that a malicious actor has exploited the vulnerability in a system without the system owner’s permission.
- A severe incident, which is an incident that negatively affects the product’s ability to protect the availability, authenticity, integrity, or confidentiality of data or functions.
These definitions should be built directly into your company’s triage criteria.
When these reporting triggers are experienced, the following tables show the required reports a company must submit and the required schedule for submission through the SRP.
EU CRA Reporting Obligations
| Actively Exploited Vulnerabilities | ||
|---|---|---|
| Stage | Deadline | Required Information |
| Early Warning | Within 24 hours of awareness | Alert of an actively exploited vulnerability, list of countries where the affected product is available |
| Notification | Within 72 hours of awareness | Affected product versions, nature of exploit, corrective or mitigating actions taken, corrective measures users can take, and sensitivity of the notification |
| Final report | No later than 14 days after a corrective or mitigating measure becomes available | Description of the vulnerability, its severity and impact, information concerning any malicious actor exploiting the vulnerability, and corrective measures made available to remedy the vulnerability |
| Severe Incidents | ||
|---|---|---|
| Stage | Deadline | Required Information |
| Early Warning | Within 24 hours of awareness | Alert of a severe incident, list of countries where the affected product is available |
| Notification | Within 72 hours of awareness | Initial assessment of the incident, any corrective or mitigating measures taken, corrective measures users can take, and sensitivity of the notification |
| Final report | Within one month after the submission of the incident notification | Detailed description of the incident, its severity and impact, root cause, and applied and ongoing mitigation measures |
The response team does not need to complete root-cause analysis before filing the 24-hour early warning. The staged process permits an initial report based on limited available information, followed by a more complete 72-hour notification and, later, a final report.
Seven Steps to Product Incident Response Preparedness
In order to meet these time sensitive reporting requirements, companies can take these 7 actions to prepare now.
Step 1: Identify In-Scope Products and Product Experts
Start by determining which product families fall within CRA scope. This work cannot wait until a vulnerability is discovered because the Article 14 reporting obligations apply to in-scope products already placed on the market, including legacy products placed on the market before the CRA’s main December 2027 application date.
For each in-scope product identify:
- The product owner and responsible engineering organization
- The product-security contact
- Current and historical product versions (both hardware and software)
- Support status
- Update method
- Principal third-party hardware and software dependencies
- The EU countries in which the product has been made available
- The personnel who can evaluate a vulnerability and develop a mitigation plan
The purpose is not simply to create a compliance inventory. It is to make sure the response team knows whom to call and if a vulnerability affects a specific product.
Step 2: Assign the Team and Decision Authority
Name primary and backup personnel. A workable CRA product-incident team will typically involve:
- Product security personnel or the Product Security Incident Response Team (PSIRT)
- Product developers/engineering team
- Enterprise cybersecurity
- Regulatory
- Legal personnel
- Customer support
- Corporate or customer communications
- A person authorized to submit the EU notification
Document who receives and triages the initial report, records the official awareness time, evaluates the evidence of exploitation, applies the CRA severity criteria, approves each reporting stage, coordinates corrective measures, and communicates with users.
Avoid a process that requires a long chain of executive approvals. The statutory clock is tied to the manufacturer becoming aware of the actively exploited vulnerability or severe incident—not to the completion of an internal investigation or approval process. The 24-hour timeline does not allow for a complete investigation to be conducted - the only way to respond quickly is to have an existing process and a team who are trained on the process.
Step 3: Write the Triage and Reporting Procedure
The written procedure should identify the intelligence and intake sources the company will monitor. These may include:
- Customer support cases/inquiries
- Vulnerability reports from security researchers
- Supplier and component-maintainer notices
- Internal testing and penetration testing
- Product telemetry
- Enterprise security alerts
- Public vulnerability and exploitation advisories
- Industry information-sharing groups
- Notifications from government cybersecurity organizations
All sources should feed a controlled triage process. The procedure should explain how to preserve evidence, identify affected products and versions, assess evidence of exploitation, determine potential product impact, record the awareness time, escalate the case, decide whether the event is reportable, and prepare the required submissions.
The procedure should also identify the correct Computer Security Incident Response Team (CSIRT) designated as coordinator (nation/government response team in the Member State where a company is established).
Reporting to authorities is not the only communication obligation. After becoming aware of an actively exploited vulnerability or severe incident, manufacturers must also inform impacted users—and, where appropriate, all users—about the vulnerability or incident and the mitigation or corrective measures users can deploy.
Step 4: Create Standard Templates and a Controlled Repository
Don't wait for an incident to decide what information the company needs to collect. Create internal templates that mirror the 24-hour, 72-hour, and final report stages. ENISA’s published reporting fields include the required types of information noted in Table 1 of this article.
The company’s internal record should also capture the awareness date and time, intelligence source, affected versions and components, evidence reviewed, decisions and approvals, notification identifiers, user communications, and a complete event chronology.
Store these records in a clearly identified repository with appropriate access controls, retention, and backup. Consistent records will accelerate preparation of the external notification and provide evidence that the company followed its defined process.
Step 5: Use the Single Reporting Platform
ENISA has established the CRA SRP as a centralized electronic entry point for notifications. A manufacturer will submit its notification through the platform and select the appropriate CSIRT designated as coordinator. The report will be made available to that CSIRT and ENISA, and the receiving CSIRT can disseminate relevant information to other Member State CSIRTs and market-surveillance authorities.
The SRP platform uses an EU Login and provides Primary and Secondary—or backup—Assigned Representative user roles for manufacturers. Companies should select those individuals, make sure they have active EU account credentials, review ENISA’s instructions and interface examples, identify the correct CSIRT, and rehearse the information-gathering process using their internal reporting templates.
Manufacturers should monitor ENISA’s SRP page for the latest platform-access information and instructions.
Step 6: Publish a Vulnerability Reporting Page
Researchers, customers, suppliers, distributors, and integrators need an obvious route to the product security team.
The CRA requires that manufacturers establish and enforce a coordinated vulnerability disclosure policy and provide a contact address for reporting vulnerabilities. Annex II also calls for a single point of contact through which product-vulnerability information can be reported and received and where the coordinated vulnerability disclosure policy can be found.
These Annex I and Annex II requirements generally become applicable with the CRA’s main obligations in December 2027. However, implementing them now is a practical way to improve readiness for the September 2026 reporting deadline because it helps vulnerability information reach the correct personnel quickly.
A dedicated security or vulnerability-reporting webpage should:
- Provide a monitored email address or secure reporting form
- Identify the products covered by the process
- Explain the information reporters should provide
- Offer a secure method for submitting sensitive information
- Describe how the company will acknowledge and coordinate reports
- Link to the company’s coordinated vulnerability disclosure policy
The contact address must route to a monitored process. An unattended security mailbox does not create a functioning vulnerability response capability.
Step 7: Test the Process
Run a tabletop exercise before the deadline. For example, assume that a researcher reports an authentication flaw in a third-party software component and provides evidence that attackers are exploiting it in a fielded industrial product.
Start the clock and require the team to:
- Identify the affected products and versions
- Find the responsible product experts
- Determine where the products were made available in the EU
- Review the evidence of active exploitation
- Evaluate the potential impact
- Identify immediate user mitigations
- Make the reporting decision
- Draft the 24-hour and 72-hour submissions
- Prepare an initial user communication
The exercise will expose missing product ownership, slow approval paths, incomplete templates, inaccessible information, and unavailable backup personnel while there is still time to correct those problems.
Preparation, Not Just Registration
CRA reporting readiness is not primarily about opening an account on an EU website. It requires an accurate product inventory, named product experts, a cross-functional response team, written decision criteria, standard templates, controlled records, a visible vulnerability-intake channel, and a process that has been tested under time pressure.
September 11, 2026 is the first major operational test of CRA readiness. Manufacturers should make sure that the right information can reach the right people—and then reach the EU—without delay.
This article was originally published on EE Times DesignLine prior to the September 11, 2026 reporting deadline.