DISA ACAS Explained: What the Vulnerability Scanning Tool Means for DoD SaaS Vendors

The Department of Defense (DoD) scans roughly 11 million devices on the DoD Information Network as part of its vulnerability management efforts across the defense enterprise. That effort uses the Assured Compliance Assessment Solution (ACAS) to assess systems against DoD security standards and identify known vulnerabilities.

Official DoD cloud and Risk Management Framework (RMF) guidance generally assigns vulnerability-scanning and related security responsibilities to the Mission Owner, with some capabilities potentially provided by the SaaS or cloud provider. Findings from DoD vulnerability and compliance assessments affect whether vendors obtain and maintain their DoD authorization.

Understanding how ACAS works, and what it requires indirectly, is necessary for any SaaS company serious about winning and retaining Defense contracts.

Key Takeaways

• ACAS shapes authorization. ACAS is a DoD-operated scanning tool used to assess systems connected to DoD environments. Vulnerability and compliance findings gathered during DoD assessments are part of the evidence considered in granting and maintaining a Provisional Authorization (PA), including through continuous monitoring and annual assessments.
• FedRAMP is foundational. Federal Risk and Authorization Management Program (FedRAMP) authorization provides the foundation for DoD Impact Levels 4 (IL4) and 5 (IL5). DoD use cases generally require FedRAMP as a base, with additional DoD-specific requirements layered on top.
• DoD adds overhead. DoD cloud authorization and Security Technical Implementation Guide (STIG) compliance can quickly add operational overhead.
• Inherited controls help. A pre-authorized FedRAMP boundary can take on much of the infrastructure-layer compliance burden. Inheriting required controls from an already-authorized boundary can shorten the authorization timeline and reduce duplicated remediation work.

DISA ACAS Is a DoD Internal Scanning Program That Shapes SaaS Authorization Outcomes

ACAS directly shapes whether a SaaS vendor earns and keeps DoD authorization. It is a DoD-operated scanning tool used to assess systems connected to DoD environments, and the vulnerability and compliance findings it generates become part of the evidence reviewed when granting and maintaining a Provisional Authorization (PA), including through continuous monitoring and annual assessments.

ACAS is a suite of Commercial Off-the-Shelf (COTS) tools that the Defense Information Systems Agency (DISA) established in 2012 to assess DoD enterprise networks against department standards. It runs on Tenable's product stack, which includes:

• Tenable.sc: Central management console that aggregates scan data, dashboards, and reporting across the ACAS deployment.
• Nessus scanners: Active vulnerability detection engine that also performs STIG configuration assessment and Common Vulnerabilities and Exposures (CVE) checks.
• Nessus Network Monitor: Passive traffic analysis component used to discover assets and identify vulnerabilities without active probing.

Together, these tools cover vulnerability management, compliance assessment, and asset discovery across DoD networks.

For SaaS vendors, the practical takeaway is straightforward: your environment must be architected to be assessed against DoD security requirements during the PA process and on an ongoing basis. Findings produced during those assessments feed directly into the authorization decision and into continuous monitoring afterward.

The compliance question then centers on how DoD cloud policy assigns scanning, assessment, and remediation responsibilities across the service stack.

How ACAS Creates Indirect Compliance Obligations for SaaS Vendors

DoD cloud policy allocates responsibility differently across Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and SaaS, while still holding the prime Cloud Service Provider (CSP) responsible for complete compliance within its offering. For SaaS vendors, the operational burden depends on where the system boundary sits, which controls are inherited, and which findings remain theirs to remediate.

Scanning Responsibility by Cloud Service Layer

The DoD Cloud Computing CC SRG v1r2 applies security requirements by cloud service model, identifying IaaS, PaaS, and SaaS:

• IaaS: The Mission Owner bears the most scanning responsibility, deploying and operating their own ACAS instance for guest operating systems and applications.
• PaaS: Responsibility varies by contract. The CC SRG requires the delineation to be documented in the Service Level Agreement.
• SaaS: The CSP is responsible for security of the cloud-based hardware, virtual machine environment, operating system, and application. Mission Owners do not deploy ACAS against CSP infrastructure at the SaaS layer.

