Notifications
Clear all
Topic starter
18/08/2026 2:19 pm
TL;DR: Unsupported software across managed hosts can be surfaced by combining endpoint inventory with the endoflife.date API, turning support-lifecycle data into severity-based alerts for EOL packages and operating systems, according to Wazuh. The operational value is visibility into where patching has already stopped, because unsupported software becomes a governance problem before it becomes a breach.
NHIMG editorial — based on content published by Wazuh: detecting end-of-life software with inventory and lifecycle data
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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
👉 Read Wazuh's blog post on detecting end-of-life software with inventory and lifecycle data →
End-of-life software detection: what security teams should monitor now?
Explore further
18/08/2026 3:11 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Detecting end-of-life software through inventory and support lifecycle checks
