CMMC scope confusion still leaves contractors guessing on compliance

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Todyl's blog post: CMMC scope and compliance uncertainty center on which organisations may be affected and what they need to determine first.

Why it matters: It matters because identity and security teams supporting defence-adjacent customers need to know when CMMC obligations apply, how scoping affects control ownership, and when an assessor-led review becomes necessary.

Context

CMMC is a defence supply-chain compliance framework that only becomes operationally relevant when an organisation handles covered information or supports a defence customer relationship. The practical problem is scope, not theory, because teams can spend time on the wrong controls if they have not first determined whether the programme applies at all.

For MSPs and small or medium business clients, the first governance question is whether their services, access paths, and evidence collection create CMMC obligations. When that is unclear, control ownership, documentation, and assessment planning all become fragile, which is why a structured scope review is the correct starting point.

Key questions

Q: How should an organisation implement CMMC 2.0?

A: Implement CMMC 2.0 by first determining the level required for the work, then closing gaps against the required practices and documenting evidence for each control. Security teams should focus on access control, configuration, incident handling, and supplier oversight, then maintain those controls through reviews, testing, and remediation tracking.

Q: Why do MSPs often find CMMC compliance harder to scope than direct contractors?

A: MSPs usually sit inside multiple customer environments, which means access paths, support tooling, and evidence records can span more than one boundary. That makes ownership and traceability harder to prove. If the provider cannot show exactly which systems and identities are in scope for each client, the assessment surface expands and compliance work becomes inconsistent.

Q: What should teams do first when CMMC requirements are unclear?

A: They should run a structured scope review before building controls or collecting evidence. The review should answer which contracts apply, which information types are involved, which systems can access that information, and who owns each control. Without that sequence, organisations risk implementing the wrong safeguards for the wrong boundary.

Q: What is the difference between CMMC readiness and audit readiness?

A: CMMC readiness is the operating state that keeps controls effective across the year, while audit readiness is the ability to prove that state to an assessor. One is operational continuity, the other is evidence packaging. Defence contractors need both, because compliance can fail either when controls drift or when they cannot demonstrate control performance clearly.

Technical breakdown

How CMMC scope is determined for service providers and clients

CMMC scope starts with the relationship between the organisation, the defence customer, and the information being handled. If a provider stores, processes, transmits, or can access covered defence information, the compliance boundary may extend beyond the obvious production system. That means MSP access, support tooling, shared services, and evidence repositories can all become part of the assessment surface. Scope is therefore a governance problem before it becomes a controls problem. Teams that define the boundary too narrowly often miss supporting systems that actually carry compliance obligations. Practical implication: map every service and access path that could touch covered information before deciding which controls to implement. See the NIST SP 800-171 and CMMC 2.0 Guide.

Practical implication: Map every service and access path that could touch covered information before deciding which controls to implement.

Why C3PAO assessment readiness matters before you assume compliance

A Certified Third-Party Assessor Organization provides the definitive assessment path when organisations need to confirm whether their controls satisfy CMMC expectations. In practice, that means evidence quality, scope clarity, and control ownership matter as much as the control implementation itself. A team can have strong technical safeguards and still fail readiness if the documentation does not match the assessed environment. This is especially true when multiple customers, contracts, or managed services blur who owns what. Practical implication: align policy, system evidence, and operational ownership before engaging an assessor.

Practical implication: Align policy, system evidence, and operational ownership before engaging an assessor.

What CMMC means for identity, access, and contractor evidence

Although CMMC is often discussed as a compliance programme, its operational burden lands heavily on identity and access governance. The organisation must be able to show who can reach covered systems, under what conditions, and with what approvals or monitoring. That makes privileged access, account lifecycle, and vendor access records central to the evidence set. When MSPs support multiple clients, identity boundaries can blur quickly, creating gaps in attestation and access traceability. Practical implication: treat identity evidence as part of the compliance boundary, not a separate administrative task.

Practical implication: Treat identity evidence as part of the compliance boundary, not a separate administrative task.

NHI Mgmt Group analysis

