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
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 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 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