How to Build a Secure Enclave for CMMC Level 2 Compliance: Architecture and Configuration Guide

How to Build a Secure Enclave for CMMC Level 2 Compliance: Architecture and Configuration Guide

What Is a Secure Enclave and Why Does It Matter for CMMC Level 2?

If your organization handles Controlled Unclassified Information (CUI) under a Department of Defense contract, you are required to protect that data within a defined, auditable environment. That environment is commonly called a secure enclave. For contractors pursuing CMMC Level 2 certification, building a properly scoped and configured secure enclave is not optional — it is the foundation on which every one of the 110 NIST SP 800-171 controls rests.

A secure enclave is a logically and physically bounded segment of your IT environment specifically designed to store, process, and transmit CUI. It is distinct from your general business network, and everything inside it — endpoints, servers, cloud services, user accounts, and data flows — must meet the security requirements outlined in NIST SP 800-171 Rev 2 and, by extension, CMMC Level 2.

Getting this architecture right before your C3PAO assessment is critical. Scope creep, misconfigured boundaries, and undocumented data flows are among the most common reasons contractors fail their assessments. This guide walks through the essential architecture decisions, configuration requirements, and documentation obligations you need to address.

Step 1: Define the CUI Boundary Before You Build Anything

The most important work happens before you configure a single system. You must define exactly where CUI lives, how it moves, and who touches it. This is your CUI boundary, and it determines the scope of your enclave and your entire CMMC assessment.

Begin by conducting a thorough data flow analysis. Map every system, application, and user that creates, receives, stores, or transmits CUI. Common CUI repositories include:

  • Engineering workstations and CAD systems
  • File servers and SharePoint environments
  • Email systems handling contract data
  • ERP and project management platforms
  • Remote access gateways and VPN endpoints

Once you have a complete inventory, ruthlessly narrow the scope. Every system inside the boundary adds compliance cost and assessment risk. Systems that do not need to touch CUI should be excluded through technical controls, not just policy statements. Our team frequently helps contractors reduce their enclave scope by 40 to 60 percent before the assessment clock starts.

For a deeper look at how CUI classification affects your boundary decisions, review our existing guidance on Controlled Unclassified Information and what qualifies as CUI in your specific contract context.

Step 2: Choose the Right Cloud or On-Premises Architecture

Most defense contractors today build their secure enclave around one of three models: a Microsoft GCC High cloud enclave, an on-premises network enclave, or a hybrid of both. Each has distinct compliance implications.

Microsoft GCC High as Your Enclave Foundation

Microsoft GCC High is purpose-built for ITAR and CUI workloads. It operates on infrastructure that is physically and logically separate from commercial Microsoft 365 tenants, staffed by U.S. persons, and authorized at FedRAMP High. For most small to mid-size defense contractors, building the CUI enclave on Microsoft GCC High significantly reduces the number of controls you must implement independently because many platform-level controls are inherited from Microsoft's authorization.

Key GCC High services relevant to your enclave include:

  • Microsoft Teams GCC High — for CUI communications and collaboration
  • SharePoint Online GCC High — for CUI document storage and access control
  • Exchange Online GCC High — for encrypted email handling CUI
  • Microsoft Purview — for CUI labeling, DLP, and audit logging
  • Microsoft Intune — for endpoint compliance and mobile device management
  • Microsoft Entra ID (formerly Azure AD) — for identity, MFA, and conditional access

On-Premises Enclave Architecture

Some contractors — particularly those in manufacturing, aerospace, or classified environments — maintain an on-premises enclave for engineering systems that cannot move to the cloud. In this model, the enclave is a physically and logically segmented network segment with dedicated firewalls, access controls, and monitoring. Air-gapped or near-air-gapped configurations may be appropriate for the most sensitive programs.

On-premises enclaves require you to own and implement every NIST SP 800-171 control without the benefit of cloud inheritance. This substantially increases both implementation cost and ongoing operational burden.

Step 3: Configure Core Security Controls Within the Enclave

Once you have defined your boundary and chosen your architecture, you must configure the specific technical controls that CMMC Level 2 requires. The following domains demand the most attention during enclave build-out.

Access Control (AC)

Implement role-based access control (RBAC) so that users can only reach CUI systems and data their role requires. In GCC High, this is enforced through Entra ID groups, SharePoint permissions, and Conditional Access policies. Multi-factor authentication (MFA) is non-negotiable — every account that can access the enclave must use phishing-resistant MFA. Privileged accounts require additional controls including dedicated admin workstations and just-in-time access where feasible.

System and Communications Protection (SC)

