Cyber Resilience Act Reporting Obligations: Who Must Report, When, and How

From 11 September 2026, some companies selling software or connected products in the EU must report serious product-security problems quickly.

These are the reporting obligations under the EU Cyber Resilience Act (CRA). They apply when a vulnerability in a product is being actively exploited, or when a severe incident affects the product's security. The first notification may be due within 24 hours of the manufacturer becoming aware of the issue.

For most teams, the practical question is not whether they can quote Article 14 of the CRA. It is whether they can recognise a potentially reportable event, bring the right people together, make a decision quickly, and submit an initial report on time.

This article provides general information, not legal advice. Whether the CRA applies to a product, and whether a specific event must be reported, depends on the facts.

What are CRA reporting obligations?

The CRA requires manufacturers to report two types of serious product-security event: actively exploited vulnerabilities and severe incidents that affect the security of a product with digital elements.

It does not mean that every bug, outage, failed deployment, or customer support issue must be reported. The reporting obligation focuses on events that create a serious security concern for the product.

The two reportable categories are:

An actively exploited vulnerability means there is evidence that someone is using a security weakness in the product without authorisation.

A severe incident means an event has a serious impact on the security of the product, including its confidentiality, integrity, authenticity, or availability.

For example, a login weakness that attackers are using to access customer accounts could be an actively exploited vulnerability. A compromised software update, stolen code-signing key, or harmful code inserted into a product could be a severe incident.

The reporting rules apply from 11 September 2026. Most other CRA obligations, including the broader product cybersecurity and conformity requirements, apply from 11 December 2027.

Who must report under the CRA?

In most cases, the reporting duty falls on the manufacturer.

Under the CRA, the manufacturer is usually the company that places a product on the EU market under its own name or brand. This may be the legal entity that sells the product, operates the service, or presents the product as its own, even where development or hosting is handled by another supplier.

This can include:

• A company selling software, an application, platform, or business tool under its own brand
• A company selling connected devices, such as cameras, gateways, sensors, printers, or wearables
• A business offering a white-label product under its own name
• A company selling a product developed by an external agency
• A company supplying a digital component separately, such as a plugin, module, library, or development kit

Using a cloud provider, developer, software vendor, or external security provider does not automatically transfer the reporting responsibility. If your company places the product on the EU market under its own name or brand, it may still be the manufacturer for CRA purposes.

Importers and distributors also have duties under the CRA, but the Article 14 reporting obligation is principally aimed at manufacturers.

Which products can be affected?

The CRA covers many products with digital elements that are made available on the EU market as part of a commercial activity.

A product with digital elements can be hardware or software that connects directly or indirectly to a device or network. This can include:

• Connected hardware, such as routers, cameras, smart devices, industrial equipment, sensors, gateways, and printers
• Desktop, mobile, embedded, server, and network-connected software
• Mobile apps that communicate with a device, online service, or network
• Software components sold or supplied separately, including plugins, modules, libraries, operating-system components, and software development kits
• Remote data-processing services that are necessary for a product to perform one of its functions

The details matter. Whether a SaaS product, cloud service, open-source project, free app, or standalone component is in scope can depend on how it is supplied, what it does, and whether it is connected to a commercial activity.

If you have several products, start by mapping what reaches EU customers, which legal entity supplies each product, and which third-party components or services each product depends on.

What problems must be reported?

You may need to report if your company becomes aware of either an actively exploited vulnerability or a severe incident affecting the security of one of its covered products.

An actively exploited vulnerability is more than a theoretical weakness or a high-severity Common Vulnerabilities and Exposures (CVE) record. A CVE is a publicly assigned identifier for a known cybersecurity vulnerability. There should be credible evidence that a malicious actor is actually using the weakness.

A severe incident can include an event that damages, or could seriously damage, the product's ability to protect data or important functions. This may involve confidentiality, integrity, authenticity, or availability.

Examples can include:

• Attackers using a vulnerability to gain unauthorised access to customer accounts
• A software update mechanism being compromised
• Malicious code being inserted into a product or release pipeline
• A stolen signing key being used, or suspected of being used, to distribute untrusted updates
• A significant supply-chain compromise that affects the security of the product
• A compromise affecting important security controls, credentials, or trusted components

