End-of-Life Software: The Hidden Risk on 6.6 Million Domains

Published 2026-08-21

End-of-life (EOL) software is any program whose vendor has stopped supporting it: no more security patches, no bug fixes, no updates, no matter what new vulnerability is discovered. When that software is the web server, mail server, or operating-system component that faces the public internet, every flaw disclosed after the end-of-support date stays open permanently — there is no fix coming. The August 2026 defaults.exposed census fingerprinted the server software behind 432,127,908 domains and found 6.6 million of them running a version whose vendor has already ended security support. Those are domains advertising, in their own server banners, that they run code no one is allowed to patch — and because most modern servers hide their version string, 6.6 million is a floor, not a ceiling.

That single number is why “end-of-life software” has stopped being an IT-hygiene footnote and become a line item in insurance renewals and compliance audits. An unpatched, unsupported server is not a theoretical risk an underwriter models — it is a known, disclosed exposure that a claims adjuster or a regulator can point to after the fact. The figures throughout come from the defaults.exposed August 2026 census, an independent scan of 432,127,908 domains graded as of 2026-08-16.

The short answer: what end-of-life software means

Software has a lifecycle. A vendor releases a version, supports it for a defined window with security updates, then declares an end-of-life (also called end-of-support or EOL) date. After that date the code is frozen. It may keep running perfectly — servers do not stop working the day support ends — but the security relationship is over. When researchers find a new vulnerability in that version, the vendor will not ship a patch, because they are under no obligation to and have moved their engineering to newer releases.

There is an intermediate stage worth naming. Many products pass through end-of-mainstream-support (no new features, security fixes only) before reaching true end-of-life (nothing at all). A few offer paid extended security updates for large customers past the public EOL date. But the internet-facing reality is binary: either your version still receives security patches through a channel you actually use, or it does not. If it does not, you are running end-of-life software, and every future vulnerability in it is yours to live with.

This matters far beyond the operating system. The exposed surface includes the web server itself (the software that answers HTTP requests), the TLS library that terminates encryption, the application runtime, and the frameworks layered on top. Any one of them can reach end-of-life independently while the rest stay current. A domain can run a fully patched operating system and still serve traffic through a web server release that was declared end-of-life years ago — which is exactly the pattern the census surfaces. For how defaults.exposed identifies the software fronting each domain, see the hosting-provider methodology.

Why EOL software is a security AND compliance problem

The security half of the problem is mechanical and, once stated, obvious. Vulnerabilities are discovered continuously in all widely deployed software. Supported software absorbs them: a flaw is reported, the vendor ships a patch, operators apply it, the window closes. End-of-life software has no such absorber. A vulnerability disclosed the week after end-of-support is public — attackers read the same advisories defenders do — but no official fix exists. The exposure is permanent and grows with time, because the count of unpatched flaws only ever increases.

Attackers actively prefer this target class. Automated scanning tools fingerprint server banners at internet scale and cross-reference them against public vulnerability databases, so a domain that advertises an end-of-life version is not merely vulnerable in principle — it is discoverable as vulnerable, cheaply, at scale. The reconnaissance is the same fingerprinting defaults.exposed performs; the difference is intent. An end-of-life banner is a shortlist entry.

The compliance half is newer and, for budget-holders, sharper. Two forces have converged. Cyber-insurance underwriters, after years of ransomware losses, now treat unsupported software as a named exposure — frequently a policy exclusion or a condition that reduces payout. And regulators, through frameworks such as the EU’s NIS2 directive, now require organisations to run vulnerability management and basic cyber hygiene as a legal duty. Running software the vendor no longer patches is a direct, documentable failure of both. The technical risk did not change; the financial and legal consequences of ignoring it did.

There is a second-order trap here specific to the modern web. A CDN or reverse proxy in front of an origin server can hide the origin’s software version and absorb some attack traffic, which makes an end-of-life origin look fine from the outside. The census sees this: 41.9 million sites sit behind Cloudflare alone. A proxy can mask an end-of-life origin, but it does not patch it — the vulnerable code is still running, still reachable through any path that bypasses the proxy, and still an unsupported component in a compliance audit. We measured how far that protection actually reaches in Does Cloudflare Make You Safer? 41.9M Domains Graded.

6.6 million domains are running it right now

