Azure Government Compliance Checklist: 30 Configuration Requirements for Defense Use Cases

Why Azure Government Compliance Demands More Than a Standard Deployment

Moving workloads to Azure Government is not a compliance event in itself. The platform provides the boundary, the FedRAMP High authorization, and the sovereign infrastructure. What it does not do is configure itself to meet your specific obligations under DFARS 252.204-7012, CMMC Level 2, ITAR, or CUI handling requirements. That work falls to you.

As a defense contractor, federal agency, or regulated organization operating in Azure Government, you are responsible for a significant portion of the security control implementation. Microsoft handles the physical infrastructure, the hypervisor layer, and the underlying platform services. Everything above that shared responsibility line is yours to configure, document, and evidence.

The checklist below reflects the 30 configuration requirements we most commonly assess, remediate, and evidence at Cleared Systems IT compliance engagements. It is organized by control domain and designed for compliance managers and IT leads who need a working reference, not a marketing brochure.

For contractors also navigating the relationship between GCC High and Azure Government, our post on what GCC High means for ITAR and CMMC 2.0 provides useful context before you work through this list.

Identity and Access Management

1. Enforce Microsoft Entra ID (Azure AD) Conditional Access policies requiring multi-factor authentication for all users accessing CUI environments, with no permanent exceptions for service accounts or legacy protocols.
2. Disable legacy authentication protocols including Basic Auth, IMAP, POP3, and SMTP Auth at the tenant level. Legacy authentication bypasses MFA and is a leading cause of credential compromise in audited environments.
3. Implement Privileged Identity Management (PIM) to enforce just-in-time access for all Global Administrator, Security Administrator, and Subscription Owner roles. Permanent standing privilege in these roles is a frequent CMMC Level 2 finding.
4. Configure role-based access control (RBAC) at the subscription and resource group level using least privilege principles. Document role assignments and review them at defined intervals, typically quarterly.
5. Enforce password policies meeting NIST SP 800-63B guidance: minimum 15 characters, no complexity requirements that drive predictable patterns, and breach-correlated blocking through Entra ID Password Protection.
6. Enable Entra ID Identity Protection with risk-based Conditional Access policies that automatically block or step-up authenticate users exhibiting leaked credential or impossible travel signals.

Data Protection and CUI Handling

1. Deploy Microsoft Purview Information Protection sensitivity labels mapped to your CUI categories and ITAR-controlled data classifications. Labels must enforce encryption and persist across email, SharePoint, OneDrive, and Teams in GCC High.
2. Configure Data Loss Prevention policies in Microsoft Purview to detect and block exfiltration of CUI via email, Teams, SharePoint, and endpoint channels. Policies must be tuned to your specific contract data types, not left on default templates.
3. Enable customer-managed encryption keys (CMK) for sensitive storage accounts, Azure SQL databases, and Cosmos DB instances containing CUI. Document key management procedures in your System Security Plan.
4. Restrict storage account access to private endpoints and disable public network access for any storage containing CUI or ITAR-controlled technical data. Service endpoints are not sufficient for high-sensitivity workloads.
5. Configure Azure Key Vault with RBAC authorization mode, soft-delete enabled, and purge protection activated. Audit all key vault operations and route logs to your SIEM.

Our post on classifying and protecting CUI with Azure Information Protection provides additional implementation detail for items 7 and 8 above.

Network Security and Boundary Control

1. Deploy Azure Firewall Premium in front of workloads handling CUI, with IDPS signatures enabled and TLS inspection configured. Standard tier lacks the threat intelligence and intrusion detection capabilities required for defense use cases.
2. Implement Network Security Groups (NSGs) at the subnet level with deny-all default rules and explicit allow rules only for documented, required traffic flows. NSG flow logs must be enabled and retained.
3. Use Azure Private Link to eliminate public internet exposure for PaaS services including Azure Storage, Azure SQL, Azure Key Vault, and Azure Container Registry where these services support CUI workloads.
4. Enable DDoS Protection Standard on virtual networks hosting internet-facing applications. Document this control in your SSP as part of your availability and resilience posture.
5. Segment CUI workloads into dedicated virtual networks and enforce peering restrictions. Do not allow CUI workloads to share virtual networks with development, test, or non-CUI production environments.
6. Disable direct outbound internet access from CUI virtual machines. Route all outbound traffic through Azure Firewall or an approved proxy with full inspection and logging.

