Why the Same Vulnerabilities Show Up on Every Scan (and How to Stop It)

Every MSP has seen it: the patch was deployed, the ticket was closed, and next month's scan reports the same finding on the same host. The client asks why they're paying for fixes that don't stick.

Most "zombie" findings come from a handful of causes. Here's how to tell them apart.

1. The patch is installed but not active

Many updates only take effect after a reboot or a service restart. The scanner checks the running version or a registry key that doesn't change until then, so the finding stays open.

Check: pending reboots on the affected hosts, and whether your patch policy lets users postpone restarts indefinitely.

2. An old copy is still on disk

The main application was updated, but an older copy still sits somewhere: a portable install in a user folder, a bundled runtime inside another product, or a leftover version after an upgrade. Java, .NET runtimes, OpenSSL libraries and browsers are frequent culprits.

Check: the file path in the finding's evidence or output section. If it points somewhere you didn't expect, that's the copy to remove.

3. The scan ran without credentials (or with the wrong ones)

Without a working login, a scanner has to guess from banners and open ports. It can't see installed patch levels, so it may keep reporting issues that were fixed, or miss ones that weren't. A credential that worked last month may have expired or lost rights since.

Check: whether the scan's authentication succeeded on that host. Most scanners report this as its own informational finding.

4. The fix needs configuration, not a patch

Some findings, like weak TLS settings, SMB signing not required, or default credentials, aren't fixed by updates at all. Patching the server won't touch them.

Check: the solution text in the finding. If it says "configure" or "disable" rather than "update", it needs a change ticket, not a patch run.

5. The risk was accepted but never recorded

Sometimes a finding stays open on purpose: a legacy machine the client can't replace, or a line-of-business app that breaks on the new version. If that decision isn't written down, it shows up as "unfixed" every month and looks like a failure.

Check: whether the client has signed off on the exception. Record it with an owner and a review date, and report it separately from open work.

Make recurring findings visible

The quickest way to catch zombies is to compare each scan with the previous one and flag findings that were marked fixed but came back. Those deserve a closer look before another patch ticket goes out. Grouping them by cause (reboot, leftover copy, credentials, configuration, accepted risk) also tells you which part of your process needs tightening.

Varaxon Scan Hub reads exports from the scanners you already use and builds client-ready reports with prioritized actions and PSA tickets after your review. Your first 3 reports are free, no credit card needed: varaxontech.com.

Related: Credentialed vs non-credentialed scans · Vulnerability remediation SLAs