Microsoft Government Community Cloud

GCC High migration: process, timelines, and choosing between a tenant, an enclave, and Azure Government

Microsoft provides no native path from a commercial tenant into GCC High. That means the first decision isn’t how to migrate — it’s which build your CUI actually calls for.

Last updated September 2026

Authored by:

Eric Salazar

Director of Professional Services, SysArc

Bernhard Bock

VP Cybersecurity Compliance Services, SysArc

Updated for 2026: what the CMMC Phase 2 suspension changed

On July 13, 2026, the Department of War suspended CMMC Phase 2 — the phase that would have made third-party C3PAO certification a condition of award starting November 10, 2026 — and stood up a CMMC Reform Task Force to deliver recommendations to the DoW CIO.

What that did not change:

• DFARS 252.204-7012 still applies, unchanged.
• NIST SP 800-171 implementation is still a contractual obligation.
• Phase 1 Level 1 and Level 2 self-assessments and SPRS submissions remain in force, with False Claims Act exposure attached to inaccurate scores.
• ITAR and EAR obligations are entirely separate from CMMC and were never affected.

The verification mechanism was paused. The security requirement was not. If CUI moves through a commercial Microsoft 365 tenant today, that is a DFARS 7012 problem this week, independent of when third-party assessments resume.

Most defense contractors arrive at the same discovery during CMMC preparation: the commercial Microsoft 365 tenant their team works in every day can’t lawfully hold CUI. Fixing that means moving to Microsoft’s government cloud, and Microsoft provides no native migration path to get there.

There are three ways to solve it, and the right one depends on how widely CUI actually touches your organization. They aren’t mutually exclusive — a common combination is an enclave now paired with an Azure Government build for engineering, with a full migration later.

This guide covers what drives the requirement, how each path works, what won’t come with you, and what an assessor will expect to see afterward.

What drives the requirement: CUI, ITAR, EAR, and FCI

For most contractors in the defense industrial base, CUI is the driver. It’s the data type most commonly cited in an assessment and the one most compliance leads research first. But CUI rarely travels alone: technical data tied to a defense article is also ITAR-controlled, and export-controlled commercial or dual-use data falls under the EAR. FCI is a lower bar that often doesn’t require GCC High on its own.

Knowing which of these actually applies to your contracts — rather than defaulting to “we need GCC High because we have CUI” — is where scoping should start.

Which row applies should be validated against your actual contract clauses and your SSP — not assumed, and not resolved by defaulting to the most expensive tier. A meaningful number of contractors are quoted GCC High when their contracts don’t require it.

A note on non-US persons

If ITAR or EAR-controlled data applies and you currently have non-US-person employees or subcontractors with access to it, you have an export-control problem that exists independently of which tenant you’re in. Tenant selection won’t solve it. In a compliant build that access model is enforced through Conditional Access and Information Barriers — but the access decisions themselves have to be made first.

Choosing the destination: GCC, GCC High, or GCC High DoD

Microsoft offers three government-community cloud tiers. Choosing the wrong one either leaves you under-protected or paying for compliance headroom you don’t need.

If your contracts flow CUI, plan for GCC High — and doubly so if that CUI carries ITAR or EAR-controlled technical data, which it usually does. If your government-facing work stops short of CUI, GCC is often sufficient and meaningfully less expensive.

GCC High DoD is a narrower case, reserved for genuine IL5 or DoD-network requirements. The delivery approach in the rest of this guide is the same either way. Only the destination tier and its security baseline change.

The three paths compared

The trade-off worth naming out loud

An enclave is faster, cheaper to license, and cheaper to assess, because the assessment boundary is smaller. It is also harder to operate and harder to police. Users will try to move files across the boundary because it’s inconvenient not to. An enclave is only as good as your data-flow discipline, which means DLP, sensitivity labels, training, and monitoring — not just architecture. Contractors who treat an enclave purely as a licensing optimization tend to end up with CUI on the commercial side, which is worse than not having built one.

