CMMC Level 2 Enclave vs Separate Tenant in Microsoft 365, decision tree, costs, and evidence you’ll need

If you’re chasing CMMC Level 2, the fastest way to blow your schedule (and your budget) is to scope Microsoft 365 the wrong way. I see it all the time: a team wants a CMMC Level 2 enclave, but they can’t explain where the boundary is, who’s inside it, and what proves it in an assessment.

I’m writing this for IT and security leaders at DoD contractors who need a practical call: build an enclave inside an existing tenant, or stand up a separate Microsoft 365 tenant for CUI. I’ll lay out how assessors think about boundaries, what must be in-scope, a plain-English decision tree, cost ranges and drivers, and the minimum evidence package I like to assemble before a C3PAO ever shows up.

What an “enclave boundary” means in Microsoft 365 (and what’s in-scope)

In Microsoft 365, an enclave is not a vibe. It’s a defined set of people, identities, devices, apps, and data locations that handle CUI, plus the controls that protect them. The boundary can be logical (inside one tenant) or physical-administrative (a separate tenant), but it has to be defensible and testable.

For Level 2 scoping, I start with the DoD’s definitions and categories, then map them to Microsoft 365 services and admin planes. The CMMC Level 2 Scoping Guide (DoD PDF) is the anchor I point clients to when we’re deciding what’s CUI-handling, what’s a security protection asset, and what’s merely adjacent.

Here’s what is usually in-scope when CUI touches Microsoft 365:

• Identities and admin plane: Entra ID users, privileged roles, break-glass accounts, group design, authentication methods, MFA, Conditional Access.
• Endpoints: Windows/macOS devices used to access CUI, their configuration baselines, encryption, patching, and Endpoint Security and Device Hardening evidence (Intune, Defender, or equivalent).
• Workloads where CUI lives or passes: SharePoint sites, Teams, OneDrive, Exchange mailboxes, plus any third-party apps connected to those stores.
• Protection and monitoring controls: Microsoft Purview labels/DLP, Defender signals, Unified Audit Log, alerting, and retention settings. Microsoft also maintains a helpful starting point at Microsoft’s CMMC offering documentation, which I use when I’m documenting what Microsoft provides versus what we must configure and operate.

And here’s the trap: in an enclave-in-one-tenant model, your “boundary” is enforced by configuration. If you can’t reliably prevent non-enclave users or unmanaged devices from touching CUI locations, the assessor won’t treat it like a real enclave. That’s where Secure Cloud Architecture decisions (identity, device trust, session controls, and data controls) matter more than the org chart.

This scoping discipline applies even when I’m doing Small Business IT outside defense work. I might keep Restaurant POS Support and Kitchen Technology Solutions separate from a back-office tenant because those systems don’t need to see CUI. The same principle holds: reduce scope, reduce evidence, reduce risk. That’s IT Strategy for SMBs in action, whether the environment is a shop floor or a SCIF-adjacent program office.

A plain-English decision tree: CMMC Level 2 enclave vs separate tenant

When I’m advising as a Business Technology Partner, I keep this decision simple: pick the option you can prove, not the option you prefer.

Plain-English decision tree (walkthrough):

Start with one question: Will CUI be created, stored, or shared in Microsoft 365? If no, your Microsoft 365 tenant might be out-of-scope (but verify connected systems and access paths). If yes, keep going.

Next: Do you need to isolate CUI users from non-CUI staff? If everyone is a CUI user, a single-tenant approach can work, but you still need strong Cybersecurity Services controls.

If you must isolate: Can you truly segregate identities, devices, and data inside the tenant? That means separate security groups, scoped Conditional Access, restricted SharePoint/Teams locations, Intune-compliant devices only, and blocking unmanaged access. If you can’t enforce it, don’t call it an enclave.

Then ask: Do multiple contracts or programs require hard separation? If contract language, customer expectations, or risk tolerance demand a clean boundary, a separate tenant is usually the safer story.

Finally: Can you afford duplicate licensing and admin overhead? If yes, separate tenant wins on clarity. If no, an enclave can still pass, but only with tight configuration and clean evidence.

Summarized bullet version:

• Choose an enclave (same tenant) when you can enforce group-based isolation, device compliance, and data controls, and you can document it cleanly.
• Choose a separate tenant when you need a hard boundary, can’t trust current device/user separation, or have program-driven separation requirements.

