The EU Cyber Resilience Act Has an EOL Problem — and the Deadline Isn't the One You Think

The EU Cyber Resilience Act's vulnerability reporting obligations begin September 11, 2026, not the widely cited December 2027 deadline. End-of-life components in shipped products create compliance gaps, as manufacturers cannot provide security updates for unsupported dependencies. The project endoflife.ai provides tools to track lifecycle dates and risk-rank remediation priorities.

Originally published at endoflife.ai. Most conversations about the EU Cyber Resilience Act Regulation EU 2024/2847 anchor on one date: the main obligations apply from December 11, 2027 . That date is real — and comfortably far away, which is exactly the problem. Buried inside the CRA is a much nearer deadline: the vulnerability and incident reporting obligations begin September 11, 2026. That's weeks away, not next year's problem. And the debt those obligations expose is one most teams have never inventoried: every end-of-life component sitting inside a product they ship. The CRA applies to "products with digital elements" placed on the EU market — software and connected products, regardless of where the manufacturer is based. Under the regulation as adopted, manufacturers must: Here's the collision: you cannot provide security updates for a product whose components no longer receive security updates. An EOL library inside a shipped product is a support-period promise you cannot keep. Before the CRA, that was tech debt. Under the CRA, it's a compliance gap with a fine attached. Not legal advice — obligations vary by product category; verify against the regulation text and current guidance. These aren't hypotheticals — they're the most common findings in real dependency scans, with dates verified against vendor lifecycle data: | Component | EOL date | Status today | |---|---|---| | Debian 10 base images | Sep 10, 2022 | ~4 years unpatched | | AngularJS any version | Dec 31, 2021 | ~4.5 years unpatched | | OpenSSL 3.0 | Sep 7, 2026 | dies 4 days before the CRA reporting deadline | | .NET 8 | Nov 10, 2026 | dies during the CRA's first reporting quarter | That OpenSSL line is worth a second look: the TLS library embedded in half the world's software loses upstream support four days before the CRA's reporting obligations begin. The real danger isn't the deadline — it's the arithmetic in front of it. Component inventory takes months. Remediation takes quarters. Migrating off every EOL dependency competes directly with your product roadmap. A team that starts discovery in 2027 has already missed the runway; the reporting obligations will be a year old before their inventory is done. Four working parts, all automatable: curl https://api.endoflife.ai/v1/status/dotnet/8 "is eol": false — until November 10, 2026. Lifecycle dates tracked against a live source, not a spreadsheet — vendors move dates; a January export is a liability by June. endoflife.ai/eol-watch https://endoflife.ai/eol-watch tracks what's coming, and every product page publishes an .ics calendar feed. Risk-ranked remediation — an inventory with two hundred findings needs an ordering. Risk scores https://endoflife.ai/risk-score rank components by recency, exposure, and exploitation signals, so the migration queue starts with the components most likely to produce exactly the incidents the CRA makes reportable. A plan for components you can't migrate in time — commercial extended-support vendors keep security patches flowing for EOL components, which maps directly onto the "updates during the support period" obligation. It's a bridge, not a destination — but for a 2026 deadline, bridges matter. The CRA converts lifecycle hygiene from an engineering virtue into a market-access requirement for the EU. The teams treating it as a 2027 problem are the ones who will discover, in 2027, that it was a 2026 problem. Full breakdown with verified dates: endoflife.ai/article-eu-cra-eol-compliance https://endoflife.ai/article-eu-cra-eol-compliance