Checking an operating system's support lifecycle before automating against it

Goal

Before an agent automates patching, upgrades or a compliance check against a host, confirm the host's operating system version is still within its vendor support window, and flag it clearly if not.

Prerequisites

Ability to identify the OS and version (see the companion article on detecting the OS from a script) and network access to the vendor's published lifecycle page, or a locally cached copy of the relevant dates.

Steps

1. Identify the OS family and exact version/release first (distribution name, major version, and for point-release trackers, the minor version too).
2. Look up the vendor's own lifecycle statement, not a third party, as the primary source:
   • RHEL: Red Hat's package update and errata support policy page states each major release's phases and their durations.
   • Ubuntu: Ubuntu's release cycle page distinguishes standard releases (9 months) from LTS releases (5 years standard, extendable).
   • Debian: the stable releases page states which release is current and tracks the point where a release stops receiving updates; the separate Debian LTS project extends security support further for some architectures.
   • Windows / Windows Server: the Microsoft Lifecycle Policy site gives fixed and modern lifecycle dates per product and servicing channel.
   • AIX: IBM's support pages publish AIX Technology Level (TL) support lifecycle dates.
   • FreeBSD: the Security Information page lists which branches currently receive security patches.
   • macOS: Apple does not publish a fixed end-of-life schedule; in practice, Apple typically ships security updates for the current release and the two previous ones — the older two often receive only part of the fixes — tracked by third-party aggregators such as endoflife.date rather than an official calendar.
3. Compare the host's version against the dates found; treat "unable to determine, no published date found" as equivalent to "flag for review", not as "assume supported".
4. Record the check's date, the source consulted, and the resulting status (supported / approaching end-of-life / past end-of-life) alongside the host's inventory record.
5. For a host past end-of-life, stop automated patch/compliance workflows from reporting a clean bill of health for that host; surface it as a finding requiring a decision (upgrade, replace, or accept documented risk) instead.

Expected result

Every host in scope has a recorded, dated lifecycle status with a named source; hosts past end-of-life are visibly flagged rather than silently included in "all patched" summaries.

Limits and test basis

Vendor lifecycle pages change; a cached date should be re-verified periodically rather than treated as permanent. Apple's absence of a published EOL policy means the macOS status is inherently an inference, not a documented fact, and should be labelled as such in any report. This methodology does not determine whether an EOL host is currently exploited — only that it will stop receiving fixes, which is a distinct and prior question automation should not skip.