Classified vs unclassified data: what CMMC really protects

At a glance

What this is: This article explains the government data hierarchy and shows that CMMC is designed to protect unclassified but sensitive information, especially CUI, not classified data.

Why it matters: For IAM and security teams, the main lesson is that scope depends on data type and system context, so access control, logging, and enclave decisions must follow where CUI actually resides.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.

👉 Read Secureframe's guide to classified vs unclassified data and CMMC scope

Context

CMMC confusion often starts with a simple but costly mistake: assuming only classified information needs serious protection. In practice, the government hierarchy separates classified data from unclassified information that still requires safeguards, and that second category is where most contractor risk sits. For CMMC programmes, the question is not whether data is classified, but whether it is controlled, where it lives, and which systems expose it.

Controlled Unclassified Information, or CUI, is the key boundary concept here because it is unclassified yet still subject to legal or contractual protection. That creates an identity and access governance problem as much as a compliance problem: if users, service accounts, collaboration tools, and cloud systems are not scoped correctly, CUI can spread well beyond the environment assessors expected to review.

Key questions

Q: What breaks when organisations treat all unclassified data the same under CMMC?

A: They either under-scope and miss CUI protections, or over-scope and burden the whole environment with unnecessary controls. The right approach is to classify data accurately, map which systems store or transmit it, and apply CMMC controls only where contract-sensitive information actually exists.

Q: Why does CUI create access governance problems for defence contractors?

A: Because CUI usually lives in commercial systems where many identities can touch it, including users, service accounts, and integrations. That makes entitlement review, logging, and offboarding essential, because the data boundary is enforced by identity controls rather than by physical isolation alone.

Q: What do security teams get wrong about enclaves for CMMC?

A: They often treat an enclave as a documentation exercise instead of a control boundary. An enclave only reduces scope if access is tightly restricted, monitored, and removed when identities or integrations are no longer needed; otherwise the boundary collapses in practice.

Q: Who is accountable when CMMC scope decisions are wrong?

A: Accountability sits with the organisation’s compliance leadership and the Affirming Official who signs the determination, especially when the decision affects assessment scope or contract eligibility. That is why scope changes need documented review, change control, and evidence that the final decision was made against current system reality.

Technical breakdown

How the government data hierarchy separates classified data from CUI

The hierarchy is often misunderstood because both classified and unclassified data can be sensitive, but they are protected through different models. Classified information is restricted through accredited facilities, cleared personnel, and dedicated networks. CUI, by contrast, is unclassified but still protected through policy, contract flowdowns, and technical safeguards inside commercial environments. That difference matters because CMMC is not trying to recreate classified handling. It is trying to impose consistent controls where sensitive unclassified data actually lives.

Practical implication: scope controls to the systems that store, process, or transmit CUI, not to every system that ever touches government information.

Why CUI lives in commercial systems and how that changes access control

CUI is usually handled in cloud platforms, contractor endpoints, collaboration tools, and engineering systems because it exists outside classified enclaves. That means the security model depends on authentication, authorization, logging, and configuration discipline rather than physical isolation alone. For identity teams, this is where governance becomes operational: access must be limited to the right users and the right service accounts, and those identities must be traced to the data they can reach. Without that mapping, you cannot prove that CUI protections are effective.

Practical implication: tie data classification to identity lifecycle controls so humans and NHIs only access the CUI they genuinely need.

Where enclaves fit in CMMC scope reduction

An enclave is a bounded environment used to contain CUI and reduce the number of systems in scope for assessment. It does not remove the need for controls; it concentrates them. The architectural trade-off is clear. An enclave can simplify governance when only part of the business handles sensitive contract data, but it also requires strict entry controls, monitoring, and offboarding discipline. If identities, tokens, and integration paths bypass the enclave boundary, the scope reduction is mostly theoretical.

Practical implication: validate that enclave access is enforced at identity and network layers, not just described in a policy document.

Threat narrative

Attacker objective: The objective is not necessarily theft in every case, but uncontrolled access to sensitive unclassified government data through weak scoping and governance.

1. Entry occurs when CUI is placed into broad commercial systems without tight scoping, giving too many users and integrations potential exposure.
2. Escalation follows when overly permissive access, shared accounts, or weak segmentation let identities reach CUI outside their intended boundary.
3. Impact is scope drift, assessment failure, and unnecessary exposure of sensitive defence data across systems that were never meant to hold it.

NHI Mgmt Group analysis

