Technology End of Life Policy Template: Retire Unsupported Software and Hardware on Time

Unsupported technology stays in production because nobody tracked the vendor's end of support date, nobody budgeted for replacement, and the risk acceptance signed three years ago was never revisited. This template gives you numbered policy statements for lifecycle tracking, notice periods, procurement, extended support, risk acceptance, compensating controls and secure disposal of hardware and software that has reached end of life. It draws on NCSC guidance on obsolete products, the Microsoft lifecycle and Extended Security Updates terms as a worked example, NIST SP 800-53 control SA-22 Unsupported System Components and NIST SP 800-88 Rev. 2 for disposal, and it maps to ISO/IEC 27001:2022 and NIST CSF 2.0. It is written for security, IT and risk leaders who need a policy they can adopt and defend. For technical options on operating systems, such as extended support programmes and upgrade paths, read the Operating System End of Life and Extended Support Guide; this page is the policy document.

How to use this template

• Replace text in square brackets, such as [Organisation], [Technology Lifecycle Owner] and [18 months], with your own roles and values. Bracketed values are illustrative starting points, not regulatory requirements.
• "Must" is mandatory; "should" is recommended practice where a documented deviation is acceptable.
• "End of life" (EOL) in this policy means the date after which the supplier no longer provides security updates for a product version under its standard terms, whatever the supplier calls it (end of support, end of servicing, end of extended support). End of sale or end of mainstream support are planning milestones, not the deadline.
• Keep the lifecycle register and replacement roadmap as separate living documents; this policy sets the rules they follow.
• Use this policy with the Patch Management Policy Template, the Asset Management Policy Template and the Data Retention and Disposal Policy Template.

Lifecycle milestones and required actions

1. Purpose

This policy sets the requirements for tracking, planning and executing the retirement of hardware, software and services before they stop receiving security updates, and for controlling the risk of any technology that remains in use beyond that point. NCSC guidance is clear that stopping use is the only fully effective fix for obsolete products; this policy makes that the default, in line with [Organisation]'s [Information Security Policy].

2. Scope

This policy applies to all technology owned, leased, managed or used by or for [Organisation], including:

• Operating systems, hypervisors, databases, middleware, language runtimes and frameworks (for example PHP, Java, .NET and Python versions), and third-party libraries.
• Commercial and open source applications, browser plug-ins and desktop software.
• Servers, end-user devices, mobile devices, printers and peripherals.
• Network and security appliances: firewalls, VPN gateways, routers, switches, wireless controllers and load balancers, including firmware.
• Operational technology, IoT and medical or laboratory devices, subject to section 4.7.
• Cloud services, SaaS features and APIs that the provider announces for retirement.
• Technology operated by suppliers that connects to [Organisation]'s networks or processes its data.

3. Roles and responsibilities

4. Policy statements

4.1 Lifecycle register

• Every in-scope asset must be recorded in [CMDB / asset inventory] with product, version, owner, business criticality and the supplier's EOL date.
• Software versions must be discovered automatically (endpoint management, authenticated scanning, software composition analysis for libraries) so that the register reflects what is actually running, not what was purchased.
• [Technology Lifecycle Owner] must monitor supplier lifecycle pages and announcements at least [monthly] and update EOL dates within [10 working days] of a change.
• Assets with no known EOL date must be flagged and the supplier contacted; unsupported open source projects (no maintained release line) count as EOL.

4.2 Procurement and standards

