EU CRA reporting starts Sept 11, 2026: what breaks first with EOL components

TL;DR

---

The EU Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) fully applies from December 11, 2027 — but its reporting obligations start earlier, on September 11, 2026.
The European Commission’s CRA page states the split explicitly: main obligations from December 11, 2027, reporting obligations from September 11, 2026.

For this early phase, knowing your components matters more than having a reporting desk ready.
If you don’t know what’s inside your product, you can’t determine within hours whether an actively exploited vulnerability affects it.
For products containing EOL (End of Life) components, you end up assembling reports and mitigation guidance with no fix coming from upstream.

What starts on September 11, 2026 is Article 14

In the official text on EUR-Lex, Article 71 splits the application dates.
The CRA as a whole applies from December 11, 2027, but Article 14 applies from September 11, 2026.
Article 14 covers the obligation to report actively exploited vulnerabilities contained in the product and severe incidents having an impact on the security of the product. Chapter IV (Articles 35–51), which governs the notification of conformity assessment bodies, has applied even earlier, since June 11, 2026.

A severe incident under Article 14(5) means an incident that negatively affects or is capable of negatively affecting the product’s ability to protect the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions, or that has led or is capable of leading to the introduction or execution of malicious code in the product or in the network and information systems of its users.

Article 14’s deadlines are measured in hours.
Once a manufacturer becomes aware of active exploitation or a severe incident, it must submit an early warning without undue delay and in any event within 24 hours, and a follow-up notification within 72 hours.
The final report deadline differs between the two cases: for exploited vulnerabilities, within 14 days after a corrective or mitigating measure is available; for severe incidents, within one month after the 72-hour notification.
ENISA’s Single Reporting Platform page also states that the SRP (Single Reporting Platform) is scheduled to go live on September 11, 2026, as the single entry point delivering reports simultaneously to the relevant CSIRT (Computer Security Incident Response Team) and ENISA.

Through the SRP, reports go to the electronic endpoint of the CSIRT designated as coordinator for the member state where the manufacturer has its main establishment in the EU, with ENISA receiving them simultaneously. The main establishment is not the registered address: it is the member state where cybersecurity decisions for the products are predominantly taken, or failing that, the member state where the manufacturer has the establishment with the highest number of employees in the EU. Manufacturers with no main establishment in the EU determine the responsible member state under Article 14(7), in order: where the authorised representative handling the most products is established, then the importer handling the most products, then the distributor, then where the most users are located.
The receiving CSIRT forwards the report, in principle without delay, to the CSIRTs of other member states where the product is made available. For particularly sensitive reports there is a procedure to delay dissemination on justified cybersecurity grounds, and in exceptional cases only part of the 72-hour notification is initially shared with ENISA. None of this means SRP reports become public immediately.

“Becoming aware” here is not the same as spotting a public CVE. An actively exploited vulnerability is one for which there is reliable evidence that a malicious actor has exploited it in a system without the permission of the system owner.
In the SRP input fields listed in ENISA’s FAQ, the 24-hour stage requires the manufacturer name and product name, while CVE ID and EUVD ID are optional. General information about the exploitation and the vulnerability, measures taken, and measures users can take become mandatory at the 72-hour stage. The early warning does not require a completed root-cause analysis, but receiving vulnerability information, determining product impact, and documenting user-facing mitigations all have to run in parallel.
Article 14(8) additionally requires manufacturers to inform impacted users — and where appropriate all users — about the vulnerability or incident and about corrective measures.

The transitional provision in Article 69(3) is easy to miss: Article 14 also applies to in-scope products placed on the market before December 11, 2027.
The Commission’s implementation FAQ explains that reporting is still required even for older products whose build environment or dependencies can no longer be reproduced — but that products placed on the market before 2027 and not substantially modified since are not retroactively subject to the CRA’s other vulnerability-handling obligations. There is also no obligation to retroactively report exploitation the manufacturer already knew about before September 11, 2026.

I previously wrote about NIST NVD’s prioritized enrichment and how NVD, KEV, GHSA, OSV, EUVD, and the SRP have started playing distinct roles.
The CRA piece of that picture is the date on which the SRP starts operating as the reporting entry point for products on the EU market.
If your process waits for NVD to attach a CPE before assessing product impact, some cases will simply not fit inside the 24-hour early warning.

With EOL components, the reporting narrative is the first thing that breaks

CRA Article 13 requires manufacturers to handle vulnerabilities in the product as a whole and in all integrated components during the support period.
The text explicitly includes due diligence when integrating third-party and OSS components.
The support period is set with the expected product lifetime in mind and is in principle at least 5 years. Only products expected to be in use for less than 5 years can shorten it to the expected lifetime. Conversely, for products reasonably expected to be in use longer than 5 years, cutting support at 5 years is not automatically sufficient.

With EOL components, the missing patches are only half the problem — the other half is what you can say in a report.
Which product builds contain the component, which product functions the vulnerability affects, whether the product can work around it without an upstream fix, and which mitigations you can hand to users.

The CRA does not flatly prohibit EOL components. But if upstream support for an integrated component ends while the product’s own support period is still running, the manufacturer’s obligations do not end with it.
The Commission’s implementation FAQ explains that if mitigations are insufficient, the manufacturer must remediate by other means — replacing the component or developing a patch itself. In exceptional cases where conformity cannot be restored, withdrawal or recall from the market may be required. Even for a vulnerability originating in a third-party component, if it is actually exploitable within your product and you become aware of exploitation, Article 14 reporting applies to your product. If the vulnerability is not exploitable in the integrated product, it is not subject to mandatory reporting.
Article 13(6) also requires a manufacturer that finds a vulnerability in an integrated component to report it to the component’s manufacturer or maintainer, and to share the fix code and relevant documentation where appropriate if it developed a fix itself.

