Skip to main content
Category: Cloud Security & Providers

Cloud Access Point

Also known as: CAP, DISA CAP
Simply put

A Cloud Access Point (CAP) is a security capability that connects the Department of Defense's internal network to commercial cloud services while protecting that network from threats originating in the cloud. It handles the connection between DoD networks and the cloud provider and provides boundary protection so that traffic can be monitored and filtered. In most DoD implementations, the CAP is a required part of the architecture for hosting mission systems in a commercial cloud.

Formal definition

Within the DoD Secure Cloud Computing Architecture (SCCA), a Cloud Access Point (CAP) is the capability that connects the Defense Information Systems Network (DISN) or NIPRNet to a commercial Cloud Service Offering (CSO), performing interface translations necessary for CSO compatibility and providing boundary protection of the DISN. According to the referenced evidence, CAP variants include the Boundary CAP (BCAP) and the Internal CAP (ICAP), among others; the BCAP is intended to protect the DISN from attacks originating in the cloud environment and performs functions such as intrusion detection. Note that ICAP in this context denotes 'Internal Cloud Access Point,' not an 'Internet CAP.' Practitioners should treat the CAP as one element of a broader secure cloud architecture and confirm the current authoritative definitions, variants, and connection requirements against the applicable revision of the DISN Connection Process Guide and DoD Cloud Computing SRG, as terminology and requirements may change across revisions.

Why it matters

The Cloud Access Point matters because it is the enforced boundary between the Department of Defense's internal networks and the commercial cloud services where mission systems increasingly run. Without a controlled point of connection, traffic moving between the DISN or NIPRNet and a commercial Cloud Service Offering would not be consistently monitored, filtered, or defended against threats originating in the cloud environment. The CAP concept exists so that DoD can adopt commercial cloud while still protecting the internal network it connects to, which is why it is generally a required element of the architecture for hosting DoD mission systems in a commercial cloud.

For practitioners, the CAP is a reminder that using an authorized commercial cloud is not the same as being connected to it securely. A Cloud Service Offering may carry a FedRAMP or DoD provisional authorization, but connecting that offering to the DISN generally still requires meeting DoD boundary-protection and connection requirements, of which the CAP is one part. Treating a cloud authorization as if it automatically satisfies DoD connection requirements is a common mistake; the CAP is where those DoD-specific network protection obligations are enforced.

Because the CAP is only one element of a broader secure cloud architecture, and because DoD terminology, variants, and connection requirements change across revisions, readers should confirm current details against the applicable revision of the DISN Connection Process Guide and the DoD Cloud Computing SRG rather than relying on any single description as permanent.

Who it's relevant to

DoD mission system owners and program managers
Teams planning to host DoD mission applications in a commercial cloud need to understand that connecting through a CAP is generally a required part of the architecture. Program managers should account for CAP connection requirements early, since they affect how a mission system reaches the DISN or NIPRNet and are distinct from obtaining a cloud service authorization.
Information System Security Managers and cloud security architects
ISSMs and architects implementing the DoD Secure Cloud Computing Architecture (SCCA) must design around the CAP's boundary-protection role and understand the distinction between variants such as the Boundary CAP (BCAP), which is intended to protect the DISN from cloud-originating attacks and performs intrusion detection, and the Internal Cloud Access Point (ICAP). They should confirm current variant definitions and functions against the applicable revision of authoritative DoD guidance.
Authorizing Officials and connection approval authorities
Those responsible for authorization and DISN connection decisions should recognize that a commercial cloud authorization does not by itself satisfy DoD connection requirements. The CAP is the enforced boundary where DoD-specific network protection obligations are met, and connection requirements should be validated against the current DISN Connection Process Guide.
Government contractors and cloud service providers supporting DoD
Vendors offering or integrating a commercial Cloud Service Offering for DoD workloads must understand that the CAP performs the interface translations necessary for CSO compatibility and provides boundary protection of the DISN. Contractors should verify the current connection and boundary-protection requirements against authoritative DoD sources rather than assuming a commercial or FedRAMP authorization is sufficient on its own.

Inside CAP

Cloud Access Point (CAP)
A security boundary construct used within the DoD environment to provide a controlled and monitored connection between DoD networks (such as the DISN) and cloud service offerings. A CAP generally provides boundary protection, traffic inspection, and a demarcation point for extending mission systems into commercial or DoD cloud environments. Readers should verify current requirements against the applicable version of the DoD Cloud Computing Security Requirements Guide (SRG) and the DISN Connection Process Guide.
Boundary Protection Function
The CAP typically performs perimeter security functions, such as filtering, traffic inspection, and monitoring, between the DoD network and the cloud service. This is intended to protect DoD networks from threats originating in or transiting through cloud environments. Specific protection mechanisms depend on the impact level and the governing SRG revision.
Internal Cloud Access Point (ICAP)
A CAP implementation type; the acronym ICAP is defined in authoritative DoD sources (for example, the DISN Connection Process Guide and DoD Cloud Computing SRG) as 'Internal Cloud Access Point.' It refers to a CAP operated internally rather than as a shared or externally provided service. There is no official DoD term 'Internet CAP.' Confirm the exact definition and applicability against the current authoritative text.
Impact Level Association
CAP requirements are generally tied to the information impact level of the data and workloads being connected, as categorized under the DoD Cloud Computing SRG. Higher impact levels typically carry more stringent connection and boundary requirements. The applicable impact levels and their requirements can change across SRG revisions and should be verified.
Connection Approval and Governance
Establishing and maintaining a CAP connection generally follows a DoD connection approval process governed by the DISN Connection Process Guide. This is distinct from a system's Authority to Operate; a CAP connection supports, but does not by itself constitute, an ATO for a mission system.

