Trackr.Live The landing site for Trackr Services
§ Trackr.Live

Nessus / Tenable

Tenable Nessus is a vulnerability scanner, and that single word does a lot of quiet work. Nessus is the engine: the thing that fires checks at a host, optionally logs in with credentials, and reports back what it found. It is not the console you triage findings in, not the dashboard your AO looks at, and not the program your DoD contract calls out by name. Those are separate products that drive the engine. Keeping the engine distinct from the console is the first thing to get straight, because a lot of the confusion around “Nessus” in federal work comes from people using the word to mean the whole stack when it means one component of it.

An abstract scan topology probing a host enclave: active and passive sensors fanning probes at a cluster of hosts while a plugin feed streams in from the side.
The vendor is Tenable Holdings, Inc. (NASDAQ: TENB), and the ownership story here runs opposite to most scanner pages. Tenable was not acquired by a larger platform. It is the acquirer. In early 2025 Tenable closed its purchase of Vulcan Cyber (roughly $147M cash plus a small RSU component, completed February 7, 2025) and folded those remediation and prioritization capabilities into the Tenable One exposure-management line. So the currency trap on this page is not “who bought them.” It is the rebrand, and an SSP that still says “Tenable.sc / SecurityCenter” is quoting a name that has changed twice.

The names changed, and your SSP probably hasn’t

Tenable dropped the dot-product naming and moved everything to a descriptive format. The mapping matters because federal documentation lags it by years, and an assessor reading current Tenable docs against a 2018-vintage SSP will see two different products that are actually the same one.

Current name Former name Role in the ACAS stack Where it runs
Tenable Nessus Nessus Active scanner (the engine) On-prem, on the scanner host
Tenable Agent Nessus Agent Host-based assessment for roaming/unreachable hosts Installed on the endpoint
Tenable Network Monitor Nessus Network Monitor (NNM) Passive discovery and assessment On a SPAN/tap, on-prem
Tenable Security Center Tenable.sc, before that SecurityCenter The console: scan orchestration, dashboards, reporting On-prem
Tenable Vulnerability Management Tenable.io Cloud (SaaS) console FedRAMP Moderate cloud
Tenable One (unchanged) Exposure-management platform Cloud
Tenable Enclave Security (new, ~2024) Vuln mgmt + container scanning for high-side On-prem / air-gap / IL5

The console rename is the one that bites. SecurityCenter became Tenable.sc, then the dot was stripped and it became Tenable Security Center. An SSP that names “Tenable.sc” is describing a real product under a name the vendor retired. Cosmetic, not a control failure, but assessors notice drift like this because it signals the document hasn’t been touched in years.

Current version reality as of this writing (spring 2026): Tenable Nessus is on the 10.12.x line, released April 2026, which added OpenSSL 3.5 / FIPS 140-3 support and Windows ARM64. Tenable Agent is on the 11.x line. Tenable Network Monitor is on the 6.x line (6.5.x current, 6.5.4 released May 2026). These numbers move monthly through security advisories (the tns-2026-xx series), so treat any specific version in a document as a snapshot, not a fact with a long shelf life.

ACAS: the same engine wearing a DISA badge

This is the part that matters for the audience. ACAS, the Assured Compliance Assessment Solution, is the DISA program that mandates vulnerability scanning across DoD. It is powered by Tenable, and the ACAS stack is built from the same products in the table above: Tenable Security Center as the console (this is the ACAS console), Tenable Nessus as the active scanners, Tenable Network Monitor for passive asset discovery, and Tenable Agent for host-based coverage.

The distinction to draw cleanly is commercial Tenable versus the DoD ACAS bundle. They share an engine, but ACAS is a DISA-managed, mandated deployment with its own STIGs, feed channels, and contract vehicle. You don’t go buy ACAS; it comes through the program. A commercial Security Center install and an ACAS Security Center install are the same software with different governance wrapped around them, and the governance is most of what makes ACAS ACAS.

There’s a live caveat. In 2025 DISA put out an RFI for a next-generation ACAS, scoped to scan on the order of 11 million devices on a 72-hour cadence, with a performance period running November 2025 through October 2030 and explicit interest in AI/ML analytics. Responses were due May 9, 2025. Whether a next-gen award lands with Tenable retaining the program, or the architecture shifts toward something else, is genuinely in flight. I’d treat “ACAS equals Tenable” as true today and provisional over a five-year horizon. If you’re writing a long-lived SSP, don’t hard-code the vendor into a sentence you can’t easily revise.

Cloud, on-prem, and the FedRAMP line

Where the product runs decides which authorization applies, and this is the part people most often state wrong.

The cloud line (Tenable Vulnerability Management, Tenable One, Tenable Cloud Security, Tenable Web App Scanning) is FedRAMP Moderate authorized, and also carries GovRAMP. Not High. As of Tenable’s January 2026 FedRAMP product offering, those products sit in the Moderate boundary. If someone tells you the Tenable SaaS is good for IL5, they are wrong, and the marketplace listing will back you up.