The August 2026 census fingerprinted server software across all 432,127,908 domains it scanned and identified 6.6 million serving a version that has passed its vendor’s end-of-support date. That is the population running public-facing code with no patch pipeline behind it — not a survey estimate, but a direct read of the software these servers announce.

Read the number the right way and it is worse than it looks. Server-software fingerprinting depends on the Server response header and related banners, and a large and growing share of the internet suppresses or genericises that string — either deliberately, as a hardening step, or because a proxy rewrites it. Every domain that hides its version is invisible to this count. So 6.6 million is the number of domains that admit to running end-of-life software; the true figure is necessarily higher, because the honest servers are the ones you can measure. We break the fingerprinting down by product in the finding-led companion report, End-of-Life Software Census: 6.6 Million Servers Admit It.

The root cause is rarely ignorance and almost always inertia. An end-of-life server is usually a working server. It answers requests, serves the site, and shows no symptom — the day support ended, nothing broke. Upgrading it means a migration: testing the application against a newer runtime, scheduling downtime, and accepting the risk that something that currently works might not after the change. Set against a threat that is invisible until it is exploited, that migration keeps losing the priority argument. Multiply that decision across every small business, hobby project, and forgotten staging box on the internet and you arrive at 6.6 million measurable instances.

The company these domains keep tells the same story of deferred maintenance. The census found 5.2 million TLS certificates that are expired but still being served — the certificate equivalent of a lapsed service contract — quantified in Expired SSL Certificates: 5.2 Million Sites Still Serving. And across the whole graded population, 295,157,813 domains — roughly 78.3% — earn an F grade once every check is scored together. End-of-life software is not an isolated defect; it clusters with every other symptom of a stack no one is actively maintaining. For the wider picture of what runs the web, see The Web Server Census 2026.

Cyber insurance and NIS2: the unsupported-software exclusion

This is where end-of-life software stops being an engineering topic and becomes a boardroom one.

Cyber-insurance policies have tightened sharply. After the ransomware loss years, underwriters stopped treating “unsupported software” as background risk and started writing it into the contract. The exact wording varies by insurer, but the pattern is consistent: many policies now either exclude losses arising from unsupported or end-of-life software, or make full payout conditional on the insured not running it on internet-facing systems. The mechanism that hurts is not the premium — it is the claim. An organisation can pay for cover, suffer a breach, and then discover during the claims investigation that the entry point was an end-of-life component the policy did not cover. The exposure the census measures is exactly the kind an adjuster can evidence from the outside, using the same public banner data. The email-control side of that same underwriting questionnaire is covered in Cyber Insurance Requirements 2026: The Email Controls Underwriters Check.

Regulation pushes from the other side. The EU’s NIS2 directive (Directive (EU) 2022/2555) requires in-scope organisations to adopt baseline risk-management measures — including vulnerability handling and disclosure, and basic cyber-hygiene practices — as a legal obligation, with the prospect of significant fines and named management accountability for failures. NIS2 does not publish a banned-products list. It does not have to: running software the vendor no longer patches is a plain failure of the vulnerability-management and maintenance duties the directive sets out. The obligation is process-based, and an unpatched end-of-life server is documentary proof the process is not running. The directive’s specific email-authentication expectations are set out in NIS2 Compliance and Email Authentication: What the Directive Requires.

For a budget-holder, the two forces combine into a simple financial case. Insurance may not pay if you run it; regulators may fine you for the maintenance failure it represents; and the fix — retiring the end-of-life component — is cheaper than either downside. The hard part has never been justifying the spend. It has been knowing which of your domains carry the exposure, because the server that is quietly out of support looks identical, from a browser, to the one that is fully patched.

How to find end-of-life software in your own stack

You cannot retire what you have not found, and the finding is the part organisations underestimate. The exposure hides in three predictable places.

The forgotten domain. Marketing microsites, old campaign pages, a staging box that was never decommissioned, the blog on a subdomain that one person set up and left. These are the servers that reach end-of-life uncontested, because no one is watching them.
The dependency you did not choose. Your application runtime, your TLS library, and the frameworks bundled into your platform each have their own lifecycles. A fully patched operating system can still ship an application stack component that is years past end-of-life.
The origin behind the proxy. A CDN hides the version string and absorbs some traffic, so the origin’s end-of-life status never shows in a casual external check — yet the vulnerable code is still there and still reachable.

