Azure Government Cloud Impact Levels: IL2, IL4, IL5, and IL6

Azure Government supports DoD Impact Levels 2, 4, and 5 in US Gov regions, and Azure Government Secret supports Impact Level 6. Microsoft documents FedRAMP High status across those regions and lists DISA provisional authorizations by level. You gain a sovereign platform, but you still need to design each system to the data it handles and the assessor you face.

DoD impact level definitions in practice

DoD sets Impact Levels in the Cloud Computing Security Requirements Guide. Microsoft’s public sector guidance describes IL4 as the level for Controlled Unclassified Information and other unclassified data that require protection under Executive Order 13556. Microsoft also describes IL5 as the level for CUI and unclassified National Security Systems data that run in dedicated infrastructure separated from non-DoD tenants. Microsoft positions Azure Government Secret for IL6 workloads that process Secret information in an isolated environment.

That split drives design choices. You host non-CUI unclassified workloads at IL2. You move CUI into IL4 or IL5 based on mission sensitivity and authorizing official expectations. You reserve IL6 for Secret workloads inside Azure Government Secret.

Azure Government regions and IL2, IL4, IL5 alignment

Microsoft runs Azure Government in US Gov Virginia, US Gov Texas, and US Gov Arizona. Microsoft maintains FedRAMP High authorizations across these regions. DISA issued provisional authorizations that cover IL2, IL4, and IL5. Microsoft publishes an audit scope catalog that shows service-by-service coverage across FedRAMP and DoD impact levels, and that catalog changes as services advance through assessments.

You should validate three things for every design:

Microsoft’s catalog lists the service at the target impact level in the target region.
Your authorizing official accepts the service scope and the shared responsibility notes for that service.

IL5 deserves extra care. Microsoft documents isolation guidance for IL5 workloads that require dedicated infrastructure separated from non-DoD tenants. You plan for that constraint early, you map it to your subscription and landing zone strategy, and you confirm it with the authorizing official.

Azure Government Secret and IL6 workloads

Microsoft built Azure Government Secret as a physically isolated environment for IL6. Microsoft describes this environment as air gapped from public networks, staffed by screened personnel, and designed for Secret-level classified data with additional control overlays. The Azure Government roadmap and service catalog call out which Secret regions and services are in scope. Do not design cross-environment connectivity that assumes direct links from Azure Government IL4 or IL5 into Azure Government Secret. You treat that boundary as a hard separation and you work through approved classified network paths.

FedRAMP High, DoD SRG overlays, and customer responsibility

FedRAMP High sets a federal baseline. DoD impact levels add SRG-specific overlays on top of that baseline. Microsoft publishes the authorizations it holds for the platform and the services. You still carry system-level responsibilities. The auditor will read your policies and look at your configurations and evidence.

NIST SP 800-171 controls remain in scope for CUI systems regardless of cloud authorizations. Examples that sit with you:

AC.L2-3.1.1, control access to systems and CUI based on approved users and devices.
SC.L2-3.13.1, monitor and control communications at external and key internal boundaries.

Media handling and physical controls also require design and procedure work:

MP.L2-3.8.3, sanitize or destroy system media that contains CUI before disposal or reuse.
PE.L2-3.10.1, limit physical access to systems, equipment, and CUI to authorized individuals.

You also need a patch and flaw management cadence:

SI.L2-3.14.1, identify, report, and correct system flaws in a timely manner.

Azure Government helps by providing sovereign hosting, US persons access controls for Microsoft operations, IL-specific service implementations, and documentation for shared responsibility. Your team still implements configuration baselines, identity policy, key management, logging, response, and supply chain controls. For DFARS obligations and incident reporting, map your plan to the clause and confirm workflows across Microsoft support and your own processes. Our post on DFARS 252.204-7012 requirements outlines the contractor-side tasks that sit outside cloud authorizations.

Placement guidance across IL2, IL4, IL5, and IL6

Place workloads based on data type and mission sensitivity, then check service authorization and isolation notes.

IL2 placement fits unclassified non-CUI workloads. You can host public-facing or low-sensitivity back-end services there. Validate that no CUI flows through telemetry, support tickets, or transient storage.

IL4 placement fits CUI. You build in Azure Government regions that list IL4 coverage for the services you plan to use. You design identity around Entra ID for GCC High or Azure Government integration, you restrict admin and break-glass accounts to US persons, and you control external connections with explicit allow lists and private endpoints.

IL5 placement fits higher-sensitivity CUI or unclassified National Security Systems data that require stronger isolation. Microsoft’s guidance calls for dedicated infrastructure separated from non-DoD tenants at IL5. You design subscriptions and landing zones that map to IL5 isolation, you segment management planes from workloads, and you plan service selection around the IL5 catalog. If you run analytics, confirm IL5 coverage for each data service in the audit scope before you commit the architecture.

IL6 placement fits Secret workloads in Azure Government Secret. You build to that environment’s access model, you plan for offline or approved cross-domain transfers, and you route operations through cleared personnel and approved facilities.

Service validation and authorization workflow

Teams that reach authorization faster follow a simple pattern.

Start with Microsoft’s FedRAMP and DoD SRG audit scope page and export the service matrix for your target region and impact level.
Engage the authorizing official with that matrix, your system boundary diagram, and your shared responsibility mapping for each service.

As you iterate, tie every design choice to an impact level requirement or a control. If a service lacks IL4 or IL5 coverage in the region you need, pick an alternative or adjust the design. If the authorizing official asks for additional isolation, fold that into the landing zone and update costs and timelines.

Relationship to GCC High and CUI programs

Azure Government hosts the underlying platform that supports Microsoft 365 GCC High. That alignment helps when you connect Entra ID tenants and conditional access policies to Azure Government subscriptions. Your CUI boundary likely spans email, files, identity, and Azure IaaS and PaaS services. Keep a clear line around that boundary and document how each control flows across it. Our post on the GCC High migration decision framework covers identity and data routing choices that affect Azure Government designs.

Design checkpoints that prevent rework

Two early checks prevent most impact-level surprises.

Confirm IL coverage by service and region before you publish a reference architecture.
Confirm IL5 isolation expectations with Microsoft and your authorizing official before you deploy shared or multi-tenant patterns.

Those two steps protect budgets and schedules more than any late-stage remediation sprint. The same pattern applies to IL6 inside Azure Government Secret, where connectivity plans and data transfer paths require early coordination.

Closing takeaways

Microsoft holds FedRAMP High and DoD SRG authorizations across Azure Government regions for IL2, IL4, and IL5, and provides Azure Government Secret for IL6. DISA issues provisional authorizations, Microsoft documents service scope, and your team implements the system controls that tie the design to your data. That division of responsibility keeps projects clear. You select the impact level based on data. You pick services from the audit scope that match that level in your region. You build controls that meet the assessor’s expectations.