GCC High Licensing and G3 vs. G5 Start With CMMC Scope

Raven Riley on August 19, 2026

GCC High Licensing and G3 vs. G5 Start With CMMC Scope

Microsoft licensing is the last decision in the chain, and it is the one most organizations make first. The contract, the data, and the Cybersecurity Maturity Model Certification (CMMC) Assessment Scope decide the Microsoft cloud and the licensing tier inside it.

The chain runs in one direction: contract, data, assessment scope, Microsoft environment, licensing tier, control design, evidence. Work it backward from a seat count and the cost lands twice, once in capabilities the design never called for, again when the tenant is wrong for the data.

The Contract Establishes What The Microsoft Environment Must Support

DFARS 252.204-7012 establishes safeguarding requirements for covered contractor information systems. Where it applies, the contractor must provide adequate security for those systems.

Paragraph (b)(2)(i) subjects that system to the security requirements in NIST SP 800-171 in effect when the solicitation is issued, or as authorized by the Contracting Officer. The clause names no revision of its own.

Paragraph (b)(2)(ii)(D) adds two obligations where an external cloud service provider will store, process, or transmit covered defense information. The contractor must require and ensure the provider meets security requirements equivalent to the Federal Risk and Authorization Management Program (FedRAMP) Moderate baseline.

The same paragraph requires the contractor to ensure the provider complies with paragraphs (c) through (g), covering incident reporting, malicious software, media preservation, forensic access, and damage assessment. A provider that clears the baseline and will not commit to the rest does not satisfy the paragraph.

Getting those commitments in writing from a hyperscaler moves at procurement speed, not engineering speed.

The Microsoft environment is now an architecture decision. Commercial Microsoft 365, Government Community Cloud (GCC), GCC High, and Office 365 DoD carry different commitments, documented in Microsoft’s Office 365 US Government service descriptions.

The Phase 2 Suspension Changed What Can Be Required, Not What Applies

The Department of War (DoW) suspended CMMC Phase 2 on July 13, 2026. The transition had been set for November 10, 2026.

The DoW Chief Information Officer memorandum states that during the suspension the Department will enforce baseline compliance with NIST SP 800-171 Revision 2 through CMMC Level 1 and Level 2 self-assessment. The same document states that DFARS 252.204-7012 requirements remain in effect.

Requiring activities may now designate only Level 1 (Self) or Level 2 (Self). The Department published no replacement date, directing a 60-day review instead.

That constrains what contracting activities may require going forward. A clause already in a signed contract stays where it is. The environment decision was driven by the clause and the data, and both are unchanged.

CMMC Assessment Scope And User Count Answer Different Questions

The CMMC Assessment Scope follows the assets involved with CUI and the assets providing security functions to that environment. User count answers a different question: how many people need Microsoft licensing.

32 CFR 170.19 requires the scope to be specified before a Level 2 self-assessment or certification assessment begins, and Table 3 defines the asset categories. CUI Assets process, store, or transmit CUI. Security Protection Assets provide security functions or capabilities to the assessment scope.

Consider an employee who never opens a CUI document. The Microsoft services protecting the systems where CUI is handled are still Security Protection Assets, and Table 3 requires them documented in the asset inventory, the System Security Plan (SSP), and the network diagram.

Those assets are assessed against Level 2 requirements relevant to the capabilities provided. Contractor Risk Managed Assets sit under a different rule in the same table.

Assigning a higher tier across the organization raises the invoice while the scoping question stays open.

G3 Versus G5 Follows The Control Design

G3 and G5 determine which Microsoft capabilities are available to support a control design. CMMC establishes what the environment has to satisfy.

Where DFARS 252.204-7021 applies, the contractor must have and maintain a current CMMC status at the level the Contracting Officer inserts into the clause, for every system used in performance of the contract that processes, stores, or transmits Federal Contract Information (FCI) or CUI.

No level appears in the regulation itself. Paragraph (d)(1)(i) is a fill-in.

Microsoft documents G3 as including Defender for Endpoint Plan 1, and lists the G5 and G5 Security offerings among the Defender for Endpoint licensing options for GCC, GCC High, and DoD.

Capability availability also depends on the Microsoft environment. Microsoft states that Defender for Endpoint for US Government customers does not have complete parity with the commercial offering, naming gaps that include Microsoft Threat Experts and enterprise Internet of Things (IoT) security.

