Category: Cloud Security & Providers

Secure Cloud Computing Architecture

Also known as:

Simply put

Secure Cloud Computing Architecture (SCCA) is a standardized set of cloud security and management services adopted by the U.S. Department of Defense (DoD) to help protect mission applications and data that run in commercial cloud environments. It defines a consistent way to secure the connection between DoD networks and the cloud, as well as the applications hosted there. Cloud providers such as AWS, Oracle, and Microsoft (through the related Secure Azure Computing Architecture) offer implementations designed to align with SCCA requirements.

Formal definition

SCCA is a DoD-adopted suite of enterprise-level cloud security and management services intended to provide a scalable, cost-effective, and standardized approach to boundary and application-level security for DoD mission workloads hosted in commercial cloud environments. Its requirements are defined in the DoD Secure Cloud Computing Architecture Functional Requirements Document (FRD); per the FRD, SCCA is intended to enable DoD mission applications operating at DoD Information System Impact Levels 2, 4, 5, and 6, with the Cloud Access Point (CAP) portion tailored to particular impact levels. Vendor SCCA implementations (for example, landing zones offered by cloud service providers) are designed to align with these functional requirements, but readers should verify the current FRD revision, the specific impact levels supported by a given implementation, and applicable DISA guidance against official sources, as scope and tailoring can vary by revision and by authorization. Note that SCCA addresses architecture and security services and is distinct from the authorization process itself; deploying an SCCA-aligned architecture does not by itself confer an Authority to Operate.

Why it matters

For DoD components and their contractors, moving mission applications and data into commercial cloud environments introduces boundary and application-level security challenges that must be resolved consistently rather than reinvented for each program. SCCA matters because it gives the Department a standardized, enterprise-level approach to securing the connection between DoD networks and commercial cloud offerings and to protecting the workloads hosted there. Without a common architecture, each mission owner would face inconsistent boundary protections, uneven management services, and greater risk of misconfiguration when connecting sensitive workloads to commercial infrastructure.

SCCA also shapes how cloud service providers position their offerings for the defense market. Vendors such as AWS and Oracle publish SCCA-aligned landing zones, and Microsoft offers the related Secure Azure Computing Architecture (SACA) as a way for DoD and civilian customers to align with the SCCA Functional Requirements Document (FRD). This alignment gives mission owners a starting point that is designed to map to DoD functional requirements, but the burden of confirming that a given implementation meets the applicable requirements, and supports the impact levels a workload actually needs, remains with the DoD customer.

A critical point for compliance officers and authorizing officials is that SCCA is an architecture and a set of security services, not an authorization. Deploying an SCCA-aligned architecture does not by itself confer an Authority to Operate (ATO). Treating adoption of a vendor's SCCA landing zone as equivalent to being authorized, or as equivalent to being secure, is a common and consequential mistake; the architecture must still be assessed and authorized under the applicable DoD process, and readers should verify the current FRD revision and applicable DISA guidance against official sources.

Who it's relevant to

DoD Mission Owners and Program Managers

Teams responsible for hosting DoD mission applications in commercial cloud environments use SCCA to obtain a standardized approach to boundary and application-level security. They must confirm which impact levels their workloads require and verify that a chosen SCCA-aligned implementation supports those levels, noting that only the Cloud Access Point portion is tailored to particular impact levels.

Authorizing Officials and ISSMs

Authorizing officials and Information System Security Managers should recognize that an SCCA-aligned architecture is not the same as an authorization. SCCA provides security services and architecture, but an ATO must still be obtained through the applicable DoD process, and the architecture's controls must be assessed against current requirements rather than assumed compliant.

Cloud Service Providers Serving DoD

Providers such as AWS and Oracle, and Microsoft through the related Secure Azure Computing Architecture (SACA), design landing zones and reference architectures intended to align with the SCCA FRD. These vendors must map their offerings to the FRD's functional components and be transparent about which impact levels their implementations actually support.

Government Contractors and Systems Integrators

Contractors building or migrating DoD workloads to commercial cloud must design to the applicable SCCA functional requirements and confirm the current FRD revision and DISA guidance. They should avoid treating vendor marketing claims about impact-level coverage as authoritative and verify supported impact levels against official sources.

Inside SCCA

Cloud Access Point (CAP)

The boundary protection component that provides a controlled connection between DoD networks (such as the DISN/NIPRNet) and commercial cloud service offerings. Per the SCCA Functional Requirements Document, the CAP portion is tailored to protect and inspect traffic to and from cloud environments hosting Impact Level 4 and 5 data, while the broader SCCA construct supports mission applications operating across DoD Impact Levels 2, 4, 5, and 6.

Virtual Datacenter Security Stack (VDSS)

A virtualized set of security controls and inspection capabilities intended to provide boundary and traffic protection for application workloads hosted within the commercial cloud environment, including functions such as traffic inspection, filtering, and monitoring at the virtualized network layer.

Virtual Datacenter Managed Services (VDMS)

A component providing shared security and management services within the cloud environment, generally including capabilities such as identity and access management support, directory services, and other enterprise-level managed functions that support hosted mission applications.

Trusted Cloud Credential Manager (TCCM)

The component addressing privileged credential and access management within the SCCA construct, intended to govern and control administrative and privileged access to the cloud environment consistent with DoD access management expectations.

SCCA Functional Requirements Document (FRD)

