The Real Death Date of Your Hardware Is Written in Someone Else's Kernel
Kit rarely dies of hardware failure any more. It dies the day upstream stops shipping a secure operating system that runs on it, and that date is set by a third party you never meet.
On 14 October 2025, Windows 10 stopped receiving free security updates. The machines didn't change that morning. Millions still boot, still run the accounts package, still drive the warehouse scanners. What changed is that Microsoft stopped patching them and offered a bill instead: Extended Security Updates at $61 per device for the first year, then double that the year after, and double again. Run a 10,000-seat estate and that is roughly $610,000 in year one just to keep working hardware safe to switch on, past a million by year two. The metal is fine. The support is what expired.
This is how business hardware dies now. Rarely from a dead fan or a seized disk. Far more often on the day upstream stops shipping a secure operating system that still runs on it, a date set by someone you have never met, optimising a maintenance burden that is not yours.
Why does hardware go obsolete before it breaks?
Take the machines stranded by that deadline. Most cannot move to Windows 11 because Microsoft set a hardware floor: a TPM 2.0 security chip and, in practice, an 8th-generation Intel Core processor or newer. Plenty of 2017-era workstations clear every performance bar the new system needs and still fail the eligibility check, kept out by policy rather than capability.
The logic repeats wherever software meets ageing silicon. A platform maintainer carries a cost for every processor generation and instruction set it promises to support. Old architectures are the least-used and the most awkward to keep alive, so the rational move is to prune them and ship a leaner codebase. Their incentive points at a smaller support matrix; yours points at a fleet that keeps running, and you absorb the gap between the two.
Physical wear at least gives you something to plan around: warranties, failure-rate curves, a spares budget. Software-driven obsolescence gives you a cliff whose location is decided in a changelog you don't read, on a schedule you don't set. One release your device is a first-class target; the next, it is a line in a deprecation note.
Scarcity just made the timing worse
None of this is new. The timing is. AI datacentre demand has drained the market for memory and storage. Through 2025, as Samsung, SK Hynix and Micron rerouted capacity toward the high-bandwidth memory that AI accelerators need, conventional DRAM contract prices rose quarter after quarter rather than following their usual seasonal softening. Treat that as the market backdrop the survival advice is responding to, not a forecast. And that advice is sensible on its face: extend refresh cycles, sweat existing assets, buy later.
The collision is obvious once you see it. At the very moment firms most need their kit to last another five years, the mainstream platforms are accelerating the retirement of older hardware to lighten their own load. The machine you budgeted to run until 2031 may lose secure updates in 2028, and if you planned the capital around the metal you costed the wrong thing.
The default platform ships with a hidden clock
Standardise on the popular default and you inherit more than its features. You import its deprecation cadence. Windows is the clearest case: fast-moving, and willing to strand functional hardware to keep its own engineering tidy, as the Windows 11 cutoff showed. The same reflex runs through Linux, where an Ubuntu interim release is supported for just nine months and even the long-term-support builds carry five years unless you pay for extended maintenance. Pick the aggressive default and you have adopted a drop-old-hardware roadmap you never negotiated.
The hedge is to treat conservative, wide-coverage platforms as the insurance policy they are. Debian commits to about five years of security support per stable release and still builds for a long list of processor architectures, from 64-bit ARM to hardware most vendors wrote off a decade ago. Red Hat Enterprise Linux publishes a ten-year lifecycle for each major version, so a server standardised on RHEL 9, released in 2022, has a supported, patched path into the 2030s. That breadth carries a cash value, and it shows up precisely when components are scarce: keeping a secure OS on older machines for years longer is the difference between a planned refresh and a forced one.
There is a subtler version of the same trade happening inside the platforms. The Linux kernel now accepts drivers written in Rust, a memory-safe language that buys genuine safety and maintainability. It also narrows portability, because the Rust toolchain does not target the oldest architectures the kernel's C code still reaches. None of this is a complaint about the engineering. The point is only that the same decision which hardens the software can quietly shrink the set of your existing devices a future release will run on. The engineers are optimising their world; the bill lands in yours.
So make the software-support horizon a purchase question rather than a disposal one. Before you buy, ask how long a maintained, secure operating system is committed to run on the thing, and weigh the answer alongside price and performance. Track it the way you track a lease expiry, because that is what it is. Getting the platform and lifecycle strategy right at the point of purchase costs far less than discovering the clock after it has run down, and in a market where stretching every asset is the survival play, it may be the cheapest decision you make all year.
You don't own your hardware's lifespan. You rent it from whoever maintains the software, on terms they can change without asking you.
Questions people ask
How do I find out when my hardware will lose software support?
Check the published lifecycle and release documentation of the operating system and platform you depend on, not the hardware vendor's warranty. Microsoft, Red Hat, Debian and Ubuntu all publish their support horizons openly. The date that matters is when secure, patched updates for your device's architecture stop shipping, and that's an upstream software decision. If a platform won't commit to a clear support horizon, treat that ambiguity as a cost.
Is it safe to keep using a device after its OS stops getting updates?
For anything touching a network, sensitive data or a regulated process, no. The hardware still works, but without security patches it becomes an unmanaged risk, and in most compliance regimes that alone forces retirement. This is why the software-support horizon, not physical failure, tends to set the real end of service life.
Does choosing a conservative platform actually extend hardware life?
It can, materially. Debian and Red Hat Enterprise Linux make long-term support and wide architecture coverage a core commitment, publishing roughly five and ten-year horizons and shipping secure updates for older devices long after aggressive mainstream stacks have dropped them. That extra runway is the hedge, and its value is highest when component scarcity makes buying replacements expensive.
Related
- Epic v Google: The App Catalogue Remedy That Hands Rivals the Moat
- Memory Prices Turned. Renegotiate the Supply Contract Before the Next Refresh.
- How AI Makes Bad Bosses Worse: The Agreeability Machine in the Corner Office
- Digital Business
Written by an AI editorial persona of Abyshire's proprietary editorial system and reviewed by our team.