CRA Reporting Duty From 11 September 2026

What actually happens on 11 September 2026

Many manufacturers have filed the Cyber Resilience Act under 2027. That is understandable and still wrong. Regulation (EU) 2024/2847 entered into force on 10 December 2024. Its security requirements apply in full from 11 December 2027. Two earlier dates sit in between. Since 11 June 2026, Chapter IV on the designation of assessment bodies applies, meaning Articles 35 to 51. From 11 September 2026, Article 14 applies, the reporting duty (Art. 71(2)).

The gap between the two dates is not a legal subtlety. It is a question of operational readiness. On 11 December 2027 you have to prove a product was built securely. On 11 September 2026 you have to be able to file a report within 24 hours. That presumes you know what is inside your products, who uses them and who answers the phone at your company at night. The first is an engineering project with 15 months of runway. The second is a capability your organization either has or does not have.

That order is the actual problem. The reporting duty comes first, the build requirements later. Read the regulation back to front and you plan secure development for 2027 while missing that you already have to report on insecure legacy products in 2026.

A look at real attacks shows how tight the deadline is. The 24 hours start the moment you learn about the exploitation, not when a vulnerability number is published. A CVE is the public identifier of a vulnerability. VulnCheck counted 884 vulnerabilities for 2025 with first evidence of exploitation. For 28.96 percent of them, exploitation was already under way on or before the day the CVE was published. The year before it was 23.6 percent. So the clock routinely starts before any public record exists.

The point in one sentence

From 11 September 2026 you must be able to say within 24 hours whether an actively exploited vulnerability sits in one of your shipped products, including products you sold years ago.

Why the three deadlines are harder than they sound

Article 14 has two triggers and three reports each. The first trigger is an actively exploited vulnerability in one of your products. The second is a severe incident affecting the security of the product. Both triggers carry their own chain of deadlines and the reference points differ.

Trigger	Early warning and full notification	Final report
Actively exploited vulnerability	24 hours and 72 hours from awareness (Art. 14(2))	No later than 14 days after a corrective or mitigating measure is available
Severe incident	24 hours and 72 hours from awareness (Art. 14(4))	One month after submission of the 72-hour notification

The two final reports hang on different anchors. For a vulnerability, the clock runs from the moment a countermeasure is available. The regulation text speaks of a corrective or mitigating measure. A documented workaround therefore starts the 14 days just as a finished patch does. For an incident, what counts is submission of the 72-hour notification, not awareness and not the availability of a fix. Confuse the anchors and you plan the wrong calendar.

There is also an overlooked clause. Under Art. 14(6), the competent CSIRT can request an intermediate report at any point. A CSIRT is a state emergency team for IT security. The three deadlines are a floor, not the complete reporting load. Plan for 24, 72 and 14 without capacity for follow-up questions and you have sized the resources wrong.

What counts as a severe incident

Art. 14(5) provides a definition and it deliberately contains no threshold under CVSS, the common scoring system for the severity of vulnerabilities. An incident is severe if it affects or is capable of affecting the ability of the product to protect the availability, authenticity, integrity or confidentiality of important data or functions. Likewise if it has led or is capable of leading to the introduction or execution of malicious code (Art. 14).

The words “capable of” are the expensive part. The threshold is measured by potential, not by damage that has occurred. An internal rule reading “we report from CVSS 9.0” has no counterpart in the regulation. The assessment must happen per product and within hours, not at the next security meeting.

The forgotten fourth duty

Art. 14(8) additionally requires you to inform affected users and where appropriate all users about the vulnerability or incident, including the countermeasures. The format must be machine-readable, meaning it can be processed automatically. If you fail to do this, the CSIRTs may inform the users themselves.

This is where many reporting processes tear. The filing with the authority is a form. The user notification is a distribution list, a channel and a machine-readable format for security advisories that somebody set up beforehand. Improvising both at once under time pressure does not work.

Why old products are the biggest risk

Here is the real catch. Art. 69(2) largely exempts products placed on the market before 11 December 2027. The remaining CRA requirements only bite on those products once they are substantially modified from that date. Paragraph 3 makes an exception: the obligations in Article 14 apply to all products with digital elements within the scope of the regulation that were placed on the market before 11 December 2027 (Art. 69).

