Tenable VM: Authentication Successful but Credentialed Scan Shows No

If you've spent any time running credentialed scans in Tenable VM, you've probably seen it: the scan completes, authentication shows as successful, but the credentialed scan column reads No. It's one of the most misunderstood results in the platform — and the distinction carries real compliance implications.

// what the two columns actually mean

Tenable VM reports these separately for a reason. Authentication success means Tenable was able to log into the device using the credentials you provided — SSH key accepted, username and password validated. The session was established.

Credentialed scan success is a different question entirely. It means Tenable was able to run its plugins against the device using that authenticated session to collect system-level data — installed packages, registry keys, running services, patch levels, configuration values. For a credentialed compliance scan to work, Tenable needs plugins that are built to interrogate that specific device type.

// where this shows up in practice

This situation is most common with network appliances and specialty management platforms — devices like Aruba AirWave, HPE iLO, certain network switches, and other vendor-specific management interfaces. These devices may accept SSH connections and authenticate Tenable's scan account successfully, but Tenable simply doesn't have compliance plugins written for them.

Aruba AirWave is a good example. The AMPCLI interface accepts SSH authentication, so Tenable will show authentication as successful. But because AirWave runs a locked-down management CLI rather than a standard Linux shell, Tenable's Linux plugins can't execute. The credentialed scan column shows No and no compliance data is collected.

This is not a configuration error. It is not a credentials error. It is a plugin coverage gap — and it's important to document it correctly in your compliance posture rather than treating it as a scan failure to troubleshoot indefinitely.

// what to do instead

When you encounter this situation, Tenable compliance scanning is not the right tool for that device. The path forward is vendor-provided assessment tooling. Most network vendors publish their own security configuration guides and assessment tools that are designed specifically for their platforms:

For Aruba devices, HPE publishes security hardening guides and the AirWave platform has its own configuration audit capabilities. For network switches and routers from Cisco, Palo Alto, and others, CIS publishes device-specific benchmarks and the vendors provide their own compliance tooling.

The key is to document the gap formally. In a federal environment, a device that cannot be assessed by Tenable needs to be captured in your asset inventory with a note explaining why credentialed scanning is infeasible, and the alternative assessment method used. This is exactly the kind of entry that belongs in a POA&M or as supporting documentation in a compliance exception.

// the key takeaway

Authentication successful but credentialed scan No is not something to keep troubleshooting from the Tenable side. Once you've confirmed credentials are valid and the device is reachable, recognize it as a plugin coverage limitation and route to vendor assessment tooling. Document it, note the alternative method, and move on. Spending hours trying to force a Tenable credentialed scan on a device it was never designed to assess is wasted effort.