Logging, Monitoring, and Incident Response

1. Enable Microsoft Defender for Cloud on all subscriptions at the Defender CSPM or workload protection tier appropriate to your resource types. Review secure score findings weekly and tie remediation to your POA&M process.
2. Configure diagnostic settings on all Azure resources to route activity logs, resource logs, and security events to a centralized Log Analytics workspace. Log gaps are among the most common findings in CMMC assessments.
3. Deploy Microsoft Sentinel connected to your Log Analytics workspace with analytics rules tuned to CMMC and NIST SP 800-171 threat scenarios. Out-of-box rules require tuning before they provide meaningful detection.
4. Set log retention to a minimum of 90 days in hot storage and 12 months in cold storage for all audit logs covering CUI environments. CMMC Level 2 and DFARS both require defined retention periods.
5. Configure automated incident response playbooks in Sentinel for high-severity alerts including impossible travel, mass file download, privilege escalation, and malware detection. Test playbooks at least annually.
6. Establish and document a cyber incident reporting process meeting the 72-hour reporting requirement under DFARS 252.204-7012, including the mechanism for submitting reports to the DIBNet portal.

If your organization is still developing the broader incident response framework behind these Azure-specific controls, our post on SSP and POA&M as critical security program components addresses how these feeds into your documentation posture.

Endpoint and Workload Security

1. Onboard all Azure virtual machines to Microsoft Defender for Servers Plan 2 and verify that Defender for Endpoint is deployed and reporting telemetry. Confirm coverage in your CMMC assessment scope boundary.
2. Enable Azure Policy with the NIST SP 800-53 R5 or CMMC Level 2 built-in initiative assigned to your management group. Use policy compliance reports as a continuous evidence feed for your SSP.
3. Configure Secure Score remediation workflows tied to your POA&M. Unaddressed high-severity recommendations should carry milestone dates and responsible owners in your plan of action documentation.
4. Disable public RDP and SSH access to all virtual machines. Use Azure Bastion for administrative access and enforce just-in-time VM access through Defender for Cloud to further restrict exposure windows.
5. Apply OS hardening baselines to all virtual machines using Azure Policy guest configuration or equivalent tooling. Document deviation from baseline as a formal risk acceptance or remediation item.

Governance, Documentation, and Boundary Scoping

1. Define and document your CUI boundary within Azure Government, including all resource groups, subscriptions, virtual networks, and identities in scope. Assessors will test whether your implemented controls match your documented boundary.
2. Maintain an Azure resource inventory aligned to your system boundary using Azure Resource Graph or a CMDB integration. Undocumented resources are uncontrolled resources.
3. Document all inherited controls from the Azure Government FedRAMP High authorization in your SSP using Microsoft's shared responsibility matrix. Do not claim credit for controls you have not actually implemented in your tenant layer.

What This Checklist Does Not Replace

This list addresses configuration-layer requirements. It does not substitute for a full NIST SP 800-171 assessment, a CMMC readiness review, or a formal CUI boundary assessment. Many organizations running Azure Government are still surprised to learn that a significant number of CMMC Level 2 practices require organizational processes, training, and documentation that have no Azure configuration analog. The technical controls above must sit inside a complete security program to satisfy an assessor.

For defense contractors who want to understand how Azure Government fits into the broader CMMC, CUI, and DFARS compliance picture, particularly around what Microsoft provides versus what you must build, the platform is a strong foundation. The gap between a compliant Azure Government configuration and a compliant organization is where most contractors get into trouble.

Organizations in the federal and defense sector that have recently migrated to Azure Government or are planning a migration should treat this checklist as a starting point, not a finishing line.

Take the Next Step With a Configuration Review

If your organization is preparing for a CMMC assessment, responding to a DCSA inquiry, or simply trying to close the gap between your Azure Government deployment and your compliance obligations, Cleared Systems can help. We conduct Azure Government configuration reviews, CUI boundary assessments, and full CMMC readiness engagements for defense contractors of all sizes. Request a quote to discuss your current environment and what it will take to get compliant and stay compliant.