CMMC confusion is fundamentally a scoping failure, not an awareness failure. The article shows that many organisations still struggle to determine whether they are in scope at all, which means the compliance risk begins before any control is selected. That is a governance weakness because teams cannot build or evidence what they have not bounded. For defence-adjacent providers, the practical conclusion is that scope definition must precede control design.

Managed service relationships make compliance boundaries more fragile than most teams assume. MSPs rarely operate in neat system silos, and access paths often extend into customer environments, shared tooling, and support workflows. That creates hidden CMMC exposure when identity and access evidence is distributed across platforms rather than owned in one place. Practitioners should assume service delivery can expand the assessment surface unless every access path is explicitly mapped.

Compliance evidence debt: organisations often discover too late that policy, system configuration, and assessor evidence are not aligned. CMMC readiness depends on being able to prove the control environment, not just operate it. When evidence is incomplete or the assessed boundary does not match reality, the organisation inherits avoidable rework and delay. The practitioner takeaway is to treat evidence collection as a design requirement, not an afterthought.

CMMC is a useful forcing function for identity governance in defence supply chains. The article sits at the point where contractor scope, access control, and managed-service accountability intersect. That makes IAM, privileged access, and contractor offboarding part of the compliance conversation, even when the source article is framed as a CMMC explainer. Teams should use the compliance boundary to tighten access ownership and evidence discipline.

Read next: NIST SP 800-171 and CMMC 2.0 Guide

What this signals

Scope discipline is the real control in CMMC programmes. Organisations that wait to ask whether they are covered usually discover that access paths, managed services, and evidence sources have already widened the assessment boundary. The practical lesson is to establish scope ownership early, then keep it stable as contracts and service relationships change.

Identity evidence will matter as much as technical evidence in CMMC reviews. Who can reach covered systems, how those accounts are approved, and how they are removed will increasingly determine whether the organisation can defend its compliance story. For defence-oriented service providers, that means IAM and privileged access records are not supporting material, they are part of the control narrative.

For practitioners

• Define the CMMC compliance boundary first Document which customers, contracts, systems, and support workflows place the organisation in scope before assigning control work.
• Map managed-service access paths Inventory every administrative, support, and remote access path that could touch covered defence information or customer environments.
• Align evidence with assessed systems Make sure policies, screenshots, logs, and ownership records describe the same environment that will be reviewed by an assessor.
• Review contractor identity records Confirm that user, privileged, and third-party accounts tied to defence work have clear ownership, approval, and offboarding records.

Key takeaways

• CMMC uncertainty is mainly a scoping problem, because organisations cannot comply reliably until they know whether defence contracts and covered information place them in scope.
• Managed service relationships can expand the assessment surface, especially when access paths, support tooling, and evidence records are distributed across environments.
• The most useful next step is a documented boundary review that ties contracts, systems, identities, and evidence to the same compliance model.

Related NHI Mgmt Group resources: NIST SP 800-171 and CMMC 2.0 Guide · Identity Security Maturity Model · GRC Maturity Model

Key terms

• CMMC Scope: CMMC Scope is the set of people, systems, data, and processes that must meet Cybersecurity Maturity Model Certification requirements. In practice, it defines where controlled unclassified information is stored, processed, or transmitted, plus any assets that can affect its protection, so assessments stay focused on relevant security boundaries.
• C3PAO: A C3PAO is a Certified Third-Party Assessor Organisation that evaluates whether an organisation meets CMMC requirements. Its role is to validate implementation through documentation, interviews, and testing, which means organisations must be able to demonstrate controls rather than simply describe them.
• Supply Chain Defence: Supply chain defence is the set of controls used to protect organisations from risk introduced through suppliers, software dependencies, and external service relationships. It depends on visibility, trust verification, and the ability to act quickly when a partner's posture changes.
• Compliance Evidence: Compliance evidence is the artefact trail that proves a control operated as intended. In identity programmes, that usually includes approvals, review outcomes, revocation records, and exception handling. Strong evidence is time-bound, attributable, and reusable across audits instead of being rebuilt manually for each framework.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.