The enclave boundary must be technically enforced, not just documented. Use next-generation firewalls to segment CUI traffic from general business traffic. Encrypt all CUI in transit using TLS 1.2 or higher. In GCC High, enable sensitivity labels through Microsoft Purview so that CUI documents carry encryption that follows the file regardless of where it is moved. Review Azure Information Protection best practices to understand how labeling policies enforce protection at the data layer.

Audit and Accountability (AU)

Every action taken within the enclave — login attempts, file access, configuration changes, privilege escalation — must be logged and retained. In GCC High, enable Unified Audit Logging across all workloads. Configure log retention to meet the 90-day active and one-year archival minimums. Integrate logs into a SIEM or Microsoft Sentinel for ongoing monitoring and alerting.

Configuration Management (CM)

Establish a baseline configuration for every system in the enclave and document it in your System Security Plan (SSP). Use Microsoft Intune compliance policies to enforce endpoint baselines and detect drift. Disable unnecessary ports, protocols, and services. Use a change management process so that all deviations from baseline are reviewed, approved, and documented before implementation.

Identification and Authentication (IA)

Enforce password complexity and account lockout policies consistent with NIST SP 800-63B guidance. Disable shared and generic accounts. Implement privileged access workstations (PAWs) for administrative access to enclave systems. In GCC High, enforce Conditional Access policies that require compliant devices as a condition of enclave access.

Incident Response (IR)

Document and test an incident response plan specific to your enclave. Under DFARS 252.204-7012, you have 72 hours to report cyber incidents affecting CUI to the DoD's DC3. Your enclave architecture must support rapid isolation of compromised systems without disrupting the entire business network — which is one reason proper segmentation from the outset is so operationally valuable.

Step 4: Document the Enclave in Your System Security Plan

The SSP is the central compliance artifact for CMMC Level 2. It must describe every system component inside the enclave boundary, every control you have implemented or plan to implement, and the rationale for any controls you consider not applicable. Assessors will use your SSP as the primary lens through which they evaluate your environment.

Your SSP must include a network diagram showing the enclave boundary, data flow diagrams showing how CUI moves between systems, an asset inventory, and a control implementation narrative for all 110 controls. Our guidance on SSP and POA&M development covers what assessors expect to find in each section.

Any controls that are not yet fully implemented must be documented in a Plan of Action and Milestones (POA&M) with realistic remediation timelines. Be honest in your self-assessment. Inflated SPRS scores create False Claims Act exposure that far exceeds the cost of honest remediation.

Step 5: Validate the Enclave Before Your C3PAO Assessment

Before scheduling your formal CMMC assessment, conduct an internal or third-party readiness review. Walk through every domain of NIST SP 800-171 and verify that evidence exists to support each control claim. Common pre-assessment findings include:

  • Undocumented systems inside the CUI boundary that were missed during scoping
  • MFA gaps on service accounts or legacy applications
  • Audit logging not configured on all enclave systems
  • Missing or outdated user training records
  • Configuration baselines documented but not actually enforced

Our CMMC, CUI, and DFARS compliance services include enclave architecture reviews and pre-assessment readiness engagements designed specifically to close these gaps before your C3PAO arrives. We have guided contractors from scope definition through certification, and we understand exactly what assessors are looking for in the evidence they collect during each assessment phase.

If you are still early in your compliance journey and want to understand the full landscape of CMMC 2.0 requirements, our CMMC 2.0 for DoD and Federal Contractors training resource provides practical, role-specific guidance for compliance teams at every stage.

For organizations that need ongoing security leadership to manage the enclave after certification, our Regulatory vCISO services provide fractional CISO support calibrated to the demands of defense contractor compliance programs.

The Architecture Decision That Derails Most Contractors

The single most common architectural mistake we see at Cleared Systems is failing to separate the CUI enclave from the general IT environment at the network and identity layer. Contractors assume that policy alone — a rule that says "don't store CUI on personal drives" — constitutes a technical boundary. It does not. CMMC assessors will look for firewall rules, access control lists, conditional access policies, and DLP enforcement that technically prevent CUI from leaving the enclave. Policy without enforcement is not a control. It is a liability.

Building a defensible secure enclave for CMMC requires deliberate architecture decisions, disciplined scoping, and continuous configuration management. The contractors who achieve Level 2 certification on the first attempt are those who treat the enclave as a formal engineering project — not an IT task list.

Cleared Systems works with defense contractors across the federal and defense industrial base to design, build, and document CMMC-compliant secure enclaves. If you are preparing for a C3PAO assessment or building your enclave from scratch, request a quote today and let us help you get it right the first time.

Social Share :


Search Blog

Categories