The authoritative DISA document (FRD v2.9, dated 31 January 2017, and subsequent versions) that defines the functional requirements for SCCA. It states that SCCA enables DoD mission applications operating at all DoD Information System Impact Levels (2, 4, 5, and 6), while noting that the CAP portion is tailored to Impact Levels 4 and 5. Readers should verify the current authoritative revision, as requirements may change across versions.

Common questions

Answers to the questions practitioners most commonly ask about SCCA.

Does SCCA apply only to Impact Level 4 and 5 workloads?

No. The Secure Cloud Computing Architecture Functional Requirements Document (FRD v2.9, 31 Jan 2017) states that SCCA is intended to enable DoD mission applications operating at all DoD Information System Impact Levels (i.e., IL2, IL4, IL5, and IL6). A common source of confusion is that the Cloud Access Point (CAP) component in particular is often tailored to IL4 and IL5 boundary requirements, which leads some readers to assume the architecture as a whole is limited to those levels. Readers should verify current applicability and any level-specific tailoring against the governing DISA documentation, because impact-level treatment and boundary requirements can differ by component and may change across revisions.

Is SCCA the same thing as a FedRAMP authorization for a cloud service?

No. SCCA is a DoD architecture defined by DISA to secure the boundary and connection between DoD networks and commercial cloud services, whereas FedRAMP is a separate authorization program maintained by the FedRAMP PMO for federal cloud service use. They are distinct authorities and do not automatically satisfy one another; a FedRAMP authorization does not by itself meet DoD SCCA or DoD Cloud Computing Security Requirements Guide expectations. Confirm the specific interplay between any cloud provider authorization and DoD requirements against current official DISA and DoD CIO guidance.

What are the core components of a SCCA implementation?

As described in DISA's Secure Cloud Computing Architecture guidance, SCCA is generally composed of four canonical components: the Cloud Access Point (CAP), the Virtual Data Center Security Stack (VDSS), the Virtual Data Center Management/Managed Services (VDMS), and the Trusted Cloud Credential Manager (TCCM). Each addresses a distinct function within the boundary and management model. Implementers should confirm the current component definitions and responsibilities against the applicable DISA documentation, as tailoring and terminology may evolve.

Which document should we treat as the governing reference for SCCA requirements?

The primary reference is the Secure Cloud Computing Architecture Functional Requirements Document (FRD), including the v2.9 edition dated 31 January 2017 and any subsequent revisions. Implementers should anchor design decisions to the current authoritative FRD and related DISA guidance rather than to vendor marketing materials, and should verify that they are working from the latest applicable version before making architecture or authorization decisions.

How does the Cloud Access Point differ in scope from the rest of the SCCA components?

The CAP functions as the boundary connection point between DoD networks and the cloud environment, and DISA guidance frequently describes CAP requirements as tailored to particular impact-level boundary conditions. This is why CAP treatment may be described differently from the broader architecture, which the FRD associates with multiple impact levels. Because CAP tailoring and boundary requirements are level-sensitive and subject to revision, verify the specific CAP requirements applicable to your workload's impact level against current DISA documentation.

Does meeting the SCCA architecture mean our system is authorized to operate?

No. Implementing the SCCA components addresses architectural and boundary security requirements, but it is not the same as obtaining an Authority to Operate. Authorization is a separate determination made by the responsible authorizing official, and an ATO is time-bound and subject to continuous monitoring rather than permanent. Teams should treat SCCA conformance and the authorization decision as distinct steps and confirm the governing RMF and authorization process against current DoD guidance.

Common misconceptions

SCCA applies only to Impact Level 4 and 5 data.

According to the SCCA Functional Requirements Document, SCCA enables DoD mission applications operating at all DoD Information System Impact Levels (2, 4, 5, and 6). It is specifically the Cloud Access Point (CAP) portion that is tailored to Impact Levels 4 and 5; the broader architecture is not limited to those levels.

SCCA is a single product or appliance a provider can simply deploy.

SCCA is an architecture defined by functional requirements across four components (CAP, VDSS, VDMS, and TCCM). It describes required capabilities rather than a single procurable product, and its components may be implemented in different ways depending on the cloud service offering and mission owner.

Meeting SCCA functional requirements is the same as holding an Authority to Operate (ATO).

Implementing the SCCA architecture supports, but does not by itself constitute, authorization. Systems still proceed through the applicable DoD authorization process and remain subject to continuous monitoring; compliance with the architecture is distinct from an authorization decision, which is time-bound and separate from assessment.

Best practices

Consult the current authoritative version of the SCCA Functional Requirements Document rather than relying on vendor marketing materials, which have been observed to overstate or misstate Impact Level coverage.

Determine the applicable DoD Information System Impact Level (2, 4, 5, or 6) for your workload early, and note that the Cloud Access Point (CAP) portion is specifically tailored to Impact Levels 4 and 5.

Address all four SCCA components, Cloud Access Point, Virtual Datacenter Security Stack, Virtual Datacenter Managed Services, and Trusted Cloud Credential Manager, when planning an implementation, rather than treating SCCA as a single product.

Coordinate with DISA and the relevant authorizing official to confirm current SCCA expectations, since guidance and requirements may evolve across FRD revisions.

Do not treat SCCA conformance as equivalent to an authorization; continue through the applicable DoD authorization process and maintain continuous monitoring, recognizing that an ATO is time-bound.

Verify privileged access controls through the Trusted Cloud Credential Manager component to ensure administrative access to the cloud environment is governed consistent with DoD access management expectations.