Secure Cloud Computing Architecture: DISA's Four Components

Department of War (DoW, formerly the Department of Defense) mission owners hosting Impact Level 4 (IL-4) or Impact Level 5 (IL-5) data in commercial cloud must use the Secure Cloud Computing Architecture's (SCCA) Cloud Access Point (CAP) to connect to the Defense Information Systems Network (DISN). SaaS vendors selling into DoW environments inherit related requirements through their mission-owner customers, which means the boundary work happens before a product ever deploys.

The Defense Information Systems Agency (DISA) published version 2.9 of the SCCA Functional Requirements Document (FRD) on January 31, 2017, and that document defines the functional requirements discussed here. The Federal Risk and Authorization Management Program (FedRAMP) provides the underlying authorization baseline discussed below.

The architecture names four components: the CAP, the Virtual Data Center Security Stack (VDSS), Virtual Data Center Managed Services (VDMS), and the Trusted Cloud Credential Manager (TCCM).

Key Takeaways

• SCCA is mandatory. All Impact Level 4 and 5 data in commercial cloud must connect to the DISN through a Cloud Access Point.  
• The components stack. The CAP defends the network boundary, the VDSS inspects traffic inside the cloud, VDMS secures hosts and management services, and the TCCM governs privileged credentials.  
• TCCM governs credentials. A person appointed by the Authorizing Official owns the Cloud Credential Management Plan and enforces least-privilege access to cloud portals.  
• FedRAMP High sits beneath. A FedRAMP High provisional authorization is accepted toward DoW IL-4, while IL-5 adds DoW FedRAMP+ security controls and additional separation requirements.

DISA Created SCCA to Unify DoW Cloud Security Under One Framework

The SCCA is a portfolio of enterprise cloud security services designed to sit between the DISN and commercial cloud. Per the SCCA FRD V2.9, its purpose is to provide a protective barrier between the DISN and commercial cloud services used by the DoD while improving the cost-performance trade in cybersecurity.

SCCA delivers the security capabilities defined by the DoD Cloud Computing Security Requirements Guide V1R6 (CC SRG), dated December 2025. The DCCS Document Library provides current DoW cloud-security publications for providers and mission owners.

Per the Department of the Navy CIO, all Impact Level 4 and 5 data hosted in commercial cloud must connect to the DISN through the SCCA's CAP. That connection requirement establishes the outer boundary; the remaining SCCA components extend control through the cloud environment and its privileged-access layer.

The Four SCCA Components Form a Layered Defense-in-Depth Boundary

SCCA's four components must operate as one defense-in-depth stack because no single control covers the full path from the DISN boundary to cloud administration. Each layer addresses a distinct part of that path, so an attacker who gets past one layer meets the next.

1. The Cloud Access Point Controls Traffic Entering DoW Cloud Environments

The CAP is the connection point between the Department of Defense Information Network (DODIN), including the Non-Secure Internet Protocol Router Network (NIPRNet), and commercial cloud. It has two jobs: provide mission owners with connectivity to approved cloud providers and protect the DISN from attacks originating inside the cloud environment. CAPs provide CAP boundary defense capabilities; they do not perform break-and-inspect or application security.

The Boundary Cloud Access Point (BCAP) provides the boundary connection between the DISN and commercial cloud. All IL-4 and IL-5 workloads hosted in the commercial cloud must use the CAP when connecting to the DISN.

The Internal Cloud Access Point (ICAP) is a cybersecurity stack protecting the DISN or datacenter network from unauthorized access originating in the cloud service provider (CSP) infrastructure, typically deployed for each physical cloud infrastructure instance. DoW primary documentation identifies BCAP and ICAP as the two CAP types.

2. The VDSS Enforces Security Policy Inside the Virtual Data Center Perimeter

The VDSS carries much of SCCA's day-to-day traffic inspection and application-protection work. The FRD requires it to:

• inspect traffic entering and exiting each mission owner virtual private network;  
• filter traffic between mission owner enclaves; and  
• perform break-and-inspect of Secure Sockets Layer/Transport Layer Security (SSL/TLS) communications destined for systems inside the cloud environment.

In practice, it replicates a traditional data center security stack in virtual form: Web Application Firewall guidance (WAF) and firewalls detect and block threats to web applications and workloads, while intrusion detection and prevention systems (IDS/IPS) monitor network activity and stop detected malicious traffic.

Who operates the VDSS is flexible. SCCA offers a suite of services that meet the defined requirements, but those capabilities may also be acquired from other service providers. Because these requirements are not specific to a cloud provider, a DoW application or mission owner can deliver them directly, provided they meet the FRD requirements.

3. The VDMS Provides Managed Security Services to Mission Owners in the Cloud

VDMS supplies host security and shared data center services beneath the mission owner's workloads. The FRD defines its core capabilities:

• A Host-Based Security System (HBSS), or approved equivalent, to manage endpoint security for all enclaves in the cloud environment.  
• Assured Compliance Assessment Solution (ACAS), or an equivalent system, for continuous monitoring.  
• Cloud-based instances of DoW patch repositories, security policy configuration and delivery, and privileged user access.  
• The TCCM function, which is currently offered as part of VDMS.

The VDSS inspects packets in transit at the virtual perimeter; VDMS keeps the hosts, endpoints, and security configurations behind that perimeter current and compliant. DISA offers enterprise implementations of both but doesn't require mission partners to use them; mission owners may develop or acquire equivalents that meet the SRG requirements.