A major outage is not automatically a CRA-reportable event. The key issue is whether the outage affects the product's security, rather than only availability, commercial operations, or customer experience.

Do we need to report every vulnerability?

No. The CRA does not require manufacturers to report every vulnerability, bug, misconfiguration, or security alert.

A vulnerability may be serious and still not trigger Article 14 reporting if there is no credible evidence that it is being actively exploited. It may still need urgent remediation, customer communication, a security advisory, or escalation under your internal process.

Other obligations may also apply. Depending on the event, you may need to assess customer contracts, cyber-insurance conditions, sector-specific rules, GDPR breach-notification duties, or other regulatory requirements.

The practical goal is not to report every technical finding. It is to identify serious product-security events quickly and make a documented decision about whether the CRA reporting threshold has been met.

When does the 24-hour deadline start?

The 24-hour deadline starts when the manufacturer becomes aware of the relevant event.

You should not wait until you know the full root cause, the complete attack path, the exact number of affected customers, or every technical detail. A credible alert from a customer, security researcher, supplier, threat-intelligence source, monitoring tool, or internal investigation may be enough to require urgent assessment.

This makes the first internal response especially important. Your team should be able to record the time the issue was first identified, preserve relevant evidence, assess the initial facts, and escalate the decision to the right person without delay.

A useful internal rule is: when credible evidence suggests attackers may be exploiting a product vulnerability, or that a severe product-security incident may have occurred, treat it as time-sensitive until a responsible person decides otherwise.

What are the reporting deadlines under the CRA?

The CRA uses a staged reporting process. An early warning is followed by a more detailed notification and, later, a final report.

Deadline	What is required
Within 24 hours	Submit an early warning notification
Within 72 hours	Submit a fuller notification with available information about the incident or vulnerability, its impact, and corrective or mitigating measures
Within 14 days	Submit a final report for an actively exploited vulnerability, no later than 14 days after a corrective or mitigating measure becomes available
Within one month	Submit a final report for a severe incident, within one month of the 72-hour incident notification

The early warning should not wait for a completed investigation. It is intended to alert the authorities that a potentially reportable issue exists.

The 72-hour notification provides more detail, where available. It should include an initial assessment of the incident or vulnerability, known security impact, measures already taken, and relevant information that may help users reduce risk.

Where are CRA reports submitted?

CRA reports are submitted through the EU's Single Reporting Platform (SRP).

The SRP is an online reporting system for manufacturers and eligible open-source software stewards that need to notify authorities about actively exploited vulnerabilities or severe incidents under the CRA. It makes the report available to the European Union Agency for Cybersecurity (ENISA) and the relevant national Computer Security Incident Response Team (CSIRT). A CSIRT is a national or sector-based team that helps coordinate responses to cybersecurity incidents.

Before an incident occurs, make sure you know:

• Which legal entity is responsible for submitting a report
• Which person or role can decide that reporting may be required
• Who can access the SRP
• Who can submit a report outside normal working hours
• Where product, customer, supplier, and technical evidence is stored
• Who owns customer communications
• Who keeps a record of the decision, timeline, and evidence

A fast deadline is difficult enough. It becomes much harder when no one knows which company is responsible, who has authority to decide, or where the relevant information sits.

What should the first report contain?

The first report should be factual, concise, and clear about what remains uncertain.

Do not delay an early warning simply because you do not yet know the root cause or full scope. Use straightforward language to separate confirmed facts from assumptions and ongoing investigation.

Where available, include:

• The affected product, relevant versions, and affected components
• When and how the company became aware of the issue
• Whether the issue may involve active exploitation, a severe incident, or both
• A short description of the known or suspected security impact
• Whether malicious activity is suspected
• The initial containment, mitigation, or corrective steps taken
• Information about affected EU markets, where known

Useful wording includes "confirmed," "preliminary," "under investigation," and "not yet known." The aim is to provide a timely, reliable first picture, not to make claims that later prove inaccurate.

Are we responsible if suppliers are involved?

