/eol-eos-flagging

name: "EOL/EOS Flagging"
description: >
  End-of-life versus end-of-support risk for devices, OS versions, and firmware:
  combining RMM inventory (make, model, OS version, firmware) with general
  lifecycle knowledge, the mandatory verify-against-vendor-lifecycle caveat, what
  qualifies as a finding versus merely "old", and criticality-first
  prioritization of the resulting risk list.
when_to_use: >-
  When identifying devices, OS versions, or firmware approaching or past
  end-of-life or end-of-support, or prioritizing that risk by device
  criticality. Use when: EOL risk, end of life devices, unsupported
  hardware, EOS flagging, is this OS still supported, end of support,
  unsupported OS, legacy hardware risk.

EOL/EOS Flagging

Overview

End-of-life and end-of-support are two related but distinct events. End-of-life (EOL) generally means the vendor has stopped selling or actively developing the product. End-of-support (EOS) — sometimes called end-of-extended-support — means the vendor stops shipping security patches. EOS is the harder deadline operationally: a device past EOS is accumulating unpatched vulnerabilities with no fix coming, regardless of whether it still "works." This skill flags both, keeps them distinct in the output, and prioritizes the resulting list by how much it actually matters if a given device is left running past its date.

This needs two ingredients: **device inventory data** (make, model, OS version, firmware version — pulled live from whatever RMM is connected) and **EOL/EOS knowledge** (which dates apply to which OS/hardware — general knowledge, not something the RMM exposes). The two must be combined explicitly, and the knowledge half must always carry a verification caveat, because vendor lifecycle dates do change (extended support gets purchased, timelines shift) and this skill's knowledge has a cutoff.

This is distinct from `warranty-tracking`: a device can be fully in warranty and past OS end-of-support (an aging laptop still under a 5-year warranty but running an OS version no longer patched), or out of warranty and still fully supported (an older desktop on a current, supported OS with no active vendor patching risk). Both signals feed `refresh-cycle-planning`, but they are not the same finding and should not be conflated in a report.

Anti-triggers

• **Unsupported software as a scored patch/CVE finding** — an out-of-support

OS surfaced with an EPSS score and exploit maturity is vulnerability management; use `sentinelone-vulnerabilities`.

• **A vendor's own end-of-life field** — Auvik and ScalePad both record

lifecycle/EOL data natively; use `auvik-devices` or `scalepad-lifecycle-manager` when the question is what that tool holds rather than how to rank the risk across a fleet.

Discovering available tools first

Never assume which RMM is connected:

1. Call `conduit__search_tools` with a query like `"list devices"`, `"device details"`, or `"OS version"` to discover which RMM connector(s) are live and their real tool names (e.g. `datto-rmm__datto_list_devices`, `ninjaone__list_devices`, `ncentral__ncentral_list_devices`, `atera__search_agents`). 2. Pull make/model, OS name and version, and firmware version where exposed — the fields vary by RMM, so check what a given platform's device-detail tool actually returns before assuming a field exists. 3. Cover all connected RMMs if more than one is present. 4. Only call concrete tools that discovery actually returned.

Key Concepts

General EOL/EOS knowledge — with a verification caveat

This skill can reason about EOL/EOS timing for widely-deployed operating systems and hardware families using general knowledge (e.g., major desktop and server OS release/support lifecycles, common consumer/business OS version end-of-support windows, well-known network hardware firmware support windows). Use that knowledge to flag likely-EOL/EOS devices found in inventory.

**Always attach an explicit caveat to any EOL/EOS date cited from general knowledge**: state that the date should be verified against the vendor's current lifecycle page before it's used to justify a purchase or a hard deadline in front of a client, because:

• Vendors extend, shorten, or restructure support timelines.
• Paid extended-support programs can push a real deadline later than the

"standard" EOS date.

• This skill's knowledge has a training cutoff and will not reflect

lifecycle policy changes announced after that point.

Never present an EOL/EOS date with false precision or as independently verified fact — frame it as "generally documented as EOL/EOS around [date/quarter] — confirm against the vendor's current lifecycle page before treating this as final."

What counts as an EOL/EOS finding

Flag a device when any of the following is true, and say which applies:

1. **OS past end-of-support** — the installed OS version no longer receives security patches from the vendor. 2. **OS approaching end-of-support** — within a lookahead window (default 6 months if not specified) of its end-of-support date. 3. **Hardware/firmware past or approaching EOL** — the device model itself, or its firmware, is past or nearing the vendor's stated end-of-life, independent of what OS it's running (relevant for network appliances, older server hardware).

Don't flag a device solely because it's "old" — flag it because a specific, named EOL/EOS date applies or is approaching. Vague "this looks legacy" judgments are not findings; a named date and source (general knowledge, caveated) is.

Prioritizing EOL risk by criticality

Not every EOL/EOS finding carries the same urgency. Combine the EOL/EOS signal with device role/criticality before ranking:

| Criticality | Examples | Why it matters more/less | |---|---|---| | High | Domain controllers, servers running production line-of-business apps, network appliances (firewalls, core switches), anything internet-facing | A patch gap here is