CRA reporting obligation since 11 September 2026: 24 hours until the first report

Which CRA obligations have applied since 11 September 2026?

Since 11 September 2026, the reporting obligation for manufacturers under Article 14 of the Cyber Resilience Act has applied. It requires manufacturers to report actively exploited vulnerabilities and serious security incidents to the authorities. All other manufacturer obligations under the CRA will follow only on 11 December 2027.

The European legislator deliberately brought this one obligation forward. Authorities are intended to obtain an early overview of attacks on connected products and to build up their own response processes before the full obligations programme applies.

The Cyber Resilience Act timetable provides for four stages:

• 10 December 2024: the CRA enters into force; the obligations do not yet apply.
• 11 June 2026: Chapter IV on notified bodies becomes applicable.
• 11 September 2026: the manufacturer reporting obligations under Article 14 CRA apply.
• 11 December 2027: the CRA becomes fully applicable; cybersecurity becomes a market access requirement.

Unlike the rest of the obligations programme, the reporting obligation is not linked to when a product was placed on the market. It covers the entire existing product portfolio.

Products that have been on the market for years and that will no longer need to undergo a conformity assessment after 11 December 2027 may also trigger reporting obligations. Whether a product is classified as critical or important is equally irrelevant, as are turnover and company size.

However, the reporting obligation does not apply retroactively: you do not have to report vulnerabilities and incidents that became known before 11 September 2026. Anyone offering products with digital elements should therefore first clarify whether they are a manufacturer within the meaning of the CRA at all.

Which companies are subject to the CRA reporting obligation?

The reporting obligation under Article 14 CRA applies to manufacturers of products with digital elements. From 11 December 2027, importers and distributors will initially report to the manufacturer and, only in the event of a significant security risk, additionally to the market surveillance authority. Open-source software stewards will be subject to their own, reduced obligation from the same date.

Which products are products with digital elements?

A product with digital elements is any software or hardware that can establish a direct or indirect data connection to another device or a network. This also includes the related remote data processing solutions that the manufacturer develops itself or under its responsibility.

The technical form of this connection is irrelevant. A USB interface that can be used to read out fault memory is sufficient, as is an Ethernet connection or cloud access.

These product groups typically fall within the scope of the CRA:

• Hardware with software: connected devices, machines and systems, as well as pure hardware components such as mainboards and circuits.
• Standalone software: mobile apps and locally installed programs that can establish an external connection.
• Remote data processing solutions: for example, the fitness dashboard without which a smartwatch could not perform one of its functions.
• Excluded: medical devices, in vitro diagnostic medical devices, motor vehicle regulations, civil aviation, marine equipment, identical spare parts, areas with overriding specific Union law, as well as national security, defence, classified information and the protection of sensitive state information.

Pure web applications and software-as-a-service are generally outside the scope because they are services. If you offer the same solution additionally as a locally installable version, that version falls within the scope of the CRA.

Who is considered a manufacturer under the CRA?

A manufacturer is anyone who develops or has developed a product with digital elements and markets it under their own name or trademark. Whether remuneration is charged is irrelevant. This broad definition covers significantly more companies than most expect.

Companies regularly underestimate two constellations:

• White label: anyone who places a third-party product on the market under their own label is deemed to be the manufacturer by legal fiction and is therefore also subject to the reporting obligation, even though they usually do not know which components are installed.
• Free distribution: free products do not fall outside the scope as long as the distribution takes place in the course of a business activity.

Within groups of companies, you should therefore determine precisely which legal entity places which product on the market under which brand. This also determines which authority is competent. You may delegate the report itself to an authorised representative, but responsibility for its proper fulfilment remains with the manufacturer.

Which incidents and vulnerabilities must you report?

Under Article 14 CRA, exactly two situations are reportable: every actively exploited vulnerability in a product with digital elements and every serious security incident affecting the security of the product. Fault on the part of the manufacturer is irrelevant.

When is a vulnerability actively exploited?

A vulnerability is actively exploited if reliable evidence shows that a malicious actor has exploited it without the consent of the system owner. Article 3 No. 42 CRA therefore requires a verifiable attack, not merely a theoretical risk.

If the vulnerability is in a purchased third-party component, reachability is decisive. If the component is installed but the vulnerability is not reachable in your product, no reporting obligation towards the authority arises.

The same incident may trigger several reports because both the component manufacturer and the manufacturer of the affected end product are subject to reporting obligations. If one of the parties reaches a different conclusion, the authority receives two divergent assessments of the same facts. Coordinated processes along the supply chain spare you these follow-up questions.

When is a security incident serious?

Under Article 14(5) CRA, a security incident is serious if it relates to the product and reaches one of two thresholds. Not every IT security incident within the company meets this requirement. The decisive factor is the impact on the security of the individual product.

The CRA names these two thresholds:

1. The incident has a negative impact, or is capable of having a negative impact, on the ability of the product to protect the availability, integrity or confidentiality of data and functions.
2. The incident has led, or is capable of leading, to the introduction or execution of malicious code in the product or in the user’s network and information system.

The current European Commission guidance cites a successful attack on a manufacturer’s update channel, through which malicious code can be introduced, as a typical case.

What is not reportable?

Not every newly discovered security flaw triggers a reporting obligation under Article 14 CRA. If there is no evidence of actual exploitation, the internal vulnerability management processes continue to apply.

These cases are not reportable under the CRA:

• Zero-day vulnerabilities without exploitation: the vulnerability is known, but there is no evidence of exploitation.
• Own test findings: results from penetration tests and comparable own investigations.
• Good-faith security research: Recital 68 CRA excludes it, which also applies to good-faith investigations conducted as part of responsible disclosure.
• Near misses without impact: events without an impact on product security.

For all these cases, Article 15 CRA provides for voluntary reporting, which does not trigger increased liability and serves only to improve the authorities’ situational awareness. If, by contrast, it is established that a matter is reportable, a very short cascade of deadlines begins.

Which deadlines apply to the reporting obligation under the Cyber Resilience Act?

Article 14 CRA provides for a three-stage reporting cascade: an early warning within 24 hours, a detailed notification within 72 hours and a final report. The deadlines for the early warning and the notification run from the manufacturer’s knowledge; different starting points apply to the final reports. Weekends and public holidays count.

The final report for actively exploited vulnerabilities is linked to a different point in time than the other deadlines. It starts only once an update or risk mitigation measure is available. This is not a free pass. From December 2027, the vulnerability management obligations will require prompt remediation.

Irrespective of these stages, the authority may request an interim report at any time. Failure to respond may also result in a fine. Compliance therefore depends above all on when the 24-hour clock starts to run.

When does the 24-hour period for the CRA reporting obligation start?

The 24-hour period for reporting actively exploited vulnerabilities and serious security incidents begins with the manufacturer’s knowledge, not with receipt of the first indication. You may conduct a brief initial assessment. However, this assessment phase cannot be artificially extended, because Article 14 CRA requires an immediate assessment.

Anyone without defined processes is vulnerable at precisely this point. Without a documented initial assessment, it is hardly possible to prove afterwards when knowledge arose and why the report was submitted only later.

The facts do not have to be finally and fully investigated. It is sufficient that there is a predominant probability that a reportable matter has occurred. From that moment, the clock starts running. The early warning is deliberately kept lean for this reason and can be corrected and supplemented in the 72-hour notification.

You should therefore define in advance what counts as knowledge in your company:

• Triggers: which events and information sources start the initial assessment?
• Evidence: which evidence do you use to assume active exploitation?
• Decision-makers: who makes the assessment, and who deputises for that person at weekends?
• Documentation: where do you record the time and reasoning, especially in the case of a decision not to report?

Anyone who already operates a robust process under Article 33 GDPR can use its assessment logic as a template. Anyone who defines these four points in advance will be able to decide within a few hours in an emergency and submit the report to the correct addressee.

To whom must manufacturers report under the CRA?

The addressee of the report is ENISA’s Single Reporting Platform, the central reporting platform for the entire EU with national endpoints. The competent endpoint is the endpoint at the seat of the main establishment in the Union. In Germany, under the national implementing act, the BSI is to take on the role of contact point and CRA coordinator.

The CRA recognises four addressees that you should distinguish:

• CRA Single Reporting Platform (ENISA): central reporting point for early warnings, notifications and final reports.
• CSIRT and BSI: designated national endpoint in Germany and, at the same time, central supervisory authority.
• Component manufacturers: upstream reporting of vulnerabilities in purchased components, mandatory from 11 December 2027.
• Affected users: information on actively exploited vulnerabilities and serious incidents, including possible countermeasures.

User information is the second, often overlooked, part of the reporting obligation. The CRA does not specify a fixed deadline for it. The Commission guidance requires risk-based and proportionate information, preferably in machine-readable form.

The CRA does not require publication to the general public. In sensitive deployment environments, such publication may even increase the risk because a vulnerability could then be exploited before users have been able to patch. By contrast, affected users should be informed without undue delay after knowledge has been obtained.

Which processes must manufacturers now establish?

Without a functional mailbox, named reporting officers and a tested process, the 24-hour period for the CRA reporting obligation cannot be met. Anyone who clarifies responsibilities and access only in an emergency loses exactly the hours that the CRA provides for the early warning.

These five steps should therefore now be in place:

