End of Life in the Web Stack: Components Without Updates

What end of life actually means

End of life is a calendar day, not a state of the software. The day before, a PHP branch is maintained; the day after, it is not – and the files on the server are byte for byte identical. The PHP Group describes the model without room for interpretation: a release branch receives regular bug fixes for two years (PHP Group), followed by a phase in which only security issues are addressed. After a total of four years, that ends as well (PHP Group). From that day on, a newly discovered flaw in that branch simply has no patch, regardless of how serious it is.

The risk is not theoretical. For its European threat assessment, ENISA analysed 4875 incidents recorded between July 2024 and June 2025 (ENISA) – a volume that shows how routinely known weaknesses are exploited at scale. In that landscape, a component without vendor fixes is not a residual risk but an open end. How you find out that a reported flaw affects your components at all is something we took apart in our article on the EUVD and CVE vulnerability feeds.

• What ends: bug fixes, security fixes, official distribution packages, and any binding vendor statement about newly reported flaws.
• What does not end: the availability of the old files on package mirrors, everyday functionality, and the impression inside the team that everything is running fine.
• What starts: your own burden of proof. From end of life onwards you have to explain why an unmaintained component sits inside a product you place on the market.
• What stays the same: the maintenance contract, the hosting plan, the invoice – none of these documents adjusts itself when a window closes.

CRA deadlines set the pace

Two dates structure the coming years. The obligation to report actively exploited vulnerabilities applies from 11 September 2026 (European Commission), and the main obligations of the Cyber Resilience Act apply from 11 December 2027 (European Commission). In between lies the period that decides whether an organisation knows its components or has to assemble them under pressure. The support period itself should not fall below five years (Official Journal of the EU) – a lower bound that many windows in the web stack have to be measured against. What the reporting duty requires in detail is covered in our article on the CRA vulnerability reporting obligation.

Now hold that lower bound against practice. An Angular major version is typically supported for 24 months (Angular), Laravel provides bug fixes for 18 months and security fixes for two years (Laravel), and a Node.js LTS line states that critical fixes are provided for a total of 30 months (Node.js). Not one of those windows reaches five years on its own. That is not a criticism of the projects – it only means the commitment you make to your customers cannot come from a single component, but from a planned move from one window to the next.

Support windows compared

The table below collects what the projects themselves commit to. It does not replace an inspection of your own installation, but it makes the orders of magnitude visible – and the spread is considerable. Between the shortest and the longest window in this list there is roughly a factor of ten: six months for a Node.js Current branch against five years for Python, Ubuntu LTS and OpenSSL LTS. Anyone combining all of these components in one product does not have one end of life, but a chain of them.

Two rows in that table deserve particular attention. An Ubuntu interim release receives only nine months of updates (Canonical) – running production on it means facing an unplanned move several times a year. And with OpenSSL the label decides: an LTS release is committed to at least five years of support (OpenSSL), while a release without that label is fully supported for only 13 months from 3.5 onwards (OpenSSL). Both components stay invisible as long as they work. They become visible the moment a scanner reads the version out of a response header – see our article on version disclosure through server headers.

Why old branches survive so stubbornly

The numbers show a very clear pattern: old branches do not disappear, they settle. 51 percent of websites run on a CMS (Web Almanac 2024) and therefore inherit its version maintenance along with every extension. Only 63.5 percent of PHP websites use the version 8 branch (W3Techs); the rest sit on older ones. Among WordPress installations that report back to WordPress.org, 17.11 percent run on PHP 7.4 and 1.346 percent still run on PHP 5.6 (WordPress.org). The second figure is small, but it describes installations whose foundation has not seen a fix in years. What that means for day-to-day operation is covered in our article on WordPress security monitoring.

The reasons for this inertia are rarely technical. A branch change touches extensions, custom modifications, build chains and test coverage at the same time, and each of those has a different owner. As long as nothing visibly breaks, postponement wins every prioritisation round. End of life changes nothing about that dynamic – it merely shifts the cost of postponement from maintenance into liability. The decisive question is therefore not whether a move is due, but how many months of remaining runtime are still on the clock.

The front end ages most quietly

Server components attract attention because they ask for updates. In the front end, by contrast, the code sits as a file in the deployment directory and does not announce itself. jQuery remains the most used library on the web and appears on 74 percent of pages (Web Almanac 2024), and jQuery UI still runs on 22 percent despite being largely deprecated (Web Almanac 2024). These files are not pulled along by any distribution update, they appear in no server package manager and in no system list. How to find them anyway is shown in our article on detecting vulnerable JavaScript libraries.