The scoping question that decides all of this: map where CUI actually enters, moves, and rests today — not where policy says it should, where it does.

Why there’s no native migration path

Unlike moving between two commercial Microsoft 365 tenants, migrating into GCC or GCC High crosses a fundamental trust boundary. GCC High in particular is a physically and logically separate infrastructure environment, screened for U.S. persons and built to meet DFARS 252.204-7012, ITAR, and EAR data-handling requirements. It has its own identity system, its own service endpoints, and its own data residency guarantees.

You cannot directly move licenses, replicate configurations, or transfer data between a commercial — or even a GCC — tenant and a GCC High tenant using Microsoft’s built-in tools.

That means every part of the project is a deliberate, documented action. Identity has to be provisioned. Security configurations have to be built against a compliance baseline rather than copied over. Third-party integrations have to be re-evaluated for availability in the destination cloud. And all of it has to happen without leaving your team unable to work.

It also means something useful: because every step is deliberate and documented, a migration run properly produces a substantial share of the evidence your assessor will later ask for.

Path 1: Full tenant migration, phase by phase

Six phases, built around one principle: nothing gets migrated blind. Each phase produces documentation the next one depends on, and nothing touches production until it’s been validated in the parallel environment first.

Phase 1 — Discovery

Before any migration work begins, the current-state environment gets mapped completely. That starts with obtaining the administrative access needed to deploy discovery and migration tooling to both source and destination environments — without it the project cannot proceed — and then inventorying total expected seat count and growth projection, current cloud application and user data across mail, files, and collaboration tools, the current identity provider for users, groups, and devices, in-scope on-premises resources such as Exchange Server, file shares, and on-prem AD, and current-state configurations and policies for every in-scope asset.

Discovery is also where every capability that has no supported migration path gets identified: SSO integrations with third-party providers, Teams that are quietly doubling as distribution lists, and use of features like Viva Connect, Whiteboard, Bookings, or Power Platform that don’t carry over. Each one gets assigned to a client owner for mitigation before cutover, rather than being discovered the week of go-live.

An automated discovery scan closes out the phase, flagging high-volume mailboxes that exceed 50GB or use Online Archive — both licensing qualifiers — and surfacing migration risks early. Results go into a shared workbook so your team can verify in-scope users and assets before licensing is procured.

That sequencing matters more than it sounds. Buying licenses before discovery is finished is how organizations end up paying for seats and SKUs they don’t need.

Phase 2 — Tenant staging

The destination tenant gets provisioned in parallel with your production environment: registering the tenant, linking it under partner ID for delegated subscription management, registering your custom domain, and onboarding key technical personnel to begin configuration.

This parallel environment does double duty. It’s the destination for the eventual data migration, and it’s a validation environment where functionality, integrations, and workflows get tested before anyone commits to a cutover date.

Phase 3 — CMMC security configuration

This is where the destination tenant gets hardened to a CMMC / NIST 800-171 security baseline built directly against Microsoft’s Technical Reference Guide for CMMC 2.0 — Microsoft’s own published implementation guidance mapping CMMC Level 2 practices to specific Microsoft 365 GCC High and Azure Government configurations.

The controls in scope at this stage are those configurable without dependency on your own system security policies and procedures — the technical baseline that holds for every tenant regardless of client-specific SSPs. The baseline spans:

• Microsoft Defender — preset security policies, file monitoring, EDR and tamper protection, Intune connectivity, and device onboarding across Windows, iOS/iPadOS, and Android
• Microsoft Entra — conditional access for MFA, device compliance and risk-based policies, SSPR configuration, guest access review automation, and hardened default user roles
• Microsoft Intune — endpoint security profiles, compliance policies, Windows Update rings, automatic enrollment, Windows Hello for Business, and platform restrictions blocking unmanaged or incompatible devices
• Exchange Online — custom quarantine policy, anti-phishing and mailbox intelligence, malware filtering and zero-hour auto purge, DKIM, and mail flow rules flagging external senders
• Microsoft Purview — unified group labeling, 365-day audit retention, and sensitivity labels for Confidential, CUI, and ITAR Restricted data, published with DLP policies that restrict external sharing and enforce policy tips