SaaS treatment in the CC SRG still carries an important condition. The DoD Cloud Computing CC SRG v1r2 states that "while the CSP's overall service offering may be inheriting controls and compliance from a third party, the prime CSP is ultimately responsible for complete compliance." For AWS GovCloud deployments, DoD and DISA guidance emphasizes a shared-responsibility approach in which scanning and security obligations depend on the system boundary and inherited controls.

STIG Configuration Compliance Across a Typical SaaS Stack

Security Technical Implementation Guides are DISA's product-specific configuration standards, and DoD Instruction (DoDI) 8500.01 is cited as mandating STIG and Security Requirements Guide (SRG) compliance for Department of Defense information technology systems. A SaaS vendor deploying a typical application stack can face hundreds of findings before accounting for network infrastructure, container platforms, or identity systems.

Key points to understand about STIG compliance within ACAS:

• Two scan types: Within ACAS, Nessus supports separate vulnerability scans and compliance scans.
• Standards used: Compliance scans use the Security Content Automation Protocol (SCAP) and/or the Extensible Configuration Checklist Description Format (XCCDF), or custom audit content, to assess configuration against DoD baselines.
• Wide coverage: Findings typically span the application, database, web server, and application server layers.
• CAT I findings: Category I (CAT I) findings are the highest-severity category and demand immediate remediation.
• CAT II findings: Category II (CAT II) findings can typically be mitigated but still require formal documentation.

Those obligations continue after the initial assessment. Once FedRAMP is in place as the baseline, DoD-specific operating requirements add another layer of cost, staffing, and monitoring burden.

Costs That Compound on Top of FedRAMP Authorization

FedRAMP authorization is the prerequisite for DoD IL4 and IL5. The sequential pipeline works as follows: FedRAMP Moderate authorization feeds IL4 (Controlled Unclassified Information, or CUI), while FedRAMP High authorization feeds IL5 (higher-sensitivity CUI and unclassified national security systems). 

Per the DoD Cloud Computing SRG V1R6 (December 2025), there is no longer a path to IL5 authorization using the FedRAMP Moderate baseline. Beyond that baseline, the added burden extends to scan frequency, reporting structure, staffing constraints, and network architecture, all of which sit atop FedRAMP.

1. Scanning Cadence

FedRAMP requires monthly authenticated vulnerability scanning, and the current DoD minimum under DoDI 8531.01 also specifies monthly scans. DISA's April 2025 Next-Generation ACAS RFI on SAM.gov proposed a target cadence of at least every 72 hours, a substantial increase over the current FedRAMP monthly minimum, with a planned contract period from November 2025 through October 2030. That target represents a major increase over FedRAMP's monthly requirement.

2. Dual Reporting Streams

Vendors with both civilian agency FedRAMP customers and DoD IL4/IL5 customers must maintain separate reporting streams. FedRAMP continuous monitoring feeds the Joint Authorization Board (JAB) or sponsoring agency. DoD continuous monitoring feeds the Mission Owner's authorization chain. These reporting obligations do not satisfy each other.

3. Personnel Restrictions

The CC SRG requires that CSP personnel with access to IL4 and IL5 data be restricted to U.S. citizens, U.S. nationals, or U.S. persons. No foreign persons may have such access. This directly constrains which staff members can work on vulnerability remediation in production systems and adds hiring and clearance overhead.

4. Network Constraints

Network architecture imposes a physical constraint: IL4 and IL5 connectivity must be routed through a DISA Cloud Access Point via the Non-classified Internet Protocol Router Network (NIPRNet). That requirement shapes how SaaS architectures connect to Mission Owner environments and can require dedicated network engineering work.

5. Compounding Operational Overhead

Continuous monitoring requires dedicated headcount and infrastructure, in addition to FedRAMP. Dual reporting streams, U.S.-person staffing, STIG remediation across large numbers of findings, and faster scanning cadences all layer on top of each other. Every line item is predictable, but most vendors discover them one at a time, after budget approval.

A pre-authorized infrastructure boundary changes the starting point. If the infrastructure layer is already authorized, continuously scanned, and maintained against DoD baselines before your application deploys, the SaaS team starts with fewer infrastructure controls to build and document.

How a Pre-Authorized FedRAMP Boundary Reduces the ACAS Compliance Surface