Possibly, yes. Suppliers play an important role, but they do not automatically take over the manufacturer's reporting duty.

Your cloud provider, external development agency, component vendor, security provider, or white-label partner may hold essential information. They may provide logs, technical evidence, patches, incident-response support, or customer-impact information. Yet the company placing the product on the EU market under its own brand may still be responsible for the CRA report.

Your supplier arrangements should make this practical. Before an incident, make sure contracts and working processes address:

• Fast access to logs, evidence, and technical contacts
• Clear incident-notification obligations
• Expected response times
• Responsibility for developing, approving, and deploying fixes
• Support for customer communication
• Escalation contacts available outside normal business hours

Do we need to tell customers?

Often, yes. Reporting to authorities and communicating with users are separate tasks.

For actively exploited vulnerabilities, manufacturers must inform affected users without undue delay and, where appropriate, provide information on corrective or mitigating measures users can take.

Customers may need to know:

• Whether they are affected
• Which versions or environments are affected
• Whether an update is available
• Whether they need to rotate credentials, revoke access, or change settings
• Whether a temporary workaround is available
• What they should monitor while the issue is being resolved

Clear customer communication reduces confusion and helps users take protective action. It should be coordinated with technical, legal, support, and leadership teams so that the message is accurate and consistent.

Do CRA reports replace GDPR or NIS2 reporting?

No. A single cyber incident can trigger more than one legal, contractual, or regulatory obligation.

An exploited vulnerability in a software product may need a CRA assessment. If personal data is affected, the organisation may also need to assess GDPR breach-notification duties. If the business is in scope for NIS2, a separate incident-reporting process may apply. Customer agreements, insurance policies, sector-specific rules, and contractual security commitments can create additional deadlines.

Use one coordinated incident process, but do not assume one report covers every obligation. Each possible reporting duty should have its own:

• Trigger criteria
• Deadline
• Responsible owner
• Required information
• Approval route
• Evidence and decision record

What happens if we miss a CRA deadline?

Missing a required CRA report can expose the manufacturer to regulatory action, including financial penalties.

The CRA allows Member States to impose fines of up to €15 million or 2.5% of the company's total worldwide annual turnover from the preceding financial year, whichever is higher, for certain breaches of the regulation's essential cybersecurity requirements and manufacturer obligations. National authorities are responsible for enforcement and penalties.

The consequences are not only financial. A poorly managed incident can also lead to:

• Customer confusion or lost trust
• Inconsistent messages from support, sales, engineering, and leadership teams
• Missed contractual, privacy, insurance, or sector-specific deadlines
• Difficulty showing regulators that the company made a reasonable and timely decision
• Delayed remediation because ownership and escalation paths were unclear

The purpose of preparation is not to turn every alert into a regulatory report. It is to ensure that serious product-security events are recognised, assessed, and handled consistently under time pressure.

How to prepare for CRA reporting

You do not need to create a large compliance programme before taking the first practical steps.

The immediate goal is to make sure your organisation can identify a potentially reportable product-security event, decide quickly whether the CRA may apply, and submit an early warning within 24 hours where required.

A focused preparation process can start with four areas:

1. Map products and ownership
   Identify the products supplied in the EU, the responsible legal entity, key versions, major suppliers, dependencies, and product owners.

2. Create a rapid escalation route
   Define which security signals require urgent review and who is responsible for making the first reporting decision.

3. Prepare the reporting process
   Confirm SRP access, core information requirements, evidence locations, decision records, and out-of-hours responsibilities.

4. Test the response
   Run a short tabletop exercise involving security, engineering, legal, support, communications, and leadership. Test whether the team can make a decision and assemble an early warning within 24 hours.

Key takeaway

From 11 September 2026, manufacturers may need to report actively exploited vulnerabilities and severe incidents affecting the security of covered products within 24 hours of becoming aware of them. The next notification is due within 72 hours, followed by a final report on a different timeline depending on whether the event involves exploitation or a severe incident.

For most companies, the first priority is not reading the CRA line by line. It is understanding which products may be affected, who is responsible for each product, how urgent security signals reach the right people, and who can make and document a fast decision when the reporting clock starts.