Who are IL5-Authorized Cloud Providers?

A defense SaaS vendor signs a Department of War (DoW, former Department of Defense) opportunity contingent on Impact Level 5 (IL-5) authorization, then discovers the cloud infrastructure beneath its product does not qualify. The contract stalls.

The four major commercial hyperscaler infrastructure providers below hold Defense Information Systems Agency (DISA) Provisional Authorizations (PAs) at IL-5, the highest level the DoW assigns to unclassified data. Other SaaS and platform offerings also carry IL-5 PAs, but the infrastructure roster is the first gate: a product cannot process unclassified National Security Systems (NSS) data, including the Controlled Unclassified Information (CUI) carried on those systems, unless the infrastructure beneath it carries IL-5.

It is also the most misread gate. A provider's IL-5 status covers only the infrastructure layer, so every mission system built on it still needs its own Authority to Operate (ATO).

Key Takeaways

• The major commercial hyperscalers qualify. AWS GovCloud (US), Microsoft Azure Government, Google Cloud through Assured Workloads, and Oracle US Defense Cloud are each confirmed at IL-5.  
• IL-5 adds requirements over FedRAMP High. The Department of Defense Security Requirements Guide Version 1 Revision 6 (DoD CC SRG V1R6), assesses IL-5 with FedRAMP+ controls, physical tenant separation, and U.S. personnel rules.  
• NSS designation sets the IL-5 line. Unclassified NSS require IL-5; CUI that is not on an NSS stops at Impact Level 4 (IL-4) regardless of sensitivity, and classified data moves to Impact Level 6 (IL-6) on separate infrastructure.  
• PAs are not ATOs. SaaS vendors inherit infrastructure controls from the CSP, but mission systems still need an Authority to Operate from a DoW component.

IL-5 Marks the Highest Impact Level for Unclassified DoW Cloud Workloads

The CC SRG V1R6 (December 2025) sorts DoW cloud data into four active Impact Levels: IL-2, IL-4, IL-5, and IL-6. DISA retired the original Levels 1 and 3 by folding retired levels upward. The four active levels cover the following data categories:

• IL-2: Non-controlled unclassified information.  
• IL-4: Controlled Unclassified Information, including higher-sensitivity CUI, where the system is not an NSS.  
• IL-5: Unclassified NSS. The Authorizing Official (AO) makes the NSS determination.  
• IL-6: Classified information up to SECRET.

DISA's Authorizing Official issues the PA for a cloud service offering at IL-4, IL-5, or IL-6, based on FedRAMP plus the additional DoW requirements in the SRG.

IL-5 stops at the classification line. IL-5 environments connect over the Non-classified Internet Protocol Router Network (NIPRNet) through a Cloud Access Point (CAP). IL-6 data is classified, uses a separate network, and sits entirely outside the FedRAMP program.

That boundary determines which commercial infrastructure offerings can host each workload.

Four Major Infrastructure Providers Hold DISA IL-5 Provisional Authorizations

Each of the four hyperscalers below holds a DISA-confirmed IL-5 PA. All four are Joint Warfighting Cloud Capability (JWCC) providers, and DISA's Cloud Infrastructure as Code (IaC) program covers them at Impact Levels 4, 5, and 6.

1. AWS GovCloud (US) Holds IL-5 Authorization Across Both Regions

DISA's authorized-offerings roster includes AWS GovCloud (US) at IL-5, covering both GovCloud regions. AWS GovCloud is the infrastructure boundary for authorized IL-5 workloads, while mission systems deployed within it remain subject to application-level assessment and authorization.

2. Microsoft Azure Government Holds IL-5 Across Five US Regions

Microsoft Azure Government appears among DISA's authorized cloud offerings, with five US regions under IL-5. Its IL-5 environment is an authorized infrastructure foundation, but each mission system must still obtain its own component-level ATO.

3. Google Cloud Holds IL-5 Through Assured Workloads

Google's IL-5 PA covers the Google Services offering, delivered through a controlled IL-5 environment. The initial PA covered BigQuery, Cloud Storage, and Compute Engine. The service catalog has expanded since that initial authorization.

4. Oracle Cloud Infrastructure Holds IL-5 and Separate IL-6 Authorization

Oracle Cloud Infrastructure is one of the four JWCC providers covered by DISA Cloud IaC at Impact Levels 4, 5, and 6. Its unclassified IL-5 offering and classified IL-6 environments occupy separate authorization boundaries.

Provider eligibility establishes the boundary; the assessment baseline determines why that boundary qualifies.

IL-5 Builds on FedRAMP High but Adds a DoW-Specific Control Overlay

CC SRG Section 5.1.1 establishes the assessment framework: a FedRAMP High provisional authorization, supplemented with FedRAMP+ controls and control enhancements (C/CEs) and the requirements in the Cloud Computing SRG, is used to assess CSOs for an IL-5 PA.

