CUI Enclave Architecture: The CMMC Scope-Reduction Strategy Most Contractors Skip

There’s a scope decision sitting underneath every CMMC budget that nobody on the buying side made deliberately. The IT environment is large. CUI lives somewhere inside it. The compliance vendor scopes everything as in-bounds because that’s the path of least resistance for the assessment. The contractor pays to bring 200 endpoints, three file servers, an email tenant, and a backup system up to NIST 800-171, when the actual CUI footprint is 12 endpoints and one folder.

That contractor is buying enterprise-scope CMMC. They could be buying enclave-scope CMMC. The cost gap is rarely under 5x and often closer to 10x. This is the highest-leverage decision in a CMMC program, and most contractors arrive at the assessment having never made it consciously.

This piece is the architecture work underneath the boundary scoping conversation. The CUI boundary scoping guide covers what an assessment boundary is. This one covers how to build the thing on the other side of the boundary, the enclave itself, so scope shrinks instead of expanding back.

What a CUI Enclave Actually Is

A CUI enclave is a defined, isolated environment that contains all CUI processing, storage, and transmission. Everything inside is in CMMC scope. Everything outside is, by architectural design, incapable of touching CUI. The enclave is the assessment boundary.

That’s the technical definition. The strategic one matters more. An enclave is a deliberate choice to keep CUI bounded, so the rest of the business runs on commodity IT that nobody needs to harden, document, or pay an assessor to evaluate.

Three things make an enclave real, not aspirational:

A defined edge. Traffic crosses through a small number of controlled paths. No back doors. No “we usually do it through the file share.”

A defined user population. Access is an enumerated list, not “anyone with a corporate badge.”

A defined data flow. CUI enters, lives, is processed, and leaves through known paths. Nothing about that is “we’ll figure it out.”

If any of those three is fuzzy, you don’t have an enclave. You have a network segment with optimism layered on top.

When Enclaves Work and When They Don’t

Enclaves work when CUI is bounded in your business. A defense subcontractor manufacturing a single CUI-bearing part: bounded. An engineering firm with three engineers working CUI projects: bounded. A logistics company touching ITAR-controlled shipments through one fulfillment workflow: bounded.

Enclaves don’t work when CUI is genuinely distributed across the business. A 200-person systems integrator where CUI flows through every program manager, every contracts officer, every email account, every collaboration channel: not enclave-shaped. That contractor needs enterprise-scope CMMC because their actual CUI footprint is enterprise-wide.

But here’s the position-taking part. Most contractors think they’re in the second category and are actually in the first. The CUI lives on three engineers’ workstations and in one SharePoint library. Everything else is contract administration, HR data, and finance. The reason the contractor thinks CUI is everywhere is that nobody ever drew the boundary. Without a boundary, CUI fills the space.

Drawing the boundary is what reveals whether you can have an enclave. The work is upstream of the architecture decision.

The Four Common Enclave Patterns

Four architectural patterns cover most contractor situations. Each has a use case where it wins and at least one mode where it becomes a liability.

Pattern 1, Cloud-Only Enclave

CUI lives entirely in a cloud environment that’s purpose-built and authorized for CUI handling. Government-community Microsoft 365 with the right service plan (commonly GCC High, sometimes GCC depending on contract), Azure Government, AWS GovCloud, or a vendor-managed CUI workspace product. Users access the enclave through a controlled path, typically a managed device or a virtual desktop session. Local endpoints don’t process CUI directly.

Use this when: You have a small to mid-size CUI footprint, your contracts allow the cloud you’ve picked (DFARS 252.204-7012(b)(2)(ii)(D) requires the external CSP to meet FedRAMP Moderate baseline or equivalent and to comply with the clause’s incident-reporting, media-preservation, and forensic-access obligations), and you’d rather pay a vendor for the heavy lifting on infrastructure controls than build it yourself. This is the path most well-advised small contractors land on.

Avoid when: Your contracts impose data-residency, classification handling, or government-furnished-equipment constraints that the cloud product can’t meet. Verify the contract terms before committing.

Pattern 2, Hybrid M365 with Conditional Access

A common variant: the contractor already runs Microsoft 365 for the whole business, can’t justify a full migration to a separate tenant, and instead carves out CUI handling inside the existing tenant using conditional access, sensitivity labels, and data loss prevention. CUI flows are gated to a specific group of users on specific compliant devices.

Use this when: The Microsoft estate is mature, the contractor has the licensing and policy discipline to enforce the carve-out, and the assessor accepts the boundary as drawn. Verify that last part with an RPO before committing.

Avoid when: The team doesn’t have the M365 administration depth to enforce conditional access cleanly. A misconfigured policy turns the entire tenant into in-scope, which is the failure mode that kills this pattern. Hybrid M365 enclaves are the most architecturally elegant pattern and the easiest one to lose control of.