1. Inventory: record which of your products contain digital elements and determine your role as manufacturer, importer or distributor. This includes a software bill of materials (SBOM) showing which components from which manufacturer are installed.
2. Create reporting channels: set up a functional mailbox such as cra-reporting@yourcompany.com and connect it to your ticketing system and existing incident response on-call function. Without a dedicated channel, indications end up in normal support and get lost there.
3. Clarify access: name one primary reporting officer and two deputies (1 Primary AR + 2 Backup ARs) for the Single Reporting Platform, each with their own EU Login and their own MFA. Access is personal. Credential sharing is not an option.
4. Document the reporting process: create a playbook with a responsibility matrix, knowledge definition, deadline clock, escalation paths, weekend on-call duty and text modules for the final report and customer communication.
5. Secure the supply chain: contractually require suppliers to report vulnerabilities, define specific response times, named contact points and exchange formats.

In addition, you need a market map recording in which Member States your products have been made available and through which channels you can reach affected users. If only certain software versions are affected, you should also be able to contact only those users.

The CRA contains no catch-all provision for other reporting obligations. A report under Article 14 CRA replaces neither the report under the GDPR nor under NIS2 or DORA. Internally, however, these processes can be brought together on a common data basis instead of conducting three parallel investigations.

Test the finished process once in a two-hour tabletop exercise. Only under emergency conditions will it become clear whether the right people are on the distribution list and whether the contact route works.

What fines may apply for breaches of the CRA reporting obligation?

Breaches of the reporting obligation under Article 14 CRA fall within the highest fine level of up to EUR 15 million or 2.5% of worldwide annual turnover, whichever amount is higher. A breach of the reporting obligation therefore carries the same weight as a breach of the essential cybersecurity requirements.

The CRA grades fines according to the severity of the breach:

• EUR 15 million or 2.5%: breaches of essential cybersecurity requirements and breaches of the reporting and manufacturer obligations under Articles 13 and 14.
• EUR 10 million or 2%: other obligations, including those of importers and distributors and those relating to conformity assessment.
• EUR 5 million or 1%: incorrect, incomplete or misleading information provided to authorities.

A narrowly limited relief applies to micro and small enterprises: breaches of the 24-hour early warning remain free of fines. This does not remove the obligation itself, and the 72-hour period applies without restriction. Under the CRA, open-source software stewards generally do not have to expect fines.

Conclusion: the CRA reporting obligation stands or falls with the reporting process

Since 11 September 2026, manufacturers have been required to report actively exploited vulnerabilities and serious security incidents within 24 hours to ENISA’s Single Reporting Platform. The obligation covers the entire product portfolio and does not distinguish by company size or risk class.

The real work lies before the emergency. The reporting form is the smallest part of it. Anyone who only then clarifies who may assess, who can report and where the access lies loses the decisive hours.

The Cyber Resilience Act is not a purely technical topic. The reporting obligation affects product strategy, compliance, contractual design in the supply chain and development itself. Where many interfaces come together, implementation takes time.

The first step, by contrast, requires little effort: a functional mailbox, three named reporting officers and a document recording who decides in case of doubt.

Frequently asked questions

#1 Does the CRA reporting obligation also apply to open-source software?

Yes, but in a graduated way. Open-source software stewards are subject to their own, reduced reporting obligation, which applies only from 11 December 2027. A steward is any legal person that is not a manufacturer, systematically and sustainably supports the development of free and open-source software and ensures its viability. They do not face fines under the CRA. Anyone who markets open-source software in the course of a business activity under their own name, by contrast, is a manufacturer and has been required to report since 11 September 2026.

#2 Does a mobile app fall under the CRA reporting obligation?

Yes, mobile apps are products with digital elements and fall under the Cyber Resilience Act as soon as they can establish a data connection. The CRA treats them as standalone software that is placed on the market. The situation is different for pure software-as-a-service offerings, which, as services, generally remain outside the scope unless they are a remote data processing solution of a product.

#3 Does a CRA report replace a report under the GDPR or NIS2?

No, the Cyber Resilience Act contains no catch-all provision for other reporting obligations. A report under Article 14 CRA fulfils neither the reporting obligation under Article 33 GDPR nor the obligations under NIS2, DORA or sector-specific law. These reports must be assessed and submitted in parallel. Internally, the processes can be brought together on a common data basis.

#4 Which CRA obligations apply from 11 December 2027?

On 11 December 2027, the Cyber Resilience Act becomes fully applicable. From that date, the essential cybersecurity requirements, conformity assessment, marking, vulnerability management and support obligation with security updates apply. The reporting obligations of importers, distributors and open-source software stewards also apply only from then. Cybersecurity therefore becomes a prerequisite for market access.

#5 Must incidents that became known before 11 September 2026 be reported retrospectively?

No, there is no retrospective reporting obligation. The reporting obligation under Article 14 CRA covers vulnerabilities and security incidents of which the manufacturer becomes aware from 11 September 2026 onwards. For matters that became known before that date, there was no reporting channel and there is no retroactive obligation. If an old matter only becomes known now, the deadline runs from that knowledge.