DISA BCAP: What Is a Boundary Cloud Access Point?

The Department of War (DoW, formerly the Department of Defense) requires off-premises commercial cloud services supporting Impact Level 4 (IL-4) and Impact Level 5 (IL-5) workloads, which cover Controlled Unclassified Information (CUI) and mission-critical data, to reach the Defense Information Systems Network (DISN) through a Boundary Cloud Access Point (BCAP), a security gateway operated by the Defense Information Systems Agency (DISA). IL-6 cloud infrastructure is treated as a closed SIPRNet enclave.

For SaaS vendors and mission owners pursuing DoW business, BCAP connectivity determines whether DoW users can reach a product at IL-4 and IL-5.

Key Takeaways

• BCAP protects the DISN. It is a DISA-managed gateway required to connect off-premises commercial Cloud Service Offerings to the DoW network, and it blocks threats that originate in the cloud.  
• Four SCCA components. BCAP sits alongside the Virtual Datacenter Security Stack, Virtual Datacenter Managed Services, and the Trusted Cloud Credential Manager in the Secure Cloud Computing Architecture (SCCA).  
• IL-4 and IL-5. The DISN Connection Process Guide states that normally all IL-4 and IL-5 CSOs connect through a DISA BCAP and identifies the DoW CIO as the waiver authority.  
• Vendors never build one. SaaS providers satisfy  
• the requirement by deploying within a provisionally authorized, BCAP-connected Cloud Service Offering, then following the DISN Connection Process Guide to onboard.

A BCAP Shields the DISN from Attacks That Originate in Commercial Cloud

The DoW's DISN Connection Process Guide (CPG) Version 6 requires a Boundary CAP to connect off-premises, commercially owned and operated Cloud Service Offerings (CSOs) to the DISN, and describes it as a DISN perimeter gateway that creates a protective barrier between the DISN and the CSO. A CSO is the commercial cloud product itself; the BCAP sits between that product and the DoW's network backbone.

Microsoft's Azure Government states: "The purpose of the BCAP is to protect the DISN from attacks that originate in the cloud environment."

The gateway performs intrusion detection and prevention and filters unauthorized traffic at the DISN boundary. These controls protect the wider DoD Information Network (DoDIN) from incidents that start inside a cloud provider's infrastructure. Its protective intent runs cloud-to-DISN, and its perimeter defenses and cyber-defense sensing cover traffic to and from applications hosted in the CSO.

A BCAP provides no direct internet access to or from a CSO or the mission applications built on it. DISA builds and operates enterprise BCAPs as a managed service, and mission owners and vendors use the managed connection.

Within the SCCA, the BCAP works with three other cloud-security components.

BCAP Is One of Four Pillars in the DoW's Secure Cloud Computing Architecture

The SCCA secures the connection points between the DISN and commercial cloud providers, and it defines four components:

• Boundary Cloud Access Point (BCAP). The DISN-edge protection layer. It includes firewalls at the DISN boundary. Intrusion detection systems (IDS) and intrusion prevention systems (IPS) provide additional cyber-defense capabilities.  
• Virtual Datacenter Security Stack (VDSS). Protects mission-owner applications hosted in commercial cloud and performs the bulk of SCCA security operations: inbound access controls, web application firewalls, DDoS protection, load balancing, and traffic inspection. It can run in the cloud or on-premises.  
• Virtual Datacenter Managed Services (VDMS). Provides host security and shared data-center services. Its functions can run in the SCCA hub, or a mission owner can deploy parts of it in their own cloud accounts.  
• Trusted Cloud Credential Manager (TCCM). The TCCM is a business role held by an individual the authorizing official appoints. This individual controls privileged access to the cloud environment and maintains the Cloud Credential Management Plan (CCMP). DISA validates that the CCMP exists before approving a DISN connection.

VDSS and VDMS are optional SCCA services a component can source from DISA or provide itself. The BCAP has no self-service equivalent for commercial cloud, except a component-built BCAP, which requires additional DoW CIO approval and is difficult and time-consuming to attain. DoW documentation uses three CAP terms, and each maps to a different connection scenario.

Three CAP Variants Control Different Types of DoW Cloud Connections

DoW documentation uses three related terms for the access-point function, each tied to a distinct connection scenario:

1. The BCAP Governs Off-Premises Commercial Cloud

It connects commercially owned and operated CSOs, such as AWS, Azure, Oracle Cloud, or Salesforce Government Cloud Plus – Defense, to the DISN. Per the DISN Connection Process Guide, one BCAP interconnects the protected network with multiple Cloud Service Provider (CSP) networks offering private connectivity.

2. The Internal Cloud Access Point (ICAP) Governs On-Premises Commercial Cloud

The DISN Connection Process Guide defines the ICAP as the boundary for on-premises commercially owned and operated CSO connectivity to the DISN, with typically one ICAP per physical CSO infrastructure instance. DISA's ICAP serves milCloud 2.0, whose project owners inherit security controls from the DISA-managed ICAP security controls.

3. The Component CAP Governs a DoW Component Running Its Own Access Point

Oracle's SCCA page names a Component CAP (CCAP) without defining it; separately, a DoW Component may build and operate its own BCAP, such as the Navy BCAP, with additional DoW CIO approval.