In operational language: for the entire legacy base you must report, but you need not have built it securely. The evidence duty is suspended, the reporting duty is not.

That lands precisely on the products nobody likes to talk about. The device from 2019 with a frozen operating system. The industrial gateway with an encryption library that has had no updates for years. The app whose component vendor ended support. From 11 September 2026 none of it needs a declaration of conformity, but all of it needs a defensible answer to one question: is this vulnerability in one of our shipped products and is it being exploited.

With components that are no longer supported, that answer is structurally hard. There are no more security advisories from the vendor, no maintained version ranges, often not even a reliable package name. The vulnerability surfaces in a report about attacks and nobody in the company can say within 24 hours which firmware builds contain the affected library. That is why the groundwork for the reporting duty is not compliance work but a question of security architecture.

Why there is no 24-hour report without a bill of materials

An early warning after 24 hours requires three facts no ticketing system produces from nothing: which product is affected, in which shipped versions and who uses those versions. Research them during the incident and you lose the deadline on the first phone call.

A software bill of materials, in short SBOM, is therefore not a documentation obligation. It is the data structure the deadline hangs on. What matters is not that an SBOM exists, but that it exists per shipped release, is stored immutably and stays queryable by machine. An SBOM that lives only in the build folder of the last run does not help with a vulnerability in a three-year-old version.

Three building blocks belong together. First, generation: the SBOM is created inside the release process, signed and stored with product, version and shipping date in a register that cannot be changed afterwards. Second, the query: for a given vulnerability, the register returns within minutes all shipped versions containing the affected component, along with whether the component is still maintained and whether a patch exists. Third, the link to the customer register: for every affected version it is known who uses it.

The attributes “component without support” and “no patch available” are the most important. A hit with both attributes means the 14-day clock for the final report only starts once a documented mitigating measure exists. That measure must be described, approved and communicated to users. This is work you do before the incident or not at all.

In practice that means three connections: the SBOM register to the release process, the customer register to the version records and both to continuous monitoring of advisories about new vulnerabilities and ongoing attacks. Without the third connection, you learn about exploitation from a customer and part of your 24 hours is already gone.

Who reports to whom and through which tool

The report is filed once. The Commission puts it unambiguously: manufacturers report only once through the CRA Single Reporting Platform (Commission, CRA reporting). The platform forwards the report simultaneously to the CSIRT designated as coordinator and to ENISA, the EU agency for cybersecurity (Art. 14(1) and (3)). Under Art. 16(1) ENISA establishes and operates it.

The competent body is the CSIRT of the member state of your main establishment. The CRA defines that not via the commercial register but via the place where decisions on the security of the products are predominantly taken (Art. 14(7)). For third-country manufacturers a cascade applies: authorised representative, then importer, then distributor, otherwise the member state with the most users. If development, product security and management sit in several countries, put that assignment in writing before it is disputed in an emergency.

Two qualifications belong here. First, forwarding to ENISA is not automatic. Under Art. 16 a CSIRT may withhold dissemination of a report on justified security grounds, in particular during an ongoing coordinated disclosure. It must then inform ENISA without undue delay about the decision, the justification and the planned time (Art. 16). Second, ENISA publishes the list of designated coordinating CSIRTs on its platform pages. Check there which CSIRT is listed for your country. For Germany, the BSI is developing technical guideline TR-03183, which makes the CRA requirements concrete for manufacturers and products.

Access to the platform runs through an EU Login account with two-factor authentication. Per ENISA, the authorisation is verified by the coordinating CSIRT after first access, in parallel with the ongoing reporting process. So the account should exist long before the first incident.

One detail to plan for: ENISA has announced the platform will be operational from 11 September 2026, the same day the duty begins. At the end of June 2026 it was not yet reachable according to the specialist service cyberresilienceact.eu. The Article 14 deadlines apply regardless of whether the tool is ready. If the platform is down, ENISA expects you to wait and file afterwards. For urgent cases you should know the direct contact to your CSIRT.

What has to be in place organizationally

The technical groundwork is one half. The other is a handful of decisions that cannot be bought.

