Where the data comes from, how it's verified, how often it's updated, and what we don't cover. Transparency is the foundation of a trustworthy reference.
Every lifecycle date on endoflife.ai is sourced directly from official vendor documentation. We do not rely on third-party aggregators, community wikis, or scraped data as primary sources. When a vendor publishes an end-of-life date, that date is our source of truth.
For products maintained by open-source foundations, we reference the official project lifecycle pages published by the maintaining organization — the Python Software Foundation, the OpenJS Foundation, the PHP Group, and so on.
Microsoft, Oracle, Red Hat, Canonical, Apple, Cisco, HPE, Dell, and other vendors publish official product lifecycle documentation. These pages are the primary source for all commercial product dates.
The PSF, OpenJS Foundation, PHP Group, Ruby core team, Django project, and other foundations publish official lifecycle schedules. These are authoritative for their respective ecosystems.
The community-maintained endoflife.date project provides a structured, machine-readable database of EOL dates verified against primary sources. We reference this as a cross-check for coverage and accuracy.
endoflife.date →CVE data and CVSS scores referenced in our security analysis content are sourced from the NVD. CISA's Known Exploited Vulnerabilities catalog is used for active exploitation status.
nvd.nist.gov →Not all vendors use the same terminology. "End of life," "end of support," "end of maintenance," "end of extended support," and "end of service life" are all used differently across vendors. We standardize these into a single EOL date representing the last day a product receives security patches.
For products with multiple support phases, we use the date when security patches stop — not the date when general support ends or when hardware replacement stops. This is the date that matters for security posture.
Every date is verified against the vendor's official lifecycle documentation. We record the source URL for each product entry. When a vendor updates their lifecycle dates, we update ours.
When different sources show different dates for the same product, we investigate. Common causes include vendor-extended support programs, regional differences, and documentation that hasn't been updated to reflect a change. We document the conflict and use the most conservative date.
Our EOL Checker uses AI to interpret product names, versions, and lifecycle context from live data. All AI-generated outputs are validated against our structured product database. The AI does not determine EOL dates — it surfaces and interprets them.
Lifecycle dates change. Vendors extend support, accelerate EOL timelines, or add new products. We maintain a quarterly review cycle for all products in the index, with out-of-cycle updates for significant changes.
Some open-source projects don't formally announce end-of-life — they simply stop receiving commits and issue responses. For these projects, we use the date of the last security-related commit or release as a proxy EOL date, and flag the entry as "effectively EOL — no formal announcement."
For products with paid extended support (Microsoft ESU, Red Hat ELS, Oracle Premier Support), we show the free/community support EOL date as the primary date and note the availability of extended support options. Paid extended support does not change the security posture for organizations that haven't purchased it.
No EOL reference is complete. Being explicit about limitations is more useful than pretending they don't exist.
Instant EOL status for any product. Free, no account required.