GCC And GCC High Carry Different Microsoft Commitments

Microsoft describes GCC as an environment for eligible government entities and organizations handling government-regulated or controlled data. Its published commitments for GCC include FedRAMP High and DFARS.

Microsoft offers GCC High to the Department of Defense (DoD) and to contractors holding or processing DoD Controlled Unclassified Information (CUI) or data subject to the International Traffic in Arms Regulations (ITAR). Microsoft agrees to ITAR contract language only for GCC High.

Read Microsoft’s Impact Level sentence in full. It first conditions the claim on an environment “assessed using NIST SP 800-53 controls at a FIPS 199 High Categorization.” Only then does the sentence reach “equivalency to IL4 or necessary inheritance for CMMC.”

Equivalency to Impact Level 4 is not an IL4 authorization, and inheritance is what your assessment uses rather than something the platform holds for you. Microsoft’s CMMC page puts it more carefully, saying GCC High “supports organizations in meeting CMMC Level 2 and Level 3 requirements (when configured appropriately).” The parenthetical is the work.

Conditional access, retention, and information protection all operate inside the cloud already provisioned. Moving a workload to a different government environment is a tenant migration, not a configuration change.

GCC High Procurement Runs Through Eligibility And An Authorized Channel

Microsoft controls eligibility for its government environments and the channels used to acquire them. Its Microsoft 365 Government purchasing documentation lists GCC High through an Enterprise Agreement with a Licensed Solution Provider (LSP), or through the Agreement for Online Services for Government (AOS-G) channel.

Cloud Solution Provider appears in the GCC column only. Office 365 DoD is Enterprise Agreement and nothing else.

Microsoft frames Enterprise Agreement and LSP at 500 seats and above in its section headings, and AOS-G at under 500 seats. It maintains separate AOS-G lists for GCC and GCC High, and for GCC alone.

Microsoft requires eligibility validation before the environment is established, and revalidation at renewal. Validation may require proof of ITAR registration with the State Department. Microsoft publishes no timeframe for the process.

Microsoft lists Agile IT on the AOS-G list covering GCC and GCC High under 500 seats.

Resolve eligibility and channel authorization before provisioning begins. A reseller that cannot transact your environment surfaces after the dates are committed.

Microsoft 365 Pricing Accounts For Part Of The Architecture

Per-user Microsoft 365 pricing covers the licenses assigned to users. Where the regulated workload requires Azure services, the architecture also carries compute, storage, networking, logging, and security consumption outside those seat licenses.

DFARS 252.204-7012 paragraph (e) turns one of those costs into a contract obligation. A contractor who discovers a cyber incident must preserve system images and all relevant monitoring and packet capture data for at least 90 days, running from submission of the incident report.

Data has to exist before the incident to be preserved after it. Microsoft Sentinel bills analytics by the gigabyte ingested, with commitment tiers starting at 100 GB per day and retention at no charge for the first 90 days.

The workload requirements determine whether those Azure services belong in Azure Commercial or Azure Government. Microsoft states that both carry the same security controls, that a third-party assessment organization has attested both for CUI workloads, and that the environment decision rests with the customer.

Azure Government adds contractual commitments: customer data stored in the United States, and access to systems processing it limited to screened US persons. Microsoft raises export control as why that difference matters, which is where ITAR-driven workloads land.

Assessment Evidence Comes From Implementation, Not Entitlement

Assessment evidence has to support how the requirement is implemented within the environment. A Microsoft entitlement establishes access to a capability, and stops there.

DFARS 252.204-7021 also requires an annual affirmation of continuous compliance in the Supplier Performance Risk System (SPRS), submitted by the affirming official. The clause defines “current,” and that definition does real work: a Level 2 certification assessment runs 3 years, while the affirmation cannot be older than 1 year.

A 3-year certificate sitting next to a 13-month-old affirmation is not a current CMMC status.

Microsoft Defender makes the difference concrete. Purchasing the license makes the capability available, and an assessor asks who configured it, who reviews the output, and what happened last time it flagged something.

Operating records accumulate over months, and no purchase order shortens that.

Pressure-test the Microsoft government licensing against the environment you are building.

Microsoft Licensing And CMMC FAQs