FedRAMP High is the entry requirement. On top of it, DISA assesses additional IL-5 requirements. These requirements include physical separation from commercial and non-federal tenants and access limited to U.S. citizens, U.S. nationals, or U.S. persons.

A CSP does not have to pursue the overlay after reaching FedRAMP High. Every IL-5 assessment, however, starts with FedRAMP High and adds the overlay before DISA issues an IL-5 PA.

The qualifying baseline must still match the workload's required protection level.

IL-5 Authorization Covers Specific Data Categories, Not Every DoW Workload

The CC SRG's data categories determine which workloads need an IL-5 provider and which do not.

• IL-5 covers unclassified NSS. The DoD CIO Cloud Security Playbook requires IL-5 or higher for CUI on NSS. The authorizing official determines the NSS.  
• CUI that is not designated NSS stops at IL-4 regardless of sensitivity, and public data stops at IL-2. IL-4 permits logical tenant separation. CSPs holding a FedRAMP Moderate authorization receive IL-2 reciprocity without additional written authorization.  
• Classified data moves to IL-6 on separate infrastructure. IL-6 handles SECRET information on a separate classified network, with active clearances for everyone with system access.  
• A Mission Owner still needs its own ATO. The DoD Cloud Authorization Process separates the two instruments: the PA "Focuses on CSO Risk and ConMon" (DISA AO), while the ATO "Focuses on Mission Risk" (component AO). Mission Owners then work the Risk Management Framework to an ATO that uses the PA.

Those categories define what the CSP's PA covers; the controls above that line are what a SaaS vendor must prove on its own.

SaaS Vendors on IL-5 Platforms Inherit Infrastructure Controls

Under the cloud shared responsibility model, the CC SRG describes inheritance directly: "Mission Owners contracting for SaaS offerings inherit the bulk of compliance with the security controls from the CSO."

On AWS GovCloud, Azure Government, Google Assured Workloads, or Oracle Defense Cloud, a SaaS vendor inherits the CSP PA's physical and environmental controls along with the covered platform controls.

The January 2025 Mission Owner Security Requirements Guide draws the boundary from the other side: the Mission Owner stays responsible for its DoW data and any configuration setting within its control. It also owns every control that is shared or fully its own. Non-inherited controls enter the Customer Responsibility Matrix (CRM).

In practice, the inherited and retained control scope breaks down as follows:

• Inherited infrastructure: The data center layer.  
• Inherited infrastructure: The hypervisor layer.  
• Inherited infrastructure: The network layer.  
• Vendor responsibility: Application security.  
• Vendor responsibility: Identity.  
• Vendor responsibility: Data handling.  
• Vendor responsibility: The vendor's own ConMon evidence.

A pre-authorized FedRAMP boundary addresses that residual burden. Vendors deploying on an inherited boundary can absorb a percentage of required National Institute of Standards and Technology (NIST) SP 800-53 Rev5 controls, leaving application-layer work as the remaining scope. Infrastructure eligibility therefore hands off to a distinct question: how quickly a vendor can clear the controls no IL-5 CSP is authorized to cover.

The remaining control scope, rather than infrastructure eligibility, determines the vendor's authorization schedule.

Accelerating Application-Layer Authorization Shortens Time to Contract

All four IL-5 providers reach that level through the same FedRAMP High foundation and the same SRG overlay, so infrastructure choice alone does not shorten a vendor's path to DoW revenue. The competitive variable is the application-layer assessment a Mission Owner sponsor must still sign off on. Vendors that treat provider selection as the finish line stall where their contracts do: waiting on an ATO no CSP can grant them.

Knox Systems runs a single FedRAMP High boundary across AWS, Azure, and Google Cloud Platform. Vendors inherit the boundary controls on day one and pursue their own authorization in approximately 90 days at roughly 90% less cost than traditional methods. Knox currently supports FedRAMP Moderate, FedRAMP High, and DISA IL-4. IL-5 authorization is in process, with an estimated completion date of December 2026.

If a DoW opportunity is waiting on authorization, book a demo to scope the application-layer work.

FAQs about IL-5-Authorized Cloud Providers

Who Issues FedRAMP High and IL-5 Authorizations?

Agency AOs issue FedRAMP High authorizations. A Program Authorization path signed by the FedRAMP Director is under development. Until that path is available, vendors proceed through agency authorization.

What Must a SaaS Vendor Document After Deploying on an IL-5 CSP?

The authorization package must include a Plan of Action and Milestones tracking for open findings and preserve evidence as remediation is completed. This record supports ongoing assessment after deployment.

How Does DISA Update the List of IL-5-Authorized Providers?

CSPs must provide 30-day notice before significant changes. The DISA AO may revoke authorization if an unapproved change alters the offering's risk posture, so authorization status can change between roster updates.

Can Multiple Mission Owners Rely on the Same DISA PA?

Yes. The same PA can support multiple Mission Owners at the same time. Reliance on the PA is not reserved for a single component or contract.

‍