The EU Cyber Resilience Act Has an EOL Problem — and the Clock Started in 2024
Most conversations about the EU Cyber Resilience Act (Regulation (EU) 2024/2847) focus on the headline date: the main obligations apply from December 11, 2027. That date is real, and it is comfortably far away — which is exactly the problem. Buried inside the CRA is a much nearer deadline and a much older kind of debt. The nearer deadline is September 11, 2026, when the vulnerability and incident reporting obligations begin to apply. The older debt is every end-of-life component sitting inside a product you ship.
What the CRA actually asks of manufacturers
The CRA applies to "products with digital elements" placed on the EU market — software, connected devices, and the components inside them — wherever the manufacturer is based. A company in Austin or Singapore selling into the EU is in scope for those products just as much as one in Munich. Under the regulation as adopted, the obligations that matter most for lifecycle management are:
- A declared support period. Manufacturers must handle vulnerabilities for a declared support period and provide security updates during it.
- Knowing your components. Manufacturers must know and document the components in their products — SBOM-style obligations that make "we're not sure what's in the build" an untenable answer.
- Reporting. Obligations to report actively exploited vulnerabilities and severe incidents apply from September 11, 2026 — more than a year before the main obligations.
- Real penalties. For the most serious infringements, penalties can reach the higher of EUR 15 million or 2.5% of global annual turnover.
One necessary caveat before going further: this article is not legal advice — obligations under the CRA vary by product category, and your team should verify specifics against the regulation text and current guidance.
The part nobody prices in: EOL components become a regulatory liability
Here is the collision the CRA quietly creates. You must provide security updates for your product throughout its declared support period. But your product is built from components — operating systems, runtimes, libraries, frameworks — and each of those has its own lifecycle, set by someone else. When a component reaches end of life, its maintainers stop shipping security fixes. From that day forward, you cannot reliably provide security updates for a product whose components no longer receive them. Every new CVE in that component lands on you, with no upstream patch coming.
An EOL library inside a shipped product is a support-period promise you cannot keep. Before the CRA, that was a security risk you could quietly carry. Under the CRA, it is a gap between what you have declared and what you can actually deliver — a regulatory exposure, not just a hygiene issue. This is the same shift already underway in the private sector, where cyber insurers have started asking about EOL software in underwriting questionnaires. The CRA does for EU market access what insurers are doing for premiums.
The lead-time trap
The real danger is not the rules — it is the runway. Consider the arithmetic most teams are avoiding:
- Component inventory takes months. Building a real inventory across products, teams, container images, and embedded firmware is a multi-month effort, and it is the prerequisite for everything else. You cannot report what you cannot see, and you cannot remediate what you have not found.
- Remediation takes quarters. Once the inventory exists, the findings are rarely quick fixes. Framework migrations, OS upgrades, and runtime bumps each consume a quarter or more of engineering time — and they queue behind each other.
- The first obligations land before the inventory does. The reporting obligations start September 11, 2026 — before the main obligations, and before most teams have finished discovery. Reporting an actively exploited vulnerability presumes you know the vulnerable component is in your product at all.
Run that math backwards from December 11, 2027 and the conclusion is uncomfortable: anyone starting discovery in 2027 has already missed the runway. Inventory plus remediation does not fit in the time remaining — and the reporting clock will have been running for over a year by then.
What "knowing your components" actually finds
These are not hypotheticals. They are the most common findings in real dependency scans — the components that surface again and again the first time a team runs a real inventory:
| Component | EOL Date | Status | What it means under a support-period promise |
|---|---|---|---|
| Debian 10 | Sep 10, 2022 | EOL | A base image nearly four years past EOL — every OS-level CVE since is unpatched |
| AngularJS 1.8 | Dec 31, 2021 | EOL | A frontend framework with no maintainer since 2021, still embedded in shipped UIs |
| OpenSSL 3.0 | Sep 7, 2026 | EOL in weeks | The crypto layer of countless products goes EOL four days before CRA reporting begins |
| .NET 8 | Nov 10, 2026 | EOL in months | A current LTS runtime that exits support mid-way through the CRA transition window |
Notice the pattern: two of these are long-dead components teams forgot they were shipping, and two are mainstream, current-feeling platforms that go EOL in the next four months — part of the broader H2 2026 EOL pileup that happens to coincide almost exactly with the CRA's reporting start date. A product that ships on Debian 10, renders its UI in AngularJS, and terminates TLS with OpenSSL 3.0 is not an outlier. It is a Tuesday.
A compliance-ready EOL process
The CRA does not tell you how to run lifecycle management. But the obligations above imply a process with four working parts:
1. Continuous component inventory
Not a one-time audit — a living picture. Upload dependency files to the scanner to get lifecycle status across a whole manifest at once, or check individual products with the EOL checker. For CI pipelines, gate builds on the API so an EOL component fails loudly instead of shipping quietly:
curl https://api.endoflife.ai/v1/status/dotnet/82. Lifecycle dates tracked against a live source
EOL dates change — vendors extend, accelerate, and clarify them. A spreadsheet snapshot from January is a liability by June. EOL Watch tracks the dates as they move, and every product page publishes an .ics calendar feed so the deadlines sit in the same calendar as your release planning.
3. Risk-ranked remediation
An inventory of two hundred findings is useless without an order to work them in. The EOL Risk Score ranks components by how dangerous their EOL status actually is — recency, exposure, and exploitation signals — so the migration queue starts with the components most likely to produce the exact incidents the CRA makes reportable.
4. A plan for the components you cannot migrate in time
Some components will not be migrated inside the support period — the AngularJS rewrite that needs six more quarters, the appliance pinned to an old base image. For those, commercial extended-support vendors can keep security patches flowing for EOL components, which maps directly onto the CRA's requirement to provide updates during the declared support period. See the extended support vendor overview for how that market works. And where migration is feasible, start with the guides: migrating off AngularJS and migrating off Node.js 18 cover two of the most common findings.
The reframe: lifecycle hygiene is now market access
For twenty years, keeping components current has been an engineering virtue — the kind of work that is always important and never urgent. The CRA changes its category. For any company selling software or connected products into the EU, lifecycle hygiene is becoming a market-access requirement: part of what it means to be allowed to sell there at all, backed by penalties that reach EUR 15 million or 2.5% of global turnover for the most serious infringements.
The deadlines are staggered, but the work is not. The inventory you need for December 2027 is the same inventory you need to meet the reporting obligations that start this September — and the same one that tells you which migrations must start now to finish in time. The teams treating the CRA as a 2027 problem are the ones who will discover, in 2027, that it was a 2026 problem.
Frequently Asked Questions
When does the EU Cyber Resilience Act apply?
The CRA (Regulation (EU) 2024/2847) entered into force on December 10, 2024. Under the regulation as adopted, the main obligations apply from December 11, 2027, but the vulnerability and incident reporting obligations — covering actively exploited vulnerabilities and severe incidents — apply earlier, from September 11, 2026.
Does the CRA apply to companies outside the EU?
Yes. The CRA applies to products with digital elements placed on the EU market, wherever the manufacturer is based. A US, UK, or APAC company selling software or connected products into the EU is in scope for those products, just like an EU-based manufacturer.
How do end-of-life components affect CRA compliance?
Under the regulation as adopted, manufacturers must handle vulnerabilities and provide security updates for a declared support period, and must know and document the components in their products. A component that no longer receives upstream security updates undermines your ability to keep that promise: you cannot reliably ship security fixes for a product built on components nobody is patching. That makes EOL components a regulatory exposure, not only a security one.
What are the penalties for non-compliance with the CRA?
Under the regulation as adopted, penalties for the most serious infringements can reach the higher of EUR 15 million or 2.5% of global annual turnover. Beyond fines, non-compliant products can face consequences affecting their access to the EU market. This is not legal advice — obligations vary by product category, so verify against the regulation text and current guidance.
Related Resources
- The H2 2026 EOL Pileup: Why the Second Half of 2026 Is Different
- Cyber Insurance and EOL Software: What Underwriters Now Ask
- Dependency Scanner — inventory a whole manifest at once
- EOL Watch — lifecycle date changes, tracked live
- EOL Risk Score — how we rank EOL severity
- Extended Support Vendors — patches for components you cannot migrate yet
- Migrating off AngularJS
- Migrating off Node.js 18