Does Commercial Microsoft 365 Meet CMMC Level 2?

The contract, the information being handled, the CMMC Assessment Scope, and the implementation determine what the environment has to support. CMMC Level 2 designates no Microsoft 365 SKU that satisfies its requirements on its own. DFARS 252.204-7012 adds requirements for covered contractor information systems and for external cloud service providers.

Do I Need GCC High To Handle CUI?

The applicable contract and data requirements establish the commitments the Microsoft environment needs, and CUI alone does not settle the question. Microsoft offers GCC High to the Department of Defense and to contractors holding or processing DoD CUI or ITAR-controlled data, and agrees to ITAR contract language only for GCC High.

Can I Buy GCC High From Any Microsoft Reseller?

Microsoft specifies the purchasing channels for GCC High and requires eligibility validation first. Its Microsoft 365 Government purchasing documentation lists an Enterprise Agreement through a Licensed Solution Provider and the Agreement for Online Services for Government channel. A reseller authorized for GCC is not automatically authorized for GCC High.

Did The Phase 2 Suspension Change My DFARS Obligations?

The DoW Chief Information Officer memorandum suspending CMMC Phase 2 states that DFARS 252.204-7012 requirements remain in effect. During the suspension the Department will enforce NIST SP 800-171 Revision 2 through Level 1 and Level 2 self-assessment. No replacement date was published, and a signed contract is unaffected.

Confirm The Microsoft Licensing Before The Architecture Depends On It

Microsoft licensing gets expensive to unwind after users, data, controls, and Azure services depend on the original decision. An unsupported assumption anywhere in that chain belongs back in the architecture discussion first.

Pressure-test the Microsoft government licensing against the environment you are building.

Which assumption in your Microsoft environment would be hardest to support with the contract, architecture, and evidence you have today?

What Counts as CUI in Microsoft 365 and Azure Government

Raven Riley on July 29, 2026

Most CUI scope decisions get made in one meeting, by whoever is in the room, and documented afterward to match. That boundary holds until a C3PAO asks who justified it. The designating agency decides what qualifies. Data flow decides what’s in scope. The Microsoft environment follows both, not the reverse.

Where CMMC Assessments Break Down in Microsoft Environments

Raven Riley on July 22, 2026

Assessment failures rarely start with missing controls. They start with decisions no one wrote down.

CMMC Level 2 assessments that stall inside a Microsoft environment tend to start from the same baseline, not a shortage of controls. Conditional access is enforced, audit logging is active, and identity governance is running on schedule, yet that baseline is not the biggest consideration for whether you pass an assessment.

One of the most common failure points Agile IT sees is whether the explanation the organization gives matches what the documentation over time says, not simply whether someone in the room can articulate why the control exists.

A functioning environment and a defensible one are separate claims, and CMMC Third-Party Assessment Organizations (C3PAOs) only accept the second one to pass assessment. Deployment proves a control exists. It doesn’t prove the organization owns the decision behind it, can reconstruct why the setting was chosen, or can produce a consistent account of how it has operated over time. The current CMMC Program Rule at 32 CFR Part 170, assessed against NIST SP 800-171 Revision 2, tests requirements on exactly that basis: whether something is met, monitored, and evidenced, not whether a setting was switched on.

Four patterns account for most of what surfaces in Microsoft 365 and Azure Government environments during CMMC Level 2 assessments, and none of them are technical: (1) scope inconsistency, (2) evidence gaps, (3) undocumented configuration decisions, and (4) control ownership drift.

Scope Inconsistency

Scope inconsistency is when the asset inventory, System Security Plan (SSP), and network diagram describe the assessment boundary differently. It often surfaces informally first, when IT, compliance, and program leadership give different answers to the same scoping question. The CMMC Level 2 Scoping Guide requires the Organization Seeking Assessment (OSA) to produce three artifacts before assessment starts: an asset inventory, SSP treatment for each asset, and a network diagram of the Assessment Scope. The failure pattern shows up when those artifacts contradict each other, or when the NIST SP 800-171A requirements are examined, interviewed, and tested by C3PAOs and they don’t match the operational reality.