Common questions

Answers to the questions practitioners most commonly ask about CAP.

Does a Cloud Access Point (CAP) authorization mean the connected cloud service is fully compliant and secure?
No. A CAP provides a controlled boundary connection point that protects DoD networks from traffic traversing to and from a cloud service offering; it is not a statement that the cloud service or the mission system running on it is fully compliant or secure. Connection through a CAP addresses boundary protection and network defense functions, but it does not substitute for the cloud service's own authorization or for the mission owner's system-level security responsibilities. Compliance and security remain distinct concerns, and a CAP connection is only one element of a broader control and authorization posture. Verify specific responsibilities against the current DoD Cloud Computing Security Requirements Guide (SRG) and applicable connection process guidance.
What does the abbreviation ICAP stand for in the DoD cloud connection context, and is it a type of internet-facing CAP?
In DoD sources such as the DISN Connection Process Guide and the DoD Cloud Computing SRG, ICAP is generally defined as Internal Cloud Access Point, not an internet-facing or "Internet CAP." The "Internal" designation reflects its role and placement in the connection architecture rather than an internet orientation. Readers should not assume ICAP means an internet CAP. Confirm the precise definition, scope, and current usage against the applicable revision of the DISN Connection Process Guide and the DoD Cloud Computing SRG, as terminology and architecture designations can change across revisions.
How does a Cloud Access Point relate to the authorization of a cloud service offering?
A CAP and a cloud service authorization address different, complementary concerns. The CAP governs the protected connection between DoD networks and the cloud environment, while the cloud service offering's authorization addresses whether that service meets the applicable security requirements. Connecting through a CAP does not by itself authorize a cloud service, and an authorized cloud service still requires an appropriate connection path. Mission owners should confirm which authorizations and connection approvals apply to their specific impact level and use case against current DoD Cloud Computing SRG and connection process guidance, as requirements can vary by revision and by agency tailoring.
Who is responsible for establishing or operating a CAP, and what does a mission owner need to coordinate?
Responsibilities for CAP provisioning and operation, and the coordination steps a mission owner must follow, are defined in DoD connection process and cloud security guidance rather than being uniform across all environments. In general, mission owners coordinate their connection through the applicable connection approval process and align with the CAP architecture designated for their impact level. Because roles, ownership, and process steps can differ by component and by revision, confirm the specific responsibilities and coordination requirements against the current DISN Connection Process Guide, the DoD Cloud Computing SRG, and any component-specific direction.
Does the required CAP configuration change depending on the information impact level of the data being processed?
Connection architecture and boundary protection expectations are generally tied to the applicable information impact level as described in the DoD Cloud Computing SRG. Different impact levels can carry different connection, protection, and access point requirements. Because these requirements and their mapping to specific architectures are subject to revision and to component tailoring, mission owners should determine the impact level of their data and confirm the corresponding CAP or connection requirements against the current SRG and connection process guidance rather than assuming a single configuration applies across all impact levels.
What documentation and approvals should a team confirm before relying on a CAP for a cloud connection?
Before relying on a CAP, teams should confirm the applicable connection approval documentation and authorization artifacts defined in DoD connection and cloud security guidance, and verify that they cover the intended impact level and use case. Because specific artifacts, approval authorities, and process steps are established in the governing guidance and can change across revisions, teams should validate current requirements against the DISN Connection Process Guide, the DoD Cloud Computing SRG, and any component-specific instructions rather than relying on prior practice. This entry does not cover contractual or component-specific implementation details, which must be confirmed against current authoritative sources.

Common misconceptions

ICAP stands for 'Internet Cloud Access Point' or 'Internet CAP.'
Authoritative DoD sources, such as the DISN Connection Process Guide and the DoD Cloud Computing SRG, define ICAP as 'Internal Cloud Access Point.' There is no official DoD term 'Internet CAP.' Practitioners should use the sanctioned expansion and verify it against the current authoritative text.
Establishing a CAP connection means a mission system has been authorized to operate.
A CAP provides a controlled, monitored boundary and follows a DoD connection approval process, but it is not equivalent to an Authority to Operate. Authorization and connection approval are distinct; a system still requires its own authorization decision and remains subject to continuous monitoring.
A FedRAMP-authorized cloud service can connect to DoD networks without a CAP or additional DoD requirements.
FedRAMP authorization does not automatically satisfy DoD requirements. Connections into DoD networks generally require use of a Cloud Access Point and adherence to the DoD Cloud Computing SRG and DISN connection processes, with requirements varying by impact level.

Best practices

Confirm the required CAP or ICAP construct against the current revision of the DoD Cloud Computing SRG and the DISN Connection Process Guide before designing a cloud connection, since requirements change across revisions.
Use the sanctioned DoD expansion 'Internal Cloud Access Point' for ICAP and avoid non-official terms such as 'Internet CAP' in documentation and briefings.
Map the data and workload impact level early, because CAP boundary and connection requirements generally scale with the applicable impact level.
Treat CAP connection approval and system authorization (ATO) as separate processes, and ensure both are completed and maintained rather than assuming one satisfies the other.
Do not rely on FedRAMP authorization alone for DoD connectivity; verify that DoD-specific SRG and connection requirements, including the appropriate CAP, are met.
Maintain continuous monitoring of the CAP boundary and connected systems, recognizing that authorizations are time-bound and subject to ongoing oversight.