Let's be clear upfront: managed enclaves are a legitimate, often smart approach to handling CUI. A well-architected enclave isolates your CUI processing environment, narrows your assessment scope, and gives you a hardened infrastructure that addresses a significant number of CMMC Level 2 technical controls. If your organization doesn't have the internal IT maturity to build and manage a compliant environment from scratch, an enclave can be exactly the right business decision.
The problem isn't enclaves. The problem is a common assumption about what they cover.
Many organizations hear "CMMC-compliant enclave" and assume that means the enclave gets them to certification, or close to it. That's an understandable conclusion, but it's not accurate. An enclave addresses the infrastructure layer. CMMC certification requires the infrastructure layer and the organizational layer. A C3PAO assesses both with equal rigor, and the organizational half is entirely your responsibility regardless of what technology you deploy.
Organizations that recognize this early build their compliance program alongside the enclave deployment. Organizations that discover it late find themselves months behind schedule, wondering why a significant investment in technology didn't move them closer to assessment-ready.
A managed enclave typically provides a pre-configured environment: endpoints, cloud infrastructure, identity management, encryption, network segmentation, monitoring, and backup. The enclave vendor manages the technical stack and inherits responsibility for a subset of NIST SP 800-171 controls, primarily in the system and communications protection, access control, and audit families.
This is real, meaningful work. Depending on the enclave architecture and the shared responsibility model, the vendor may address 40 to 60 of the 110 controls at the infrastructure layer. That's a significant head start.
But CMMC Level 2 has 110 controls. And a C3PAO assesses all of them.
The controls an enclave cannot address are the organizational ones: the policies, procedures, training, governance, and operational behaviors that your organization must implement, document, and sustain. No enclave vendor can install these for you, because they describe how your people operate, not how your systems are configured.
Here's what remains your responsibility after the enclave is deployed:
Written policies and procedures. Your organization needs a complete set of security policies that cover every control family: access control, awareness and training, audit and accountability, configuration management, incident response, and the rest. These policies must be specific to your organization, approved by leadership, and accessible to staff. They cannot be the enclave vendor's policies. They must be yours.
System Security Plan (SSP). The SSP is the single most important document in your CMMC assessment. It describes your entire security posture: what's in scope, how each control is implemented, who is responsible, and what the boundaries are. The enclave vendor may provide a shared responsibility matrix or a partial SSP for their portion, but the overall SSP is yours to build and maintain.
CUI scoping and boundary definition. CUI doesn't stay inside the enclave. It enters from somewhere (contracts, email, supplier data) and it exits to somewhere (deliverables, subcontractors, archives). The pathways between your broader environment and the enclave are in scope. The people who access the enclave are in scope. The devices they use to access it are in scope. Scoping is your responsibility.
Security awareness and training. Every person who handles CUI or uses systems in the assessment scope needs security awareness training that is specific to your environment. Role-based training is required for staff with security responsibilities. The enclave vendor doesn't train your people. You do.
Incident response. You need a documented incident response plan, a trained incident response team, and evidence that you've tested the plan (tabletop exercises at minimum). The enclave vendor has their own incident response procedures for the infrastructure they manage. You still need yours for the organizational layer.
Configuration management and change control. How does your organization manage changes to systems, software, and configurations? Is there a change control board or approval process? Are baseline configurations documented? The enclave vendor manages their infrastructure changes. You manage everything else.
Risk assessments. Your organization needs to conduct and document periodic risk assessments that cover your entire assessment scope, not just the enclave. Risk assessment is an organizational activity that considers threats, vulnerabilities, and impacts across your environment.
Physical security. If CUI is accessed from physical locations (offices, manufacturing floors, home offices), those locations have physical security requirements: visitor logs, access restrictions, screen placement, clean desk procedures. The enclave vendor secures their data centers. You secure your facilities.
Every enclave vendor provides a shared responsibility matrix that maps which controls they handle and which remain with the customer. This is a useful document, and good vendors are transparent about the division. The challenge is that the customer-responsible controls are often more extensive than organizations expect.
The customer-responsible side includes the entire policy and governance layer, all training and awareness activities, incident response, risk management, physical security, and the operational discipline to sustain all of it over time. For most small and mid-size organizations, these controls represent the hardest part of CMMC compliance, because they require organizational change, not just technology deployment.
This isn't a shortcoming of the enclave. It's the nature of CMMC. The standard was designed to evaluate both the technical environment and the organization operating within it. No technology solution, no matter how well-architected, can address both halves.
If you're evaluating an enclave, the right questions to ask are not just about what the enclave covers, but about what it doesn't cover and how you plan to address the gap.
Do you have a plan for who will write your policies and procedures? Not adapt a template, but write policies that reflect how your organization actually operates?
Do you have someone who will build and maintain the SSP? This is a living document that needs regular updates as your environment changes.
Do you have a training program, or a plan to build one?
Do you have an incident response plan that your team has actually rehearsed?
Do you have a change control process?
If the answer to most of these is no, the enclave is giving you a strong foundation, but you're still facing a significant compliance program build. Recognizing that early, and planning for it, is the difference between organizations that certify on schedule and organizations that stall six months after deploying the enclave, wondering why they're not closer to ready.
Enclaves are good infrastructure. They solve a real problem. Choose a vendor that is transparent about what they cover and what remains your responsibility. Then build the compliance program around it: the policies, the procedures, the training, the governance, and the operational discipline that an assessor will evaluate with the same rigor as your technical controls.
The organizations that get this right treat the enclave as the starting point, not the finish line.
Take our 3-minute Readiness Check and get an instant gap summary based on your environment.
Start Readiness Check →
An independent firm focused exclusively on CMMC compliance for defense contractors and the DIB.