A network diagram marking an asset out of scope, an SSP implying otherwise, and an interview or technical check showing Controlled Unclassified Information (CUI) still flowing through it is the actual failure, not three artifacts describing a boundary differently. That informal disagreement is only the early warning sign. What holds up under review is whether the artifacts and the physical environment still agree once the boundary is on paper.

Tenant architecture decisions compound this. Whether CUI-handling workloads sit in GCC, GCC High, or some hybrid arrangement using enclaves is typically decided early, treated as settled, and never re-examined as new workloads get layered in. A team that assumed a workflow stayed inside GCC High finds during scope validation that a shared mailbox or a line-of-business app now routes CUI through commercial tenant infrastructure. The architecture wasn’t wrong when it was built. It was never validated against how the environment actually operates, and the boundary on paper stopped matching the boundary in practice well before assessment prep started asking pointed questions.

Once a mismatch like this surfaces, the instinct is often to fix it by expanding the boundary defensively rather than resolving why the artifacts disagreed in the first place. That doesn’t address what actually broke down. Over-scoping to compensate wastes capital on systems that never needed to sit inside the boundary. Under-scoping leaves the exact gap an assessor is trained to find. Neither substitutes for a scope decision that was made once, documented, and repeated the same way across every artifact an OSA is required to produce.

Evidence Gaps

Evidence gaps surface once a control is confirmed to be working exactly as intended and the assessor moves to the next question anyway:

Why does this conditional access policy exclude a specific group?
Why was legacy authentication retained for one application after being disabled everywhere else?
Why does an exception exist for a break-glass account?

These are ordinary operational decisions, and most Microsoft environments carry dozens of them. The issue is never that the decision was wrong. It’s that the decision exists only as a configuration setting, with no record tying it to the requirement it satisfies or the person who approved it.

The same gap opens between the SSP narrative and what the environment currently reflects. An SSP might describe a conditional access requirement one way while the deployed policy has since been modified to accommodate a vendor exception, a merger, or a new business unit, and the narrative was never updated to match. The control still functions correctly. The evidence package no longer agrees with itself, and an assessor reading the SSP against the live tenant finds the mismatch before anyone explains the exception that caused it.

A working policy is the baseline assessors start from, not what earns a passing result. Whether the conditional access policy behaves as configured is rarely in question; what’s tested is whether the explanation for why it’s configured that way matches the documentation already on file for it, not just whether someone can articulate a reason when asked. Security tools generate data. A documented decision trail is what turns that data into evidence, and that distinction is the entire basis on which NIST SP 800-171 assessment objectives operate.

Undocumented Configuration Decisions

Conditional access, audit log retention, and identity governance carry the heaviest share of this exposure in Microsoft environments, because each one requires an ongoing decision rather than a one-time activation.

Audit log retention configured in Microsoft Purview means little to an assessor without the decision record tying the retention interval to the requirement it’s meant to satisfy. Identity governance access reviews running on schedule mean little without documented ownership of what happens when a review flags access that never gets revoked. Conditional access exceptions accumulate for legacy systems, specific roles, and vendor accounts over time, and each one needs a decision behind it that can be produced independent of who happens to be explaining it that day.

Each of these three settings carries the same structural weakness. The technical control and the governance decision behind it live in two different places: one inside the Microsoft admin center, and one that’s supposed to exist in policy, a risk acceptance memo, or an SSP appendix. When only the technical side gets maintained, the environment continues operating correctly while the governance record goes stale, and the two versions drift apart without anyone noticing until an assessor asks for both.

The configuration has to hold up as its own witness. If the explanation only exists in one person’s memory, it isn’t evidence yet. It’s an assumption that hasn’t been tested.

Control Ownership Drift

Control ownership drifts when responsibility for a control changes over time without the supporting documentation changing with it. In Microsoft environments, administration is frequently divided across infrastructure, security, compliance, and managed service providers. A conditional access policy may be created by one team, reviewed by another, and monitored by a third. The control continues operating as intended while accountability becomes increasingly difficult to demonstrate during assessment.

The gap usually appears when an assessor asks who owns the control, who reviews it, who approves exceptions, and where those decisions are documented. Different answers from different stakeholders become evidence that ownership was never maintained consistently. The control itself remains functional. The governance record describing responsibility no longer reflects the environment as it exists on the day of assessment.

