Supportability, not age: scoring end-of-life risk

There is a reflex in infrastructure risk that feels right and is quietly wrong: treat old as risky and new as safe. Refresh cycles, depreciation schedules, "five-year hardware lifecycles" — all of it trains us to read the date on the asset tag as a proxy for trustworthiness.

It isn't, and a trust signal built on age produces exactly the wrong verdicts. This is a closer look at the lifecycle domain — one of the factors behind the trust score.

Age is a proxy. Supportability is the thing.

A four-year-old server running a fully supported, patched, encrypted stack is healthy. A laptop unboxed last week, running an operating system the vendor no longer patches, with no disk encryption and an exposed management port, is critical — on day one.

So the framework scores supportability, not age. There is no newness bonus and no aging penalty anywhere in the model. What matters is whether the software and hardware are vendor-supported and defended right now, because that is what determines whether a known problem can actually be fixed. A device past vendor support can't be patched out of its risk — the patch doesn't exist to apply. That isn't an old device; it's an unsupportable one, and the distinction is the whole game.

Why end-of-life is a disqualifier, not a deduction

It's tempting to treat an end-of-life OS as a few points off an otherwise-fine score. The framework doesn't, because a weighted average is the wrong instrument for a catastrophic finding. An unsupported operating system, an exposed remote-management surface, a known-exploited CVE with no encryption underneath — these don't get diluted by a clean scorecard around them. They cap the verdict. One genuinely critical condition makes a system critical. That's not pessimism; it's how a competent operator already triages, made consistent and enforceable.

Measure remediation, not the calendar

If you ever do score "modernization," score it as remediation velocity — is debt being paid down? — never as an age curve. Moving a workload onto newer tin that's still unsupported buys you nothing. The question is never "how old is it," it's "is it supported, defended, and getting better or worse."

What this changes in practice

Read lifecycle risk this way and the operational picture flips in useful ways:

• Refresh budgets follow risk, not the calendar. You modernize what is unsupportable and exposed, not what is merely old — and you can defend the spend with evidence.
• "Patched and supported" beats "new." The cheapest trust win is often keeping a supported system current, not replacing a healthy one.
• The scary devices surface first. The new box with the bad posture stops hiding behind its purchase date.

One honest caveat the model insists on: where there isn't enough signal to judge supportability, it doesn't guess — the device reads Unknown rather than a flattering default. That discipline is its own subject: Unknown is an answer.

Stop reading the asset tag, and start reading the evidence. Back to the map: the Augustine Infrastructure Trust Framework.

SAUTERA™ is the reference implementation of the Augustine Infrastructure Trust Framework.