CMMC Enclave Strategy: When to Isolate CUI Instead of Rolling Out Full Level 2

Most defense contractors do not actually need to bring their whole company into CMMC scope. They think they do, and they price it that way, and then they either flinch at the number or spend a year rolling out controls to laptops that will never see a controlled drawing. There is a better move for a lot of shops, and it is not new. It is an enclave.

The idea is old, the execution is what has changed. The point of this piece is to lay out when an enclave is the right call, what the three real-world patterns look like, and where enclave projects tend to fall apart. If you have already picked a path, treat this as a checklist. If you have not, treat it as a decision tool.

The Basic Idea

An enclave is a bounded place where CUI lives, and only that place. Everything outside it is designed and documented so it cannot receive, store, process, or transmit CUI. The 110 NIST SP 800-171 controls apply inside the enclave, in full. Outside the enclave, you have to prove the CUI does not go there, which is its own control problem but a much smaller one.

The reason to bother is scoping. A full-company Level 2 rollout means every laptop, every server, every email account, every phone, and every third party they talk to is in the assessment boundary. That is the number that scares people. An enclave takes that boundary and shrinks it to the systems the CUI actually touches. See our SSP system boundary guide and CUI scoping for how the boundary drawing works in practice.

An enclave does not exempt you from anything. DFARS 252.204-7012 still applies. NIST 800-171 still applies. The SPRS score still has to be honest. What the enclave changes is where the controls have to be implemented and where the assessor has to look.

When an Enclave Actually Fits

An enclave is the right call in a handful of specific situations. It is the wrong call, or at least a costly one, in others. Be honest about which side of the line you are on.

An enclave fits when CUI touches a small share of the business. One program. One team. One customer. Ten users out of two hundred. If the ratio is that lopsided, dragging the rest of the company through Level 2 to serve the ten is a bad trade.

An enclave fits when you do a mix of DoD and commercial work. Commercial customers do not want your CUI controls in their workflow. Applying enterprise-wide MFA the way NIST 800-171 expects, or enterprise-wide FIPS-validated cryptography, changes the experience for people who have no reason to be inside the compliance boundary in the first place. An enclave lets each side live in its own environment.

An enclave fits when the boundary can be enforced credibly. This one is the hinge. If your CAD engineers are willing and able to work only inside a virtual desktop, that boundary is enforceable. If they will insist on pulling drawings down to their laptop to work offline on a plane, the boundary is a fiction. Do not build one you cannot enforce.

An enclave usually does not fit when CUI is everywhere. If every engineer, every project manager, and every finance user regularly opens CUI in the normal course of their job, an enclave is trying to swim upstream. In that world the whole shop is the environment, and full Level 2 is the honest path. Start with the requirements checklist if that is you.

The Three Enclave Patterns

Real deployments mix and match, but almost all of them are variations on three patterns. Pick the one that fits your work, not the one that sounds most impressive on a slide.

1. The cloud enclave. Microsoft GCC High is the canonical example. AWS GovCloud (US) is another. The idea is that CUI email, storage, chat, and collaboration all live inside a compliance-focused cloud tenant that is contractually and technically separate from the commercial one. Users have a GCC High identity for CUI work and, often, a commercial identity for everything else. Good for office-style CUI (documents, drawings sitting in SharePoint, program email). Weaker where CUI has to run through specialized on-premises tools that do not have a government-cloud version.

2. The virtual desktop enclave. Users connect from any laptop into a locked-down remote desktop, and the desktop is the only place CUI ever renders. Local clipboard, printing, and file transfer are disabled at the session layer. Endpoints outside the enclave stay clean because CUI is never actually delivered to them. Good for shops with a lot of mixed-use endpoints or contractor labor. See our VDI for CMMC writeup for the mechanics and the trade-offs.

3. The physical enclave. A room, a floor, a hardened workstation, or a physically segregated network at a facility. Used when CUI has to be handled on-premises because a machine tool, a test bench, or a classified-adjacent process demands it. Least flexible, most defensible, and often the right answer for manufacturers. See CMMC physical security requirements for what the assessor will look for around the door.