Pattern 3, On-Premises Enclave

A physically and logically separated network segment, typically with its own subnet, dedicated workstations, dedicated file storage, and dedicated security controls (firewall, SIEM agent, endpoint protection, identity provider integration). Users in the enclave have separate accounts from the corporate accounts.

Use this when: You have a small number of CUI users in a single physical location, you have local IT capacity to manage the environment, and your contracts or workflow require local CUI handling. Some manufacturing and prototyping environments fit here.

Avoid when: You don’t have on-site IT depth or you’re trying to extend the enclave across multiple sites. On-prem enclaves are real estate. They get expensive fast when you need them in three places.

Pattern 4, Multi-Tenant or Shared Enclave

A managed-service offering where multiple defense contractors share infrastructure that the provider operates as a CUI environment. The provider handles inheritance of infrastructure controls. The contractor is responsible for their user-, data-, and application-layer controls.

Use this when: You’re a very small contractor without IT capacity, and you’ve validated through the shared responsibility matrix which controls the provider actually inherits and which still land on you. The provider’s CMMC posture is not your CMMC posture. Don’t conflate them.

Avoid when: The provider can’t produce a customer responsibility matrix at all. If they can’t tell you which controls you still own, you can’t tell your assessor either. That’s an unrecoverable position.

The Boundary Control Catalog

The architectural value of an enclave comes from concentrating specific controls at the edge, where they do the most work, instead of replicating them across the enterprise. The catalog below maps the NIST 800-171 controls that, in practice, sit at the enclave boundary versus inside the enclave.

Controls that live at the enclave edge

These are the controls that define the enclave by limiting what crosses it.

SC.L2-3.13.1 (Boundary protection): Monitor and protect communications at external and key internal boundaries. The foundational enclave control. The firewall or cloud perimeter that defines the enclave edge lives here.

SC.L2-3.13.5 (Public-Access System Separation): Publicly accessible system components are implemented on subnetworks physically or logically separated from internal CUI networks. If you host anything publicly that touches the enclave, the segregation must be explicit.

SC.L2-3.13.6 (Network Communication by Exception): Network traffic is denied by default and permitted by exception. The enclave’s policy is allow-list, not deny-list. If you can’t list the allowed traffic, the enclave isn’t bounded.

SC.L2-3.13.7 (No split tunneling): Remote devices accessing the enclave can’t simultaneously connect to external networks. Either the device is in the enclave session or it isn’t.

AC.L2-3.1.3 (Control CUI Flow): Approved authorizations control CUI flow in and out of the system. Binds the technical boundary to the policy boundary.

AC.L2-3.1.12 (Control Remote Access) and AC.L2-3.1.13 (Remote Access Confidentiality): Remote sessions into the enclave are monitored and protected with cryptographic mechanisms.

SC.L2-3.13.8 (Data in Transit): Cryptographic mechanisms protect the confidentiality of CUI in transit across the boundary.

SC.L2-3.13.11 (CUI Encryption): Where cryptography is used to protect CUI confidentiality, it must be FIPS-validated. This is the validation overlay that sits on top of the transit (3.13.8) and at-rest (3.13.16) controls — it dictates what kind of cryptography must be used, not where. Along with MFA (IA.L2-3.5.3), it is one of two requirements that can earn partial credit: per § 170.24(c)(2)(i)(B)(4)(ii), a 3-point deduction (rather than 5) when encryption is deployed but not FIPS-validated.

Controls that live inside the enclave

These are the controls that govern what happens once data is past the edge.

AC.L2-3.1.1 (Authorized Access Control) and AC.L2-3.1.2 (Transaction & Function Control): Enclave user accounts and the transactions they can execute are managed separately from corporate accounts. A frequent failure point. If enclave users authenticate against the same identity store as the corporate environment, the boundary is leaky.

AU.L2-3.3.1 through 3.3.9 (Audit and accountability): Audit logs for enclave activity, with attribution, retention, and review. Log destinations should not sit outside the enclave unless those destinations are also in scope.

SC.L2-3.13.16 (Data at Rest): Encryption protects CUI stored within the enclave.

IA.L2-3.5.3 (MFA): Multi-factor authentication for accounts that touch the enclave from outside it.

CM.L2-3.4.1 (System Baselining) and CM.L2-3.4.2 (Security Configuration Enforcement): The enclave runs its own baseline configuration and enforces distinct security configuration settings, separate from the corporate baseline.

The catalog isn’t exhaustive. It’s the spine. The rest of NIST 800-171’s 110 controls attach to one side of the boundary or the other based on the asset they govern. An assessor will trace each control back to a specific in-scope asset, which is why the asset inventory is the document that determines whether your enclave architecture survives contact with the assessment.

The Scope-Creep Failure Mode