There are two complementary ways to look. Internally, an asset inventory cross-referenced against vendor end-of-support calendars is the authoritative source: it sees the versions a public scan cannot, because it reads them from the systems directly. This is the method a serious vulnerability-management programme runs on, and it is the one an auditor will ask for. Its weakness is completeness — it only covers the assets you remembered to inventory, which is exactly where forgotten domains slip through.

Externally, a public scan closes that gap from the attacker’s vantage point. It reads the server banners, certificate details, and protocol support that any internet host can see, and it catches the domains your internal inventory forgot — precisely because it does not depend on you knowing they exist. That is the layer defaults.exposed measures: it reports the software your domain advertises, the state of its certificate, and its TLS posture, the same public signals an underwriter’s scan or an attacker’s reconnaissance would collect. Relevant methodology sits in TLS version and certificate expiry. The two approaches are additive: the internal inventory sees deeper, the external scan sees wider, and end-of-life exposures tend to live in the gap between them.

Check your domain free at defaults.exposed — it reads what your domain publishes to the public internet and flags the maintenance signals that correlate with end-of-life software, in about 30 seconds and with no account.

What to do when you find it

Finding an end-of-life component turns a vague worry into a concrete task, and concrete tasks get done. Work it in order.

Confirm the version and its support status. Match the software and version against the vendor’s published end-of-support date. Distinguish end-of-mainstream (security fixes only) from true end-of-life (nothing) — the urgency differs, but both are on the clock.
Assess the exposure. Is the component internet-facing? Does it handle authentication, payments, or personal data? An end-of-life server behind no protection and in front of sensitive data is a different priority from an isolated internal tool. Rank by reachability and blast radius, not by alphabetical order.
Plan the migration, do not just patch around it. The only durable fix for end-of-life software is to move to a supported version. Virtual patching, WAF rules, and proxies buy time and reduce noise, but they do not restore the patch pipeline — the underlying code is still frozen. Treat mitigations as a bridge to the upgrade, never a substitute.
Retire what you do not need. A meaningful share of end-of-life servers exist only because no one turned them off. If a domain or service has no owner and no purpose, decommissioning it is faster, cheaper, and safer than upgrading it — and it removes the compliance liability entirely.
Make it recur. End-of-life is a date, not an event: today’s supported version is next year’s liability. Fold an end-of-support review into your regular vulnerability-management cadence so the next EOL date is caught before it lands, not after a scan or a claim surfaces it.

Doing the upgrade properly — closing the certificate, TLS, and header gaps that cluster around a neglected stack, not just the one banner — is where a structured fix earns its keep; see how the fix works.

What this means

For business owners, end-of-life software is a risk you can be held to account for without ever being breached. An insurer can decline a claim because an unsupported component was internet-facing; a regulator can fine the maintenance failure it represents; and a customer’s due-diligence questionnaire can fail you for it. The good news is that it is one of the most findable risks there is — the server usually announces its own version — and one of the most fixable, because the remedy is a known upgrade or a decommission, not a research project. The census found 6.6 million domains carrying this exposure in the open; the only question that matters is whether one of them is yours.

For IT and security teams, the census reframes end-of-life from a backlog ticket into an audit finding waiting to happen. Your internal inventory sees the versions but misses the forgotten domains; an external scan catches those but sees only what is public. Run both, rank by reachability, and treat proxies and virtual patches as bridges to an upgrade rather than a resting state. When a stakeholder asks “are we running anything unsupported?”, the defensible answer is a maintained inventory reconciled against vendor end-of-support dates and an external scan that confirms it from the outside — not silence, and not a green padlock that hides an origin no one has touched in years.

FAQ

What is end-of-life software? End-of-life (EOL) software is a product whose vendor has stopped supporting it — no more security patches, bug fixes, or updates, regardless of what vulnerabilities are later discovered. The software often keeps running normally, which is precisely the danger: nothing breaks on the end-of-support date, so the risk is invisible until a flaw is exploited. Once a version is end-of-life, every future vulnerability in it stays permanently open, because no official fix will ever ship. The August 2026 census found 6.6 million public domains serving end-of-life web-server software with no patch pipeline behind them.

Why is end-of-life software a security risk? Because vulnerabilities keep being discovered, but end-of-life software stops receiving fixes. Supported software absorbs each new flaw through a patch; end-of-life software cannot, so its exposure only grows over time. Attackers actively hunt these systems — automated tools fingerprint server banners at internet scale and match them to public vulnerability databases, making an end-of-life server discoverable as vulnerable, cheaply and en masse. The 6.6 million domains the August 2026 census identified as running end-of-life software are advertising, in their own response headers, exactly the code an attacker’s scanner is looking for.