The same pattern develops as organizations add business units, inherit legacy systems, or reorganize administrative responsibilities. Documentation often reflects the environment that existed when the control was implemented rather than the one operating today. Shared responsibility across Microsoft, internal teams, and external service providers adds another layer of complexity when governance records do not clearly define where one responsibility ends and another begins.

Ownership becomes part of the assessment evidence alongside the technical control itself. Microsoft 365 and Azure Government centralize identity, access, compliance, and governance functions, but responsibility for those controls is often distributed across multiple teams. The technical configuration can remain unchanged while the documented ownership behind it gradually diverges from operational reality, leaving multiple accounts of the same control for an assessor to reconcile.

Why the Gap Surfaces Now

In July 2026, the Department of War (DoW, formerly DoD) suspended CMMC Phase 2 requirements and opened a review of the program. That pause changes timing, not exposure. DFARS 252.204-7012, NIST SP 800-171 compliance, and SPRS self-assessment scores remain contract requirements while the review runs, and the gaps described above exist regardless of the enforcement schedule.

For subcontractors carrying a prime’s compliance warning, this exposure doesn’t resolve the same way it did under self-assessment. C3PAO certification versus self-assessment is set by contract terms, not by prime or sub status, and DFARS 252.204-7020 flows the applicable level down regardless of tier. Which situations call for a C3PAO assessor and which don’t still come down to what the specific contract requires. Phase 1 gave DoW Program Managers discretion to require Level 2 (C3PAO) in place of self-assessment on individual contracts, and individual contracts can still carry that requirement today. Organizations that treat the suspension as a reason to stop preparing will meet the same gaps when enforcement resumes, on someone else’s timeline.

Confused about C3PAO requirements after the DoW announcement?
Read our breakdown of the Phase 2 suspension.

Self-attestation absorbed a certain amount of internal inconsistency, because the organization was answering its own questions. Third-party assessment doesn’t work the same way. A C3PAO assessor has no context for why a scope decision was made, no history with the environment, and no reason to fill in gaps generously. The assessor works from the SSP, the assessment objectives, and whatever the organization can produce in the room. The inconsistency between all of those components becomes a line item, not a conversation.

Where This Leaves an Organization

Assessment doesn’t create these gaps. It reveals decisions that were already made or never formally made at all. It evaluates a boundary, a policy, and a review process exactly as they exist on the day the assessor arrives (not as they were intended to exist).

Organizations that walk into assessment with a defensible position aren’t the ones with more controls than everyone else. They’re the ones who settled scope, evidence, and configuration ownership before a C3PAO forced the question, which means the validation happened on their timeline instead of the assessor’s.

Frequently Asked Questions

Why do CMMC Level 2 assessments fail?

Most CMMC Level 2 assessment failures trace to governance gaps, not missing controls. The four most common patterns in Microsoft environments are scope inconsistency across required artifacts, evidence gaps behind working controls, undocumented configuration decisions, and control ownership drift. Each one leaves an assessor with accounts that do not agree, even when the environment itself is functioning correctly.

Does GCC High guarantee CMMC compliance?

No. GCC High is a tenant decision, not a certification. It provides the infrastructure to meet requirements tied to CUI and ITAR data, but assessment outcomes depend on how the environment is scoped, configured, documented, and evidenced. An organization can fail an assessment inside GCC High and, depending on contract requirements and data types, pass outside of it.

What evidence do C3PAO assessors require?

C3PAO assessors work from the NIST SP 800-171A assessment objectives, which means every requirement is examined, interviewed, and tested. Expect to produce a current System Security Plan, an asset inventory, a network diagram of the Assessment Scope, and decision records tying each configuration to the requirement it satisfies. A control that works but has no documented decision behind it is a finding waiting to happen.

Is CMMC still required after the Phase 2 suspension?

Yes. The Department of War suspended CMMC Phase 2 requirements in July 2026 pending a program review, but that pause changes timing, not obligation. DFARS 252.204-7012, NIST SP 800-171 compliance, and SPRS self-assessment scores remain contract requirements, and individual contracts can still require third-party certification. Organizations that treat the suspension as a reason to stop preparing will face the same gaps when enforcement resumes.

Looking for support? A strategy session is where we look at where you are and determine what the right next step is, whether that’s a gap analysis, a mock assessment pressure test, or building out what’s missing, before an assessor makes that determination for you. Schedule a strategy session.