OpenEoX: Big Tech Is Standardizing Machine-Readable EOL Data — We Read the Draft and Filed Comments
The way software end-of-life dates move between machines is about to get its first industry standard. OpenEoX, an OASIS Open technical committee whose members include Cisco, Dell, IBM, Microsoft, Oracle, Red Hat, Siemens, Huawei, Flexera, Germany's BSI, the NSA — and CISA, which co-chairs it — has published the first public draft of its Core Schema v1.0. The 30-day public review is open to anyone — OASIS explicitly invites "anyone who consumes or publishes end-of-life data" — and closes August 13, 2026. CISA is publicly urging adoption.
We publish end-of-life data for a living — roughly 500 products and 8,000+ versions, consumed by humans, CI pipelines, and AI agents. So we read the draft, and we filed public comments grounded in what operating that dataset has taught us, including the mistakes it has taught us. Here's the short version of both.
What the draft actually is
The Core Schema is deliberately tiny — six fields in a JSON document:
| Field | Required | Meaning |
|---|---|---|
$schema | Yes | Schema identifier |
end_of_life | Yes | Last day the product is supported in any way |
end_of_security_support | Yes | Last day the vendor commits to security fixes |
last_updated | Yes | When this record last changed |
general_availability | No | Launch date |
end_of_sales | No | Last day the product can be ordered |
Dates are RFC 3339 timestamps, or the literal string "tba" for "to be announced." Identifying which product and version a record describes is deliberately out of scope — that's the job of the companion "OpenEoX Shell" specification. Minimal, machine-first, JSON-native: structurally, this is the right shape.
What the draft gets right
The split between end of life and end of security support is the single best decision in the document. Vendors genuinely behave this way — support ends in phases, and the date security fixes stop is the one that matters for risk. Existing datasets (ours included) have had to engineer around formats that collapse these into one date. Making both mandatory forces publishers to answer the question consumers actually ask.
Making end_of_life mandatory — with "tba" as the escape valve — is also right: it makes "we haven't thought about the end of this product's life" an invalid state. Under the EU Cyber Resilience Act, declaring support periods is becoming a legal obligation anyway; the schema and the regulation point the same direction.
What we flagged — from operator scars
1. "tba" conflates the two most different states in lifecycle data. When a lifecycle record has no date, it means one of two opposite things: the product is supported and no end has been announced — or the product is already dead and the vendor never published the exact date. The first is the safest state in the schema's domain; the second is the most dangerous. One sentinel cannot carry both. This isn't hypothetical for us: 482 versions in our dataset — about 6% — are "past EOL, exact date unknown," and a bug in our own pipeline that conflated these two states once published dead software as supported for ten weeks before we caught it. We proposed a second sentinel (or an explicit flag) so machine consumers can't repeat our mistake at industry scale.
2. last_updated tells you that something changed, not what. Published EOL dates drift more than anyone admits: in our July verification pass of 54 flagship products against vendor documentation, 11 required corrections — including an extended-support date Microsoft revised after general availability and a Kubernetes EOL that slipped past its announced date in practice. A consumer of OpenEoX documents can only detect a moved date if it happens to have stored the previous copy. We proposed an optional field carrying the superseded value or a revision source, so silent date movement — the failure mode we encounter most — becomes detectable.
3. Product identity has to survive vendors changing their own version schemes. Out of scope for Core, but worth saying early, because it just happened: in July 2026, Oracle moved MySQL releases from 9.x numbering to calendar-based 26.x — Connector/J 26.7.0 directly supersedes 9.7.0. Any identity scheme that assumes version numbers only go up in place will misread that as two unrelated products. Our own drift tooling caught it within days; a standard should assume such changes as a design condition.
What this means for you
If you build security, asset-management, or SBOM tooling: this schema is likely to become an input you're expected to consume and a format you're expected to understand. The draft is a 30-minute read; the comment window closes August 13. If the "tba" ambiguity above would bite your product too, say so — numbers from the field are what public reviews are for.
If you run infrastructure: nothing to do yet — but OpenEoX adoption would eventually mean vendors publishing lifecycle dates your tools can ingest directly instead of scraping support pages. That's the world our machine-reader thesis described in July, arriving on an OASIS letterhead. The transition period — where some vendors publish OpenEoX, most don't, and dates still drift — is where aggregation and verification matter most.
Where we stand: we intend to publish OpenEoX-format output for our dataset as the specification stabilizes — our data is already served by API and MCP server, and a standards-shaped endpoint alongside them is a natural addition. Verified dates in, standard format out.
Frequently Asked Questions
What is OpenEoX?
An OASIS Open standardization effort defining a unified, machine-readable format for product lifecycle information — general availability, end of sales, end of life, and end of security support — across software and hardware. The technical committee launched in December 2023 and includes Cisco, Dell, IBM, Microsoft, Oracle, Red Hat, Siemens, Huawei, Flexera, Germany's BSI, the NSA, and CISA, which co-chairs it.
What's in the Core Schema draft?
Six JSON fields: mandatory end_of_life, end_of_security_support, and last_updated; optional general_availability and end_of_sales; plus the schema identifier. Dates are RFC 3339 or "tba". Product identification is handled separately by the OpenEoX Shell spec.
How do I comment on the draft?
The public review closes August 13, 2026 at 23:59 UTC and is open to non-members. The OASIS invitation has the comment mechanics; submissions are publicly archived.
Will endoflife.ai support OpenEoX?
We intend to publish OpenEoX-format output as the spec stabilizes, alongside our existing JSON API and MCP server. We filed public comments on CSD01, including a proposed fix for the "tba" ambiguity described above.