TL;DR: The DoD’s Revision 2.3 adds new CMMC scoping clarifications for joint ventures, paper-only CUI, significant change, and encryption, but the pattern is unchanged: organizations still misread what falls inside scope and when reassessment is required, according to Secureframe. Continuous compliance, not one-time certification, is now the real test for DIB programmes.
At a glance
What this is: The DoD’s latest CMMC FAQ revision adds more scoping clarity, but Secureframe says the core problem remains persistent confusion about what falls in scope and when reassessment is triggered.
Why it matters: IAM, compliance, and security teams in the DIB need to treat CMMC scoping and change control as an ongoing governance process, because boundary errors now affect certification, contract eligibility, and supply-chain assurance.
Context
CMMC scoping is the governance problem here, not just a paperwork problem. The article argues that organisations keep treating scope as something to settle once, even though the assessed boundary changes as systems, data flows, and controls change over time.
For DIB teams, this matters because CUI handling, change management, and reassessment decisions are tightly linked. Where the environment includes shared systems, hybrid paper and digital workflows, or post-assessment drift, the control question is whether the documented scope still matches reality.
The article’s central point is that repeated FAQ revisions are a symptom of recurring misinterpretation, not edge-case ambiguity. That is typical in mature compliance programmes that have not yet made scope management a live operational discipline.
Key questions
Q: What breaks when CMMC scope is not clearly defined?
A: When scope is unclear, teams usually over-include systems or under-document access paths, and both outcomes create assessment risk. The organisation cannot prove which identities touch CUI, who owns them, or how exceptions are governed. That uncertainty usually surfaces as failed evidence reviews, delayed remediation, and inconsistent treatment of privileged access across environments.
Q: Why does CMMC scoping create legal and contract risk when environments change?
A: Because the assessed boundary is part of the compliance commitment, not just an internal note. If a significant change alters the systems or controls that were originally evaluated and that change is not reassessed or documented, the organisation can no longer defend its compliance posture to the government or a C3PAO.
Q: What are the signs that a CMMC program is losing scope control?
A: Common signs include SSPs that lag the live environment, undocumented system changes, UIDs that do not match actual contract systems, and teams assuming a partner or encryption layer covers unassessed assets. Those symptoms indicate that the compliance boundary is being managed on paper rather than in operations.
Q: What should DIB teams do when a change may affect CMMC scope?
A: They should evaluate the change before implementation, document its security impact, update the SSP when the change is complete, and involve the Affirming Official in the decision. The key is to determine whether the modification alters the assessed boundary before it becomes a finding.
Technical breakdown
Why CMMC scope keeps expanding in practice
CMMC scope is defined by where FCI or CUI is processed, stored, or transmitted, not by organisational labels such as joint venture, subcontractor, or prime. That means the real boundary is technical and operational, tied to systems, data paths, and supporting security functions. When teams delay boundary mapping until after award or assessment, they create avoidable scope drift. The DoD’s repeated FAQ updates suggest that many organisations still treat scope as a document rather than an operating model.
Practical implication: map systems to contract-relevant data flows before bid submission and keep the scope model aligned to live environments.
Why encryption does not create logical separation
Encryption protects data in transit or at rest, but it does not enforce a system boundary by itself. Logical separation depends on architectural controls such as firewalls, routing rules, VLANs, and network enforcement that prevent in-scope and out-of-scope environments from interacting in ways that break the assessed boundary. In CMMC terms, this distinction matters because assessors evaluate whether the boundary is actually enforceable, not whether sensitive data is encrypted somewhere inside it.
Practical implication: prove separation with network and architectural controls, not with encryption alone.
What qualifies as a significant change under continuous compliance
A significant change is one that affects the previously assessed scope, not every routine maintenance activity. The article distinguishes operational updates like patching from changes that alter security design, introduce new functions, or remove a control the assessment depended on. That distinction is important because continuous compliance fails when organisations assume the original assessment still describes the current environment. In practice, change control must preserve the relationship between the SSP, the live environment, and the assessed boundary.
Practical implication: use change management to test whether a modification alters the assessed boundary before it is implemented.
NHI Mgmt Group analysis
CMMC scoping failure is a governance failure, not a documentation problem. The recurring revisions show that many organisations still treat scope as a one-time checklist item instead of a live control boundary. That mindset breaks when systems, data flows, and responsibilities shift after assessment. For DIB programmes, the control question is whether the assessed environment still exists in the form that was certified.
Encryption-only scoping is a boundary illusion. Encryption reduces data exposure, but it does not define where trust begins and ends inside a defence environment. The article’s clarification matters because practitioners often confuse confidentiality protection with architectural separation. In NIST-CSF terms, this is an access and boundary integrity issue, and the practical response is to prove control enforcement, not just data protection.
Continuous compliance is becoming the real CMMC operating model. The repeated FAQ updates and emphasis on post-assessment change management signal that certification is no longer the finish line. Organisations that cannot keep SSPs, approvals, and actual infrastructure aligned will create legal and contractual risk even if they passed once. The practitioner takeaway is simple: assess drift continuously or expect the next review to expose it.
Joint venture scope is a supply-chain identity problem as much as a compliance problem. The article shows that status inheritance depends on which systems actually process CUI, not who owns the company on paper. That makes boundary mapping, system attribution, and responsibility assignment part of the governance model. DIB teams should treat shared operating structures as a control design problem, not a legal assumption.
Scoped change control needs a named decision owner. The article places meaningful weight on the Affirming Official and on evaluating whether a change alters the assessed boundary. That is the right direction, because CMMC breaks when everyone assumes someone else will determine whether the change is significant. Practitioners need a defensible decision path before implementation, not after a finding.
What this signals
CMMC scoping is now a change-management discipline. The article’s strongest signal is that DIB teams cannot separate compliance maintenance from operational change control. Once the live environment diverges from the assessed boundary, certification quality depends on whether governance catches the drift before assessors do.
Logical separation has to be proven, not assumed. Encryption may protect data, but assessors are looking for enforceable separation between in-scope and out-of-scope environments. That pushes security and IAM-adjacent teams to think in terms of system boundaries, access paths, and evidence, not just protective tooling.
Scope ownership must sit inside the programme, not outside it. If the decision about significance is left to ad hoc interpretation, the organisation will keep rediscovering the same problem at each assessment cycle. The better model is a standing governance process that aligns system changes, evidence, and sign-off with the current environment.
For practitioners
- Map CUI-processing systems before proposal submission Identify every system that will process, store, or transmit FCI or CUI during contract performance and tie it to the correct CMMC UID before award.
- Separate boundary control from encryption strategy Document the architectural controls that enforce logical separation, including firewalls, VLANs, and routing rules, rather than treating encryption as a scope-reduction control.
- Reassess changes against the assessed scope Use change management to test whether a modification affects the previously assessed scope, then update the SSP and supporting evidence before the next affirmation.
- Build the Affirming Official into change governance Require review of security-impacting changes by the Affirming Official so scope decisions are made before implementation and can be defended during assessment.
Key takeaways
- The article shows that CMMC scope confusion persists because teams still separate certification from the operational reality of change.
- The most important clarifications concern joint ventures, paper-only CUI, significant change, and encryption, but each one only works if the live environment matches the assessed boundary.
- DIB organisations need a continuous compliance model that ties UID mapping, change control, and reassessment decisions to the systems actually handling CUI.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | CMMC scoping and reassessment are governance and risk-management decisions. |
| PR.AA-05 — Access Permissions, Entitlements and Authorizations | In-scope system access and boundary enforcement depend on controlled authorisation paths. | |
| Recommendation — Align scope decisions to a formal risk-management strategy and keep the assessed boundary under governance. Review authorisations that let contract systems process CUI and remove any access outside the assessed boundary. | ||
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | The article centres on when changes trigger reassessment and how changes must be governed. |
| CA-7 — Continuous Monitoring | The article argues that compliance must be maintained between assessments, not only at certification time. | |
| AC-4 — Information Flow Enforcement | Logical separation and scoping depend on enforcing where CUI can flow, not on encryption alone. | |
| Recommendation — Use CM-3 to require impact review and approval before changes alter the assessed CMMC environment. Apply CA-7 to monitor drift between the SSP and the live environment throughout the assessment cycle. Use AC-4 to enforce CUI flow restrictions with boundary controls instead of relying on encryption. | ||
Key terms
- CMMC Scoping: CMMC scoping is the process of defining which systems, users, and workflows are inside the compliance boundary for handling FCI or CUI. It is based on actual data processing, storage, and transmission paths, not on organisational charts or assumptions about inherited coverage.
- Logical Separation: Logical separation means customers share the same application or infrastructure but are divided by software-enforced boundaries instead of physical ones. It is only meaningful when access checks, routing, and storage partitioning consistently preserve tenant context and prevent cross-customer exposure.
- Significant Change Request: A Significant Change Request is the formal review path for material changes to an authorized system. When the change affects identity scope, trust relationships, hosting, or access paths, the request ensures the approved boundary and the real operating state stay aligned.
- Affirming Official: The Affirming Official is the senior representative who signs the annual CMMC affirmation and is legally responsible for declaring whether the assessed environment still matches reality. The role is accountable for accuracy, even when the underlying change was driven by IT or a third party.
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, the industry's only accredited NHI security programme. It is suitable for practitioners who need a structured way to connect governance, access control, and identity operations.
Published by the NHIMG editorial team on July 10, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org