CMMC Secure Enclave: When It Cuts Your Level 2 Scope — and When It Backfires

The Defense Compliance Report is an independent trade publication on CMMC 2.0 and DIB compliance. We are not affiliated with the Department of Defense, the Cyber AB, or any U.S. government agency, and this page is not legal or compliance advice.

Sources we read for this guide: 32 CFR Part 170 (eCFR), the Federal Register CMMC Program Final Rule and DFARS Final Rule, the DoD CMMC Level 2 Scoping Guide, the official CMMC Program FAQ (Revision 2.3, May 2026), the Cyber AB Code of Professional Conduct v2.0, NIST CSRC (SP 800-171 Rev. 2, SP 800-172), and DFARS 252.204-7012 / -7019 / -7020 / -7021 / -7025 on Acquisition.gov.

A CMMC secure enclave is a deliberately walled-off part of your IT environment — cloud, on-premises, or a secure overlay — where you keep all of your Controlled Unclassified Information (CUI) and the systems that touch it, so the assessment focuses on that boundary, plus the systems that protect or connect to it, instead of automatically pulling in your whole company. The assessment standard inside that boundary is the 110 security requirements in NIST SP 800-171 Revision 2 — the same 110 that apply to CMMC Level 2.

Here's the part the vendor demos skip: an enclave does not reduce the 110 requirements. Every one of them still applies insidethe boundary. What it reduces is how many systems and people that boundary has to contain. And the boundary only counts if it's enforced by architecture, not drawn on a slide. Your CMMC Third-Party Assessment Organization (C3PAO — the independent firm authorized to certify Level 2) assesses whether your scope holds, and a paper-only enclave can be expanded on assessment day.

That's the whole decision in one breath. The rest of this page is the part nobody puts in one place: which situations an enclave actually fits, what has to live inside the boundary to survive an assessment, how the real architectures compare, what it costs in dollars we can source, and the specific scoping traps — VDI endpoints, encryption, your MSP — that 32 CFR Part 170 and the CMMC FAQ have now answered in writing.

Quick verdict: does an enclave fit your situation?

The one honest caveat, up front

An enclave is not “CMMC in a box.” If your people keep downloading, printing, emailing, and editing CUI outside the boundary, an enclave can make your environment lookcleaner while leaving the real assessment problem untouched — and you'll have paid for a platform that didn't fix anything. That's the failure mode we see most often.

Here's the flip side, and it's the reason this strategy exists: when CUI flow is narrow, enforceable, and documented, an enclave is the difference between hardening 20 workstations and hardening 200. For most small and mid-size defense suppliers with that kind of contained CUI footprint, it's the most practical path through CMMC Level 2 — faster, cheaper, and less disruptive than re-architecting the whole company. The strategy is sound. The execution is where it lives or dies.

If nearly everyone in your company touches CUI as part of normal work, an enclave is the wrong tool for you. You'd be better served by a whole-environment Level 2 program — start with our CMMC Level 2 readiness checklist instead of shopping for an enclave.

What is a CMMC secure enclave?

A CMMC secure enclave is a controlled environment that contains the people, systems, applications, cloud services, endpoints, and processes that handle CUI, separated from the rest of the organization. The point is not to dodge CMMC requirements; it's to limit how many assets must meet and prove those requirements by controlling where CUI is processed, stored, transmitted, and protected. CMMC has no special shortcut called “enclave certification” — the assessment question is whether your scope definition is defensible and technically enforced.

In practice, an enclave is the controlled workspace for CUI. It might be built on Microsoft 365 GCC High, Azure Government, or AWS GovCloud; it might be a Virtual Desktop Infrastructure (VDI) environment; it might be a secure file-sharing and email overlay; or it might be a segmented on-premises network. Whatever the technology, the job is the same: create a defined boundary where CUI lives, and keep everything else out of it.

It helps to be precise about the words, because vendors use them loosely.

Does a CMMC secure enclave actually reduce CMMC Level 2 scope?

Yes — but only when the enclave changes the real CUI boundary, not just the diagram. Systems outside the enclave must not process, store, or transmit CUI, and some assets that protectthe enclave can remain in scope even though they never hold CUI themselves. The official asset categories decide this, and they matter far more than any vendor's marketing.

Under 32 CFR §170.19 and the DoD CMMC Level 2 Scoping Guide, every asset in a Level 2 assessment falls into one of fivecategories — not four, not six. Here's what the rule actually says, and what each category means for your enclave:

The five Level 2 asset categories (what the rule says vs. what it means for your enclave)

The line that beats the vendor diagrams