The product’s own end-of-support date carries a disclosure obligation too. Article 13(19) and Annex II(7) require the end month and year of the support period to be clearly and easily accessible at the time of purchase, and where technically feasible, a notification to users when it is reached.

The original endoflife.ai article frames this as an EOL component inventory problem.
Its examples are Debian 10, AngularJS, OpenSSL 3.0, and .NET 8. Checking primary sources: official Debian 10 LTS ended June 30, 2024 and official AngularJS support ended in January 2022. Debian 10 has third-party paid ELTS (Extended LTS), but that is separate from official Debian LTS.
On the official OpenSSL roadmap, OpenSSL 3.0 LTS support ends September 7, 2026 — four days before the CRA reporting start date of September 11. Under the .NET official support policy updated June 9, 2026, .NET 8 LTS and .NET 9 STS (Standard Term Support) both end on November 10, 2026. Don’t rely only on aggregated EOL data services — verify each product against the upstream lifecycle tables and the scope of any paid extended support.

I covered the related migration deadlines in .NET 8/9 and Windows Server 2012 2026 EOL deadlines. Microsoft’s generic “ends in 2026” list still carries a stale May 12, 2026 end date for .NET 9, but the current per-product .NET policy sets STS support at 2 years, so .NET 8 and .NET 9 end together on November 10.
That article separated .NET target frameworks from Windows Server host OS. The CRA adds a third dimension: which builds of the products you ship to the EU market still contain the component.
A .NET 8 web API, a management console on an old Windows Server, an appliance embedding OpenSSL 3.0, an AngularJS admin UI — under the CRA these live in one per-product component inventory, not in separate migration spreadsheets.

Make SBOMs queryable per product

The CRA explicitly defines the SBOM (Software Bill of Materials) and, in Annex I Part II(1), requires manufacturers to identify and document vulnerabilities and components in the product, including by drawing up an SBOM in a commonly used machine-readable format covering at the very least the top-level dependencies. Article 13(24) lets the Commission specify the format and elements via implementing acts.
This is not a blanket obligation to publish SBOMs to all users. Annex II(9) is the item that points users to the SBOM where the manufacturer has decided to provide it. The SBOM becomes part of the technical documentation, and market surveillance authorities can request it with a stated reason where needed for conformity checks.

What the 24-hour early warning actually needs is not a tidy component list file — it’s the ability to query, right now, which products contain what.
Prebuilt containers, embedded firmware, Electron apps, admin frontends, and CI-generated bundled binaries all sit under the same product name.
Collecting dependency manifests alone misses base images, OS packages, and statically linked libraries.

The npm compromises I’ve been tracking in supply chain articles were mostly about what runs at install time.
The CRA’s EOL problem asks a question that comes before runtime compromise: can you state, within hours, that the shipped product contains that component?
Concretely: tie package-lock.json or pnpm-lock.yaml for npm, image digests for containers, package lists for OS layers, and firmware build artifacts for embedded targets to product versions.

Leaning on NVD CPEs alone fails here for the reasons I wrote before: Deferred status and CVEs with no CPE assigned slip through.
Match by other routes — GHSA and OSV package names, vendor advisories, distribution security trackers, and EUVD exploitation status.
The question is not “is there a CVE” but “has information about confirmed exploitation or a severe incident landed on a component in this product build.”

Reading a vendor-adjacent article for what it is

The DEV Community article this started from is also a funnel into endoflife.ai’s own EOL database and API.
The components and dates it lists are useful input, but your organization’s regulatory response and adopting an external service are separate decisions.

What the CRA fixes in advance are the dates and deadlines:
September 11, 2026; 24 hours; 72 hours; 14 days after a fix or mitigation is available for vulnerabilities; one month after the 72-hour notification for severe incidents.
How EOL management is implemented varies by organization.
Wire together your existing SCA, container scanning, SBOM generation, internal CMDB, release ledger, and customer-facing support-period display, and verify you can make a per-product call when exploitation intelligence arrives.

Internal-only tools not made available on the EU market are in principle not “made available on the market” and not directly in scope.
Products sold into the EU — hardware, desktop apps, mobile apps, embedded software, connected devices, and bundled management software — can be in scope even if the seller sits outside the EU.
A standalone SaaS or cloud service is not by itself a “product with digital elements.” But remote data processing that the manufacturer designs and develops, and without which the product cannot perform its functions, is part of the product and in scope.
Article 2 also carves out product classes: medical devices and in-vitro diagnostics, covered motor vehicles, certified aeronautical products, marine equipment, spare parts made to the same specification, and products developed exclusively for national security or defence.
OSS stewards (organizations providing sustained support for OSS development) fall under Article 24: they report actively exploited vulnerabilities to the extent they are involved in the development, and severe incidents affecting network and information systems they provide for OSS development.

Article 64 sets administrative fines for violations of the essential cybersecurity requirements in Annex I and the obligations in Articles 13 and 14: up to 15 million EUR or 2.5% of worldwide annual turnover, whichever is higher.
Microenterprises and small enterprises are exempt from fines for missing the 24-hour early warning deadline, and OSS stewards are exempt from CRA fines altogether — but the reporting obligations themselves remain.
Before September 11, 2026, get this onto a ledger shared by product and security teams: which products contain what, how components past upstream support are handled, and who files to the SRP when exploitation becomes known.