Managed backup, restore, and reporting on top of the tenant is configured at this stage if it’s in scope — scope, schedule, reporting, notifications, and client access all set before data starts moving.

Phase 4 — Data migration

Email, SharePoint, OneDrive, Teams, and Groups data moves through purpose-built third-party migration tooling, deployed either cloud-hosted or client-hosted depending on the environment, with migration plans and policies built per in-scope dataset.

• Email typically runs in the background while users keep working in the legacy mailbox, syncing incrementally until cutover.
• SharePoint and OneDrive need tighter sequencing because content is actively being modified. Modern-page look-and-feel customizations generally have to be rebuilt post-migration rather than migrated as-is.
• Teams is the hardest workload. Migrated meetings are best treated as placeholders for users to recreate post-migration rather than expecting a one-to-one carryover.

For CUI specifically — and any ITAR or EAR-controlled data traveling with it — data moving into GCC High has to be handled so regulated data is never exposed in transit. That means encrypted migration tooling with credentials isolated from non-cleared personnel, and documenting the process as part of your media sanitization records for the SSP rather than treating it as an implementation detail.

Phase 5 — Cutover preparation and go-live support

Before anyone commits to a cutover date: cutover strategy, communication documentation, and support matrix drafted, and testing run to validate every configuration built in staging. That includes scheduled communications, an MFA registration tutorial, web-access instructions, and a documented support path for technical issues during synchronization.

Endpoint cutover runs one of two ways, and it’s worth deciding which you want early:

• Mentor Method — SysArc consults on documentation and your internal support team executes the cutover, typically after resetting endpoints to ensure clean, consistent enrollment. Lower cost, and your team comes out of it knowing how the environment works.
• Full Service — SysArc executes the endpoint cutover directly.

Either way, connectivity and policy enforcement get bench-tested against a simulated production user and workstation before any real endpoint is touched, and a pilot program with key personnel can independently validate functionality first.

The cutover event is typically a weekend, to minimize user impact. It includes disabling non-administrative access to the legacy environment, completing the final delta synchronization, completing custom domain registration in the destination tenant, and updating public DNS to redirect mail and services.

The data migration process is non-destructive. If an abort condition triggers before domain transfer, changes are reverted and users continue operating in the legacy environment. Once the custom domain transfers, that’s the point of no return — which is why that step is sequenced deliberately and last.

Phase 6 — Post-cutover support

Support here is focused on getting your organization actually live in the protected environment: resolving outstanding technical issues such as data consistency, tenant configuration, hybrid identity sync, and permission inconsistencies that didn’t replicate cleanly. High-profile issues get prioritized first, and the legacy tenant stays available with administrative access only during this window so nothing is lost if something surfaces late.

The engagement isn’t finished when data lands in the new tenant. It’s finished when your people are working productively in a compliant environment.

Migrating from any source environment

The path above describes the most common route, Microsoft 365 Commercial to GCC High. The same discovery-through-post-cutover approach applies regardless of where your data lives today: Microsoft 365 Commercial, Microsoft 365 GCC for organizations stepping up as contract requirements escalate, on-premises Exchange Server in hybrid or pure on-prem configurations, Google Workspace as a full re-platforming, and other legacy email and collaboration systems evaluated case by case during Discovery.

Path 2: The 30-day enclave

Not every organization needs — or can justify the timeline and cost of — migrating an entire tenant. Many contractors have only a small subset of users, sites, or mailboxes that actually touch CUI: an engineering team, a contracts group, a handful of program leads.

For that, the answer is a standalone GCC High (or GCC) enclave — a purpose-built compliant environment the in-scope users work from, while everyone else stays exactly where they are. Because there’s no legacy tenant to synchronize and no full data migration in scope, enclaves move fast: a production-ready enclave typically delivers in about 30 days when no data migration is required.