The DoD does not pre-approve your enclave. No one at the Department signs off on your architecture in advance. Your C3PAO assesses whether your scope definition is reasonable and whether your boundary is technically enforced. The enclave strategy is explicitly recognized in CMMC guidance as valid — the regulation even writes one enclave pattern (VDI) directly into the scoping rules — but a boundary that exists only on a network diagram can be expanded on the first assessment day. Architecture that the assessor can verify is architecture that holds.

What quietly pulls the rest of your company back into scope

This is the list we wish every enclave buyer saw before signing. Each of these can drag enterprise systems into your assessment even when CUI “lives in the enclave”:

• A shared identity provider used by both the enclave and the rest of the business
• Shared endpoint management or EDR tooling
• A shared SIEM or centralized logging stack
• Shared backups that capture CUI
• A shared help desk with privileged access into the enclave
• Shared network controls and routing that aren't truly segmented
• Shared email transport, shared file storage, or shared printers
• MSP/MSSP tools that administer, monitor, or secure the environment
• Administrator accounts that live outside the enclave but can reach inside it

Enclave fit by situation: the decision matrix

Use this matrix to match your situation to an enclave fit score, and understand what to focus on and what kind of help you need. If you land on “Low,” “Not yet,” or “Unknown until scoped,” buying an enclave today is premature — the money is better spent on CUI discovery and a readiness review.

What has to live inside the enclave to make the boundary hold up?

A defensible enclave contains not just the CUI files, but the entire workflow that creates, receives, edits, stores, transmits, protects, backs up, logs, and shares them. A boundary that covers the storage location but ignores email, downloads, printers, backups, security logs, admin accounts, and supplier sharing is usually not a boundary an assessor will accept. The test is simple to state and hard to fake: can CUI get out of the enclave through any path you haven't controlled?

Map the CUI flow before you map the network

Before anyone talks about platforms, draw the data. Every line below is a place CUI can escape your boundary:

1. Where CUI enters (a prime's portal, an email, a contract deliverable)
2. Who receives it (which people, which roles)
3. Where it's stored (which repositories, which tenants)
4. Where it's edited (which applications)
5. Which apps process it (and whether they cache or sync)
6. Which endpoints access it (managed, unmanaged, mobile)
7. Whether it's downloaded, printed, exported, or emailed
8. Which systems log or back it up
9. Which providers administer or secure it
10. Where CUI leaves the company (to subs, suppliers, the government)

If you can answer all ten with confidence, you're ready to choose a boundary. If you can't, no platform will save you — you have discovery to do first.

The boundary checklist

These are the questions to put to any team — or any vendor — before money changes hands. Each one is a place scope quietly grows.

A proposal team of five people receiving CUI, drafting inside a controlled workspace, and sharing only through approved channels is often a textbook enclave. An engineering team that needs local CAD tools, machine interfaces, supplier transfers, and occasional printing can still use an enclave — but the design needs real scoping work first, because the “how does the file get out” question is where these projects succeed or fail. A manufacturer should never buy a document-sharing enclave and assume it solved CUI on the shop floor.

VDI and endpoints: can they really stay out of scope?

Yes — and this is one of the few places the DoD gives you a clear, written answer. 32 CFR §170.19 states that an endpoint hosting a VDI client configured to allow no processing, storage, or transmission of CUI beyond the keyboard, video, and mouse sent to the VDI client is an Out-of-Scope Asset — with no documentation requirements for that endpoint. The official CMMC FAQ then spells out exactly what “configured correctly” means in questions F-Q1 and F-Q2. The rule and the FAQ have settled a question the DIB argued about for years.

But read the conditions closely, because the whole benefit evaporates if you miss one. The governing test: if the configuration allows the endpoint to process, store, or transmit CUI, the endpoint is a CUI Asset and is fully in scope.

Encryption, MSPs, and the cloud: three places contractors get the scope wrong

These three areas produce more bad enclave decisions than anything else, and the official CMMC FAQ now addresses all three in writing. Encryption protects data but does not, by itself, create a network boundary. An MSP usually doesn't need its own certification but is often part of your scope. And buying a government cloud like GCC High satisfies only half the equation — it never makes you certified. Get these three right and your enclave decision gets dramatically simpler.

Encryption is not separation — but it's not useless either

The CMMC FAQ answers two related questions that vendors love to blur. First (FAQ B-Q8): encrypted CUI is still CUI.Encrypting a file or a packet does not “decontrol” it; as long as the underlying information is controlled, the ciphertext is too, and you can't treat it as out of scope just because it's wrapped. Second (FAQ F-Q3): encryption alone cannot create logical separation for a network inside your assessment scope. Logical separation comes from enforced architecture — firewalls, routing controls, network segmentation — that actually stops CUI from moving where it shouldn't.

Now the useful part. FAQ F-Q4 confirms that if your enclave is otherwise logically separated from the broader enterprise network, transmitting properly encrypted CUI across out-of-scope enterprise networking does not drag those enterprise components into scope. In plain terms: you can run encrypted CUI over your general corporate network as transit without pulling that network into your assessment, as long as the separation is real and enforced, not crypto alone. Prove your boundary with segmentation you can demonstrate on a network diagram, and let encryption do what encryption is for.

What MSPs, MSSPs, and CSPs actually have to prove

A provider's label matters less than what it does with your data. Relevant terms:

• An External Service Provider (ESP) is an outside person, technology, or facility you use to support your IT or cybersecurity.
• A Cloud Service Provider (CSP) offers cloud-based services.
• Security Protection Data (SPD) is the security-relevant data — logs, configurations, security telemetry — that protects your assessed environment.

Here's how the CMMC FAQ (questions E-Q1 through E-Q5) and 32 CFR §170.19 actually sort this out:

• An MSP or MSSP that processes, stores, or transmits neither CUI nor Security Protection Data does not meet the CMMC definition of an ESP. If it handles your SPD, its services are assessed as Security Protection Assets within your assessment.
• An MSP that does not store, process, or transmit CUI is not automatically required to hold its own CMMC certification (FAQ E-Q3, E-Q4). It may voluntarily undergo certification — which can reduce assessment effort during your own assessment — but it isn't required.
• If an MSP stores your CUI on a non-cloud system, its systems fall within your scope and must meet the relevant requirements.
• Using cloud tools to deliver a service does not make an MSP a CSP. If you're the cloud tenant and the MSP merely administers your environment, it isn't a CSP (FAQ E-Q5).
• Even when an MSP-hosted enclave holds its own Level 2 certification, that environment is still an ESP in your scope. The certification lets your assessor rely on the MSP's validated controls — it does not remove the environment from your assessment and never transfers your responsibility.

The throughline: an MSP's certification is a strong indicator, not a substitute. Your scope is determined by how CUI and SPD are processed, stored, transmitted, and protected — not by who you hired. For a deeper breakdown, see our guide on CMMC external service provider requirements.

Does buying GCC High make you compliant? No — and this is the most expensive misunderstanding in CMMC

Under DFARS 252.204-7012, any cloud service that stores, processes, or transmits CUI must meet the FedRAMP Moderate baseline — or documented FedRAMP Moderate equivalency(FAQ E-Q1). Equivalency, defined by the December 21, 2023 DoD CIO memorandum, means a cloud offering has been assessed by a FedRAMP-recognized third-party assessor against 100% of the FedRAMP Moderate baseline, with no outstanding control-related Plans of Action and Milestones, documented in a “body of evidence.” Equivalency is a DoD construct, not a FedRAMP authorization listed on the FedRAMP Marketplace.

• A platform's FedRAMP authorization is not your configuration. Your C3PAO assesses how youset the environment up — your tenant configuration, identity, and administrative controls — not just the provider's authorization. A “FedRAMP authorized” badge on the platform is the floor, not the finish line.
• Buying a government cloud satisfies only the cloud half of the equation. Standing up Microsoft 365 GCC High, Azure Government, or AWS GovCloud does not make you CMMC certified. You still have to implement the applicable requirements across your scope and pass your assessment. The cloud handles the cloud's responsibilities; you handle yours.

Which CMMC enclave architecture fits: GCC High, AWS GovCloud, a secure overlay, managed, or on-prem?

Build your own if you have in-house cloud and security depth; buy a managed enclave if you need speed and lack that depth; choose the cloud platform based on whether you handle export-controlled data and what your team already runs. The right architecture follows your CUI flow and your export-control status — not a vendor's preference.

Assessment cost figures are the DoD's published estimates from the rulemaking; operational and one-time ranges are industry-reported and dated mid-2026. Named-platform FedRAMP statuses should be confirmed live on the FedRAMP Marketplace, and provider credentials in the Cyber AB Marketplace, before you rely on them.

CMMC secure enclave FAQ

How we built this guide

We built this page as a primary-source scoping decision guide, not a provider ranking. We cross-checked the active CMMC rule, the DFARS implementation clauses, the NIST publication versions, the official scoping guidance, the CMMC FAQ's edge cases, and the Cyber AB ecosystem rules, and we used contractor forums only to understand the questions people actually ask — never as a source for regulatory claims.

The Small Business Administration's Office of Advocacy formally asked the DoD for clear, concise enclave guidance for small businesses to lessen the compliance burden — confirming this isn't a niche concern but a recognized one across the DIB.