If you want a solid scoping perspective before you design controls, I like the practical framing in CyberSheath’s CMMC scoping write-up and the Microsoft 365 viewpoint in this M365 and Azure scoping article. I don’t use either as an authority, but they help teams think like assessors.

Cost comparison in 2026: enclave vs separate tenant (what really drives spend)

Cost isn’t just licenses. It’s duplicated controls, admin time, and the grind of evidence collection. In 2026, licensing also matters because Microsoft has announced commercial Microsoft 365 E5 moving to $60/user/month starting July 1, 2026, and government pricing varies and can change by program and agreement. Your exact mix (GCC, GCC High, add-ons) should be validated with your reseller and your assessor scoping plan.

Here’s how I estimate the big buckets:

Cost bucket	Enclave in existing tenant	Separate tenant for CUI
Licensing	Lower incremental cost if you can scope premium features to enclave users	Higher cost due to duplicate baseline licenses for CUI users, and sometimes extra admin accounts
Duplicated tooling	Often shared SIEM, backup, ticketing (if allowed by scope)	More duplication (separate logging pipelines, backup targets, monitoring rules)
Admin time	Moderate, heavy upfront design for Conditional Access, Intune, Purview	Higher ongoing, two tenants means twice the policy lifecycle
Migration effort	Low to moderate (move CUI into controlled sites, fix sharing)	Moderate to high (tenant-to-tenant moves for mail, files, Teams)
Ongoing evidence	Medium, evidence must prove segmentation inside one tenant	Medium to high, evidence is clearer but comes from two admin planes

Typical planning ranges I use (non-binding):

• Initial build and hardening: 40 to 120 hours for an enclave, 80 to 200 hours for a separate tenant, depending on identity cleanup and device readiness.
• Office 365 Migration effort: moving CUI workspaces inside one tenant might be days, a tenant split is often weeks once you include Teams, mail, permissions, and user change management.
• Ongoing compliance ops: 5 to 15 hours/month for enclave evidence and access reviews, 10 to 25 hours/month for a separate tenant (two sets of access reviews, exceptions, policy drift checks).

Key drivers that swing the outcome: how messy identity is today, whether endpoints are already Intune-managed, whether you need Infrastructure Optimization on networks and VPNs, and how serious you are about Business Continuity & Security (immutable backups, tested recovery, and incident drills). This is also where Cloud Management maturity shows up fast, because a separate tenant is two production environments to run.

Minimum viable evidence package (what I hand an assessor first)

When I’m packaging evidence, I want an assessor to see the boundary, see the settings, and trace controls to operation. My minimum set looks like this:

• SSP excerpts: boundary statement, in-scope asset inventory, roles, and how each NIST SP 800-171 control is met for the enclave or tenant.
• Network and data-flow diagrams: how CUI enters, where it’s stored (SharePoint/Teams/OneDrive/Exchange), how it leaves, and what blocks exfiltration.
• Tenant settings exports: org-wide sharing settings, external collaboration, guest restrictions, and identity protection settings (exported reports or screenshots with dates).
• Conditional Access policy list: policy names, target groups, grant controls (MFA, compliant device), session controls, and exclusions (with justification).
• Intune compliance policies: compliance rules, configuration baselines, encryption requirements, update rings, and proof of device compliance rates.
• Purview evidence: label policy configuration, DLP policies, sensitive info types used, and screenshots/exports showing policy scope (who and where).
• Audit and log retention: Unified Audit Log settings, retention windows, SIEM forwarding proof (if used), and admin activity monitoring.
• Incident response and access reviews: IR plan, last tabletop or incident record, privileged access review records, and periodic user access recertifications.

I also include proof that Endpoint Security and vulnerability management are operating, not just configured. That’s where Innovative IT Solutions stop being a pitch and start being an audit pass.

Disclaimer: This is operational guidance, not legal advice. For final scoping decisions and assessment readiness, I recommend validating your boundary and evidence plan with a qualified RPO and your intended C3PAO.

Closing thought

A CMMC Level 2 enclave can be the right move, but only if you can prove the boundary with settings, logs, and repeatable process. A separate tenant costs more, yet it often buys you clarity and fewer arguments on assessment day. If you want help choosing the path and building the evidence binder, I treat it as Technology Consulting with one goal: make your scope smaller, your controls tighter, and your Tailored Technology Services easier to defend.