CUI scoping is an identity governance problem before it is a compliance problem: the article is right to frame CMMC around where data lives, but the deeper issue is who and what can reach it. Humans, service accounts, and integration identities all expand scope when their permissions are not tied to data classification. In practice, CMMC readiness depends on identity lifecycle discipline as much as document handling.

Unclassified does not mean low risk when contractor systems are over-connected: commercial tooling, collaboration platforms, and cloud services become the de facto control plane for CUI. That creates a governance gap if organisations assume classification alone determines protection. The field needs more precise scoping, better entitlement review, and tighter service account oversight.

Enclaves only work when the boundary is enforced by identity controls as well as architecture: an enclave without rigorous authentication, logging, and offboarding becomes a symbolic boundary rather than a control boundary. This is where NHI governance matters, because machine identities often outlive the projects they support. Teams should treat enclave access as a lifecycle-managed privilege, not a static network exception.

CMMC exposes a broader misunderstanding about data protection models: many programmes still equate sensitivity with classification, even though regulatory obligations frequently attach to unclassified data. That is a dangerous simplification for contractors handling export-controlled information, controlled technical data, or contract-derived material. The practical conclusion is that data classification, access governance, and control scoping must be designed together.

Named concept, CUI boundary drift: this article illustrates how sensitive unclassified data spreads when organisations fail to maintain a precise boundary between protected contract data and the rest of the environment. Once that boundary drifts, assessments become harder, exposure grows, and containment costs rise. Security teams should map and continually test that boundary before compliance work starts.

What this signals

CUI boundary drift: contractor programmes increasingly fail at the seam between data classification and identity governance. Once service accounts, automation, and shared collaboration tools are allowed to accumulate access without a precise scope model, CMMC readiness becomes harder to evidence and easier to dispute.

The practical signal for security leaders is that CMMC scope work must move upstream into data mapping, identity review, and contract-driven access design. The strongest programmes will treat CUI as a governed asset with lifecycle controls, not just a label on a document.

For practitioners

• Define the CUI boundary explicitly Create a system and data inventory that shows where CUI is stored, processed, transmitted, and backed up, then link each location to an accountable owner and assessor-ready evidence set.
• Map human and non-human access to CUI Review user roles, service accounts, API integrations, and automation paths that can reach CUI, then remove access that is not justified by contract scope or operational need.
• Use enclaves only with enforced identity controls If you reduce scope with an enclave, require strong authentication, logging, segmented connectivity, and offboarding for every identity that can enter or manage it.
• Align CMMC scope with lifecycle processes Revisit provisioning, access review, and offboarding so identities connected to CUI are removed when contracts end, projects close, or integrations are retired.

Key takeaways

• CMMC is about protecting unclassified but sensitive government data, not only classified information.
• The real control problem is scope, because CUI lives in commercial systems that depend on identity governance and logging.
• Contractors that define the CUI boundary clearly, then enforce it through access lifecycle controls, reduce both compliance risk and operational friction.

Key terms

• Controlled Unclassified Information: Controlled Unclassified Information is government information that is not classified but still requires safeguarding or dissemination controls. It typically appears in contractor environments, commercial cloud services, and engineering workflows, so protection depends on policy, access control, and scoping rather than on classified networks.
• CUI Enclave: A CUI enclave is a bounded environment used to isolate controlled unclassified information from the rest of an organisation. It can reduce assessment scope, but only if identity, logging, segmentation, and offboarding controls are enforced consistently at the enclave boundary.
• Data Scope: Data scope is the set of systems, identities, and workflows that must be included when protecting a defined data type. In CMMC programmes, scope is determined by where CUI is stored, processed, transmitted, or supported, not by what the organisation stores in general.
• Identity Governance: Identity governance is the set of controls that defines who approves access, who owns it, how it is reviewed, and when it is removed. In practice, it turns identity management from a deployment task into a durable control system that can withstand audits, organisational change, and operational growth.

What's in the full article

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

• The article’s plain-language breakdown of each data category and the examples contractors are most likely to encounter.
• The detailed comparison of CUI, CDI, FCI, and classified information and how those labels affect scope decisions.
• The explanation of how enclaves can reduce assessment scope when CUI is concentrated in a limited part of the environment.
• The article’s CMMC and NIST 800-171 mapping context for contractors preparing for assessment.

👉 Secureframe's full post explains the classification hierarchy, CUI examples, and enclave scoping in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, and secrets management for practitioners who need to connect access control with real operational scope. It is designed for security and identity teams building stronger governance across human and non-human identities.