What Is End of Life (EOL)?

End of life (EOL) is the vendor-declared date after which a product is no longer sold, updated, or supported by its manufacturer - the formal signal that an asset should be replaced, isolated, or retired rather than relied on. It is set by the vendor and applies to every owner of the product, which makes it different from useful life: useful life is your own estimate of how long an asset stays productive, while EOL is a date someone else sets.

The catch is that “end of life” is not one milestone. Vendors wind products down in stages - end of sale, end of software maintenance, end of security support, end of service life - and different vendors attach the EOL label to different points on that timeline. This page pulls the vocabulary apart, explains what actually stops at each stage, covers what auditors and insurers expect, and sets out the options when an asset reaches its date.

What you will learn

• EOL milestones, term by term
• Why EOL matters
• Mainstream, extended and paid extended security updates
• What EOL means for compliance, audits and insurance
• Software, hardware and the assets with no published date
• How to find and record EOL dates
• Your options when an asset reaches EOL
• Planning replacements around EOL
• EOL vs useful life, warranty, obsolete and legacy
• FAQ

EOL milestones, term by term

A product lifecycle typically runs through the milestones below, in roughly this order. Not every vendor publishes every one, and the labels vary, but the sequence is consistent: first the product stops evolving, then it stops being sold, then it stops being fixed, then it stops being supported at all.

Three things to take from the table. First, EOS is the ambiguous acronym: it is used for both end of sale and end of support, and the two can be years apart. Second, the final milestone has half a dozen names - network vendors tend to say last date of support, server and storage vendors say end of service life, operating system vendors say end of support or end of extended support - and some hardware vendors use “end of life” for the announcement that starts the whole sequence rather than the date that ends it. Third, because of the first two, an asset register should store dates, not labels: an “EOL” column that means end of sale for one product and end of support for another is worse than no column at all.

Why EOL matters

Nothing breaks on the EOL date; what changes is what no longer happens. Software past end of security support receives no patches, so every newly discovered vulnerability stays open for as long as the software runs - which is why unsupported operating systems are the first thing a penetration tester looks for and the first question on most cyber-insurance forms. For hardware, spare parts dry up, repairs get slower and dearer, firmware bugs stay unfixed, and drivers stop being written for newer operating systems. Costs shift, too: the money the vendor used to spend on maintenance now comes out of your budget, as workarounds, corrective maintenance, and emergency purchases.

There is also a compounding effect. An unsupported asset holds back everything that depends on it: an old server pins an old database, which pins an old application, which pins the old client operating system on every desktop that uses it. The longer the chain, the more expensive the eventual migration, which is how “we will replace it next year” turns into a five-year legacy system that nobody dares touch.

For equipment whose safe operation depends on the manufacturer, EOL bites harder still. Care and medical assets such as wheelchairs and hospital beds are often retired not because they stop working but because parts and authorised servicing for the model are discontinued, and a mandated inspection schedule cannot be met without them.

Mainstream, extended and paid extended security updates

Many software vendors run a two-phase model. In the mainstream support phase the product receives new features, non-security fixes, and security patches. In the extended support phase, usually the last few years before end of support, it receives security patches only - no new functionality, and often no non-security fixes without a paid agreement. Each phase has its own published date, and it is the end of extended support that most people mean when they say a product has gone EOL.

Beyond that, a growing number of vendors sell extended security updates (ESU) or extended lifecycle support: a paid, time-limited programme that keeps critical security patches flowing after the official end of support. For hardware, the equivalent is third-party maintenance, where an independent provider supplies parts, engineers, and sometimes firmware workarounds after the vendor’s end of service life.

Windows 10 is the live worked example. Support ended on 14 October 2025. Microsoft then offered an ESU programme: for organisations it is priced per device and rises each year for up to three years, and for consumers a one-year enrolment was offered, which Microsoft has since extended into 2027. Three lessons generalise from it:

• ESU is a bridge, not a destination. It buys time to migrate; it does not restore full support, and the price escalates to make sure you do not stay.
• Enrolment status matters for compliance. Under most certification and audit schemes an ESU-enrolled device counts as supported for as long as the programme runs; an unenrolled device on the same operating system does not.
• A perpetual licence does not expire at EOL. The software stays yours to run; it is the updates and support that stop. The distinction matters for licence compliance and for the perpetual vs subscription decision on replacements.

Other dates in the same window show how dense the calendar has become: SQL Server 2016 reached the end of extended support on 14 July 2026, Office LTSC 2021 and Windows 11 version 24H2 (Home and Pro) reach end of support on 13 October 2026, and Windows Server 2016 follows on 12 January 2027. An organisation that discovers these one at a time is doing something wrong with its register.

