# End-of-Life Software Register: [Organisation name]

> Register of software, firmware and hardware platforms that are at or approaching end of life (EOL) or end of support (EOS): what is installed where, the vendor's support dates, the migration plan and date, interim mitigations, exceptions, and the support periods you promise for your own products. Based on NIST SP 800-40 Rev. 4, *Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology* (April 2022), which treats unsupported technology as a risk to plan for, and informed by dated legal examples: the EU Cyber Resilience Act (Regulation (EU) 2024/2847) support period rules, the UK product security regime for consumer connectable products, and CISA Binding Operational Directives 26-02 (end-of-support edge devices, February 2026) and 26-04 (risk-based security updates, June 2026) for US federal agencies. Replace every `[bracketed]` value and every row marked *Example*. The legal parts are a documentation format, not legal advice: check the current official text and a qualified professional.

<!--
Guidance: How to use this template
- Feed the register from the CMDB (`ops/cmdb-data-model`, class SWP with its end-of-support date attribute) and from the asset register, not from memory. Review it monthly and before every budget cycle.
- Record the vendor's dates with a link and the date you checked them. Vendors move dates; an unsourced date is a guess.
- Start migration planning at least [18] months before end of support for platforms, and earlier for anything embedded in products you ship.
- Related templates: Patch Management Policy (`ops/patch-management-policy`), Vulnerability Management Policy (`security/vulnerability-management-policy`), Versioning and Release Policy (`dev/versioning-release-policy`) for your own products' support periods, CRA Vulnerability Handling (`security/cra-vulnerability-handling`), SBOM and VEX Policy (`security/sbom-vex-policy`), Security Exception Request (`security/security-exception-request`), Change Request (`ops/change-request`), Technology Radar (`architecture/tech-radar`).
- Example organisation: Corvid Commerce, a fictional online retailer. Product versions in examples are generic. Delete every *Example* row before use.
-->

## Document control

<!-- Guidance: The register is a living record. Keep the review date current; auditors and insurers often ask for it. -->

| Field | Value |
|---|---|
| Document ID | [REG-EOL] |
| Version | [1.0] |
| Status | [Draft / Active] |
| Owner | [@asset-manager] |
| Approvers/reviewers | [@ciso], [@head-of-infrastructure], [@product-security-lead] |
| Review cadence | [Monthly], plus before each budget cycle |
| Last reviewed | YYYY-MM-DD |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Register created from CMDB export |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved; edge devices separated into their own view |

## 1. Definitions and rating

<!-- Guidance: Vendors use these terms differently. Write down how you map each vendor's terms to yours, and rate every entry by the time left to end of security fixes, because that is what drives risk. -->

| Term | Meaning in this register |
|---|---|
| End of sale | Vendor stops selling; support continues |
| End of standard support | Vendor stops feature and non-security fixes |
| End of security support (EOS) | Vendor stops security fixes; this date drives the rating |
| Extended support | Paid or contractual extension of security fixes, with its own end date |
| End of life (EOL) | No support of any kind |

| Rating | Rule *(Example)* | Action |
|---|---|---|
| Red | Past EOS, or EOS within 6 months and no funded migration that completes before EOS | Exception required (section 4) and monthly report to the CISO |
| Amber | EOS within 18 months and not Red | Migration plan with funded date |
| Green | EOS more than 18 months away, or migration complete | Monitor |

## 2. Register

<!-- Guidance: One row per product version and environment group, not per host; the CMDB holds the host list. Questions: does the row cover every install, including disaster recovery and build images? Pitfall: tracking only operating systems and missing runtimes, libraries, firmware and appliances. -->

| ID | Product and version | Type | CIs and count | Service(s) | EOS date (source, checked) | Rating | Migration target | Migration date | Change | Owner |
|---|---|---|---|---|---|---|---|---|---|---|
| EOL-001 *(Example)* | Database engine 15 | Database | CI-DB-0012 and 2 replicas | Online checkout, orders | YYYY-MM-DD (vendor policy page, checked 2026-10-01) | Green, migrated | Engine 16 | Done 2026-09 | CR-NNNN | [@dba-lead] |
| EOL-002 *(Example)* | Server operating system, release N-2 | Operating system | 14 hosts, reporting zone | Reporting | 2026-12-31 (vendor lifecycle page, checked 2026-10-01) | Red | Release N | 2027-02-28 | CR-2302 | [@infra-lead] |
| EOL-003 *(Example)* | Store VPN appliance, model X | Edge device firmware | 46 store devices | Store connectivity | Past EOS since 2026-06-30 | Red | New appliance model | 2027-01-31 | CR-2288 | [@network-lead] |
| EOL-004 *(Example)* | Application runtime, major version N | Runtime | 6 applications | Internal tools | 2027-04-30 (project release schedule, checked 2026-10-01) | Amber | Version N+2 | 2027-03-31 | Planned | [@platform-lead] |
| EOL-005 *(Example)* | Open source web framework 2.x | Library | 3 applications (from SBOM) | Marketing site | Maintainers ended 2.x security fixes YYYY-MM-DD | Red | Framework 3.x | 2026-12-15 | CR-2295 | [@web-lead] |
| [EOL-] | [Product and version] | [Type] | [CIs] | [Services] | YYYY-MM-DD ([source], checked YYYY-MM-DD) | [Rating] | [Target] | YYYY-MM-DD | [CR-] | [@name] |

Summary *(Example)*: 5 entries; 3 Red, 1 Amber, 1 Green. Red entries cover 63 CIs and instances (14 hosts, 46 devices, 3 applications).

## 3. Interim mitigations