The compliance burden described above concentrates at the infrastructure layer: operating systems, network configurations, database hardening, web server settings, encryption implementation, and continuous monitoring tooling. A pre-authorized FedRAMP boundary can take on much of this infrastructure-layer burden, allowing the SaaS team to focus its implementation effort on the application layer.

Ways a pre-authorized boundary helps:

• Inherited controls: Many required security controls may already be implemented, documented, and assessed before the SaaS vendor deploys.
• Clear boundary documentation: A Third-Party Assessment Organization (3PAO) documents the boundary between inherited and customer-responsible controls and evaluates the system against the applicable National Institute of Standards and Technology (NIST) 800-53 baseline.
• Infrastructure-layer coverage: The boundary can handle physical and network security, encryption, identity management, audit logging, automated remediation, and continuous monitoring.
• Pre-handled STIG findings: Infrastructure STIG findings, CAT I database vulnerabilities, web server configuration checks, and operating system hardening requirements are inherited rather than remediated from scratch.
• Narrower residual scope: The vendor's remaining obligations focus on application-level access controls, application-specific logging, data classification, and customer-specific integrations.

Vendors evaluating a pre-authorized boundary for DoD-specific use cases should seek direct clarification on ACAS fit for IL4/IL5 environments.

The Cost of Waiting Grows With Every Procurement Cycle

Every quarter a SaaS vendor delays FedRAMP authorization is a quarter of evolving compliance expectations, growing remediation backlogs, and lost opportunity, while competitors who moved first may have already secured agency sponsorship and benefit from authorization reuse across federal procurement. The ACAS-driven requirements are specific, and the operational demands compound, so the choice is whether to absorb those costs at the infrastructure layer or inherit them from a boundary that has already done the work.

Knox Systems is a FedRAMP-as-a-Service platform that operates a pre-authorized boundary, covering FedRAMP Moderate, FedRAMP High, and DISA IL-4 (IL-5 authorization in process, estimated December 2026), meaning SaaS vendors can inherit most infrastructure-layer controls rather than owning the full ACAS-related compliance surface themselves. 

Knox's platform uses that control-inheritance model to compress the path to FedRAMP and position vendors for DoD PA assessment, with the infrastructure boundary handling encryption, identity, audit logging, and continuous monitoring out of the box.

Ready to see how much of the ACAS compliance surface you can inherit? Book a meeting.

FAQs About DISA ACAS and DoD SaaS Authorization

How Long Does It Typically Take to Get a DoD Provisional Authorization After FedRAMP?

Timelines vary by Mission Owner and impact level, but vendors should generally plan for several additional months after FedRAMP authorization to complete the DoD PA assessment, package review, and onboarding for continuous monitoring. Inherited controls from a pre-authorized boundary can shorten that window because much of the infrastructure-layer evidence is already in place.

What Happens if an ACAS Scan Identifies a CAT I Finding in Production?

CAT I findings are treated as the highest severity and generally require immediate remediation or a formal risk acceptance with compensating controls. Unresolved CAT I findings can place the PA at risk during continuous monitoring and can be flagged in the Mission Owner's authorization chain, so vendors usually maintain a documented response process tied to scan cadence.

Can a SaaS Vendor Use Its Own Vulnerability Scanner Instead of ACAS?

Vendors typically run their own scanners for internal vulnerability management and FedRAMP continuous monitoring, but those tools do not replace ACAS when the system is connected to the DoD Information Network (DoDIN). DoD assessments rely on ACAS-generated artifacts, so vendor environments must be architected to produce evidence that aligns with ACAS and the Mission Owner's expectations.

Does ACAS Apply Differently to IL4 Versus IL5 Environments?

The scanning methodology is consistent, but IL5 environments carry tighter constraints around personnel, network routing, and the sensitivity of findings. IL5 typically demands stricter handling of scan output, more restrictive access to remediation workflows, and closer alignment with national security system controls than IL4.

How Often Do STIG Baselines Change, and What Does That Mean for Vendors?

DISA publishes quarterly STIG updates and revises individual product STIGs as vendor software changes. SaaS teams should expect to absorb new or modified checks every quarter, which means configuration baselines, automation scripts, and remediation runbooks need ongoing maintenance rather than a one-time hardening effort.