What EOL means for compliance, audits and insurance

Most security and compliance frameworks do not say “you must not run EOL software” in those words. What they do is require supported, patched systems, and unsupported software fails that test by definition. A survey of the ones that come up most often - none of this is legal advice:

• Cyber Essentials (UK) - unsupported software within the assessment scope is an automatic fail. The accepted remedies are to upgrade, to enrol in a vendor’s paid extended security updates, or to segregate the device onto a separate network or sub-set so it falls outside the certified scope.
• PCI DSS 4.0.1 - requirement 12.3.4 requires a review at least once every 12 months confirming that hardware and software technologies in scope are still supported by the vendor and still receive security fixes, with a documented, management-approved remediation plan for anything that is at or approaching end of life.
• ISO 27001:2022 - the controls on technical vulnerability management and on the installation of software expect an organisation to know which of its products are unsupported, to risk-assess them, and to have a plan for taking them out. The asset inventory control is what makes that possible; see ISO 27001 asset management.
• UK GDPR and GDPR article 32 - the duty to maintain appropriate technical security measures. The UK regulator has treated unsupported operating systems as inadequate security in enforcement decisions, particularly where personal data was exposed through a vulnerability that a supported system would have patched.
• DORA - financial entities in the EU must identify and document their legacy ICT systems, and assess the risk of those systems at least yearly, with end of life explicitly in mind.
• NIS2 - essential and important entities are expected to manage risk across their asset estate, which includes knowing what is unmanaged, unsupported, and still connected.
• Cyber insurance - proposal forms routinely ask whether any unsupported software or operating systems are in use and, if so, how they are isolated. A claim traced to an unpatched EOL system may be reduced or excluded, and a misdeclared answer can void the policy.

The common thread is documentation. Auditors and insurers rarely expect zero unsupported assets; they expect you to know which ones you have, to have a written justification and a compensating control for each, and to have a date by which each one goes.

Software, hardware and the assets with no published date

Software EOL is sharp. A published date after which no patches ship, full stop. Many vendors also run version-based support policies - only the current and previous major version (N-1), or the last two (N-2), are supported - so a version can drop out of support simply because two newer ones have shipped, without any specific announcement. For SaaS, EOL usually means shutdown: the service goes away entirely on the date, so the planning question is data export and migration, not patching. Good software asset management tracks version and support status, not just licence counts.

Hardware EOL is gradual. Firmware and driver support usually ends first, then vendor parts, then vendor service, and third-party maintenance and the secondary parts market typically stretch usable life several years past end of service life for common enterprise kit such as servers and networking equipment. The two interact: hardware is frequently forced into retirement because the operating system it needs has gone EOL first. The Windows 11 hardware requirements are the current example - a large number of otherwise sound laptops and desktops cannot upgrade from Windows 10 and are being retired for that reason alone. An asset can be physically sound and still be end of life - which is also why refurbishment helps with worn hardware but cannot rescue unsupported software.

Many assets have no published EOL date at all. Tools, furniture, beds, hoists, and most non-connected equipment never get a lifecycle bulletin. The practical proxies are the manufacturer’s recommended service life, whether spare parts and consumables are still available, and whether the item can still meet its mandated inspection or servicing schedule. For medical devices, the IMDRF legacy-device framework draws the line explicitly: EOL is the point at which the manufacturer no longer sells the product, and end of support (EOS) is when all service support ends - with responsibility for managing the device’s risk shifting further onto the healthcare provider at each step.

How to find and record EOL dates

The vendor’s own lifecycle page is authoritative and changes first. Most large vendors publish lifecycle or EOL bulletin pages listing end-of-sale and end-of-support dates per model and version, and issue product change notifications (PCN, PDN, or EOL notices) before each milestone - typically around six months before end of sale, with a last-time-buy window after it. Subscribing to those notices for the products you own is the cheapest early-warning system there is. For software, community aggregators such as endoflife.date collect release and support dates for hundreds of products in one place; similar aggregators exist for enterprise hardware. Treat them as a convenient index and confirm the date on the vendor page before acting on it.

The better habit is to ask before you buy. “How long will this be supported?” is a procurement question, and regulation is starting to force an answer: the EU Cyber Resilience Act requires manufacturers of products with digital elements to define and state a support period during which they will provide security updates - at least five years unless the product is expected to be used for less - with the main obligations applying from 11 December 2027. The UK’s PSTI regime already requires consumer connectable products to carry a published defined support period. Either way, the support period becomes a fact you can record at purchase rather than hunt for later.

Record it as separate fields, because they are separate things:

• Purchase date - when your unit was bought
• Warranty end - when the repair guarantee on your unit expires; see warranty tracking
• End of sale - when the model stops being sold new
• End of security support - when security patches stop; the date that matters most for software
• End of support / EOSL - the final vendor milestone
• Expected useful life - your own estimate, which drives replacement budgeting and depreciation
• Lifecycle status - supported, extended support, ESU, unsupported, retired

Warranty end and EOL are the most commonly confused pair. Warranty is about your unit and your purchase date; EOL is about the product line and the vendor’s roadmap. A product can reach EOL while your unit is still under warranty, and support can outlast the warranty by years.

Your options when an asset reaches EOL

There are five realistic responses, and a well-run register uses all of them:

1. Upgrade or migrate to the successor product or version. The default answer for anything internet-facing or business-critical.
2. Buy time with vendor extended support, paid extended security updates, or third-party maintenance for hardware. Legitimate as a bridge with a defined end date; expensive as a habit.
3. Isolate and harden. Segment the asset onto its own network, remove internet access, restrict accounts, disable unused services, and increase monitoring. Compensating controls of this kind are also how you take a device out of a certification scope.
4. Accept the risk formally. A documented, signed-off decision by someone with the authority to own the consequences, stating the justification, the compensating controls, and the replacement date. Undocumented acceptance is not acceptance; it is neglect with a delay.
5. Retire and decommission. Data sanitisation, removal from the network, licence recovery, and responsible disposal or resale - see asset decommissioning and IT asset disposition.

The prioritisation rule is simple: replace first whatever is internet-facing, holds sensitive data, is business-critical, or has no compensating control available. An unsupported office printer on a segregated VLAN can wait; an unsupported firewall or file server cannot.

Planning replacements around EOL

EOL planning is mostly a recording discipline: capture the relevant dates when the asset is purchased, hold them on the asset record, and periodically ask the register one question - what reaches end of support in the next 12 to 18 months? That is the lead time anything needing procurement, testing, and migration requires; vendors’ own notices arrive far later, typically around six months before end of sale, which is too late for anything but the simplest swap.

The output of that question is a staggered refresh rather than a series of surprises. Spread replacements across two or three budget cycles instead of letting a single date, such as an operating system’s end of support, force a fleet-wide purchase in one quarter. Tie the plan to the hardware refresh cycle already in place, so EOL dates shape the cycle rather than fight it, and treat post-EOL running costs - extended support fees, third-party maintenance, workarounds, and downtime - as part of the total cost of ownership when comparing “keep” against “replace”. It also gives time to plan decommissioning properly, with data wiped and documented, instead of in a rush.

EOL vs useful life, warranty, obsolete and legacy

The words around EOL are used loosely, and the differences matter on a register:

• End of life - a date declared by the vendor, applying to every owner of the product
• Useful life / economic life - the owner’s estimate of how long the asset stays worth running; also the depreciation horizon. See useful and economic life
• Physical life - how long the thing keeps working, regardless of anyone’s estimate or support
• Warranty end - the end of the repair guarantee on your unit; unrelated to support status
• Discontinued - production has stopped; support may continue for years
• Obsolete - the state after the final EOL milestone, when nothing more is available from the vendor
• Legacy - old but still in use; may or may not still be supported
• Deprecated / sunset - a software feature, API, or service that is being withdrawn, usually with a notice period before removal

Two consequences follow. A fully depreciated asset can still be in use and fully supported - accounting life and vendor life are independent. And an asset can be fully supported yet past its useful life, or past EOL yet nowhere near the end of its physical life. The register needs both sets of dates because they answer different questions: what the finance side charges, and what the security and operations side can safely run.

FAQ

What is the difference between EOL and EOS? End of sale (EOS) is when the vendor stops selling the product; support and updates usually continue for a while afterwards. End of support - also abbreviated EOS, confusingly - is when patches, parts, and help stop. Where end of life (EOL) sits depends on the vendor: software vendors often use it as the final milestone, while hardware vendors often place EOL at end of sale and call the final milestone end of service life (EOSL) or last date of support. Record the actual dates rather than relying on the labels.

Does a product stop working when it reaches end of life? No. Nothing switches off on the EOL date. What stops is the flow of security patches, firmware and driver updates, spare parts, and vendor help. The product keeps running, but every new vulnerability stays open, repairs get slower and dearer, and the risk transfers from the vendor to you. For anything connected to a network or holding data, running past EOL is a security decision that should be made deliberately, documented, and given a replacement date.

What is the difference between EOL, EOSL and end of sale? End of sale is the date the product can no longer be bought new. End of service life (EOSL), also called last date of support or last day of support, is the final milestone after which the vendor offers no support, patches, or service contracts at all. End of life is the ambiguous one: in enterprise hardware lifecycles it usually means the product has been retired from sale while service continues until EOSL, whereas in software it often means the same thing as end of support.