Most real contractors run some combination. A cloud enclave for program email and drawings, plus a virtual desktop for engineers who need to work outside the office, plus a physical enclave around a specific machining cell. The pattern that matters is not which one you pick, but that the CUI never leaves the union of them.

The Boundary Is the Whole Job

If you take one thing from this piece, take this. The value of an enclave is entirely a function of how boring and enforceable the boundary is. A leaky enclave is worse than no enclave, because it produces a false sense of scope while quietly pulling the outside environment back in.

• Email addresses are boundary objects. If a program mailbox lives in the enclave, the address it uses has to be an enclave address. Do not forward CUI notifications to a commercial account. Do not accept CUI-bearing email into a commercial inbox and "then move it over." The routing decides the scope.
• File transfer is a boundary object. Uploading to the enclave is fine. Downloading out of it, or exporting to a personal drive, drags the destination into scope. Disable it at the platform layer, not with a policy PDF.
• Print jobs are boundary objects. A CUI print job that lands on a shared printer on the corporate network is a scope leak. Enclave printers or nothing.
• Personal devices are boundary objects. BYOD into a virtual desktop enclave can work if the session controls are tight. BYOD as a general MDM policy does not.
• Third parties are boundary objects. Any vendor, MSP, or subcontractor that touches CUI is inside your enclave whether the org chart says so or not. Our subcontractor flow-down guide covers the contract side.

Assessors do not judge enclaves on how sophisticated the inside looks. They judge them on whether the boundary holds under normal use, and they will ask specifically how it fails. Have an honest answer.

Buy Versus Build

The other big decision is how much of the enclave you build yourself. There is a spectrum, and it maps roughly to how much of your compliance evidence you own versus inherit.

Buy heavy. GCC High tenant plus a managed CMMC service provider. Most of the technical controls are inherited from Microsoft under the shared responsibility model, and most of the operational controls are inherited from the MSP. You still own governance, personnel security, physical security at your own site, and evidence of how you configured what you bought. Faster to stand up. Higher recurring cost. Less flexibility.

Build heavy. On-premises virtual desktop infrastructure, your own identity, your own logging, your own SIEM. Cheaper long-term for larger organizations. Slower to stand up. More of the 110 controls sit on your team. Realistic for shops with a real IT function, punishing for shops without one.

The middle. A cloud enclave for the parts that map cleanly to a cloud tenant, plus a physical enclave for the machining cell or the test bench that does not. This is where most real deployments land. It also produces the most complicated boundary, so the documentation has to be tight.

One rule that holds across the spectrum. Do not buy an enclave you do not have the operational muscle to run. A GCC High tenant that no one is administering to compliance is not compliant. See our take on compliance software versus spreadsheets for how the operational side of this tends to break.

Where Enclave Projects Actually Fail

Almost all enclave failures look like one of these five. If you are early in the project, use this list as a pre-mortem. If you are late in the project, use it as an audit.

• The scope drifted after go-live. The enclave was launched for one program and quietly picked up three more without anyone re-drawing the boundary. Six months later, half the company is using it and no one is sure what is in scope.
• The users routed around it. Engineers found the virtual desktop slow, so they started emailing themselves drawings to the commercial inbox. Nobody caught it until the assessor did.
• The MSP was assumed, not documented. Nobody produced a shared responsibility matrix for the enclave, so no one can say cleanly which controls the MSP is running and which the contractor is. See our software landscape piece for how this gets sorted at the tooling layer.
• Third-party access was invisible. An IT contractor with credentials into the enclave was never accounted for. Every third party in the enclave is in scope.
• The evidence lives in Slack. The controls are running. The evidence that the controls are running is in someone's chat history. Assessors do not accept "we do this, trust us." Keep the evidence in one place and keep it current.

The through-line is human, not technical. An enclave is a discipline as much as an architecture. The architecture is the easy part.

Frequently Asked Questions