The first six months of an enclave look great. Twelve endpoints, one file store, one identity group. Clean.

Then a year passes. A new program manager needs access “just for one project.” A new application gets stood up “temporarily.” A backup destination changes “for cost reasons.” An MSP starts a new ticketing integration that pulls metadata from inside the enclave to a corporate dashboard. Nobody updates the boundary documentation.

By assessment time, the enclave is no longer the enclave. Its actual perimeter is forty-something endpoints, a half-dozen integrations, three file destinations, and the corporate identity provider. The contractor still describes it as the original twelve-endpoint enclave because that’s what’s in the SSP.

The assessor traces the data flows and finds the new ones. The “enclave” reclassifies to “the corporate network with extra steps,” and the assessment scope expands mid-engagement. This is the most expensive way to fail a CMMC engagement, because the contractor has paid for enclave-scope readiness and is now being held to enterprise-scope evidence.

Three structural defenses prevent it.

A change-control gate at the enclave edge. Any new account, application, integration, or data destination that touches the enclave requires a documented approval that includes the impact on scope. No exceptions for urgency. The exception culture is what kills enclaves.

A quarterly boundary review. The boundary documentation, asset inventory, and data flow diagrams get re-walked against actual environment state. New systems get classified. Old systems get retired or reaffirmed. The review produces a dated artifact, not a verbal sign-off.

An MSP integration discipline. Any system the MSP touches that touches the enclave gets evaluated for scope inclusion. The MSP isn’t a special case. Their tools are in scope if they reach CUI or the protection of CUI. The MSP-CMMC integration question is downstream of this boundary decision, not upstream of it.

Picking Your Pattern

Five questions decide which enclave pattern fits.

How many CUI users do you actually have? Under 25, almost any pattern can work. Over 100, cloud-only or hybrid M365 are usually the only economics that scale.

Where is the CUI work physically performed? Single office, single shift: on-prem can work. Distributed, hybrid, remote-first: cloud-only is the natural fit.

What does the contract say about data residency and cloud authorization? Some contracts mandate specific cloud authorizations (commonly GCC High for ITAR-touching CUI). Read the DFARS 7012 clause and any contract-specific flowdowns before assuming a pattern is available. The DFARS 252.204-7012 guide covers what to look for.

Do you have the IT capacity to operate the pattern, or do you need to lean on a vendor? On-prem requires real IT hands. Cloud-only is more shippable to a managed-service partner. Hybrid M365 demands the most policy-administration sophistication of any pattern.

How much friction is acceptable for the CUI users? Cloud-only via virtual desktop is the highest friction for users. On-prem is usually the lowest. The friction has a real productivity cost that deserves a line in the budget.

There isn’t a “best” pattern. There’s a best pattern for a specific contractor’s CUI footprint, contract terms, IT depth, and user tolerance. The job is to pick deliberately, not by default.

Implementation Gotchas

Five things that derail enclave implementations even when the architecture is sound.

Data labeling without enforcement. Sensitivity labels in M365 are useful, but a label without a policy that enforces what can be done with labeled content is decoration. The label has to be wired to DLP, conditional access, and audit, or it’s a sticky note.

User access shortcuts. The most common collapse is granting corporate identities access to enclave resources “just for now.” Enclave identities should be distinct. Yes, it’s friction. Yes, it’s also the boundary.

MSP and outsourced IT visibility. If the MSP is using RMM tools that mirror endpoint state, ticketing systems that log content, or backup systems that snapshot CUI, the MSP’s tooling is in scope. This isn’t a gray area. Walk every MSP integration before assessment.

Evidence trails on enclave boundary changes. Every approved exception to the enclave perimeter needs an artifact: who approved it, when, what changed, what control compensated for the change. Without that trail, the boundary documentation drifts from reality, and the SSP drifts with it.

Assessor and RPO alignment. The enclave architecture has to survive contact with the assessor. Don’t commit to a pattern without walking the boundary, the asset categorization, and the inheritance assumptions with an RPO or your prospective C3PAO. The cheapest place to find out the assessor sees your boundary differently than you do is before the assessment, not during.

The Default Should Flip

Enterprise-scope CMMC became the industry’s default because it was the easiest thing for compliance vendors to sell and the most predictable thing for assessors to evaluate. It’s the wrong default for any contractor whose CUI is bounded. Most CUI is more bounded than the contractor assumes, and the compliance cost math of enterprise-scope versus enclave-scope rarely justifies the larger footprint.

Enclave-first is the rational starting position. Test it against your data flows and contract terms, pick the pattern that fits, and architect the boundary so it doesn’t grow back. Most contractors figure this out after the enterprise-scope assessment. We’d rather they figure it out before.

Map your CUI footprint and we’ll show you where the enclave fits and what the scope difference looks like.