For FedRAMP High, DoD IL5, classified, or air-gapped environments, the product is Tenable Enclave Security, a newer offering (launched around 2024) that does vulnerability management plus container image scanning. It deploys on-prem, in air-gapped or private-cloud boundaries, or as a managed service inside AWS FedRAMP High / IL5. It’s backed by Security Center under the hood. The practical takeaway: most DoD ACAS work today is still on-prem Tenable Security Center, not the cloud SaaS, and the cloud-versus-on-prem question is really a question about what boundary you’re authorized to operate in.

Plugins and the feed, which is where air-gap breaks

Nessus detections ship as plugins, written in NASL. Coverage is the plugin feed, and the feed updates continuously. Online update is the default and it just works.

Air-gapped is the federal reality, and it doesn’t just work. The offline path pulls a plugin set from plugins.nessus.org/offline.php and side-loads it into Security Center or the scanner. That introduces a human step, and the human step rots. A stale plugin feed inside a closed enclave produces the most dangerous output a scanner can give you: a clean result that is clean only because the engine doesn’t yet know about the CVE. When something looks too quiet in an air-gapped deployment, the feed date is the first thing to check, before you touch scan policy or credentials.

Deeper: Essentials, and why the free tier won’t do compliance work.
Nessus Essentials is the free edition, capped at 16 IPs per scanner and running on a feed delayed by roughly a day relative to paid tiers. It’s fine for learning the tool. It is not an ACAS substitute, and not only because of the IP cap: Essentials does not include the compliance/audit engine, so you cannot run SCAP, CIS, or STIG audit policies on it. That capability lives in Nessus Professional and Nessus Expert (and in the ACAS-bundled scanners). If you’re evaluating Nessus for CM-6 config checking and testing on Essentials, you’ll conclude the feature doesn’t exist, because in that edition it doesn’t.

What it does well, what people file tickets about

The strengths are real. Plugin coverage is broad, credentialed scanning goes deep (the difference between a credentialed and an uncredentialed scan of the same host is not subtle), and because Nessus is the de-facto standard, its findings map cleanly to what assessors already expect to see. Passive Network Monitor catches assets that active scans miss entirely, which on a sprawling network is not a nice-to-have.

The complaints are also real. Credentialed scan setup is fiddly: Windows wants WMI and registry permissions configured just so, and Linux wants SSH keys plus a sudo arrangement that someone has to own. False positives happen and disputing them is manual. Scan windows and host load can knock over fragile OT or legacy gear that was never built to be probed. The Security Center console feels dated. And licensing surprises by asset count are a recurring budget conversation.

Here’s my flag, and it’s contestable: passive Network Monitor coverage is undervalued in most ACAS deployments. Teams lean on active credentialed scanning because that’s what the cadence rewards and what the dashboards count, and they treat NNM as an afterthought. But passive monitoring is exactly what surfaces the unmanaged host, the rogue device, the thing nobody put in the active scope. I’d argue an ACAS deployment running active-only is leaving its most useful blind-spot detector switched off. Reasonable engineers will disagree on how much SPAN/tap infrastructure that’s worth.

Control ties, and what this tool is not

The primary anchor is RA-5, Vulnerability Monitoring and Scanning. In a DoD context, Nessus is the RA-5 tool; ACAS exists to satisfy RA-5 at scale. Because the engine also runs compliance and audit policies (SCAP content, CIS benchmarks, STIG audit files), it doubles as a configuration checker, which ties it to CM-6, Configuration Settings. Scan output drives remediation, so SI-2, Flaw Remediation, follows naturally, and the recurring ACAS cadence feeds CA-7, Continuous Monitoring.

Be honest about the boundary. This is a network vulnerability and compliance scanner, not a developer-testing tool. SA-11 (developer security testing) and SA-15 belong to the SAST and DAST world, and forcing them onto Nessus to pad a control-mapping table is the kind of thing that reads as not understanding either category. If you want SA-11 coverage, that’s a code scanner’s job. Nessus answers RA-5, CM-6, SI-2, and CA-7, and it answers them well; let it stay in its lane.

Operational notes

Scanner placement is a segmentation question. Active scanners need network reach into what they scan, which fights against the isolation your architecture wants, so most deployments run scanners per enclave rather than trying to reach across boundaries. Agents cover the hosts active scanners can’t reach reliably, which in practice means roaming endpoints and cloud instances. Network Monitor goes on a SPAN port or tap and watches.

On integration: findings feed eMASS to populate RMF POA&M and continuous-monitoring tracking, results commonly ship to a SIEM (Splunk or Elastic, depending on the shop), and ticketing hooks vary. The pitfalls that produce bad data are predictable. A credentialed scan that silently lost its credentials reports the host as clean when it’s just unscanned. An agent that stopped checking in keeps serving its last result until someone notices the timestamp. Scan windows collide with each other and with the operational load they’re scanning. None of these throw a red error; they all quietly degrade the truthfulness of the dashboard, which is worse.

Scale changes the answers. A few-hundred-host enclave on on-prem GovCloud and an 11-million-device DISA-scale program are the same engine solving different problems, and advice that fits one will mislead the other. Qualify by environment before you copy anyone’s deployment shape.

Sources

Adjacent material on this site