• Before purchase, the remaining support life of a product must be checked. Products for critical uses must have at least [3 years] of security update support remaining at purchase.
• Contracts must require the supplier to publish EOL dates, give at least [12 months'] notice of end of support, and supply security updates for the full support period.
• [Enterprise architecture] must publish approved versions and must not approve new deployments of versions within [12 months] of EOL.
• SaaS or managed services should be preferred where they remove the need for [Organisation] to keep versions current, as NCSC suggests.

4.3 Notice and planning

• Notices must be issued to owners at each milestone in the lifecycle table. Each notice must name the affected assets, the EOL date and the required action.
• Replacement plans must include the migration approach, dependencies (applications that require the old version), test plan, rollback, funding and target completion date at least [3 months] before EOL.
• Dependencies that block upgrade, such as a business application certified only on an old platform, must be raised with the application owner and supplier at the [24-month] milestone, not at the deadline.

4.4 Extended support

• Paid extended support may be used only as a time-limited bridge to complete an approved migration, not as a long-term substitute. NCSC describes paid extended support as a stopgap.
• Extended support must be approved by [CISO] and [Finance], cover the full period the asset will remain, and be confirmed to include security updates for the affected product. For example, Microsoft's Windows 10 Extended Security Updates are bought one year at a time for a maximum of three years, cover critical and important security updates only, and exclude new features and general technical support.
• Assets under extended support must still be patched within the [Patch Management Policy] timelines.
• Extended support must not extend beyond [the supplier's final available date or 3 years], after which the asset must be retired or handled under section 4.5.

4.5 Risk acceptance for EOL assets

• Any asset that will run past EOL without supplier security updates requires a risk acceptance before the EOL date, requested by the asset owner and recorded in [risk register].
• The request must state the business reason, affected assets, data processed, exposure, compensating controls under section 4.6, replacement date and cost of replacement compared with the cost of continued risk.
• Approval levels: [CISO] for internal, non-critical assets; [CISO and executive sponsor] for assets that are internet-facing, process [Confidential] data or support critical services.
• Risk acceptances must expire after no more than [6 months] and be re-approved, not rolled over, with evidence of progress on replacement.
• Internet-facing EOL assets, including edge devices such as firewalls and VPN gateways, must not be accepted beyond [30 days] past EOL. See the Edge Device End of Life Replacement Playbook.

4.6 Compensating controls

EOL assets kept under risk acceptance must have, as a minimum, the controls below, enforced technically rather than by policy alone:

• Isolation: placed in a separate network zone with allow-listed traffic flows; no direct internet access, email or web browsing; removable media blocked.
• Reduced function: non-essential services, protocols and accounts disabled; required services moved to supported platforms where possible.
• Access: administrative access only through [privileged access workstation / PAM]; no shared or default credentials; service accounts and stored secrets on the asset inventoried, scoped and rotated, since an unpatched host is a likely place for credential theft. See the Privileged Access Management Policy Template.
• Monitoring: enhanced logging forwarded to [SIEM] with specific alerts, and fast response to events, because older systems are harder to monitor and exploitation is more likely.
• Recovery: tested backups or a rebuild image, and periodic re-imaging where practical.

4.7 OT, medical and embedded systems

• Where safety certification, regulation or supplier validation prevents upgrade, the asset owner must document this in the risk acceptance, agree the replacement point with the manufacturer, and apply the controls in section 4.6 with operations engineering.
• Replacement of long-lived OT systems must be included in capital plans at least [5 years] ahead of the expected EOL.

4.8 Retirement and disposal

• Retirement must follow the [Change Management Policy] and include removing the asset from DNS, directory services, monitoring, backups and the network, and disabling or deleting its accounts, certificates and API credentials.
• Storage media must be sanitised before reuse, resale or disposal using methods appropriate to data sensitivity, following NIST SP 800-88 Rev. 2, with a certificate of sanitisation or destruction retained for [7 years]. See the Media Sanitisation Guide.
• Disposal suppliers must be approved under [Supplier Security Policy] and provide chain of custody records.
• Licences, support contracts and the lifecycle register must be updated within [10 working days] of retirement.

4.9 Suppliers

• Suppliers that connect to [Organisation] networks or process its data must not use EOL technology for those services. This must be a contract term and checked during supplier assurance reviews.

5. Exceptions

All exceptions to this policy are handled through the risk acceptance process in section 4.5. No exception may be granted for internet-facing EOL assets without compensating controls. See the Security Exceptions and Risk Acceptance Guide.

6. Compliance and monitoring

Compliance will be checked by [internal audit]. Unapproved EOL assets may be disconnected by [Security operations].

7. Review and approval

• Policy owner: [CISO]. Approved by: [risk committee / executive board] on [date].
• Review at least annually, and after any incident involving an EOL asset or a major supplier lifecycle change.
• Version history: [version], [date], [summary of change], [approver].
• Related documents: [Information Security Policy], [Asset Management Policy], [Patch Management Policy], [Change Management Policy], [Data Retention and Disposal Policy], [Supplier Security Policy].

Implementation guidance

Rolling out the policy

1. Build the baseline: export software and hardware versions from endpoint management, scanners and cloud inventories, match them to supplier EOL dates, and report how many assets are already past EOL or due within 18 months. See the Asset Inventory and CMDB Security Guide.
2. Triage the past-EOL list: internet-facing and critical first. Each one needs a dated retirement, an extended support contract or a risk acceptance with isolation within [90 days] of policy approval.
3. Tie it to budget: give [Finance] a three-year replacement forecast from the register, so replacement is funded before notices start arriving.
4. Change procurement: add support lifetime checks and contract terms before the next renewal cycle.
5. Test isolation controls on one accepted EOL asset with a penetration test or attack simulation, then apply the pattern to others.

Decisions for small and large organisations

• Small organisations: keep the register in your endpoint management tool, follow major supplier dates (operating systems, office suites, firewalls), and replace rather than accept: isolation is hard to do well without a dedicated team.
• Large organisations: automate EOL matching for libraries and runtimes as well as operating systems, publish a rolling roadmap, and report EOL exposure to the board alongside vulnerability metrics.
• Upgrade, extend, isolate or retire: upgrade where the application supports it; extend only for a bounded migration; isolate only where a hard dependency exists; retire where the business value no longer justifies the cost.

Common failure patterns

• Tracking operating systems only: runtimes, frameworks, firmware and libraries reach EOL silently. See Unsupported PHP versions.
• Extended support as a plan: paid updates are bought year after year with no migration funded.
• Isolation on paper: the accepted asset still browses the web or shares admin credentials with supported systems.
• Edge devices forgotten: firewalls and VPN appliances run past end of support because they are owned by the network team and outside the patch tool. Federal agencies in the US now face CISA direction on end-of-support edge devices; see the CISA Binding Operational Directives Guide.
• Disposal without sanitisation: retired drives and devices leave with data and stored credentials still on them.

Framework mapping

Sources: NCSC: Obsolete products, Microsoft: Fixed Lifecycle Policy, Microsoft: Extended Security Updates for Windows 10, NIST: SP 800-88 Rev. 2 Guidelines for Media Sanitization and NIST: SP 800-53 Rev. 5 (SA-22 Unsupported System Components). For a worked example see the Windows 10 End of Life guide.

This template is provided for guidance and must be adapted to your organisation. It is not legal advice. Related NHI Mgmt Group resources: Operating System End of Life and Extended Support Guide · Legacy Application Security · Patch Management Policy Template · Vulnerability Management Policy Template