Why Enclaves Exist
The single largest cost driver in CMMC Level 2 compliance is scope — the count of systems, identities, and network segments that handle CUI and therefore fall under the 110 NIST 800-171 Rev 2 requirements. A 50-person company that handles CUI on every workstation is committing to apply MFA, audit logging, encryption, configuration management, and the rest of the 110 controls to all 50 endpoints, every cloud service, every identity, and every network segment. The same company that confines CUI to a 5-person enclave reduces the in-scope footprint by roughly 90%.
That scope reduction compounds: less to remediate during preparation, less to assess during the C3PAO engagement, less to monitor for the three-year certification period, and a smaller blast radius if something fails. For organizations whose CUI exposure is genuinely limited — a few program managers handling drawings on a defense subcontract, an engineering team working on one ITAR-controlled product line — the enclave is almost always the cheapest path to certification.
Enclaves do not reduce the assessment requirement. An enclave compresses the in-scope environment, but every requirement still applies to whatever is inside the enclave. A 5-person enclave still needs all 110 controls implemented, documented, and assessed — just over a much smaller surface.
The Two Architectural Choices
Every organization preparing for CMMC Level 2 makes a strategic decision before any technical work begins: harden the entire organization, or carve out an enclave. The tradeoffs are real in both directions.
| Whole-Org Compliance | CUI Enclave | |
|---|---|---|
| Cost to stand up | Higher — every system, every identity, every network segment must meet 800-171 | Lower — only enclave components require remediation; rest of org stays as-is |
| Operational burden | Distributed across the whole IT footprint | Concentrated in the enclave — but the rest of the org runs normally |
| User experience | Uniform — all users live under the same controls | Bifurcated — enclave users may have separate devices, separate logins, and friction when collaborating with non-enclave colleagues |
| C3PAO assessment scope | Large — assessor evaluates the entire environment | Small — assessor focuses on the enclave; out-of-scope systems are reviewed only to confirm CUI cannot reach them |
| Breakage risk | Low — no dependency on a boundary; CUI can't leak into "out-of-scope" systems because there are none | High — the entire model depends on CUI never crossing the enclave boundary; one user emailing a drawing to their personal account invalidates the architecture |
| Best for | Organizations where most or all staff handle CUI; security-mature orgs that already operate close to 800-171 | Organizations where CUI is concentrated among a small subset of staff; organizations starting from a low security baseline |
The whole-org path is rarely chosen by small contractors. It tends to make sense only when CUI is so pervasive that an enclave would cover most of the organization anyway, or when the organization is mature enough that the incremental cost of full hardening is small.
The Boundary Problem
An enclave is defined by its boundary. Every part of the boundary must be enforced by technical and procedural controls, documented in your SSP, and demonstrable to an assessor. There are five dimensions that must be addressed for a boundary to hold:
- Identity: Who can authenticate into the enclave? A separate Microsoft Entra ID tenant, a partitioned directory, or a wholly separate IAM is the strongest boundary. Sharing identities between commercial and enclave environments — single sign-on across both — is permissible but creates lateral-movement exposure that must be addressed.
- Endpoints: Which physical or virtual devices can access enclave resources? Common options: dedicated laptops issued only to enclave users; virtual desktop infrastructure (VDI) where users log in from any device but the desktop runs in the enclave; or hardened bring-your-own-device with strict conditional access. Each option has different cost and friction profiles.
- Network: How does traffic reach the enclave? Site-to-site VPN, Zero Trust Network Access (ZTNA), a segmented VLAN with firewall enforcement, or a pure cloud-to-endpoint pattern with no on-premises component. The network boundary must be enforced — not assumed.
- Data flow: Where does CUI enter the enclave (vendor portals, encrypted email, secure file transfer) and where does it exit (deliverables back to the prime, archival)? Every entry and exit point is a control surface.
- People: Which named individuals are authorized to access the enclave? An enclave with a defined user roster, regular access reviews, and immediate offboarding when staff change roles is enforceable. An enclave where "anyone in engineering" can request access is not.
The boundary must be demonstrable, not just declared. Stating in your SSP that "the CUI enclave is logically separated from the corporate network" does nothing on its own. The assessor will look for the firewall rules, the conditional access policies, the directory structure, and the data flow controls that actually enforce that separation. If those controls don't exist, the boundary doesn't exist.
Major Platform Patterns
Most enclaves are built on one of five recurring patterns. None is strictly better than the others — the right choice depends on CUI volume, existing tech stack, user count, and budget.
Microsoft 365 GCC High
What it is: A separate Microsoft 365 tenant operated in a dedicated Microsoft government cloud region, with US-person personnel restrictions and FedRAMP High authorization. Provides Exchange, SharePoint, Teams, and OneDrive in a CUI-eligible environment.
What it covers: A meaningful portion of the 110 800-171 requirements through inheritance — particularly identity (Entra ID), audit logging, and parts of access control and system & communications protection. Customer-responsible portions are still substantial.
Gotchas: Requires a sponsor letter (a DoD contract or letter of intent) before Microsoft will provision a tenant. Significantly more expensive per-seat than commercial M365. Some commercial M365 features are unavailable or behave differently. Migration from commercial M365 is a project in itself. Commercial Microsoft 365 — including Microsoft 365 Business Premium and even Microsoft 365 E5 — is not authorized to hold CUI, regardless of what a Microsoft sales representative may suggest. The standard GCC offering is FedRAMP Moderate authorized and can hold many types of CUI, but GCC High is the preferred environment for CUI under DFARS 7012 and is required when the CUI is also ITAR-controlled (because GCC may have non-US-person support personnel that would violate ITAR's US-person rule).
PreVeil
What it is: A purpose-built end-to-end encrypted email and file collaboration platform that operates as an overlay on top of an organization's existing commercial environment. CUI is handled exclusively within the PreVeil application; everything outside it is out of scope.
What it covers: A large portion of the cryptographic, transmission protection, and storage protection requirements through the encrypted overlay model. PreVeil publishes a customer responsibility matrix for the controls it inherits, shares, or leaves to the customer.
Gotchas: Endpoint compliance is still the customer's responsibility — the device that runs the PreVeil app must still meet 800-171 endpoint requirements. PreVeil is purpose-fit for email and file collaboration; if your CUI workflow requires CAD, PLM, ERP, or other line-of-business applications, PreVeil alone is insufficient. Best fit: very small organizations whose CUI exposure is narrow (correspondence and document exchange with primes).
Kiteworks & similar MFT platforms
What it is: A managed file-transfer and secure collaboration platform that primes commonly use to send CUI down to subcontractors. Subs interact with the platform as authenticated users; the platform itself is FedRAMP authorized.
What it covers: Strong on transmission protection, audit logging, and access control around the file exchange surface. Useful when the CUI exposure is primarily "files arrive from the prime, files go back to the prime."
Gotchas: The MFT platform is only the entry/exit point for CUI. Once a file is downloaded to a sub's local environment for engineering work, that local environment is in scope. Treating the MFT platform as "the enclave" is a common scoping error — the enclave is wherever the CUI lives at rest, not just the channel it arrives through.
Azure Virtual Desktop in GCC High, AWS GovCloud WorkSpaces, dedicated VDI
What it is: Users log in from their normal endpoint (corporate laptop, home device, BYOD) to a virtual desktop hosted inside a CUI-eligible cloud environment. CUI never lands on the user's endpoint — it stays in the virtual session.
What it covers: A significant scope reduction on the endpoint side, because the local device becomes a thin client rather than an in-scope endpoint. Most 800-171 controls move to the virtual desktop image, the underlying cloud platform, and the access broker.
Gotchas: Requires strict prevention of data egress from the virtual session — clipboard redirection, file download, drive mapping, screen recording, and printing must all be controlled. If a user can copy CUI from the virtual desktop to the local clipboard, the local endpoint is in scope. The user experience can be poor for graphics-heavy CAD or simulation workloads. Network latency from the user's location to the cloud region matters.
AWS GovCloud, Azure Government, Oracle Government Cloud (custom build)
What it is: The customer architects their own CUI environment from primitives in a government-region cloud. Provides maximum flexibility for organizations with unusual workloads (large simulation clusters, custom engineering toolchains, GIS, classified-adjacent workflows).
What it covers: The customer inherits the FedRAMP-authorized infrastructure layer but is responsible for designing and implementing every control above the hypervisor. Identity, networking, data protection, logging, configuration management — all on the customer.
Gotchas: Highest engineering cost of any pattern. Suits organizations with mature cloud engineering capability and unusual workload requirements. For typical office-productivity CUI exposure, the cloud productivity enclave (Pattern 1) is usually a better fit at lower cost.
FedRAMP Equivalence and CSP Inheritance
Department of Defense policy requires that any cloud service used to store, process, or transmit CUI be authorized at the FedRAMP Moderate baseline or be demonstrably equivalent. This is the single most consequential rule when evaluating an enclave platform.
Commercial cloud services cannot hold CUI. Commercial Microsoft 365, Google Workspace, Dropbox Business, Slack (commercial tier), Zoom (commercial), and the general-public versions of nearly every major SaaS application are not FedRAMP Moderate authorized. They cannot lawfully hold CUI under DFARS 252.204-7012, and using them for CUI is both a regulatory violation and an automatic finding in any C3PAO assessment. This is true regardless of how strong the security controls of the commercial offering may be.
The DoD CIO memorandum of December 21, 2023 ("Federal Risk and Authorization Management Program (FedRAMP) Moderate Equivalency for Cloud Service Provider's Cloud Service Offerings") set a strict bar for "equivalent." A CSP claiming equivalence must be assessed by a FedRAMP-recognized third-party assessment organization (3PAO) against 100% of the FedRAMP Moderate baseline controls, with zero control-related findings, no open POA&M items from the assessment, and a complete Body of Evidence available to DIBCAC on request. Self-attestation of equivalence is explicitly not permitted. In practice, very few cloud services that are not formally FedRAMP authorized meet this bar.
Before adopting any cloud service for an enclave, verify its authorization status:
- Search the FedRAMP Marketplace for the specific service offering and confirm "FedRAMP Authorized" status at Moderate or High
- For services claiming equivalence, request the 3PAO assessment package and the evidence body, and have your security team confirm it meets the equivalence standard
- Confirm the specific edition or tier you intend to use is the authorized one — a vendor's "Federal" or "Government" tier is the authorized variant; their "Commercial" or "Enterprise" tier typically is not
Shared Responsibility and the Customer Responsibility Matrix
Every cloud-based enclave inherits some 800-171 requirements from the underlying provider and leaves others to the customer. The Customer Responsibility Matrix (CRM) — published by the cloud provider — maps each control to the responsibility split. Reading and understanding the CRM is the first step in any enclave architecture decision.
The numbers in the table below are illustrative only. They are not drawn from any specific CSP's published CRM and should not be used to plan inheritance assumptions. Always work from the cloud provider's actual published CRM — Microsoft publishes its CRM through the Service Trust Portal; AWS publishes through AWS Artifact. The pattern below shows the structural takeaway only: that no platform inherits more than roughly half the requirements, and that most assessment findings cluster in shared-responsibility controls left at default settings.
| Control Family | Inherited from CSP | Shared | Customer Responsible |
|---|---|---|---|
| Access Control (AC) — 22 reqs | ~5 | ~10 | ~7 |
| Audit & Accountability (AU) — 9 reqs | ~4 | ~3 | ~2 |
| Configuration Management (CM) — 9 reqs | ~3 | ~3 | ~3 |
| Identification & Authentication (IA) — 11 reqs | ~2 | ~6 | ~3 |
| Personnel Security (PS) — 2 reqs | 0 | 0 | 2 |
| Physical Protection (PE) — 6 reqs | ~5 | ~1 | 0 (cloud-only) / 6 (hybrid) |
| System & Communications Protection (SC) — 16 reqs | ~6 | ~6 | ~4 |
| System & Information Integrity (SI) — 7 reqs | ~2 | ~3 | ~2 |
Two patterns matter here. First, no platform — including the most comprehensive — inherits more than roughly half the requirements. Even on a fully cloud-hosted enclave, there is meaningful customer-responsible work in identity configuration, access policy, data classification, audit log review, and incident response. Second, the "shared" rows are where most assessment findings cluster: shared controls require the customer to actually configure something correctly (enable MFA conditional access, configure audit log retention, define account lockout thresholds), and the most common failure is leaving the cloud platform at its default settings.
Where to find the real CRM: Microsoft publishes its FedRAMP responsibility matrix through the Microsoft Service Trust Portal. PreVeil publishes its 800-171 responsibility matrix on its compliance documentation page. For any cloud service in your enclave, request the current CRM in writing — it is a contractual artifact, not optional documentation.
The Bridging Problem
The most common cause of enclave failure is not a missing control inside the enclave — it is a bridge that lets CUI cross the boundary into systems that are out of scope. Assessors test for these bridges aggressively, and finding even one can invalidate the entire enclave architecture.
Bridging failures assessors will probe
- Personal email used for CUI correspondence. A user receives a CUI document in the enclave, then forwards it to their personal Gmail to work from home. The personal email account is now an out-of-scope system holding CUI.
- BYOD access to enclave resources. A user logs into the enclave's webmail from a personal phone or laptop. Unless the BYOD device is enrolled in MDM and meets endpoint requirements, the device is now an in-scope endpoint that has not been assessed.
- Copy-paste from enclave to commercial. A user copies CUI text from a virtual desktop or PreVeil window and pastes it into commercial Microsoft Word, commercial Slack, or a personal note-taking app. The destination is out of scope and now contains CUI.
- Screenshots and screen recording. A user screenshots a CUI document for reference and saves it to their personal cloud photo backup. The cloud photo service is out of scope and now contains CUI.
- Printing to commercial print queues. A CUI document is printed from the enclave, but the print job routes through a corporate print server that is not in the enclave. The print server has now handled CUI.
- Commercial backup or archive systems. An enclave file server is backed up to a commercial cloud backup that is not FedRAMP authorized. The backup itself is now an out-of-scope CUI repository.
- Shadow IT for collaboration. Enclave users find the enclave's collaboration tools clunky and revert to a commercial alternative for "just this one project." The shadow tool now holds CUI.
- Contractor and subcontractor laptops. A consultant or subcontractor accesses enclave resources from a device that is neither owned nor managed by the prime organization. Unless the device meets enclave endpoint requirements, this is an unmanaged in-scope endpoint.
- Mobile device access without containerization. A user receives enclave email on a personal phone with no MDM or app containerization. Email containing CUI now resides on an unmanaged mobile device.
- Federation back to the commercial directory. The enclave authenticates against the corporate Active Directory or commercial Entra tenant, meaning a compromise of the commercial directory grants access to the enclave. This may be technically permissible but requires careful documentation and additional controls.
Each of these failures has the same root cause: a control gap at the boundary between in-scope and out-of-scope systems. The boundary must be enforced by technical controls (data loss prevention, conditional access, MDM, endpoint configuration), not by user training alone. Training that says "don't put CUI in personal email" is not a control — it is a request.
Choosing a Pattern
The right enclave pattern is rarely obvious. Work through these questions in order:
- How much CUI do you actually handle? If it's primarily correspondence and small documents from a prime, an encrypted overlay (PreVeil) or productivity enclave (GCC High) is sufficient. If you have engineering CAD files, simulation data, or large datasets, you'll need a productivity enclave or a custom-built cloud environment.
- How many users need access? Under 10 users with narrow CUI exposure: encrypted overlay is the cheapest viable path. 10–100 users with diverse workflows: productivity enclave (GCC High) is typically the best fit. Over 100 users, or unusual workloads: consider VDI or a custom-built environment.
- What is your existing tech stack? Already on Microsoft 365 commercial? GCC High is a difficult migration but the closest functional analog. Already on Google Workspace? You will need to migrate to a Microsoft or AWS enclave — Google does not offer a CUI-eligible workspace. Heavy use of specialized engineering tools (CAD, PLM, simulation)? VDI or a custom environment may be required to host them.
- Do you have a sponsor letter for GCC High? If you do not yet have a DoD contract or a letter of intent from a prime, Microsoft will not provision a GCC High tenant. PreVeil and Kiteworks have lower onboarding barriers.
- Can you actually enforce the boundary? Whatever pattern you choose, walk through the bridging failures above and confirm you can enforce against each one. If you cannot — particularly around BYOD, personal email, and copy-paste — the enclave model is the wrong choice and whole-org compliance is the more honest path.
Documenting the Enclave in Your SSP
An enclave architecture must be reflected in your SSP — particularly in the boundary, environment, and inheritance sections. See the System Boundary section and the Inheritance & Shared Responsibility section of the SSP guide for the documentation requirements. Specifically:
- The boundary statement must name the enclave and explicitly enumerate what is out of scope
- Network architecture diagrams must show the enclave perimeter, the data entry and exit points, and the controls enforcing each boundary crossing
- The inherited control list must reference the cloud provider's CRM by document name and version
- Bridging controls (DLP policies, conditional access rules, MDM configurations, endpoint restrictions) must be documented as the technical enforcement of the boundary, not assumed
- The user roster of authorized enclave users must be maintained and reviewed regularly — the enclave is only as defensible as the authorization decisions feeding it
For subcontractors who handle CUI received through your enclave, see the guide on DFARS 252.204-7012(m) Flow-Down Obligations — the CMMC requirements you carry must be flowed down to any sub that handles your covered defense information.
Authoritative References
Related resources: Once you've chosen a pattern, walk through the documentation requirements in the SSP writing guide, then map your enclave's CRM against the 110 control deep dives to identify the customer-responsible portions. If you flow CUI to subcontractors, see DFARS 252.204-7012(m) Flow-Down Obligations.