On top of that comes everything that foreign servers reach into your page with: embeds for payment, maps, chat or measurement. Someone else decides their version state, and an end of life there rarely reaches you at all. This class of components belongs in the inventory just as much as your own package – we looked at it separately in our article on third-party scripts, because there the silent replacement of a file is an issue alongside end of life.

The inventory: eight fields per component

A list that only holds names does not help at this point. To turn an inventory into a decision, every component needs the same fields – and they have to be built so that a missing value stays recognisably missing instead of quietly passing as zero. The same logic applies to bought-in services: anyone with providers in the stack needs their evidence in the same structure, as described in our article on NIS2 supply chain vetting.

1. Name and branch – not the patch version, but the branch the support window is attached to (the PHP branch, for instance, not the third digit).
2. Origin – distribution package, vendor package, library in the deployment directory, or an embed from a foreign server.
3. End of life as stated by the vendor – as a date, with a reference to the page it is published on.
4. Source of that date – the address where the commitment is published; without it, the date is an assertion.
5. Remaining runtime in months – the only value that produces a meaningful sort order.
6. Measured yes or no – a field of its own that records whether the value was actually determined or merely estimated.
7. Accountable role – a role, not a person, so the assignment survives a staffing change.
8. Successor – the branch you will move to, including its own end of life. Without this field, every move becomes fresh research.

Calculating and grading remaining runtime

An inventory turns into an order of work as soon as every component carries a remaining runtime. The arithmetic is trivial; the value behind it is not, because it turns a list into a plan. Python, for example, fixes end of life firmly at five years after a version is released (Python Software Foundation) – the date is therefore settled on release day and can be entered years in advance. What matters is that a value which was not determined stays visibly undetermined. We recommend the same separation between measured and assumed for the health check endpoint, which otherwise returns green answers for dependencies nobody checked.

from datetime import date

def remaining_months(eol, today=None):
    """Months until end of life. None means: not determined."""
    if eol is None:
        return None
    today = today or date.today()
    return (eol.year - today.year) * 12 + (eol.month - today.month)

def grade(months):
    if months is None:
        return "unmeasured"      # do not treat as 0
    if months < 0:
        return "expired"
    if months <= 3:
        return "critical"
    if months <= 12:
        return "plan"
    return "watch"

inventory = [
    ("php-branch", date(2027, 12, 31)),
    ("node-lts", date(2027, 4, 30)),
    ("frontend-library", None),
]
for name, eol in inventory:
    m = remaining_months(eol)
    print(f"{name}: {grade(m)} ({m if m is not None else 'no date'})")

Four grades are enough to steer by: expired, critical, plan, watch – plus the fifth category unmeasured, which deliberately gets no number. A component without a determined end of life is not a safe component, it is an unknown one. Filling those cases with a zero or a generous default produces a list that looks reassuring throughout. A regular security scan adds the outside view of the same stack: whatever versions become visible from outside belong in the same table as what you know from inside.

Planning the migration before the window closes

A move that only starts after end of life happens under time pressure and reliably produces new defects along the way. The workable order is therefore reversed: the date for the move is derived from the end of life, not from free capacity. In practice, dependencies tend to surface that nobody had on their list – a certificate problem, for instance, that only becomes visible after moving to a newer library, as described in our article on detecting an incomplete certificate chain.

1. Set the target date: the move is finished before the window closes – not on the same day.
2. Choose the successor: the specific target version including its own end of life, so the next move is already in the calendar.
3. Check dependencies: extensions, custom modifications and the build chain against the target version, before dates are promised.
4. Pull test coverage forward: whatever is not checked before the move gets checked in production afterwards.
5. Bring security headers along: a migration is the cheapest moment to set the cross-origin headers COOP, COEP and CORP properly.
6. Define the way back: a documented route back that has been rehearsed without time pressure, not a theoretical one.
7. File the evidence: date, target version, test result – that is what later proves the support period was upheld.

A component without a determined end of life is not a safe component, it is an unknown one. That difference decides whether a list is a basis for decisions or merely reassurance.

— XICTRAQ

Keeping end-of-life dates in view continuously

An inventory is a cut-off date; end of life is a movement. Between the two lies the reason spreadsheets rarely survive this task: they start ageing the moment they are finished. The CRA component cockpit therefore keeps the inventory running, connects it with hints about reported vulnerabilities, and speaks up when a remaining runtime falls below the configured threshold – 90, 30 and 7 days before the date, instead of once a year when someone reviews the list.

The organisational gain is larger than the technical one. Anyone who can state at any time which components run in which version, and when their window closes, answers customer and auditor questions from the record rather than from memory. Which plans include this capability is listed on the pricing overview, together with the applicable minimum contract term. The effort for the first inventory remains yours – the effort for every following one does not.