A Controlled Unclassified Information enclave is the technical and architectural boundary inside which your organization stores, processes, and transmits CUI. Everything inside that boundary is in scope for CMMC Level 2. Everything outside it is not. A clean enclave reduces scope, reduces cost, and reduces the number of controls your team has to maintain. A compromised enclave design does the opposite — expanding the assessment surface and importing risk from the corporate environment.
Most organizations we engage with have drafted their enclave in the early weeks, built it in the middle of the program, and discovered during pre-assessment that something fundamental needs to change. The cost of fixing an enclave after build-out is significantly higher than the cost of designing it correctly up front. Below are the seven mistakes we see repeatedly, in order of how much damage they cause.
Mistake 1 — Flat east-west segmentation
The enclave is a single VLAN or a single subnet. Every server inside it can reach every other server. There is no internal segmentation, no micro-segmentation, no control on lateral movement. The justification is usually simplicity — “it’s all CUI, so why separate it?”
The problem: a compromised workstation inside the enclave becomes a pivot point to every other workstation and every server inside the enclave. There is no defense in depth. From an assessor perspective, Access Control AC.L2-3.1.3 (control of information flows) becomes hard to demonstrate, and from an operational perspective, a single compromise becomes a full-enclave incident.
Correct architecture: segment the enclave by function. Workstations on one segment, application servers on another, management tooling on a third, logging and SIEM on a fourth. Enforce traffic rules between segments with a stateful firewall or equivalent. Micro-segmentation tools (Illumio, Cisco Secure Workload, or host-based firewalls managed centrally) help, but a classical segmented design works fine if configured correctly.
Mistake 2 — Shared authentication with corporate
The enclave uses the same identity provider as the rest of the company. The same Okta tenant, the same Azure AD, the same Google Workspace directory. The justification is always the same — “it’s easier for users, they already have accounts.”
The problem: a compromised credential anywhere in the corporate environment is a compromised credential in the enclave. Every shadow-IT SaaS tool that your marketing team connects via SSO is now part of your CUI boundary from an identity perspective. The assessor will follow the identity chain out of the enclave and into places you did not intend to put in scope.
Correct architecture: a separate identity domain for the enclave. Whether that’s a dedicated Azure AD tenant, a separate Okta org, or a standalone directory, it must be operationally distinct. Users who work in the enclave have two accounts — their corporate account and their enclave account — and the two do not federate. Yes, this is more friction. It is also the right answer.
Mistake 3 — Unscoped logging
The enclave sends logs to the corporate SIEM, or to a shared logging backend, or to an S3 bucket nobody monitors. There is no dedicated logging pipeline with defined retention, integrity controls, and review cadence for the enclave specifically.
The problem: the AU domain becomes difficult to demonstrate. You cannot show the assessor the enclave’s audit record as a distinct artifact. If the corporate SIEM has a retention of 30 days and the CMMC requirement is 12 months (for specific event types), you have a gap you cannot close quickly. If the logging pipeline has a break in chain-of-custody, you have an integrity problem.
Correct architecture: a dedicated log pipeline for the enclave. Dedicated SIEM or a clearly defined partition of a shared SIEM, with retention tuned to 800-171 requirements, integrity controls on log storage (write-once or cryptographic hashing), and a documented weekly or monthly review process that produces its own audit record. The logs your assessor wants to see are not just the application logs — they are the logs of the logging system itself.
Mistake 4 — Missing boundary protection documentation
The network diagram shows the enclave. It does not show where CUI enters the enclave, where it leaves, and what control each ingress and egress point enforces. Boundary protection exists technically but is not documented in a form the assessor can evaluate.
The problem: SC.L2-3.13.1 (boundary protection) is graded on whether you can demonstrate that information flows are controlled at managed interfaces. A diagram that shows the enclave as a cloud-shape with arrows going in and out does not satisfy this. An assessor will ask “what happens at this line?” and expect a specific control to be named.
Correct architecture: every ingress and egress point is documented with a named control, a named owner, and evidence of the control in operation. CUI enters the enclave via this specific mechanism, routed through this specific firewall rule, logged to this specific SIEM index, reviewed on this specific cadence by this specific role. The boundary documentation should be thick enough to survive a detailed walk-through.
Mistake 5 — GFE/CFE integration without interface agreement
The engagement involves government-furnished equipment or customer-furnished equipment integrated into the enclave, but there is no written interface agreement documenting who owns which control, who responds to incidents, and how change management flows across the boundary.
The problem: when the assessor identifies shared responsibility between your team and the GFE/CFE provider, they will ask for the agreement that documents it. If the agreement doesn’t exist, the control is effectively orphaned — neither party can demonstrate ownership, and it lands as a gap in your assessment. Verbal handshakes do not satisfy CMMC.
Correct architecture: a written interface agreement (sometimes called an ISA or MOU) executed before integration, specifying control responsibility by control number, incident notification procedures, change management flows, and access and data handling boundaries. For GFE specifically, coordinate with the government program office — they have standard templates and will tell you what they need to see.
Mistake 6 — Overly broad CUI scope
Everything is labeled CUI. Every project document, every email, every network share. The justification is “we don’t want to miss anything.”
The problem: the CUI scope determines what goes into the enclave. If everything is CUI, the enclave has to contain everything — which means the corporate environment and the CUI environment effectively merge. The assessment applies to the entire company, and the cost of compliance triples. When the assessor asks why that marketing planning document is labeled CUI, and you cannot articulate the specific CUI category it falls under, the label gets called into question.
Correct architecture: a data classification policy with specific CUI category definitions (CUI Basic, CUI Specified, and the specific categories that apply to your contracts — CUI//SP-PRIV, CUI//SP-PROP, etc.). Not everything is CUI. Most things are not. A handful of specific data types, clearly identified, that live in the enclave and nowhere else. The corporate environment is out of scope because CUI is not permitted there by policy, and that policy is technically enforced.
Mistake 7 — No continuous monitoring plan at go-live
The enclave is architected, built, documented, and assessed. Then the assessment passes and the team moves on to other priorities. Twelve months later, configurations have drifted, access reviews have lapsed, and the logging pipeline has degraded. Re-assessment finds gaps that were not there at go-live.
The problem: Level 2 certification is valid for three years with surveillance. CMMC expects continuous monitoring, not just point-in-time compliance. The organization that passes at go-live and fails at surveillance has not invested in the operations that maintain the posture.
Correct architecture: a continuous monitoring plan defined before go-live, with specific cadences for each control family — daily log review, weekly access review, monthly vulnerability scanning, quarterly configuration review, annual policy refresh. Each cadence generates its own evidence, which rolls up into an annual health check that anticipates surveillance audits. A named accountable role owns the continuous monitoring program; it is not distributed across the original implementation team.
The meta-pattern
The common thread across all seven mistakes is the temptation to take the simpler architectural path in service of user convenience or organizational inertia. CUI enclave design is not the place for that tradeoff. The cost of re-architecting a deployed enclave is substantially higher than the cost of making the harder choice at design time. The six-to-nine-month Level 2 preparation window does not have room for a major architectural rework at month four.
If you are in the architecture phase right now, this article is a gift. If you are past it, it is diagnostic — run each mistake against your current design and decide which ones you can still fix. Some can be mitigated with compensating controls and documented risk acceptances. Others cannot.
Either way, the time to know is now, not at pre-assessment.
We design CUI enclaves from scratch in our IT & Security Buildout engagements and remediate architectural debt inside CMMC Level 2 engagements. A related read if you are preparing for a C3PAO assessment: what assessors actually look for at Level 2. For the next architectural mistake category coming into scope: how AI/ML tools intersect CUI enclaves under the NDAA Section 1513 framework and the June 2026 AI EO — particularly relevant if your team is deploying code copilots, AI documentation tools, or AI-assisted security tooling into CUI workflows.