<!-- Guidance: NIST SP 800-40 Rev. 4 treats software that can no longer be patched as a case that needs its own risk response: mitigate, transfer, avoid or accept. Record the mitigation per Red entry and test that it works. -->

| Entry | Mitigation *(Example)* | Verified by and date |
|---|---|---|
| EOL-002 | Hosts moved to an isolated network segment, inbound access only from the reporting jump host, extended support purchased until 2027-03-31 | [@security-engineer], YYYY-MM-DD |
| EOL-003 | Management interface removed from the internet, remote access limited to the managed provider address range, enhanced logging to the security monitoring service | [@network-lead], YYYY-MM-DD |
| EOL-005 | Web application firewall rules for known framework issues, dependency monitoring alerts on new advisories | [@web-lead], YYYY-MM-DD |

## 4. Exceptions

<!-- Guidance: Running unsupported software is a risk decision, made by someone with the authority to accept it, for a limited time. Use the Security Exception Request (`security/security-exception-request`) and link it here. -->

| Exception ID | Entry | Reason | Compensating controls | Approved by | Expires |
|---|---|---|---|---|---|
| EXC-EOL-001 *(Example)* | EOL-003 | Replacement hardware delivery slots for 46 stores run to January 2027 | Section 3 mitigations | [CISO] | 2027-01-31 |
| [EXC-] | [EOL-] | [Reason] | [Controls] | [@name] | YYYY-MM-DD |

## 5. Legal and regulatory examples (dated)

<!-- Guidance: These rules apply only to the organisations and products they name. Confirm whether they apply to you with a qualified professional, and check the current official text before relying on any date. Checked 2026-10-30. -->

| Jurisdiction | Rule | What it asks, in short | Relevance to this register |
|---|---|---|---|
| EU | Cyber Resilience Act, Regulation (EU) 2024/2847, Article 13(8) and related provisions; in force 10 December 2024, reporting obligations from 11 September 2026, main obligations from 11 December 2027 | Manufacturers of products with digital elements set a support period reflecting expected use time, generally at least five years (shorter only where the product is expected to be used for less), handle vulnerabilities throughout it, and state the end date of support clearly at the time of purchase | Record the support period you promise for each product you ship (section 6), and the support periods of third-party components you rely on |
| UK | Product Security and Telecommunications Infrastructure (Security Requirements for Relevant Connectable Products) Regulations 2023, in effect since 29 April 2024 | Manufacturers of consumer connectable products publish the minimum length of time security updates will be provided, with an end date, in clear terms | Same as above for consumer connectable products sold in the UK |
| US (federal agencies) | CISA BOD 26-02, Mitigating Risk From End-of-Support Edge Devices, issued 5 February 2026 | Federal civilian agencies inventory devices on CISA's end-of-support edge device list within 3 months; by 12 months decommission listed devices already past support and inventory edge devices that are, or within 12 months will be, end of support; decommission identified devices by 18 months; set up continuous discovery within 24 months | Use the edge device view (`Type` = edge device) as the inventory; contractors are affected only where a contract requires it |
| US (federal agencies) | CISA BOD 26-04, Prioritizing Security Updates Based on Risk, issued 10 June 2026 | Some vulnerabilities may be remediated at the next scheduled major upgrade or rebuild, unless conditions change, for example the vulnerability is added to the Known Exploited Vulnerabilities catalog | Record the planned upgrade date as the remediation date for such deferrals and re-rate when conditions change |

Official texts: EUR-Lex for Regulation (EU) 2024/2847 (https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng); GOV.UK guidance on the UK product security regime (https://www.gov.uk/government/publications/the-uk-product-security-and-telecommunications-infrastructure-product-security-regime); CISA directives at https://www.cisa.gov/news-events/directives.

## 6. Support periods for our own products

<!-- Guidance: Complete this section if you ship software or connected products. The support periods you promise depend on the end-of-support dates of what you build on: check that no core component ends support before your promise does. -->

| Product | Support period end (month and year) | Published where | Core components and their EOS | Gap? |
|---|---|---|---|---|
| Corvid Edge Agent 3.x *(Example)* | [Month YYYY] | Product page and release notes | Application runtime version N+2, EOS [YYYY-MM-DD]; embedded database library, EOS [YYYY-MM-DD] | [Yes: runtime ends support before our promise; upgrade path planned in release 3.4] |
| [Product] | [Month YYYY] | [Location] | [Components and dates] | [Yes / No] |

Detail of support tiers and long-term support trains is owned by the Versioning and Release Policy (`dev/versioning-release-policy`).

## 7. Metrics and review

<!-- Guidance: Report a few numbers monthly, in the Service Review Report (`ops/service-review-report`) or the security metrics report. -->

| ID | Measure | Formula | Target *(Example)* |
|---|---|---|---|
| EOL-M01 | End-of-support exposure | CIs past EOS / CIs in scope | Below 1%, excluding approved exceptions |
| EOL-M02 | Red entries without an approved exception | Count | 0 |
| EOL-M03 | Migration plans on schedule | Amber and Red entries on schedule / Amber and Red entries | 90% |
| EOL-M04 | Source freshness | Entries with dates checked in the last 90 days / entries | 100% |

## Standard and licence note

Based on NIST SP 800-40 Rev. 4, *Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology* (April 2022, https://csrc.nist.gov/pubs/sp/800/40/r4/final), a US Government work, and on the public texts named in section 5: Regulation (EU) 2024/2847, the UK product security regime guidance, and CISA BOD 26-02 and BOD 26-04. Rules are summarised in original words with dates checked on 2026-10-30; no table or long passage is copied. Ratings, thresholds, targets and examples are illustrative and not normative. This register is not legal advice: check the current official text and a qualified professional before relying on any legal date or duty. All text is original, written for this collection. Template licence: MIT.