When There's No Patch, It's a Decision, Not a Ticket

A compliance scan kept re-flagging the same handful of vulnerabilities on an old server, round after round, for years. The expected response is “patch it.” But when I actually dug in, the patches did not exist for that operating system — the fixes had been written for newer releases and never backported to the end-of-life version the box ran. You could scan that server every week forever and the findings would never clear, because there was nothing to apply. That’s a category a lot of vulnerability programs handle badly: a vulnerability with no available fix isn’t a ticket to keep reopening, it’s a decision someone needs to make.

”Open until patched” assumes a patch exists

Vulnerability management implicitly assumes every finding has an endpoint: a patch you apply, after which it closes. For an end-of-life platform that assumption breaks. The vendor moved on; fixes land in current releases and never come back to the old one. So the finding has no patch-shaped resolution — and a process that only knows “reopen until patched” will keep that item open in perpetuity, generating busywork and noise on every scan. The first honest step is to recognize the category: this isn’t “not patched yet,” it’s “no patch will ever come.” Those demand completely different responses, and conflating them buries the real ones.

Re-scanning a vulnerability that has no patch isn’t diligence. It’s a loop with no exit condition.

Severity in the abstract is not your risk

Before deciding what to do, get the risk right, because the scanner’s severity is generic and your context is specific. The findings on this box were rated by their abstract worst case — but in context, several were far lower risk than the label suggested: they were client-side issues that required the host to initiate a connection to a malicious server, on a machine that was only ever connected to through a tightly controlled path. The scanner doesn’t know any of that. It reports the platonic severity; you know the reachability, the usage pattern, and the preconditions an attacker would actually need. Real risk is the abstract severity filtered through your environment, and that filtering is the analysis a scan can’t do for you. (It’s the heart of why vulnerability management is a triage problem, not a checklist.)

When there’s no patch, name the real options

Once you’ve established there’s no patch and you’ve assessed the true risk, you’re at a fork with exactly two honest paths — and “keep it open and re-scan” is not one of them:

• Documented risk acceptance. If the real-world risk is genuinely low — contained, low-impact, hard to reach — the right move may be to formally accept it: written down, with the reasoning (no fix exists, here’s why the contextual risk is low, here’s the compensating control), signed by an accountable owner, revisited on a schedule. That’s not sweeping it under the rug; it’s the opposite — making the acceptance explicit and owned instead of letting it rot as a perpetual open ticket.
• Replace the platform. If the risk isn’t acceptable, then the finding is telling you something bigger than itself: the end-of-life platform is the actual problem, and the fix is to migrate off it. The individual CVE is a symptom; the unsupported OS is the disease.

Both are decisions. Both close the loop. Neither is “open a ticket and run the scan again next week.”

The CVE is a symptom of the platform

The deeper point: when an unpatchable system keeps generating findings, chasing each finding individually is treating symptoms. The findings will keep coming because the platform is end-of-life — that’s the root condition, and no amount of per-CVE work addresses it. So a pile of no-patch findings on one host should escalate, not just accumulate: they’re collective evidence for a replace-or-formally-accept decision about the platform itself. Reading them that way turns scanner noise into a clear signal that a real decision is overdue.

Don’t let no-fix findings live as zombie tickets

The trap is the zombie ticket — a finding that can never close, reopened every scan cycle, slowly training everyone to ignore the report it lives in. That’s corrosive, because a report full of un-closeable items is a report people stop reading, and then the real findings hide in the noise. The fix is to force the decision: for any finding with no available patch, either accept it explicitly with an owner and a review date, or escalate it to a platform-replacement plan. Make the call, record it, and get it out of the perpetual-reopen loop. When there’s no patch, the work isn’t technical anymore — it’s a decision, and someone has to own it. If you’ve had to make the accept-or-replace call on an unpatchable system, I’d like to hear how it went.