CMMC shared responsibility is bigger than Microsoft 365 GCC High

At a glance

What this is: This post explains how CMMC responsibility is divided across Microsoft, the contractor, and an MSP in GCC High, and shows that compliance still depends on documented configuration and evidence.

Why it matters: It matters because IAM, logging, training, and incident response duties cannot be assumed away by cloud inheritance, and identity teams must prove who controls what across human and non-human access paths.

By the numbers:

• Microsoft can cover nearly half of NIST 800-171 requirements, with 53 of 110 controls inherited in a GCC High deployment.
• 110 NIST 800-171 requirements
• The table below shows the general responsibility distribution of all 110 high-level requirements across the 14 NIST SP 800-171 control families in a GCC High deployment.

👉 Read Secureframe's CMMC shared responsibility guide for GCC High

Context

CMMC shared responsibility is the division of security work between the cloud provider, the customer, and any managed service provider supporting the environment. In practice, the hard part is not buying GCC High. It is proving that identity controls, audit evidence, training, and incident response are owned, configured, and operating inside the contractor’s boundary.

For IAM and compliance teams, the key issue is that cloud inheritance does not remove accountability. The article is really about governance drift, where teams mistake platform capability for operational compliance. That pattern is familiar across identity programmes, including service accounts, access reviews, and non-human identity administration, because responsibility must be explicit before it can be audited.

Key questions

Q: What fails when organisations assume GCC High automatically makes them CMMC compliant?

A: The failure mode is governance drift. Organisations confuse platform inheritance with operational responsibility, then discover that access controls, logging, training, and incident response still require configuration, evidence, and ownership. GCC High can support compliance, but it does not perform compliance for the contractor.

Q: Why do identity controls matter so much in CMMC shared responsibility?

A: Because CMMC evidence often depends on who can access CUI, how privileged access is limited, and whether authentication and review processes are operating as intended. Identity controls become the proof layer for many shared requirements, so weak IAM configuration can undermine otherwise strong cloud infrastructure.

Q: How do you know whether a shared responsibility matrix is actually working?

A: A working matrix maps each control to a real owner, a real process, and a real evidence source. If the document cannot explain who configures the control, who reviews it, and what artifact proves it is operating, the matrix is cosmetic rather than operational.

Q: Who is accountable when an MSP operates part of the CMMC environment?

A: The contractor remains accountable for demonstrating compliance, even if an MSP performs configuration or monitoring tasks. The MSP can execute work, but it cannot absorb assessment responsibility, answer for gaps it does not own, or replace the contractor’s evidence and oversight.

Technical breakdown

Inherited controls vs. customer controls in GCC High

GCC High changes the control stack by separating platform-level inheritance from customer-operated security work. Inherited controls are those Microsoft operates in the cloud layer, such as physical security and some infrastructure protections. Customer controls are policies, procedures, and operational processes the contractor must design, configure, and evidence. The important nuance is that compliance lives at the assessment-objective level, not the marketing claim level. A control being technically available in the tenant does not mean it is effective in practice. That distinction is what C3PAOs test.

Practical implication: map every control to inherited, shared, or customer-owned status before assessment evidence is collected.

Conditional Access, RBAC, and audit logging are only controls when configured

The article’s access-control example is the best illustration of shared responsibility. Entra ID can support Conditional Access, role-based access control, and multi-factor authentication, but the environment is not secure by default. The same applies to audit logging: logs may exist, but review cadence, alert thresholds, retention, and escalation paths are still operational decisions. In identity terms, this is the difference between a control being present and a control being governed. The platform supplies capability; the customer supplies policy and proof.

Practical implication: treat identity configuration, log review, and policy enforcement as assessed operating controls, not setup tasks.

Why MSP delegation does not remove compliance accountability

An MSP can implement and run parts of the environment, but it cannot absorb the organization’s accountability for CMMC. That is a common governance failure in regulated environments: teams outsource execution and then assume they have outsourced responsibility. In reality, assessors look for evidence that the contractor understands the control, can explain it, and can prove it is operating. This has direct relevance to identity governance because delegated administration, access review, and log monitoring all depend on clear ownership chains.

Practical implication: document MSP responsibilities, but keep internal ownership, evidence, and assessor-ready narratives inside the contractor’s programme.

Threat narrative

Attacker objective: The attacker objective is to exploit governance gaps in a supposedly compliant environment, gain access to controlled data or systems, and increase the chance of undetected persistence or assessment failure.

1. Entry occurs when contractors assume GCC High inheritance equals compliance and leave identity or logging controls underconfigured.
2. Escalation follows when default access policies, weak review processes, or undocumented MSP activity create gaps that an adversary can exploit through privileged accounts or unmanaged access.
3. Impact is failed control validation, exposure of CUI, or assessment findings that block certification even though the platform itself was not the point of failure.

NHI Mgmt Group analysis

Cloud inheritance is not compliance inheritance. The central mistake in GCC High programmes is treating provider authorization as a substitute for operational control. Microsoft may inherit infrastructure duties, but the contractor still has to configure identity, logging, evidence, and response. That distinction is foundational to CMMC and to any identity programme that depends on cloud boundaries. Practitioners should assume the assessor will test the operating model, not the license label.