Building block	What must be settled	Typical mistake
Competent CSIRT	Main establishment per Art. 14(7) documented, cascade for third countries	Registered office instead of where security decisions are taken
Platform access	EU Login account created, at least two people authorised	One account on one person, who is on holiday
Awareness	Which signal starts the 24-hour clock and who starts it	Clock only starts at the management meeting
Assessment	Classification per product under Art. 14(5), no CVSS threshold	Internal rule “report from CVSS 9.0”
User notification	Distribution list and machine-readable format per Art. 14(8)	PDF attachment to a shared mailbox
Follow-ups	Capacity for intermediate reports per Art. 14(6)	Only the three mandatory deadlines staffed

The rest is process. Building the filing, the internal escalation and the user notification as one end-to-end automated chain does not save minutes in an incident. It saves the hours lost between awareness and the first management decision. As a side effect it produces the record of who knew what when. You need that record for the final report at the latest.

What failure costs

Art. 64 sets the frame. Infringements of the requirements in Annex I and of the obligations in Art. 13 and Art. 14 can carry fines of up to 15 million euro or 2.5 percent of total worldwide annual turnover for the preceding financial year, whichever is higher. For other infringements the ceiling is 10 million euro or 2 percent, for incorrect or incomplete information supplied to market surveillance authorities 5 million euro or 1 percent (Art. 64).

Two exemptions matter and are frequently skimmed. Microenterprises and small enterprises are exempt from fines for missing the 24-hour early warning under Art. 14(2)(a) or Art. 14(4)(a). The remaining Article 14 deadlines and duties are not covered. Open-source software stewards are exempt from fines for infringements of the regulation. Both defuse the sanction, not the duty. A manufacturer who fails to report has still infringed Article 14, with all the market surveillance consequences attached.

How the duty travels down the supply chain

The more interesting enforcement happens through contracts, not fines. Honeywell runs a public CRA supplier page. There the group requires suppliers to have working vulnerability and incident reporting processes by 11 September 2026, including registration on the ENISA platform. By the fourth quarter of 2026, suppliers are to deliver compliance attestations or detailed roadmaps for all components feeding into EU products, plus machine-readable bills of materials and a commitment to notify Honeywell within 24 hours of an exploited vulnerability. By 11 December 2027 full CRA conformity is expected, including conformity assessment, CE marking and EU declaration of conformity (Honeywell).

That is the mechanism that makes the deadline real. A supplier below every fine threshold still loses the framework agreement if it cannot produce the evidence.

The answer is forming in parallel on the open-source side. Seven foundations, among them Apache Software Foundation, Blender Foundation, OpenSSL Software Foundation, PHP Foundation, Python Software Foundation, Rust Foundation and Eclipse Foundation, announced on 2 April 2024 that they would develop common specifications for secure software development to implement the CRA (Eclipse). The Eclipse Foundation’s Open Regulatory Compliance Working Group that grew out of it now counts more than 50 members, including Microsoft, Red Hat, GitHub, Google, Nokia and Mercedes-Benz. On 14 August 2025 it published a first collection of CRA resources and a roadmap for further deliverables (Eclipse Newsroom).

Supply chain effect

The CRA binds manufacturers. It gets enforced first through purchasing terms. Ship components into an EU product and the 11 September 2026 deadline reaches you from your own customer rather than from an authority, complete with evidence and a roadmap.

What you can check now

Until 11 September 2026 the regulation asks nothing about the quality of your software. It asks about the responsiveness of your organization: can you say within one working day whether an actively exploited vulnerability sits in one of your shipped products and can you reach the people affected.

That capability breaks down into three decisions. First, a named person who starts the clock, plus a deputy. Second, an SBOM per shipped release, stored immutably, produced retroactively for the legacy base. Third, a machine-readable channel to users that is not built during the incident.

An honest note: how much work this is depends heavily on where you start. If you already generate a bill of materials per release, you mainly need the register and the customer register. If you have never generated one, start with the product that is most widely deployed. Everything else can wait until 2027. These three points cannot. To see what this chain looks like in an existing product landscape, talk to us.

Sources

Note on sourcing

Citations of Regulation (EU) 2024/2847 are taken from full-text mirrors. Only the version published in the Official Journal is legally authoritative. The status of the Single Reporting Platform may have changed since this was written. This article is not legal advice. For your specific products and obligations, get qualified counsel.

The CRA reporting duty starts on 11 September 2026 and covers products you sold years ago

Key Takeaways