One terminology trap: Oracle's SCCA page uses "ICAP" to mean "Internet CAP," while the DISN Connection Process Guide, the authoritative DoW source, uses it for the internal, on-premises variant. When reading vendor documentation on CAP variants, check which definition applies. Choosing a variant that doesn't match the CSO's hosting model can delay the proposal by months because the CSO's hosting model fixes the connection path a mission owner can use, regardless of the vendor's preference.

IL-4 and IL-5 Mission Workloads Generally Connect to the DISN Through a BCAP

On June 14, 2024, the Cloud Computing Security Requirements Guide (SRG) was restructured to use the National Institute of Standards and Technology (NIST) SP 800-53 Rev5 controls and split into separate CSP and Mission Owner documents.

The Mission Owner overview describes internal CAPs and DODIN/NIPRNet Boundary CAPs. The DISN Connection Process Guide states that normally all IL-4 and IL-5 CSOs connect to the DISN through a DISA BCAP. It also cites contractual language under which the DoW CIO may waive the requirement. For IL-6, cloud infrastructure is treated as a closed, self-contained enclave connected only to SIPRNet.

For SaaS vendors, the practical requirement is deploying within a BCAP-connected, provisionally authorized CSO.

Mission Owners Follow a Defined BCAP Onboarding Process

The CPG's C sections define the path from a cloud project to an active BCAP connection, built around the Cloud IT Project (C-ITP): a software application or information service implemented into a DoW provisionally authorized CSO.

1. Initiate the Cloud IT Project. The Mission Owner identifies the software application or information service to be implemented in a DoW provisionally authorized CSO.  
2. Verify the CSO holds a DoW Provisional Authorization (DoW PA). DISA issues the DoW Provisional Authorization to pre-qualify a CSO to host DoW missions; only a CSO holding a PA at the appropriate Impact Level can host a registered C-ITP.  
3. Register the C-ITP in the Systems/Network Approval Process (SNAP) or SGS. The Mission Owner registers the application, its CSP/CSO, its Mission Cyberspace Defense (MCD) provider, and its connection method in the Cloud Module of DISA's SNAP database. The C-ITP's Authorizing Official must have issued the Authority to Operate (ATO) before registration is complete.  
4. Submit the connection request to the DISN Connection Approval Office (CAO). The Mission Owner submits through SNAP/SGS; the same channel handles resubmission after corrective actions.  
5. Receive the Cloud Permission to Connect (CPTC). The DISN CAO won't issue a CPTC for an incomplete submission. It identifies corrective actions and notifies the Mission Owner's points of contact, or issues the Cloud Permission to Connect acknowledging registration and authorizing connection.  
6. Complete SCCA onboarding. The Mission Owner submits the SCCA Onboarding service request form. The DISA SCCA Program Management Office (PMO) then engineers the IL-4 or IL-5 connection to a DISA BCAP or ICAP (serving milCloud 2.0) and implements applicable VDSS and VDMS services. The PMO activates the BCAP connection only after the CPTC is issued.  
7. Connect via the appropriate CAP. Per the DISN Connection Process Guide, your final implementation steps depend on the CSO's Impact Level and which CAP it uses.

Before a Mission Owner can start these steps, a SaaS vendor must choose a deployment architecture that places its product inside a provisionally authorized, BCAP-connected CSO, because DISA handles the gateway but not the vendor's hosting decision. One way to shorten the runway is to deploy inside a pre-authorized boundary that already carries a DoW Provisional Authorization at the target Impact Level, allowing the vendor to inherit a substantial share of NIST SP 800-53 Rev5 controls from the underlying environment rather than building them from scratch. That inheritance model turns BCAP connectivity from a construction project into a deployment choice.

Choose a Deployment Path That Puts You Inside a BCAP-Connected CSO on Day One

BCAP connectivity is a downstream consequence of a single upfront decision: whether the product runs inside a provisionally authorized CSO that is already connected to a DISA BCAP. Vendors that get this decision right inherit the gateway, the DISN routing, and the boundary protections as part of the environment. Vendors that get it wrong face months of rework, because the CSO's hosting model, not the vendor's preference, fixes the connection path a Mission Owner can use.

Knox Systems operates a pre-authorized FedRAMP-as-a-Service boundary designed to compress that runway. Vendors deploying inside it inherit 60% to 80% of required controls and reach authorization in approximately 90 days.

Knox currently supports FedRAMP Moderate, FedRAMP High, and DISA IL-4, with IL-5 authorization in process and estimated for December 2026. Vendors must still satisfy the separate DoW Cloud Access Point connectivity requirement through the Mission Owner's onboarding process, but the underlying boundary and control inheritance are already in place.

Ready to scope your path to DoW authorization? Schedule a demo to walk through your target Impact Level, your CSO options, and how a pre-authorized boundary can accelerate a BCAP-connected deployment.

FAQs about DISA BCAP

Can a SaaS Vendor Obtain BCAP Connectivity Independently?

No. A SaaS vendor gains BCAP connectivity through a provisionally authorized, BCAP-connected CSO and the Mission Owner's connection process, not through a vendor-owned gateway.

Does BCAP Replace a CSO's DoW Provisional Authorization?

No. A DoW Provisional Authorization establishes that the CSO can host missions at the applicable Impact Level, while BCAP provides the approved connection path to the DISN.

Who Operates Security Controls After Connection?

DISA continues to operate the enterprise BCAP and its boundary protections. Mission owners remain responsible for their applications, connection records, and any SCCA services they provide themselves.

‍