Conditional access becomes a governance control only when policy, exception handling, and evidence are linked. The article correctly points to Conditional Access and RBAC as shared responsibilities, but the deeper lesson is that identity controls fail when they are left in default or undocumented states. This is where NIST SP 800-53 access control and auditability expectations intersect with CMMC evidence. Practitioners should view every identity policy as an audit object, not a configuration toggle.

Delegated administration creates a responsibility chain, not a responsibility transfer. MSPs often operate security tools, but the contractor remains the party that must explain who monitors, who approves, who reviews, and who escalates. That matters for both human IAM and non-human identity governance, because privileged access and audit review cannot be proven by contract language alone. Practitioners should require a documented ownership chain for each control and each administrative path.

Shared responsibility should sharpen identity governance, not dilute it. The best outcome of this model is not convenience, but precision: each control has an owner, a verifier, and an evidence source. That makes governance more testable and reduces the risk that IAM, PAM, or logging gaps get hidden behind cloud-provider assumptions. Practitioners should use the SRM as an identity governance map, not just a compliance spreadsheet.

Control inheritance exposes a broader compliance blind spot: organisations often measure platform coverage instead of operational readiness. GCC High can satisfy a large share of the technical baseline, but CMMC ultimately measures whether controls are implemented, maintained, and demonstrated. This is the same failure mode that appears in NHI programmes when teams assume vaulting or cloud hosting equals secure operation. Practitioners should assess readiness by control execution, not by service tier.

What this signals

CMMC programmes now need an ownership model, not just a control model. The practical signal for practitioners is that SRMs, SSPs, and evidence packs must align with how identity and access decisions are actually made. If your team cannot show who owns conditional access, privileged administration, and audit review, the assessment gap is already present. For the identity dimension, use the Ultimate Guide to NHIs , Regulatory and Audit Perspectives to anchor audit expectations.

Shared responsibility exposes a familiar identity problem: unmanaged credentials hide inside supposedly managed environments. That matters because cloud and MSP inheritance can make teams overlook service accounts, automation tokens, and delegated admin paths that still need lifecycle control. The broader pattern is credential sprawl across both human and non-human access paths, which undermines CMMC evidence quality and operational confidence.

Control ownership will increasingly be evaluated alongside evidence freshness. In regulated environments, the question is moving from whether a platform supports a control to whether the organisation can prove recent operation of that control. That is why CMMC teams should treat identity reviews, secret handling, and delegated administration as living processes rather than annual paperwork exercises. For the broader identity baseline, see Top 10 NHI Issues.

For practitioners

• Build a control ownership map before evidence collection Assign every CMMC requirement to Microsoft, the contractor, or the MSP, then document the decision in the SSP and SRM so assessors can trace ownership without ambiguity.
• Verify identity controls beyond tenant defaults Confirm that Conditional Access, MFA, RBAC, and device restrictions are explicitly configured for CUI access, because default GCC High settings do not equal compliant identity governance.
• Turn audit logging into an operating process Define who reviews logs, how often, what events trigger escalation, and how retention aligns to the contract lifecycle, then keep evidence of those reviews.
• Document MSP execution and internal accountability separately Write down which tasks the MSP performs, which decisions the contractor retains, and who answers assessor questions when control operation is reviewed.
• Refresh the SRM whenever scope changes Update the shared responsibility matrix when services change, workloads move, or new systems enter scope, because stale responsibility mapping becomes an assessment finding.

Key takeaways

• GCC High can inherit security capabilities, but it does not inherit compliance accountability.
• The most common CMMC failure mode is not missing technology, but undocumented ownership and weak evidence.
• Identity configuration, privileged access, and audit review are operational controls that must be proven, not assumed.

Key terms

• Shared Responsibility Matrix: A shared responsibility matrix is a control mapping document that shows which security tasks belong to the cloud provider, the customer, or another service provider. In regulated environments, it must align with the actual operating model, evidence sources, and assessment boundaries, not just the vendor’s service description.
• Inherited Control: An inherited control is a security requirement that the customer satisfies by relying on controls already implemented by the cloud provider. The customer still has to document the inheritance, understand its scope, and prove that the control applies to the system boundary being assessed.
• Customer Responsibility: Customer responsibility covers the policies, procedures, configurations, and operational activities that the organisation itself must implement to meet compliance requirements. In cloud compliance programmes, this includes the parts of identity governance, monitoring, training, and response that cannot be delegated away.
• C3PAO Assessment: A C3PAO assessment is the formal third-party review used to determine whether a contractor meets CMMC requirements. Assessors test whether controls exist, operate effectively, and are backed by evidence that matches the organisation’s documentation and staff explanations.

What's in the full article

Secureframe's full blog covers the operational detail this post intentionally leaves for the source:

• A control-by-control Shared Responsibility Matrix across the 14 NIST SP 800-171 families for GCC High
• Specific examples of what Microsoft inherits versus what the contractor must configure in access, audit, and incident response
• Guidance for documenting MSP responsibilities in the SSP and CRM so assessors can trace ownership
• The article's breakdown of common shared responsibility mistakes and how they show up during a C3PAO assessment

👉 Secureframe's full post covers the control matrix, MSP boundaries, and assessment pitfalls in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, IAM, and secrets management. It helps security and identity practitioners build the control discipline needed across regulated cloud and compliance programmes.