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

ACAS

If a system is on the DoDIN, it gets scanned by ACAS. There is no version of the conversation that ends with “we decided not to.” What trips up people new to the DoD side of the house is what ACAS actually is. It is not a product you download. It is a program of record: a specific bundle of Tenable software that DISA licenses, validates, configures, and pushes out under its own version control. The Assured Compliance Assessment Solution is the wrapper. Tenable’s scanners are the engine inside it.

Schematic of a segmented DoD enclave with distributed scan engines reporting into a single central console, vulnerability findings flowing out to a compliance record.

So “ACAS found this” means a DISA-blessed Tenable Security Center install running plugin content DISA approved, against a scan policy that was probably handed down rather than written locally. The distinction matters operationally, not just pedantically. You can run commercial Nessus with last night’s plugins. You cannot run ACAS that way, because the whole point of the program is that the builds and the feed are validated and posted through the ACAS PMO before you get them. ACAS lags commercial Tenable on purpose, and if you treat the two as interchangeable you’ll eventually upgrade something DISA hasn’t cleared and have an awkward conversation during an assessment.

Who actually makes it, and the naming you’ll trip over

The program traces back to an April 2012 award with two names on it: Tenable (then Tenable Network Security) for the software, and Hewlett Packard Enterprise Services as the integrator. The integrator role is the part that matters for “who holds the contract,” and it has followed the corporate lineage forward to Peraton. Tenable still supplies the engine, and Tenable is still independent and publicly traded (NASDAQ: TENB) as of this writing, despite the take-private rumors that circulate about basically every security vendor now. So “who makes it” hasn’t changed hands the way Fortify or Wiz have.

The naming, though. The console in older docs, older STIGs, and frankly most people’s muscle memory is Tenable.sc (and before that, SecurityCenter). Tenable has quietly walked that back. The current name in the 2026 documentation is just Tenable Security Center, on the 6.x line (6.8 shipped February 2026 with VPR data folded into the feed). The .sc shorthand isn’t dead in conversation, but if you’re writing an SSP narrative someone will read in two years, write “Tenable Security Center.” Same story on the passive side: Nessus Network Monitor is now Tenable Network Monitor. The active scanner is still Nessus. Agents are now Tenable Agents (was Nessus Agents).

One thing that is dead: the Log Correlation Engine. LCE shows as end-of-life across every version in Tenable’s current lifecycle matrix. If your ACAS architecture diagram still has an LCE box on it, that diagram is legacy. Don’t carry it forward and don’t cite it as a current capability. It isn’t one.

Piece Current name What it does Notes
Console Tenable Security Center (6.x) Aggregation, repositories, dashboards, Assurance Report Cards Was Tenable.sc, was SecurityCenter. The brain.
Active scanner Nessus Credentialed + uncredentialed vuln and compliance scans Distributed by segment; this is the part that “is” Nessus
Passive monitor Tenable Network Monitor (NNM) Discovery and traffic analysis off a SPAN/tap Finds the hosts your active scans never reach
Agents Tenable Agent Host-resident scanning for things you can’t reach over the network Useful for laptops, transient assets
~~Log Correlation Engine~~ (retired) (retired) End-of-life. Drop it.

Where it sits in the compliance flow

The governing instruction to point at is DoDI 8531.01, DoD Vulnerability Management, the current policy backbone for the whole vuln-management apparatus, IAVM included. USCYBERCOM CTO 08-005 is the original directive that made enterprise scanning mandatory, and you’ll still see it cited, but the operational tasking has moved through later USCYBERCOM task orders. For a memo, lead with 8531.01 and the active TASKORD rather than the fifteen-year-old CTO number.

ACAS exists to feed the rest of the machinery, not to be an end in itself. Findings map to CVE, IAVM identifiers (IAVA/IAVB), and STIG IDs in a single credentialed pass, and those mappings are what make the output usable downstream:

  • Into eMASS, where vulnerabilities become POA&M line items. There’s an official path for getting Security Center data in, but be honest about what it buys you: a lot of shops still massage exports because the automated ingest never quite covers every field the package reviewer wants.
  • Into the readiness assessment your command answers to, and here’s the terminology trap: CCRI is gone. JFHQ-DODIN retired Command Cyber Readiness Inspections and stood up CORA, the Cyber Operational Readiness Assessment, on March 1, 2024. Note it’s “Cyber,” not “Command Cyber”; people get the expansion wrong constantly. CORA dropped the old pass/fail inspection model for a risk-based, ATT&CK-informed posture assessment, with visit frequency driven by a multifactor analysis instead of a fixed calendar. If your runbook still says “CCRI prep,” it’s naming a program that doesn’t exist.