Users access the enclave through Azure Virtual Desktop or Windows 365 Cloud PCs — a virtual desktop purpose-built for the regulated work, with secure upload and download to SharePoint, printing, and the Office 365 app suite. Day-to-day non-regulated work continues on the user’s existing device and tenant.

An enclave is also the right fit when a full migration is on the roadmap but not yet approved. It gets your highest-risk data and users compliant now, on a 30-day timeline, without waiting on a multi-month tenant-wide project.

Path 3: Azure Government for engineering and file-based workloads

SharePoint is a strong fit for documents and collaboration. It’s a poor fit for the way engineering and production teams actually work.

CAD/CAM/CAE software like SolidWorks, digital design and simulation tools, and physical production and prototyping equipment typically need direct, traditional file-share access rather than a document library — for file locking, path length, application compatibility, and machine integration reasons. Forcing that workload into SharePoint produces workarounds, not compliance.

For those environments the answer is a dedicated Azure Government build purpose-built for CUI and ITAR-controlled engineering data, commonly including existing on-premises file servers migrated into Azure Government so the drive mappings, folder structures, and NTFS permissions your engineers already know come with them.

What a typical build includes

• Network and perimeter security — a dedicated virtual network with segmented subnets for virtual desktop and file server workloads, network security groups restricting file-share traffic to authorized subnets only, next-generation firewall with intrusion detection and TLS inspection, and secured administrative access with no public RDP exposure
• Migrated on-premises file servers — existing Windows file servers lifted into Azure Government as hosted VMs, preserving drive mappings, folder structures, and NTFS permissions so engineering teams keep working the way they already do
• Compute and virtual desktop — AVD session hosts sized for CAD and engineering workloads running Office, Teams, CAD applications, and SharePoint CUI access, alongside dedicated file server VMs with encrypted SMB and legacy protocols disabled
• Identity and access — Entra ID with MFA, Conditional Access, privileged identity management, and Information Barriers where separation of user communities is required
• M365 GCC High integration — SharePoint site collections for collaboration that doesn’t require a file share, Purview sensitivity labels with encryption, and DLP policies blocking external sharing of CUI
• Security and monitoring — Defender for Cloud and Defender for Office 365, SIEM with unified audit integration and log retention aligned to CMMC requirements, and hardware-backed key and certificate management
• Storage — Azure Files or Blob Storage sized to the engineering team’s working set, with profile containers for consistent virtual desktop sessions
• Compliance — an Azure Policy CMMC Level 2 initiative assignment applied across the environment

Choose this path when your CUI or ITAR-controlled technical data lives in CAD/CAM/CAE files, simulation datasets, or machine-integrated production systems that need real file-share semantics. If your CUI is primarily documents and email, path 1 or path 2 fits better.

What doesn’t come with you

Part of running an honest practice is telling clients what won’t carry over cleanly, before it becomes a surprise during cutover week. These gaps apply primarily to full tenant migrations — enclave and Azure Government builds are greenfield and largely sidestep them — but all of them get flagged during Discovery regardless of path.

Beyond Microsoft’s own parity gaps, every third-party application integrated with your tenant needs checking — not “does the vendor have a government version,” but “is it available in GCC High, authorized appropriately, and does our license cover it.” Common problem areas: ERP and MRP connectors, CRM, HR and payroll, email security and archiving gateways, backup tooling, eSignature, MDM, SIEM connectors, and engineering or PLM tools that authenticate against Entra ID.

Cross-tenant collaboration

Collaboration between GCC High and commercial tenants is restricted, and the workflow will differ from what your teams do today. If your engineering group currently shares SharePoint sites with primes, subs, or customers, model exactly how that works post-migration during scoping. It’s a frequent post-cutover complaint and an avoidable one.

Handling CUI during the migration itself

