My grandson's PS4 needed an update the other day..

and he wanted to know why it warns you not to power off during the process. If you've ever had to do this, then you know that the answer is to theoretically prevent a bricked device. Theoretically, because I hope we've come a long way since the early days of firmware updates where that was a distinct possibility. With something like a PS4, I'd expect enough thought and care in the process that the warning is more belt-and-braces than genuine peril.

Look beyond the shiny consoles though, at the more ubiquitous and less glamorous devices: routers, printers, phones, any smart device really. There's a good chance that whether it ever gets an update correlates strongly with what it costs and how important it's considered. Cheap routers have always been notorious. Finding the right support site is hard enough. Then you navigate it and discover, and I'm sure you'll relate to this, that the last update is five years old and requires an obsolete version of Windows. Irksome doesn't begin to cover it.

There are two things going on here. The first is that you've been running a device without effective software support for some time, possibly since the moment you bought it. The second is that finding this out is more than a chore. It's often a long and complex challenge, and one none of us want to accept. It might have been okay-ish to replace a router every year or so if needed, but we mostly don't. Mostly we run these devices until they die or a shiny new one catches our eye.

Take a moment to check when your router firmware was built. Go on, I'll wait.

Shocking, isn't it? My "new" router, in theory two years old, has how-to videos on YouTube that are nine years old.

Here's the rub: you're always running old software that may or may not be supported, may or may not have updates available, and may or may not have known vulnerabilities.

In olden days, you'd just shrug and live with it. In the new 'AI Detecting Vulnerabilities at Scale in all Open Source' era, old software is potentially dangerous and not knowing what you're running is going to be expensive as regulations and even insurers catch up.

Finding out is stupidly hard, and it's all on you.

Well, It Just So Happens…

…that there's a standards effort aimed at exactly this. The OASIS OpenEoX group is building a common, machine-readable way to publish product lifecycle information across commercial software, hardware and open source alike: when it launched, when sales stop, when security fixes stop, when everything stops. Really, a whole lot of interesting project milestones. I recently joined the technical committee, representing HeroDevs, so consider my interest declared.

The first piece of the standard is currently in public review, and I'll come back to how it works and how you can weigh in. First though, it's worth seeing quite how hard this problem actually is, because "is this still supported?" turns out to be one of the most stubbornly manual questions in software.

Silence Is the Safe Option

Why is it like this? Partly because updating firmware in home goods has always been close to impossible. Manufacturers don't want the hassle, and they certainly don't want to be taken to court because an update bricked ten thousand devices. Shipping a fix carries risk. Shipping nothing carries none. So plenty of devices that could be updated never are, because the manufacturer never intended to provide a fix in the first place.

Open source has a related problem. A solo maintainer walking away rarely posts an announcement. They just stop. The commits go quiet, the issues pile up, and nobody declares the project dead because there's nobody whose job that is.

Even the People Measuring This Struggle

The OpenSSF built Scorecard, a tool to evaluate open-source software projects. It checks code health, assesses supply chain risks and generally judges whether a project is still alive. Even they had difficulty working out what "alive" means. Their Maintained check counts any commit in the last 90 days as a sign of life, and even an issue comment from the core team registers a pulse. And the heartbeat can be entirely artificial. A suitably configured GitHub Action merrily merging Dependabot PRs keeps the pulse going indefinitely, even when the maintainers have no intention of ever fixing a bug.

The excellent endoflife.date tracks the most important ~500 products directly. The HeroDevs dataset I work with tracks over 12 million. Getting a definite answer for any one of them takes real detective work and the occasional finger in the air. That produces exactly the failures you'd expect: live projects marked dead, dead projects marked live, and the worst case, zombie software that looks healthy and isn't.

Now Multiply

So far this has mostly been about the box under your telly. Widen the lens. Oracle boasts Java on 3 billion devices. The public app stores hold millions of apps between them, and that's before the commercial software stacks that never go near a store. Then there's the enormous fleet of Linux running at the edge: point-of-sale terminals, digital signage, kiosks, industrial gateways, cameras, sensors, each one a full OS with its own kernel, its own package versions and its own patching story, or lack of one. Add device drivers, industrial controllers, and every dependency in every application your company ships: the same question, "is this still supported", applies to all of it, and the answer is just as hard to find at enterprise scale as it was for your router.

There's no consistent, machine-readable way for anyone, vendor, maintainer or manufacturer, to say "this component is finished, here's the date, act accordingly." Where that signal exists at all, it's buried in forum posts, changelogs and support portals that need a human to go and read them.

Attackers don't have that problem. AI has already industrialised vulnerability discovery. I've written elsewhere about machine-speed vulnerabilities, human-speed fixes, and the EOL question is the same asymmetry in a different hat. The least we can do is make "is this even supported?" answerable at machine speed too.

How OpenEoX Goes About It

So, back to the standard. The scope covers every milestone from launch to shutdown, including End-of-Security-Support: the point where vulnerability fixes stop even though the product still "works" in the brochure sense. That milestone matters more than the final EOL date, and it's the one most often left vague.

The committee list is worth a look: Cisco, Microsoft, IBM, Oracle, Red Hat, Dell and Siemens, alongside CISA and Germany's BSI. These are the companies whose products have never had a standard way to signal lifecycle status. CISA is already urging producers to publish this data openly, without hiding it behind customer portals or paywalls. Whether that holds once the standard asks these same companies to commit to hard, public, machine-readable dates is the real test. Joining a standards committee is easy. Publishing your own End-of-Security-Support date, in a format a scanner can parse, for a product you'd rather let fade away, takes more nerve.

The design comes in layers, deliberately. The Core schema is tiny: four milestones in sequence, General Availability, End-of-Sales, End-of-Security-Support, End-of-Life, plus a last_updated field and an explicit tba for dates not yet decided. A separate Shell layer handles product identity, and an API layer covers how tools discover and fetch the data at scale. Because Core carries no identity of its own, it slots straight into things that already exist: an SBOM knows which product it describes, so it can include an OpenEoX statement. Same for a CSAF advisory.

The detail I like most: a "vendor" in OpenEoX terms is whoever created or maintains a product, which explicitly includes open source communities and individual maintainers. A one-person project gets the same standard way to say "this is finished, here's the date" as a billion-dollar LLM.

Where This Stands and How to Weigh In

The Core Schema v1.0 (CSD01) is in public review until 13 August 2026. You don't need to be an OASIS member to comment: an email is enough.

• Read the spec. It's short.
• Send feedback to the public comment list (comments fall under the standard OASIS Feedback License).
• If you build scanning or SBOM tooling, point a real JSON Schema validator at the published schema and see what happens.
• Want in properly? TC membership is open to interested parties.

A standard only starts to work once ignoring it costs somebody something. Whether OpenEoX gets there or ends up as one more well-attended committee producing beautifully structured JSON that nobody is obliged to publish is worth watching.

Reading the spec will take you less time than it did last time you tried to find an update for your router.