Free Software EOL Policy Template

[Company] Software End-of-Life (EOL) Management Policy

Version: [1.0] · Effective date: [DATE] · Policy owner: [ROLE/NAME] · Next review: [DATE + 1 year]

1. Purpose & Scope

1.1 Purpose

Software that no longer receives security updates from its maintainer cannot be patched, no matter how quickly [Company] responds to new vulnerabilities. This policy establishes how [Company] identifies software approaching or past its end of life, classifies the resulting risk, and remediates or formally accepts it — before the absence of patches becomes an incident.

1.2 Scope

This policy applies to all software components used in [Company] production and business-critical environments, regardless of where they run or who operates them, including:

• Operating systems (servers, workstations, mobile devices)
• Runtimes, language platforms, and frameworks
• Databases, message brokers, and middleware
• Network devices, firewalls, VPN concentrators, and other appliances (including their firmware)
• Hypervisors and virtualization platforms
• Container base images and orchestration platforms
• CI/CD infrastructure, build agents, and developer tooling
• Embedded, IoT, and operational technology (OT) systems
• Commercial software and self-hosted third-party applications

Out of scope: [e.g., software in fully isolated lab environments with no production data — define your exclusions explicitly rather than leaving them implicit].

2. Definitions

3. Roles & Responsibilities

One named individual must hold each role. Shared or unassigned ownership is the most common cause of EOL software going unnoticed.

4. Software Inventory Requirements

4.1 Coverage

[Company] maintains a software inventory covering every component in scope under Section 1.2. The inventory explicitly includes the categories that most often escape tracking:

• Vendor appliances — firewalls, load balancers, storage arrays, backup targets, and any "black box" device that runs an operating system [Company] does not directly manage
• CI/CD and build infrastructure — runner images, build agents, and pinned tool versions that outlive the projects that configured them
• Container base images — the FROM lines in every actively deployed image, not just the application layer
• Embedded and OT systems — devices whose software version changes rarely and is easy to treat as furniture
• Transitive platform dependencies — bundled components (e.g., an embedded database or TLS library inside a purchased product) where the vendor's product lifecycle, not the component's, governs patching

4.2 Minimum record

Each inventory entry records, at minimum:

• Product name and exact version/release in use
• Named asset owner (per Section 3)
• Environment(s) and business criticality
• Internet exposure (directly reachable from the internet: yes/no)
• EOL/EOS date, or "no published date" recorded explicitly
• Source of the lifecycle date and the date it was last verified (per Section 5)
• Current risk tier (per Section 6) and, where applicable, remediation plan or exception reference

4.3 Maintenance

The inventory is updated when systems are deployed, upgraded, or decommissioned, and reviewed on the cadence set in Section 11. Automated discovery and scanning [is/is not] used to detect unrecorded software; discrepancies between discovered and recorded software are treated as inventory defects and assigned to the asset owner.

5. Lifecycle Data & Verification

5.1 Source hierarchy

Lifecycle dates are recorded from the most authoritative available source, in this order:

1. The vendor's or maintainer's published lifecycle documentation — the authoritative source. In any conflict, the vendor's own page prevails.
2. Community-maintained or commercial lifecycle aggregators — services that track dates across many products (for example, the open endoflife.date dataset or endoflife.ai) — acceptable for day-to-day monitoring and for products whose vendor documentation is unclear, provided the source itself cites vendor documentation.
3. Indirect sources (press coverage, forum posts, support tickets) — usable only as a trigger to verify against a higher tier, never as the source of record.

5.2 Re-verification cadence

Recorded dates are re-verified against their source:

• [Monthly] for components classified Critical or High, or with EOL within [180] days
• [Quarterly] for all other components
• Immediately when a vendor announces a lifecycle change affecting a recorded product

5.3 Date drift

Vendors change published lifecycle dates — moving them earlier, later, or restructuring support phases — usually by editing the same page in place, without an announcement. A date recorded once and never re-checked must be treated as unverified. Every recorded date carries its source and verification date so that staleness is visible, not assumed away.

5.4 Products without published dates

Some maintainers publish no lifecycle dates at all. For these, the inventory records "no published date," and the asset owner applies the vendor's observed practice (e.g., "supports current release only") as a working assumption, documented as such. Absence of a date is a risk factor, not an exemption.

6. Risk Classification

Every in-scope component is assigned exactly one tier. Where multiple criteria match, the highest applicable tier applies.

Notes:

• A component under an active extended-support contract covering the deployed version is classified as if supported (Medium/Low by date of the extended support end), with the contract referenced in the inventory.
• Internet exposure is assessed per deployment, not per product — the same version can be Critical in a DMZ and High in a segmented internal network.
• KEV applicability is assessed against the deployed version, including vulnerabilities fixed only in versions the EOL line will never receive.

7. Remediation Standards

7.1 Remediation SLAs