During migration, your CUI passes through third-party migration tooling. That tooling — the credentials it holds and the personnel who operate it — is temporarily part of the story you’ll tell an assessor.

• Scope the tooling. The platform is processing CUI. Document what it is, where it runs, how it’s authenticated, what it retains, and for how long. Cloud-hosted and client-hosted are both defensible; what matters is that you chose deliberately and can say why.
• Ask whether the tool holds a FedRAMP authorization. Your regulated data is passing through it. This is a legitimate question, not trivia.
• Restrict who operates it. Engineers with access to export-controlled data must satisfy the same US-person requirements as anyone else touching that data. Credentials stay isolated from non-cleared personnel.
• Encrypt in transit and at rest, and document it.
• Log the migration. Job records, error and reconciliation reports, and completion evidence are useful operationally and necessary as artifacts later.
• Don’t stage CUI somewhere new. Interim file shares, admin workstations, and export directories created “just for the migration” have a way of surviving the project. If you create one, put it in scope and decommission it deliberately.

Ask any provider you’re evaluating how they handle this. A provider who hasn’t thought about it is telling you something.

What your users will notice

User-experience change is real even with advance notice and training, though how much depends on the path. In a full tenant migration, every user feels it:

• A different sign-in. GCC High portal and sign-in endpoints differ from commercial. Bookmarks break. Expect this to generate the highest ticket volume of anything.
• Mobile app reconfiguration on every phone and tablet. Do it through endpoint management where possible.
• Integrations that behave differently or aren’t available. Whatever couldn’t come across, users will notice on day one and attribute to the migration rather than to compliance.
• Reduced newer features, including Copilot. If people have built habits around them, set expectations well before cutover.
• External sharing friction. Give program and engineering teams a specific playbook, not a general reassurance.
• Search and history gaps depending on scope decisions — Teams private chat especially. Decide, document, and communicate in advance. Surprises here erode trust in the whole project.

In an enclave or Azure Government build, impact is narrower by design. Only in-scope users get a new virtual desktop and workflow; everyone else is unaffected. The trade-off is that those users maintain two contexts, so the boundary rules need to be explicit and the compliant path needs to be the convenient one.

Either way: clear communications ahead of go-live, role-appropriate training, and a help desk staffed through the first week post-cutover is the difference between a smooth transition and a wave of tickets that undermines confidence in the project — regardless of how clean the technical work underneath it was.

Decommissioning the legacy tenant

Abandoning a commercial tenant that still contains CUI is not a compliance strategy, and “we stopped using it” is not evidence.

1. Confirm the migration is complete and reconciled — reconciliation reports, not impressions.
2. Resolve legal holds and retention obligations first. Litigation hold, eDiscovery, and records retention may require content to remain accessible. Work this with legal before cancelling anything; you may need to retain limited licensing or export archives to a compliant location.
3. Remove all CUI — and any ITAR or EAR-controlled data alongside it — from mail, SharePoint, OneDrive, Teams, and anywhere else it accumulated, including recoverable items and version history.
4. Document the removal as media sanitization. This is your evidence and it belongs in your SSP.
5. Decommission and surrender licenses, and record the date.

The legacy tenant typically stays available with administrative access only for roughly 30–60 days post-cutover to catch late-surfacing issues, then gets sanitized and decommissioned. Contractors get dinged here not for making a mistake but for having no record of what they did. Treat decommissioning as an artifact-producing step.

The evidence your assessor will want

A migration done well hands you a substantial chunk of your assessment evidence. A migration done fast hands you a working environment and nothing else — and you rebuild the documentation later, from memory, under time pressure. Capture as you go:

• SSP updates reflecting the new environment, its boundary, and inherited controls
• Customer Responsibility Matrix for the cloud services in scope, showing which controls Microsoft provides and which are yours
• Boundary and data-flow diagrams showing where CUI is permitted to travel
• Configuration baselines as implemented — Conditional Access, MFA, device compliance, DLP and labeling policies, privileged access — traceable back to the Microsoft Technical Reference Guide control mappings
• Migration records — job logs, reconciliation reports, and documentation of how CUI was protected in transit
• Media sanitization records for the decommissioned tenant
• Cloud service authorization references and the DFARS 7012 commitments applicable to your licensing
• Policies and procedures updated to describe how the environment is actually operated
• Training records for enclave users on the boundary rules

Because the security baseline is built against Microsoft’s published CMMC guidance rather than an internal interpretation, the configuration evidence maps back to a citable source — which is materially easier to defend in an assessment than “this is how our engineers usually set it up.”

Licensing, eligibility, and seat minimums

Eligibility validation

Microsoft validates that your organization qualifies before provisioning a GCC High tenant. Expect to supply evidence of a contract or subcontract indicating a regulated data requirement, a CAGE code, active SAM registration, and attestation regarding organizational ownership and US-person status.

Foreign ownership is the most common disqualifier. US subsidiaries of foreign parents are generally ineligible without additional arrangements such as a Special Security Agreement. This is solvable but not quickly — if it applies to you, start here rather than with a migration plan.

Licensing through a single partner

SysArc is a Microsoft AOS-G (Agreement for Online Services – Government) partner, authorized to sell GCC, GCC High, and GCC High DoD SKUs directly, without routing you through a separate licensing reseller. Licensing, tenant build, and migration or enclave deployment run through one accountable partner rather than three vendors pointing at each other when something doesn’t line up.

Practical consequences of GCC High licensing regardless of who sells it:

• Commercial licenses do not convert, transfer, or credit.
• Ask about minimum quantities early. Not every AOS-G partner sells in small volumes, and an enclave-sized deal can fall below what some of them will quote — which narrows your provider list faster than anything else.
  
• You will pay for both environments during any parallel-run period. Budget for the overlap; it’s where finance usually gets surprised.
• Some commercial products, add-ons, and pricing programs have no GCC High equivalent. Verify each line of your license inventory rather than assuming a one-to-one swap.
• Discovery findings — mailboxes over 50GB, Online Archive usage, actual in-scope seat count — are licensing qualifiers. This is why discovery precedes procurement.

License selection is a compliance decision

Which SKUs you buy determines which NIST 800-171 controls you can satisfy with native tooling versus bolt-on products. Identity governance, endpoint protection, security awareness training, and SIEM capability all live in specific license tiers, and Microsoft’s Technical Reference Guide for CMMC maps its recommended configurations to specific service capabilities. Mapping this deliberately before you commit is cheaper than discovering the gap during assessment prep.

What drives the cost

Rather than a number that won’t fit your situation, here’s what moves the total, roughly in order of impact:

1. Which path you’re on. An enclave and a full tenant migration are different orders of magnitude, and it’s the biggest single lever available.
2. Seat count in scope — and whether discovery narrowed it before licenses were bought.
3. Licensing overlap during any parallel-run period.
4. Data volume and SharePoint complexity. Permissions depth and versioning cost more than raw terabytes.
5. Integration remediation. Rebuilding Power Platform assets or replacing an unavailable line-of-business application can exceed the migration itself.
6. Identity complexity. Hybrid identity and untidy directories add weeks.
7. Endpoint approach — Mentor Method versus Full Service is a real cost decision, and it also determines how self-sufficient your team is afterward.
8. VDI or Azure Government infrastructure where the design calls for it. Engineering-grade compute is not office-grade compute.
9. Source variety. On-prem Exchange plus Google Workspace plus a commercial tenant multiplies effort.
10. Change management and support surge around cutover.
11. Documentation and evidence production, if it isn’t in the migration scope.
12. Ongoing operations. A compliant environment has to stay compliant.

The cheapest thing you can do to reduce nearly all of this: reduce your data and tighten your scope before you migrate.

How to vet a GCC High migration provider