Cadence in practice: credentialed scans at least weekly, daily delta scans on the high-value stuff, continuous passive discovery via Tenable Network Monitor, and compliance/STIG audit runs on a monthly-ish rhythm that tightens whenever an assessment is on the calendar. Plugin feeds for air-gapped enclaves come down as offline differential pulls, and the offline activation dance is exactly as annoying as everyone says.

What it’s good at, and what it isn’t

The plugin coverage is genuinely strong. Tenable’s research output is one of the better ones in the business, and the audit files for STIG, CIS, and USGCB content track current benchmarks closely enough that you’re not fighting stale checks. A credentialed Windows or RHEL scan that comes back clean is meaningful signal. The repository and asset model handles a segmented enclave reasonably well once it’s laid out right. Emphasis on once: a sloppy repository design will have every team double-counting assets and your dashboards quietly lying about your licensed seat count.

Now the complaints, because there are real ones.

The on-prem console feels its age next to the SaaS product. Filters you want are buried three menus deep, and anyone who’s used Tenable Vulnerability Management (the cloud product, renamed from Tenable.io) finds Security Center clunky by comparison. A daily gripe, not a capability gap.

Credentialed scanning against fragile targets is the operational landmine. Run a default-policy credentialed scan against a domain controller, an ICS/OT segment, or a RHEL 7 box three patch cycles behind, and you can still cause an outage despite years of tuning guidance. The fix is per-asset-class policies and scan windows, not one omnibus policy you point at everything. Don’t run a single scanner against the whole enterprise either, or you’ll time out or get throttled by the network gear in between.

False positives on STIG audits are a recurring tax, especially registry checks that don’t account for a legitimate organizational setting or a third-party hardening tool that got there first. Service-account rot is the silent one: a GPO change strips your scan account’s rights, scans degrade to uncredentialed, and coverage looks fine on the dashboard while measuring almost nothing. Watch the credentialed-scan success rate, not just the green tile.

Here’s my flag, and it’s contestable: most ACAS findings backlogs aren’t a scanning problem, they’re a remediation-ownership problem, and bolting a fancier scanner onto the front of it won’t help. DISA’s next-gen ACAS RFI (April 2025) describes a system that can scan roughly 11 million DoDIN devices every 72 hours, AI analytics and all, with a performance period running toward 2030. Fine. But the bottleneck in most enclaves isn’t “we can’t find the vulns fast enough.” It’s that the POA&M has four hundred open items and no clear owner for half of them. Scanning faster just produces the same backlog faster. The capability is worth having; I just don’t buy that throughput is the constraint that’s actually hurting people.

Deployment shape and the control ties

The shape that survives contact with reality: one Security Center per enclave or security boundary, Nessus scanners distributed by network segment with dedicated least-privileged-but-audit-capable scan accounts, and Tenable Network Monitor hung off SPAN ports at the choke points where traffic concentrates. Wire syslog out to whatever the SOC runs (Splunk if you have it, otherwise the messier Elastic ingest path), set up the eMASS path early rather than as an afterthought, and put a ticketing hook into ServiceNow or Jira so findings get assigned instead of dying in a dashboard nobody opens.

On the NIST SP 800-53 side, ACAS is first and foremost an RA-5 instrument: vulnerability monitoring and scanning, full stop. That’s the headline, and where ACAS output is load-bearing in an ATO package. Around it: CM-6 for the STIG/SCAP configuration-setting checks, CM-8 because the scan data doubles as system inventory, SI-2 for flaw-remediation tracking, SI-4 for monitoring inputs, and CA-7 because the whole cadence is your continuous-monitoring evidence. Credentialed scans also touch AC-2 and AC-6 sideways, since the privileged scan account itself is a thing you govern and account for. Don’t oversell that last one in a narrative; an assessor knows the difference between ACAS evidencing account control and ACAS being an access control.

Deeper: why “we run ACAS” is not the same as “we run Nessus.” A commercial Nessus or Tenable Vulnerability Management deployment is yours to version, tune, and feed on your own schedule. ACAS is not. The licensing, the approved builds, the plugin feed, and often the scan policies come down through DISA and the ACAS PMO, and the value of the program is precisely that constraint: every DoD enclave scans against validated content rather than whatever each team happened to configure. You give up agility for defensibility. You can’t grab a brand-new plugin the day it drops, but you also never have to defend your baseline to a CORA team, because it’s the mandated one. Fighting that trade (running off-baseline because the commercial release fixed something sooner) is how you turn a clean assessment into a finding.

ACAS isn’t glamorous and it isn’t optional. Keep the feed current through the PMO, tune policies per asset class, govern the scan accounts, and pipe the output into the systems your team already lives in. Done that way it’s the most useful single artifact in an RMF package. Done as a dashboard nobody trusts, it’s just noise with a DoD logo on it.

Sources

Adjacent material on this site