4. The TCCM Governs Identity and Privileged Access Across the Cloud Boundary

The TCCM consists of a person and credential-management processes. Appointed by the Authorizing Official, the TCCM performs the following duties:

• Establishes plans and policies for account access to the cloud environment.  
• Maintains the Cloud Credential Management Plan.  
• Enforces least-privilege access for privileged accounts managed through the CSP's identity system.  
• Creates, issues, and revokes role-based, least-privilege customer portal credentials for DoW privileged users, as directed by the FRD.

These duties map to the National Institute of Standards and Technology (NIST) Special Publication 800-53 Rev5 (September 2020). Access Control (AC) and Identification and Authentication (IA) control families: account management, least privilege, and multifactor authentication.

The role earns its place among the four components because privileged portal credentials control the tenant itself, a layer above the traffic the VDSS inspects. The cloud security advisory AA24-057A from the Cybersecurity and Infrastructure Security Agency (CISA) documents Russian Foreign Intelligence Service (SVR) actors using stolen account credentials and access tokens to reach cloud-hosted government accounts. Those controls depend on clear operational ownership. That dependency makes allocating duties among DISA, mission owners, and CSPs part of the architecture itself.

SCCA Assigns Distinct Responsibilities to DISA, Mission Owners, and CSPs

DISA, cloud service providers, and mission owners divide SCCA responsibilities under the FRD and current cloud-security publications.

• DISA publishes the SCCA FRD and DoW cloud-security requirements and operates the BCAP and ICAP connection process. DISA cyber personnel work with DoW Authorizing Officials to verify applicable components and controls before issuing an Authority to Operate (ATO).  
• Cloud service providers are responsible for the underlying cloud infrastructure and may supply VDSS capabilities, though mission owners or third parties may deliver them instead. For typical Infrastructure-as-a-Service (IaaS) and Platform-as-a-Service (PaaS) deployments, the FRD assigns CAP, VDSS, VDMS, and TCCM requirements to the CSP or an authorized Security-as-a-Service provider.  
• Mission owners procure, deploy, and securely operate the mission systems: maintaining trusted configuration baselines, performing continuous monitoring, routing internet-facing applications through the CAP and VDSS, encrypting DoW files in the cloud instance, configuring portal credentials for least privilege, and administering the TCCM role. The DCCS Document Library maintains the applicable requirements.

For a SaaS vendor, your product lands inside the mission owner's slice of the model, and your customer carries SRG obligations your architecture must support. Those obligations surface in the customer's authorization package, so the architecture questions arrive well before deployment.

FedRAMP High and SCCA Define the Authorization Foundation for DoW Workloads

The FedRAMP minimum security baseline applies to DoW cloud services, with DoW FedRAMP+ security controls adding DoW-specific requirements.

IL-4 covers Controlled Unclassified Information (CUI). Under the DoW reciprocity model, a FedRAMP High provisional authorization counts toward an IL-4 provisional authorization, while the SRG's non-control requirements still get assessed. IL-5 covers higher-sensitivity CUI and unclassified National Security Systems; it requires a FedRAMP High authorization plus DoW FedRAMP+ control enhancements and additional separation requirements.

For SaaS vendors deploying into these environments, the practical consequence is the same sequencing: the FedRAMP authorization process comes before DoW eligibility. One way vendors shorten that sequence is by deploying onto a pre-authorized boundary: an existing FedRAMP-authorized environment whose common controls the vendor's product inherits, rather than standing up and authorizing its own boundary from scratch.

Inheriting a boundary that already supports FedRAMP High and DISA IL-4 (and, where available, IL-5) shifts much of the control implementation and assessment work into the boundary provider's existing authorization package. That authorization scope makes the SCCA-compliant deployment boundary an upfront architecture decision, not a deployment-stage task.

SCCA Compliance Is a Prerequisite for DoW Cloud Access, Not an Option

SCCA compliance is not optional for any SaaS vendor that wants to reach DoW IL-4 or IL-5 customers, and the deployment-boundary decision that determines how you meet it is the single choice that gates DoW eligibility. When they decide early, eligibility follows the product; when they defer, every downstream milestone slips.

Knox Systems provides a pre-authorized FedRAMP boundary spanning Amazon Web Services (AWS), Azure, and Google Cloud. It supports FedRAMP Moderate, FedRAMP High, and DISA IL-4 today, with IL-5 in process (estimated December 2026). SaaS vendors on the boundary can inherit 60% to 80% of required NIST SP 800-53 Rev5 controls and reach authorization in approximately 90 days at roughly 90% less than traditional costs.

If you are scoping what SCCA-compliant deployment demands of your product, book a meeting with Knox to map your path to DoW-eligible authorization.

FAQs about Secure Cloud Computing Architecture

What Are the Four Types of Cloud Architecture?

Cloud deployment models include four types: public, private, community, and hybrid. DoW further narrows deployment options based on the data's sensitivity and impact level.

What Are the General Components of Cloud Computing Architecture?

General cloud architecture models describe five cloud architecture actors (consumer, provider, auditor, broker, and carrier). The service layer sits above the resource abstraction and control layer, which in turn sits above the physical resource layer. SCCA adds DoW-specific security components on top.

What Are the Main Tenets of DoW Cloud Computing Security?

The main DoW cloud security tenets are isolation, containment, redundancy, layers of defense, least privilege, situational awareness, and physical and logical segmentation. Mission owners must also register their cloud connections in DISA's SNAP Cloud Module before connecting to the DISN.

‍