The following service levels are defaults for [Company] to tailor; the structure (shorter deadlines for higher tiers, plans due before EOL) is the load-bearing part.

7.2 Acceptable remediation outcomes

Remediation means reaching one of these end states:

1. Upgrade to a supported version of the same product (prefer the LTS release with the longest remaining published runway, not merely the next version up)
2. Migrate to a supported alternative product
3. Decommission the system entirely
4. Extended support contracted for the deployed version, treated as a bridge with a defined end date — not a destination
5. Risk acceptance under Section 8, for the cases the above cannot reach

7.3 Planning principle

Upgrade cost rises and option count falls after EOL. Emergency migrations of unsupported systems are the most expensive and highest-risk change activity [Company] performs; the SLAs above exist to make them rare.

8. Exceptions & Risk Acceptance

An exception is a formal, documented decision to run software past EOL without full remediation. Exceptions are legitimate — some systems genuinely cannot be upgraded on schedule — but they are never implicit.

Every exception must be:

1. Written — using the form in Appendix B, stored in [the exception register]
2. Time-boxed — maximum duration [6 months]; renewal requires a new approval, not an extension
3. Compensated — naming specific, verified compensating controls (e.g., network isolation, removal of internet exposure, enhanced monitoring, virtual patching/WAF rules, restricted accounts), with the security team confirming the controls are actually in place
4. Signed — approved by the executive sponsor (Section 3), who thereby owns the residual risk; Critical-tier exceptions additionally require [CISO / CEO] sign-off
5. Reviewed — re-examined at every quarterly review (Appendix A); an expired exception is a policy violation, not a rollover

Exceptions are tracked in a register showing owner, expiry, and compensating controls, and the register is included in the [quarterly] report to [executive team / board].

9. Procurement & Development Gates

The cheapest EOL problem is the one not acquired. The gates below move lifecycle awareness to the point of selection.

9.1 Procurement gate

Before [Company] purchases or renews software, appliances, or devices, procurement records:

• The vendor's published lifecycle policy and dates for the product being bought — or, where none exists, a written support commitment (duration of security updates) in the contract
• Whether extended support is available past standard EOL, and on what terms
• The product's expected in-service life at [Company] versus the vendor's committed support window — a purchase whose support window is shorter than its intended service life requires [Policy owner] approval

Products from vendors that publish no lifecycle dates and will not commit to a support duration in contract require a documented risk assessment before purchase.

9.2 Development and build gates

• New systems start supported: new projects and services must be built on versions with a published support runway of at least [the expected time to next planned upgrade], preferring LTS releases.
• CI checks: build pipelines [should/must] include a check that flags runtimes, base images, and platform dependencies that are past EOL or within [90] days of it, using lifecycle data per Section 5. [Company] may use any tool or data source that implements this — free options exist, including CI actions built on the sources listed in Section 5.1.
• Container base images: deployed images must use base images whose underlying distribution release is supported; base image updates are part of routine dependency maintenance, not a special project.

10. Compliance Mapping

This policy supports [Company]'s obligations under the frameworks below. The mapping is informational — the frameworks' own texts govern. Rows that do not apply to [Company] may be deleted.

11. Review Cadence & Policy Maintenance

• Quarterly: inventory and classification review per Appendix A, led by [security team], with results reported to [Policy owner].
• Annually: full review of this policy by the [Policy owner], including SLA defaults, tier thresholds, and the compliance mapping (regulations change faster than policies — Section 10 in particular must be re-checked against current framework texts).
• On event: material vendor lifecycle changes, acquisition of new system categories, or a security incident involving EOL software trigger an out-of-cycle review of the affected sections.

Changes to this policy are versioned, dated, and approved by [approver]. The version history is maintained [below / in the policy register].

Appendix A: Quarterly EOL Review Checklist

• Inventory completeness: new systems deployed this quarter are recorded; decommissioned systems are removed
• Hiding-place sweep: appliances, CI/build infrastructure, container base images, and embedded/OT entries reviewed for coverage (Section 4.1)
• All recorded lifecycle dates re-verified within cadence (Section 5.2), verification dates updated
• Vendor lifecycle changes since last review identified and applied (date drift check, Section 5.3)
• Every past-EOL component classified Critical or High, with no unclassified stragglers
• CISA KEV catalog checked against past-EOL inventory entries; any match escalated to Critical
• Internet exposure flags spot-checked against actual network configuration
• Components entering the [90]-day Medium window identified; remediation plans initiated
• Remediation SLAs (Section 7): overdue items escalated to [Policy owner]
• Exception register reviewed: expired exceptions escalated, compensating controls re-verified (Section 8)
• Extended-support contracts checked for coverage of deployed versions and upcoming contract end dates
• Quarterly summary (posture, tier counts, overdue items, open exceptions) reported to [executive team / board]

Appendix B: Risk Acceptance Form