Detecting end-of-life software through inventory and support lifecycle checks

At a glance

What this is: This post explains how combining endpoint inventory with support-lifecycle data helps detect end-of-life software before unsupported versions become exploitable exposure.

Why it matters: It matters to IAM and security practitioners because unsupported software expands the attack surface, weakens control assurance, and can hide behind incomplete asset visibility across managed endpoints.

By the numbers:

• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.
• 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits.

👉 Read Wazuh's blog post on detecting end-of-life software with inventory and lifecycle data

Context

End-of-life software creates a support gap: the vendor stops issuing regular security updates, but the software often remains in production. In practice, that turns patch management into an asset-visibility problem because teams cannot protect what they cannot reliably identify across endpoints and workloads.

The identity angle is indirect but real. EOL software often coexists with service accounts, tokens, and automated workloads that depend on it, so stale software can become a hidden control failure inside broader IAM and NHI programmes. This is a common enterprise condition, not an edge case.

One practical reason this problem persists is that support lifecycles differ by product and version, making manual tracking brittle at scale. A central inventory with lifecycle awareness is therefore more useful than ad hoc spreadsheet-based review.

Key questions

Q: What breaks when end-of-life software is still in production?

A: Unsupported software breaks the normal security lifecycle because it no longer receives patches, compatibility fixes, or vendor-backed remediation. That means known flaws can remain exploitable indefinitely, and hidden dependencies or forgotten deployments often persist beyond the organisation’s awareness. The result is a predictable attack surface that grows harder to govern the longer it stays live.

Q: Why do unsupported packages create more risk than normal vulnerable software?

A: A vulnerable but supported package can usually be patched, replaced, or temporarily mitigated with vendor guidance. Unsupported software removes that option. Security teams must then rely on compensating controls while running code that no longer receives regular fixes, which increases the chance of persistent exposure and delayed recovery.

Q: How can security teams tell whether EOL monitoring is actually working?

A: Look for complete endpoint coverage, accurate version mapping, and a low number of unidentified packages. If lifecycle checks only catch obvious operating systems but miss packages, the monitoring is incomplete. A working process should also show clear prioritisation by age past EOL and a visible remediation owner for each finding.

Q: Who should own remediation when a malicious dependency is discovered?

A: Ownership should sit with the development team that introduced the dependency, with AppSec and SOC providing detection, validation, and closure checks. That division matters because the fix usually requires dependency updates, lockfile regeneration, and redeployment. Security should verify the change, but the application owner must make it happen.

Technical breakdown

How endpoint inventory exposes unsupported software

The detection model starts with software inventory. A syscollector-style agent gathers package and operating system data from endpoints, then normalises product names and versions so they can be matched against lifecycle sources. That matters because EOL status is version-specific, not product-wide. A platform may have one supported release and several unsupported ones at the same time. Once inventory is centralised, the lifecycle check can compare installed versions against known release cycles and identify where support has already ended.

Practical implication: build a single, queryable asset inventory before trying to judge EOL exposure.

How lifecycle APIs turn version data into risk signals

A lifecycle API adds the missing context by mapping a package or OS release to published support dates, latest versions, and end-of-life status. The control value comes from correlation, not from the API alone. If the installed version maps to a cycle whose EOL date is in the past, the software is no longer receiving vendor security fixes. That is the point at which vulnerability management becomes a governance issue, because the organisation is choosing to run unsupported code.

Practical implication: connect inventory data to lifecycle metadata so support status is evaluated continuously, not manually.

Why severity should reflect days past end of life

Time since EOL is a useful severity signal because exposure compounds after support ends. A system that crossed EOL yesterday and one that crossed EOL two years ago are not equivalent, even if both are unsupported. Using days past EOL to grade alerts gives security teams a prioritisation layer that is more actionable than a binary supported or unsupported flag. It also helps separate remediation urgency from simple detection volume, which matters in large estates with many stale packages.

Practical implication: use age past EOL to prioritise upgrade queues and escalation thresholds.

Threat narrative

Attacker objective: The attacker wants durable access to weakly defended systems that can be exploited with less effort than current, patched software.

1. Entry occurs when attackers target systems running unsupported software because the vendor no longer patches newly discovered vulnerabilities.
2. Escalation follows when known flaws remain exploitable long after disclosure, especially on internet-facing appliances and legacy endpoints.
3. Impact is achieved through malware deployment, ransomware, or backdoor persistence on systems that cannot be safely patched back into a supported state.

NHI Mgmt Group analysis

