Why a Remediated TLS Vulnerability Still Shows Active in Tenable Asset Inventory

You remediated a TLS vulnerability. The credentialed scan ran, the finding is gone from the scan output. But you check the asset inventory and it's still sitting there marked Active — not Fixed, not Resolved. Active. You know you fixed it. The scan agrees. So why won't Tenable let it go?

This is one of those situations that looks like a Tenable bug but is actually a data reconciliation problem rooted in scan history. Here's what's happening and how to clean it up.

// how the confusion starts

It begins with an uncredentialed scan. Tenable authenticates via the network but doesn't have OS-level access, so it fingerprints the host based on what it can see — open ports, banner responses, service headers. It finds a TLS vulnerability — maybe TLS 1.0 still enabled, an expired certificate, or a weak cipher suite. Tenable logs the finding against the asset and records what it thinks the OS is based on that limited fingerprint.

Then the credentialed scan runs. Now Tenable has proper OS-level access — it can see exactly what OS version is running, what patches are applied, what services are actually configured. It re-evaluates the TLS finding with full context. The remediation is confirmed and the finding drops off the scan output. But the asset record in inventory is carrying history from both scans — and they don't reconcile cleanly.

// why asset inventory doesn't update cleanly

Tenable's asset inventory builds a historical record for each asset over time. When the uncredentialed scan logged the TLS finding, it created an entry tied to that asset's UUID. The credentialed scan ran later — but because the OS fingerprint changed significantly between the two scans, Tenable may have treated them as separate or parallel asset records. The credentialed scan result doesn't overwrite the uncredentialed history. It sits alongside it.

The inventory surfaces the worst-known state — Active — because from a risk perspective Tenable defaults to treating unresolved historical findings as still present until explicitly cleared.

// how to confirm this is what's happening

In Tenable VM, open the asset detail and check the vulnerability history for the TLS finding. Look at the Last Seen date. If it's older than your most recent credentialed scan — that's your confirmation. The finding is tied to the stale uncredentialed record, not the current scan results.

// the fix — delete the asset and rescan

The cleanest resolution is to delete the asset from Tenable's inventory and run a fresh credentialed scan. This forces Tenable to build a new asset record from scratch — correctly fingerprinted from the start — with no uncredentialed history carrying forward.

Before you do this, confirm two things. First, verify the TLS remediation is actually complete on the host — check the service configuration directly, don't rely on scan output alone. If you're dealing with TLS 1.0, verify the protocol is disabled at both the OS and application layer. Second, confirm your credentialed scan policy covers this host and the credentials are valid. A fresh scan with bad credentials just recreates the same problem.

Tenable VM → Assets → find the asset
→ select it → Actions → Delete asset

Then run a targeted credentialed scan
against the host IP to rebuild the record.

The new scan will create a clean asset record. If TLS is properly remediated the finding won't appear. The inventory reflects that from day one — no stale history attached.

// when not to delete the asset

If the asset has a long history of other findings being tracked for POA&M purposes, deleting it wipes that history too. In that case, work with Tenable support or check if your version supports manually closing the stale finding against the specific asset UUID. This preserves the rest of the asset history while clearing the orphaned TLS entry.

// bottom line

A TLS vulnerability showing Active in Tenable asset inventory after a successful credentialed remediation scan is almost always a data reconciliation issue between an old uncredentialed record and the current credentialed scan history. Check the Last Seen date, confirm the remediation is real, and if the asset has no critical POA&M history — delete it and run a clean credentialed scan. It's faster than trying to force Tenable to reconcile conflicting scan records that were never properly linked.