Tech Support
Documentation
Login
Contact Us
Go straight to an AI summary of this blog post instead 
Key Takeaways
- Under the Cyber Resilience Act, you have to handle vulnerabilities in your product, including those in its dependencies, for at least five years unless it is expected to be in use for a shorter period.
- Many open-source frameworks support a release for one to three years, so a product launched on a recent release can lose access to upstream security fixes partway through its support period.
- Four routes to keep security fixes coming after upstream support ends: move to a newer release, replace the dependency, fix it yourself, or buy the fixes.
- Reporting duties have applied since 11 September 2026, so an actively exploited vulnerability in a dependency already past end of life is reportable today, with no upstream fix to point to. The support period rules follow on 11 December 2027.
The EU Cyber Resilience Act (CRA) support period needs to last at least five years unless a product is expected to be in use for a shorter period. Recent versions of popular frameworks like Laravel, Django, and Spring Boot stopped receiving open-source security fixes within 1 to 3 years of release. If you ship software built on those frameworks, upstream fixes stop partway through your support period, and you have to provide the fixes for the remainder.
A support period is the time during which a manufacturer has to keep handling vulnerabilities in a product. Under the CRA, the manufacturer is whoever markets the product under its own name or trademark in the course of a commercial activity, whether for payment or free of charge. The manufacturer’s duty to address vulnerabilities covers the entire product, including its components. The people maintaining the libraries underneath usually carry no matching duty, so nothing obliges them to keep fixing the version you ship.
The main obligations take effect on 11 December 2027, which may seem distant until you compare the support period requirements with how long the frameworks you’d pick today will continue to receive fixes.
What the CRA Support Period Requires
The Cyber Resilience Act is Regulation (EU) 2024/2847. In the Act’s terms, a manufacturer is any natural or legal person who develops a product, or has it developed, and markets it under their own name or trademark, whether for payment or free of charge. It defines the support period as the time during which the manufacturer has to ensure that the product’s vulnerabilities are addressed effectively.
Article 13 of the CRA requires manufacturers to set the period to reflect how long the product is expected to be in use. Reasonable user expectations, the nature of the product, and its intended purpose all count. The period has to be at least 5 years. The one exception is a product expected to be in use for less, in which case the period matches that expected use. Where a product is reasonably expected to be in use for more than five years, the period has to be longer. The Act’s recitals give routers, operating systems, and industrial control systems as examples.
Three duties come with the period. Manufacturers have to release security updates without delay and free of charge. The only exception is a tailor-made product, where the manufacturer and a business user can agree on a fee for updates. The end date, with at least the month and year, has to be clear at the point of purchase. And each security update stays available for at least 10 years, or for the rest of the support period if that’s longer. All three apply to fixes for the open-source components inside the product as much as to your own code. The published end date is a public commitment, so find out how long your dependencies will continue to receive upstream fixes before you print it.
Note: Products placed on the market before 11 December 2027 fall under the CRA’s main requirements only if they undergo a substantial modification after that date. That means a change after launch that affects compliance with the Act’s product requirements or changes the purpose for which the product was assessed. Article 14, which covers reporting, works differently: its duties apply to in-scope products already on the market, and they’ve been in effect since 11 September 2026.
How Long Common Dependencies Last
Three framework versions, one each from Python, PHP, and Java, have recently reached end of life. In this article, end of life means the date a project stops issuing security fixes for a version.
| Dependency | Released | Upstream security fixes ended | Span | Basis |
|---|---|---|---|---|
| Django 4.2 (long-term support) | 3 April 2023 | 7 April 2026 | About 3 years | Project policy, not law |
| Laravel 11 | 12 March 2024 | 12 March 2026 | 2 years | Project policy, not law |
| Spring Boot 3.5 | 22 May 2025 | 30 June 2026 | About 13 months | Project policy, not law |
Each project words this differently. Django calls it the end of extended support, Laravel lists when security fixes stop, and Spring calls it the end of open-source support. For you, they mean the same thing because the version you shipped stops receiving upstream fixes.
None of the three got five years of upstream security fixes, which is the least the CRA asks of you. The framework’s release date matters less than your product’s launch date, though, because your support period starts when you place the product on the market. On the day you launch, check how much upstream support the framework has left. Take a product launched on 11 December 2027, the day the support period rules begin: its support period has to run at least until 11 December 2032. Built on Laravel 13, released on 17 March 2026, it would keep getting upstream security fixes until 17 March 2028, about three months into that period. Built on Django 5.2, a long-term support release, it would keep getting them until April 2028, about four months in. Newer framework releases will arrive before December 2027: Laravel ships a major version roughly every year, and Django’s 6.2 is due in April 2027, with extended support through April 2030, a little over two years into the same period. Whichever version you launch on, upstream fixes end years before your support period does, and the fixes for the remaining years have to come from you.
You can move to a newer release, and many teams will, but that’s engineering work landing before or during your support period. Three frameworks aren’t the whole stack, and some of your dependencies will outlast five years. The job is to check each one’s published dates against yours.
Who Owes What for the Open-Source Code You Ship
The CRA says two things about components you didn’t write. Component is the word for the dependencies you pull in. Article 13 requires manufacturers to exercise due diligence when integrating third-party components, including open-source ones, so that those components don’t compromise the product’s security. And when a manufacturer finds a vulnerability in a component, they have to report it to the component maintainers and remediate it in their own product. If the manufacturer writes a fix, they have to share the code or documentation with those maintainers, in a machine-readable format where appropriate.
Maintainers are treated differently depending on who they are. An open-source software steward is a legal person, other than a manufacturer, that systematically supports specific open-source products intended for commercial activities and keeps them viable. Foundations and companies that publish open-source software in a business context can fall into that group. Article 24 asks stewards to put in place and document a cybersecurity policy that supports secure development and effective vulnerability handling, and to cooperate with market surveillance authorities. It adds limited reporting duties. Open-source projects that aren’t monetized generally fall outside manufacturers’ obligations, and individual contributors to projects they don’t run aren’t covered.
From the Regulation: When a manufacturer determines the length of its support period, Article 13 allows it to take into account the support periods of third-party components that provide core functions. That can justify a longer period. It cannot take you below the five-year minimum, so a framework that loses upstream fixes after two years does not let you declare two. The five-year minimum still applies.
| Point | What it says | Basis |
|---|---|---|
| Minimum length | At least five years, unless the product is expected to be in use for less | Binding (Article 13) |
| Components | Vulnerability handling covers the product’s components, including open-source ones | Binding (Article 13) |
| Maintainers | Stewards need a documented cybersecurity policy (covering vulnerability handling) and have no support period for any version | Binding (Article 24) |
| Five years as a floor | Five years is a minimum, and the Commission’s guidance says it is not to be treated as the default for all products | Guidance (Commission, non-binding) |
| Versions | Each substantially modified version placed on the market needs its own declared support period; a modification that leaves the expected use time unchanged leaves the original period unchanged too | Guidance (Commission, non-binding) |
Taken together, upstream usually owes you no support period, and the CRA makes you, as the manufacturer, responsible for handling vulnerabilities in the finished product.
What You Can Do When a Dependency Reaches its End of Life
Once upstream stops, somebody has to produce the fixes, and the CRA doesn’t say who has to write them. That leaves four routes, each with a different bill.
Move to a newer release: This works when you control when customers get new versions, and it costs engineering time each cycle. Across a stack with several frameworks on different calendars, those migrations add up.
Replace the dependency: A maintained alternative removes the problem if one exists and you can afford the rewrite.
Fix it yourself: Your team backports security fixes to the version you ship. That takes people who know the code well, and Article 13 requires you to report the vulnerability to the maintainers and share your fix with them.
Buy the fixes: Some projects sell extended support for older versions. Spring’s own announcement, for example, says commercial support for Spring Framework 6.2 runs until mid-2032. Spring’s support data lists enterprise support for Spring Boot 3.5, the release in the table above, to 30 June 2032. Independent providers also sell patches for end-of-life versions. Coverage depends on the specific versions you run, so give the provider your actual version list and confirm each one is covered before you count on it.
Two other moves look tempting. Declaring a shorter support period isn’t available unless you expect the product to be in use for less than five years. Documenting a known vulnerability in a risk register explains it, but the CRA requires manufacturers to address and remediate vulnerabilities without delay, and a register entry isn’t a fix.
What to Decide Before You Set a Support Period
You have to state the end date at the point of purchase, so it’s easier to settle the dependency questions before you publish it than after.
- Start with an inventory: A current list of what your product contains, usually a software bill of materials (SBOM), shows you which dependencies to check, including those pulled in by your direct dependencies.
- Line up the dates: Put each dependency’s published end-of-life date next to the CRA support period you’re considering. A spreadsheet works.
- Check each version: Support runs per version, as shown by the Django, Laravel, and Spring Boot dates. Look up the end-of-life date for the exact version you ship. The Commission’s guidance also expects a declared support period for each substantially modified version you place on the market.
- Name a fixer for each gap: For each dependency that falls short, pick one of the four routes and decide who owns it.
- Flag what’s already past its end: If a dependency in a shipping product is past end of life today, the gap exists now. If the product is in scope, an actively exploited vulnerability in that dependency has been reportable within 24 hours since 11 September 2026. The 72-hour notification that follows has to say what you did about it, while there is no upstream fix to point to.
- Write down why: The technical documentation has to include the information you used to set the period, so keep your reasoning.
Closing the Gap Before December 2027
You declare a support period when you place a product on the market and then carry it for years, while the underlying frameworks follow their own calendars. Lining up the two before you commit shows how many of those years you will spend sourcing security fixes for code whose maintainers have stopped patching it.
If one of the frameworks underneath your product loses upstream security fixes before your support period ends, somebody still has to produce the fix. Endless Lifecycle Support (ELS) from TuxCare does it. TuxCare engineers backport security fixes to the exact versions you already run, for as long as you depend on them. Your developers keep the versions they have and the workflows they use. ELS also pairs with SecureChain, which verifies open-source packages before install and patches them while upstream is still active.
Bought together, SecureChain and ELS hand over coverage automatically. When a maintainer stops releasing security fixes for a version you run, coverage for that version moves from SecureChain to ELS. You don’t have to track each component’s end-of-life date to know when upstream fixes stop. The products now cover JavaScript, Python, Java, Go, and PHP ecosystems.
FAQ
What’s the EU CRA Support Period Minimum Duration?
The EU Cyber Resilience Act (CRA) sets a minimum support period of five years. A manufacturer can go shorter only if the product is expected to be in use for less, and then the period matches that use. A product people will plausibly use for longer needs a longer period.
Do Open-Source Maintainers Have to Keep Supporting Old Versions?
Generally not. The Cyber Resilience Act (CRA) treats two groups differently, and neithergroup has a support-period obligation. Open-source software stewards, legal persons who systematically support commercial-use open-source products, have to document a cybersecurity policy, including vulnerability handling, and cooperate with authorities. Open-source projects that aren’t monetized fall outside the manufacturer obligations, and individual contributors to projects they don’t run aren’t covered at all. Either way, the manufacturer shipping the code has to keep it patched for the support period it declared.
What Happens When a Dependency Loses Security Fixes During the Support Period?
The duty stays with the manufacturer. Under the Cyber Resilience Act (CRA), vulnerabilities in the product, including its components, have to be handled for the whole support period it declared. Routes include moving to a supported release, replacing the dependency, writing the fix, or buying patches for the old version.
What Do Manufacturers Have to Tell Users About the Support Period?
Under the Cyber Resilience Act (CRA), the end date of the support period, with at least the month and year, has to be clear at the point of purchase. Manufacturers also record how they set the period in their technical documentation and, where technically feasible, notify users when support ends.
Does the Cyber Resilience Act Apply to Products Already on the Market Before December 2027?
Only if they’re substantially modified. Under the Cyber Resilience Act (CRA), products on the market before 11 December 2027 face its requirements only after a substantial modification from that date. Article 14’s reporting duties, including for actively exploited vulnerabilities, apply to those products anyway.
Is the Commission’s Guidance on the Cyber Resilience Act Legally Binding?
No. The European Commission published its Cyber Resilience Act (CRA) guidance on 27 July 2026 to explain how to apply the rules, but it’s non-binding. The regulation itself and the adopted delegated or implementing acts have legal force, and only the EU’s Court of Justice can provide an authoritative interpretation. The guidance does show how the Commission expects the rules to be applied, so it is the reading to plan against until a court says otherwise.