EOL software is an identity governance problem when services, tokens, and workloads depend on it. Unsupported software rarely exists in isolation. It usually anchors authentication flows, scheduled jobs, and service integrations that continue to run after support ends. That makes lifecycle visibility a dependency for IAM and NHI governance, not just for vulnerability management. Practitioners should treat unsupported software as a control failure with downstream identity consequences.

Asset inventory without lifecycle context produces false confidence. Many teams can list endpoints, but far fewer can tell which installed packages are already outside vendor support. That gap is where exposure accumulates, because patch coverage, exception handling, and risk acceptance all depend on knowing the support state of what is deployed. The practical conclusion is that inventory must be lifecycle-aware to be operationally useful.

Lifecycle drift is the named concept this article exposes. Lifecycle drift: the gap between what is installed in production and what the vendor still supports. This drift is especially dangerous in distributed estates where endpoints age unevenly and ownership is fragmented. When lifecycle drift is unmanaged, remediation becomes reactive and attackers gain time to exploit known weaknesses. Practitioners should measure and reduce drift as a first-class governance metric.

Severity should reflect support status, not just vulnerability count. A long list of CVEs tells only part of the story if the underlying product is out of support. Unsupported software changes the equation because even routine remediation may no longer be available. That means security operations, patch management, and service ownership need a shared escalation path for EOL findings. Practitioners should route EOL alerts as upgrade imperatives, not informational hygiene.

What this signals

Lifecycle drift will become a more visible control metric as inventory platforms, patch tools, and lifecycle databases are increasingly combined. Teams that can correlate installed software, support status, and ownership will reduce both exposure and debate over which upgrades are truly urgent.

For identity programmes, the hidden issue is dependency management. Legacy services often retain service accounts, tokens, and automation hooks that outlive the software they authenticate to, so EOL remediation should be coordinated with access review and credential replacement.

A useful programme signal is the ratio of identified EOL assets to assets with named owners. When that ratio stays high, patching is being treated as a technical task rather than a governed lifecycle process, and risk will continue to accumulate.

For practitioners

• Map installed software against support lifecycles Join endpoint inventory with a lifecycle source such as endoflife.date so every detected package and OS release is checked against a current support timeline. Prioritise products whose release cycle no longer receives vendor security updates.
• Escalate unsupported software by days past EOL Assign higher response priority as the EOL age increases, because older unsupported releases are more likely to be targeted and harder to remediate safely. Use the age signal to separate urgent upgrades from routine patch queues.
• Tie EOL findings to service ownership and exception handling Require every unsupported product to have an owner, a remediation date, and a documented exception if it must remain temporarily in use. This prevents EOL exposure from being lost inside generic vulnerability backlogs.
• Review identity dependencies on legacy platforms Identify service accounts, API integrations, and scheduled jobs that rely on EOL software so the upgrade plan includes credential changes and access testing, not just package replacement.

Key takeaways

• Unsupported software becomes a governance problem as soon as vendor patches stop.
• Visibility into installed versions and support timelines is the control that turns EOL risk into actionable remediation.
• Identity-dependent services on legacy platforms require lifecycle fixes, not just package upgrades.

Key terms

• End-of-life software: Software that no longer receives upstream security fixes, compatibility updates, or vendor support. In security governance terms, EOL status means the organisation owns every remaining patching, compatibility, and risk decision, including how dependencies and access paths are controlled.
• Lifecycle-Aware Inventory: An asset inventory that records not just what is installed, but whether each package or operating system release is still supported. This lets teams link software discovery to remediation urgency, ownership, and exposure duration instead of treating all installed software the same.
• Days Past End Of Life: A severity measure that shows how long a product has been unsupported after its vendor support date passed. It is useful because older unsupported releases generally have a larger attack window, less reliable remediation options, and a stronger case for immediate upgrade or replacement.
• Lifecycle Drift: Lifecycle drift is the gap between the intended state of an identity and the access that remains active in systems after the business context changes. It often appears as delayed revocation, stale privileges, or unowned credentials, and it is a practical indicator that governance is out of sync.

What's in the full article

Wazuh's full blog post covers the implementation detail this post intentionally leaves for the source:

• The full Python detector script for correlating endpoint inventory with endoflife.date support timelines
• The Wazuh rule logic that grades EOL findings by days past end of life and maps them to alert levels
• The exact server-side configuration steps for logging, scheduling, and custom rule deployment
• The dashboard search pattern used to surface EOL events in the threat hunting workflow

👉 Wazuh's full post includes the detector workflow, rule configuration, and dashboard steps for EOL alerting.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in practical operational terms. It helps security and identity practitioners connect lifecycle control with access risk across modern environments.