Is it safe to keep using Windows 10 after end of support? Not on an internet-connected device without extended security updates. Windows 10 reached end of support on 14 October 2025. Devices enrolled in Microsoft’s Extended Security Updates (ESU) programme keep receiving security fixes for a limited, paid or enrolled period; unenrolled devices get none. The options are to upgrade eligible hardware to Windows 11, enrol in ESU as a bridge while you migrate, replace PCs that fail the Windows 11 hardware requirements, or isolate the remaining devices from the network. Check Microsoft’s lifecycle page for the current ESU end dates, as they have been extended once already.

Can end-of-life software pass a compliance audit or Cyber Essentials? Generally not if it is in scope. Cyber Essentials treats unsupported software in scope as an automatic fail; PCI DSS 4.0.1 requires an annual review confirming components are vendor-supported, with an approved remediation plan for anything at EOL; ISO 27001 expects unsupported products to be identified and risk-treated. The accepted remedies are to upgrade, enrol in paid extended security updates, or segregate the device out of scope with documented compensating controls.

How far in advance should you plan for an asset’s end of life? Start 12 to 18 months before the end-of-support date for anything that needs procurement, testing, and migration - servers, network equipment, line-of-business software, and fleets of PCs. Vendors typically publish end-of-sale notices around six months before the date, so the lead time has to come from your own register, not from the vendor. Spreading replacements across two or three budget cycles avoids a single cliff.

Is end of life the same as end of warranty? No. A warranty is a repair-or-replace guarantee for a fixed period after purchase, and it is tied to your unit and your purchase date. End of life is a vendor-wide milestone tied to the product model or version. Support can outlast the warranty by years, and a product can reach EOL while your unit is still under warranty. Hold warranty end and EOL as separate fields on the asset record.

Can you keep using equipment after EOL? Physically, yes - nothing switches off on the EOL date. The risk is what no longer happens: software stops receiving security patches, hardware loses access to spare parts and firmware fixes, and failures take longer and cost more to resolve. For anything connected to a network or holding data, running past EOL is a security decision, and it should be made deliberately rather than by default.

How do you find a product’s EOL date? Most major vendors publish product lifecycle pages or EOL bulletins listing end-of-sale and end-of-support dates per model and version, and issue product change notifications before each milestone. Community aggregators such as endoflife.date collect software dates in one place. The reliable habit is to look the date up when the asset is purchased and record it on the asset record, alongside the warranty end. Where no date is published - common for simpler hardware - the practical proxy is parts availability and the end of any support contract.

The takeaway

End of life is a vendor’s date, not a switch. The product keeps running past it; what disappears is the patching, the parts, and the support that made running it reasonable, and with them the vendor’s share of the risk. Because vendors attach the EOL label to different points - end of sale for some, end of service life for others - the useful discipline is to hold the concrete dates on every asset record, separately from the warranty and the useful-life estimate, and to ask the register what reaches end of support in the next 12 to 18 months. From there the choices are the same every time: upgrade, buy time with extended support, isolate, accept the risk in writing, or retire. Any of those is a decision. Discovering an unsupported system during an audit or an incident is not.

Related terms

• Useful Life - your own estimate of an asset’s productive years, as opposed to the vendor’s EOL date
• Asset Decommissioning - the controlled retirement process EOL should trigger
• Asset Lifecycle - the full sequence from acquisition to disposal that EOL sits inside
• Hardware Refresh Cycle - the planned replacement rhythm EOL dates should feed
• Warranty Tracking - the repair-guarantee date that is often confused with EOL
• Data Sanitisation - wiping storage before an EOL asset leaves the building
• Zombie Asset - the unsupported, forgotten equipment that EOL planning is meant to prevent
• Refurbishment - a way to extend hardware life, when parts and support still exist
• Calibration - accuracy servicing that becomes impossible once vendor support ends
• Inspection Schedule - the recurring checks that often force the EOL decision on regulated equipment

Tools that make this easier

AMPthilly holds the dates EOL planning runs on directly on each asset record: purchase date, warranty start and end, expected useful life, and custom fields per asset type for the vendor milestones you choose to track, such as end of sale and end of support. Filters by warranty status, category, and status let you pull the list of what needs a decision this budget cycle, and CSV export hands finance the same data for the replacement plan. When an asset is retired, its status changes to retired and the full audit history - ownership, transfers, service desk tickets, and attached invoices - stays on the record for the auditor. Maintenance and financial fields sit on the Pro plan. Start free - no credit card required - or talk to us about your setup.