The discussion sounds simple, but the underlying issue is anything but. The customer purchased servers back in 2017 and normally replaces them every five to six years. Under typical circumstances, they would have been shopping for replacements around 2022 or 2023.
That’s how it would have played out in the past. Then the pandemic struck, bringing supply chain disruptions along with it. The original end-of-life announcement that would have arrived around 2023 got pushed back — to 2026 for general software updates and 2028 for security patches.
That stretched the usable lifespan of that server platform to roughly a decade, which means this setup is practically ready for retirement, and it’s running in a healthcare setting no less.
Once the pandemic eased, they should have upgraded right away. They didn’t. Now, in the present day, they asked us to put together a design proposal and bill of materials, and we’re caught in yet another unprecedented supply chain crunch — this time driven by AI chip production demands and hyperscaler competition.
Lead times stretched to eight to ten months. On top of that, costs have surged well beyond what they would have paid the previous year, since the cost of goods has skyrocketed.
That leaves them in a spot where buying new hardware is simply beyond their budget. But even if money weren’t an issue, they’d still be waiting close to a year for equipment to arrive. Then comes the actual deployment and migration work. By the time all that wraps up, they’d be right up against the 2028 security patch cutoff — and well past the 2026 general software update deadline.
And that doesn’t even account for the operating system compatibility issues these aging servers face. Newer VMware versions aren’t supported on this hardware, including VCF 9, and Broadcom is actively pushing customers to migrate. So they’re stuck between a rock and a hard place with no easy way out.
The CTO’s response was, “What are we supposed to do? I can’t believe you’re doing this to us.”
More than anything, I genuinely want to help them. But there’s nothing we can do to give them the kind of help they’re looking for.
We often say that age alone isn’t a reliable indicator of risk, and that’s accurate. So now we’re working through the environment to reduce risk wherever possible and identify vulnerabilities we can still patch. For the ones we can’t patch or can’t address at all, we have to look at alternatives — like buying new hardware or migrating to the cloud — when equipment lead times are too long and compliance rules permit it.
It’s a tough spot for the customer, and there are no clean solutions. When there’s no clean answer, the next best thing is to minimize uncertainty.
Build the inventory and map the exposure
The reality is, you can’t evaluate risk if you don’t know what you have, and most configuration management databases have blind spots.
How you gather that inventory depends on what tools you already have in place. If you’re running a vulnerability scanner like Nessus, Qualys, or Rapid7, you probably already have this information. Export it to a CSV file, and you’re already halfway through the assessment.
If you don’t have a scanner, Greenbone OpenVAS is free, open-source, and runs in Docker or on a virtual machine. A single scan gives you host platforms, mapped CVEs with severity ratings, and structured output.
If you’d rather use something lighter, Nmap remains the go-to tool. Run it with service version detection and XML output against your own network ranges. That gives you active host IP addresses, open ports, and service banners.
runZero has a free tier and generally does a better job than Nmap at device fingerprinting, particularly for network appliances and storage controllers.
Whichever path you take, you end up at the same destination: a structured inventory with hostnames, platforms, versions, and enough detail to determine what’s vulnerable.
Now, end of life is when the vendor stops selling a product. End of support is when the vendor stops releasing things like security patches. That’s the date that defines your exposure. Once a platform crosses that threshold, the CVE list only grows and the patch pipeline dries up.
There’s a free resource called endoflife.date — a community-maintained database covering hundreds of platforms with lifecycle dates and a public API. For anything not listed there, check the vendor’s lifecycle pages directly.
The result is your inventory annotated with end-of-support dates and a flag on every asset that has passed its support deadline.
For every flagged asset, the next step is determining what’s genuinely exploitable. A software version might appear in a CVE listing, but the OEM may have hardened it so that the vulnerability isn’t actually exploitable in practice.
If you’re working from Nmap data or a manual inventory, there are two databases you should know about: NIST’s National Vulnerability Database and CISA’s Known Exploited Vulnerabilities catalog.
The difference between a system with 40 CVEs and zero KEV entries versus a system with 12 CVEs and 3 KEV entries is the difference between manageable risk and active danger. The age of the equipment won’t tell you which scenario you’re dealing with — that’s exactly why you need the CVE profile.
Find it, score it, fix it
Now we apply a weighted formula to score every asset.
The formula I use is: KEV count multiplied by 20, plus the highest CVSS score multiplied by 4, plus the number of months past end of support, plus additional weight for high data sensitivity, internet-facing exposure, and assets that can’t be upgraded to post-quantum cryptographic standards. Tune the weights to match your organization’s risk tolerance.
This method aligns with CISA’s Stakeholder-Specific Vulnerability Categorization framework, which prioritizes exploitation status and mission context over raw severity scores. The specific weights are adjustable. The core principle — that KEV entries carry more weight than CVSS severity, and CVSS severity carries more weight than age — is what stays constant.
The age-based approach had them in the wrong order. The risk-based approach puts them in the right sequence and sorts them into three tiers.
- Tier 1: Immediate action required. These are assets past their end-of-support date with entries in the KEV catalog, especially those in regulated environments or handling sensitive data. These have known, actively exploited vulnerabilities with no patches on the way. In most regulatory frameworks, justifying a risk acceptance for these without compensating controls — such as network segmentation, a WAF, or an IDS — is extremely difficult and must include a remediation plan with a defined timeline.
- Tier 2: Managed risk with documentation. These are assets past end-of-support with CVE counts but no current KEV entries, or assets approaching end-of-support within the next 12 months. Document the risk acceptance: who approved it, under what conditions, and for how long. The absence of that documentation is itself a compliance finding in most frameworks.
- Tier 3: Monitored. This covers everything still within its support window, receiving patches, with manageable risk profiles. These belong on the planning timeline with no immediate action needed. The key is making sure their end-of-support dates are visible in the infrastructure calendar so they don’t quietly become Tier 1 assets through neglect.
One final consideration: NIST finalized post-quantum cryptographic standards in 2024, and not all legacy hardware can support the new algorithms. Some replacements will be driven by cryptographic migration needs regardless of the CVE profile.
Don’t overlook post-quantum readiness. The “harvest now, decrypt later” threat is real.
What you walk away with
Once the assessment is complete, you’re left with three outcomes that fundamentally change the planning conversation.
First, you have a prioritized refresh queue ordered by risk rather than age. That answers the question of where to spend first — and it’s analysis you can defend.
Second, you get a documented risk acceptance for everything you’re choosing not to refresh immediately. This is the compliance artifact most organizations are missing. It identifies the asset, the exposure profile, the business justification, and who signed off on the decision.
Third, you get a refresh sequence that auditors, leadership, and your own team can stand behind. Eventually, a CISO, board member, or auditor will ask why a particular system was still running. The answer can’t be, “Well, it hasn’t hit retirement age yet.” The answer needs to be documented, risk-informed, and grounded in real data.
If you want the refresh queue to stay current as new CVEs and vulnerabilities emerge, you can deploy a platform like Wazuh that automatically cross-references your assets against CVE databases. That turns this one-time assessment into an ongoing process fed by a continuous data stream.
Right now, you walk away with a starting point that any team can execute without outside consultants or a big budget. Most organizations that go through this process uncover at least one piece of the puzzle they were missing before, and that’s usually enough to reshuffle the entire queue.
In an environment where refresh budgets are tight and timelines are stretched thin, the order of the queue matters more than anything.
This article is published as part of the Foundry Expert Contributor Network.
Want to join?