Does cyber insurance cover end-of-life software? Often not, or not fully. Many cyber-insurance policies now either exclude losses arising from unsupported or end-of-life software, or make full payout conditional on not running it on internet-facing systems. Exact wording varies by insurer, so read the policy — but the pattern across the market is that unsupported software has moved from background risk to a named exclusion or condition. The exposure bites at claim time: a breach through an end-of-life component can be evidenced by an adjuster from the same public banner data the census uses, and used to reduce or deny the payout. You can see what your domain advertises with a free check at defaults.exposed.

What happens when software reaches end of life? The software keeps working, but its security lifecycle ends. The vendor ships no further security patches, so any vulnerability found after the end-of-support date has no official fix. In practice this means three compounding problems: a permanently growing set of unpatched flaws, discoverability by attackers who fingerprint versions at scale, and a compliance liability — insurers and frameworks such as NIS2 treat running unsupported software as a documentable failure of basic maintenance. The only durable remedy is to migrate to a supported version or decommission the system; mitigations like proxies buy time but leave the frozen code in place. The census found 6.6 million domains already in this state.

Data to cite

“6.6 million domains run end-of-life web-server software with no vendor security patches — and because many servers hide their version, that is a floor, not a ceiling.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“The August 2026 census fingerprinted server software across all 432,127,908 domains it scanned.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“5.2 million TLS certificates are expired but still being served — the certificate equivalent of a lapsed maintenance contract.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“295,157,813 domains — about 78.3% — earn an F grade once every check is scored together, and end-of-life software clusters with the other symptoms of an unmaintained stack.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“41.9 million sites sit behind Cloudflare, which can mask an end-of-life origin but cannot patch it.” — defaults.exposed August 2026 Domain Security Census (432M domains)

See where your own domain stands

End-of-life software is the rare risk that is both easy to miss and easy to prove. Easy to miss, because the server keeps working and looks identical from a browser to one that is fully patched. Easy to prove, because the server usually announces its own version to anyone who asks — including an underwriter’s scanner, a regulator’s auditor, and an attacker’s reconnaissance bot. The census found 6.6 million domains in that state, and most of their owners have never seen it stated plainly.

Check your domain free at defaults.exposed — it reads the software banner, certificate state, and TLS posture your domain publishes to the public internet and flags the maintenance signals that travel with end-of-life software. Takes about 30 seconds. No account needed. If you want the gaps closed properly — the end-of-life component retired and the certificate, TLS, and header defects around it fixed — see how the fix works.

Read the flagship census report: The State of Domain Security 2026 →

Aggregate data only. Data stored and processed in the EU.

Data source: defaults.exposed August 2026 census, methodology v9, as of 2026-08-16. 432,127,908 domains scanned; server software fingerprinted across the full scanned population. All figures are counts of scanned or graded domains. End-of-life status is assessed against vendor end-of-support dates for the software versions domains advertise.

How to cite this report

Press / blog: defaults.exposed (2026). End-of-Life Software: The Hidden Risk on 6.6 Million Domains. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/v9/articles/end-of-life-software-the-hidden-risk-on-6-6-million-domains

Academic: defaults.exposed. (2026, August 21). End-of-Life Software: The Hidden Risk on 6.6 Million Domains. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/v9/articles/end-of-life-software-the-hidden-risk-on-6-6-million-domains

In-line citation: (defaults.exposed, August 2026 Domain Security Census, n=432,127,908 domains scanned)

About the defaults.exposed August 2026 Census

The defaults.exposed Domain Security Census is a recurring independent measurement of the public domain namespace. The August 2026 edition scanned 432,127,908 domains between 1–16 August 2026 and graded 376,928,750 of them using methodology v9. Scans are conducted from EU infrastructure. No individual domain, registrant, or business is named in any report. All figures are aggregate distributions. Data is stored and processed within the EU.

Methodology: defaults.exposed/v9/methodology Full census report: defaults.exposed/en/articles/the-state-of-domain-security-2026

Data sourced from the August 2026 grading methodology (v9) — 34 checks, 376 million domains. Browse the census statistics or the Census Explorer, or see all August 2026 research →