Contractors routinely ask peers for provider recommendations because this market is hard to evaluate from outside. These are the questions defense contractors actually raise when they compare notes. Ask them of whoever you’re talking to, including us.

1. Can you sell us GCC High licensing directly, and what’s your minimum quantity? First question, not fifth. Only a limited number of AOS-G partners sell in small volumes, and they don’t always say so up front.
2. Are you the reseller, the integrator, or both — and if both, why is that better for me? There’s a legitimate argument for separating them. There’s also a real case for one vendor, mostly about accountability when something breaks between licensing and configuration.
3. Will you teach my team to administer this, or do I stay dependent on you? Ask whether endpoint cutover and ongoing administration can be run by your own staff with the provider mentoring, and what documentation and RBAC handover comes with the project.
4. What does ongoing support look like after cutover, and who staffs it? Ask for a reference who’s been a client for more than a year, not one who just finished a migration.
5. Will you recommend an enclave — or tell me I don’t need GCC High at all — if that’s the right answer? A provider who never recommends the smaller scope is selling a product, not designing a solution.
6. What’s your security baseline built against? “Our best practices” is a weaker answer than a citable published standard. Ask which document, and which version.
7. Which migration tooling do you use, is it FedRAMP authorized, and do you run it as SaaS or self-hosted?
8. Who holds credentials to my data during migration, and do they satisfy US-person requirements?
9. How do you handle third-party application compatibility? Is that assessment in scope, and what happens when something isn’t available?
10. What about our workstations and engineering applications? Endpoint enrollment, profile handling, and CAD or production-equipment file access are real workstreams that migration-tool vendors don’t cover.
11. Which Microsoft licenses do you recommend, and which controls does each help me satisfy? A provider who can map SKUs to control families is thinking about your assessment. One who quotes the most expensive bundle is thinking about margin.
12. What documentation do I get? Ask for the artifact list and match it against section twelve.
13. What’s your abort plan if cutover fails, and at what point does it become irreversible? There should be a specific answer. Ours is that the migration is non-destructive up until custom domain transfer.
14. What does your assessment support look like? A compliant tenant is not a certification. Someone has to carry the evidence forward.

On the Microsoft partner list

Microsoft publishes a public list of approved AOS-G partners, and it’s the standard way providers demonstrate status — we link to it ourselves. It’s worth knowing that practitioners have flagged the list as not always current, including companies that no longer resell. Use it as a starting point and ask any provider to confirm their status directly.

Frequently asked questions

Sources and references

The security baseline described here isn’t an internal interpretation of compliance requirements — it’s built against published guidance from Microsoft and the federal government.

• Microsoft Technical Reference Guide for CMMC 2.0 (Version 1.0 Preview, October 2024) — Microsoft’s official implementation guidance mapping CMMC Level 2 practices to Microsoft 365 GCC High and Azure Government configurations.
  
• NIST SP 800-171 — Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations.
• DFARS 252.204-7012 — Safeguarding Covered Defense Information and Cyber Incident Reporting.
• ITAR (22 CFR 120–130) and EAR (15 CFR 730–774) — the export control regulations governing defense articles and technical data, and dual-use items.

Scope it with someone who builds these

SysArc has been designing and operating compliant environments for the defense industrial base since 2004 — as a Microsoft AOS-G partner licensing GCC, GCC High, and GCC High DoD directly, with a security baseline built specifically against Microsoft’s published CMMC guidance.

If you’re at the scoping stage, the most useful next step is a conversation about where your CUI actually lives and which of the three paths fits. No obligation to move anything.

Request a consultation See our migration services

Related reading

• What is Microsoft GCC & GCC High? A guide for DoD contractors
• What’s the difference between Microsoft 365 GCC and GCC High?
• Do DoD contractors need GCC or GCC High for DFARS, CMMC, or ITAR?
• Why standard Microsoft 365 won’t cut it for CMMC Level 2
• GCC High enclaves for US subsidiaries of multinational companies
• How SysArc helped 2 Circle Inc. migrate to GCC High