One of the questions I hear most frequently from organizations beginning their CMMC journey is whether they should build a CMMC Level 2 enclave or create a completely separate Microsoft 365 tenant. It’s a good question, but I often think it’s the wrong one to ask first. Before discussing architecture, licensing, or technology, organizations should first understand what each approach is trying to achieve. The real decision isn’t about which design is technically better. It’s about understanding the business problem you’re trying to solve.

Too often, conversations jump immediately to GCC High, Microsoft 365 licensing, identity architecture, or migration projects. Those are all important discussions, but they come much later. Whether you’re pursuing CMMC Level 2, protecting Controlled Unclassified Information (CUI), or simply trying to improve your overall security posture, understanding the purpose behind an enclave or a separate tenant is far more valuable than understanding the technical implementation.

Start with the Assessment Boundary

One of the most important concepts to understand is that CMMC does not prescribe a particular architecture. It doesn’t require every organization to build an enclave, nor does it require a separate Microsoft 365 tenant. Instead, the Department of Defense focuses on something much more fundamental: the scope of assessment.

The official CMMC Level 2 Scoping Guide explains how organizations identify the people, technology, facilities, and assets that fall within their CMMC assessment boundary. That boundary is determined by where CUI is stored, processed, or transmitted, as well as the assets that directly support those activities. Once that scope has been defined, the organization is responsible for demonstrating that the required security controls have been implemented within that boundary.

This distinction is important because many discussions about enclaves and separate tenants begin with architecture. In reality, architecture is simply one way of supporting a well-defined assessment boundary. The assessment boundary comes first; the technical design follows.

Understanding a CMMC Enclave

At its core, a CMMC enclave is a defined assessment boundary within an organization’s existing environment, intended to limit where CUI is stored, processed, or transmitted. Rather than bringing the entire enterprise into scope for a CMMC Level 2 assessment, an organization can establish a smaller, clearly defined environment where sensitive work takes place.

The primary objective is to reduce assessment scope. By limiting the number of systems, users, and supporting assets that interact with CUI, organizations can reduce the size of the environment that must demonstrate compliance with the applicable CMMC practices. That doesn’t necessarily make compliance easy, but it can make it significantly more manageable than attempting to include an entire enterprise that has little or no interaction with CUI.

It’s important to recognize that an enclave is not simply a collection of technical controls. It’s a business decision about where sensitive information belongs and who genuinely needs access to it. Once those decisions have been made, the technology is used to enforce those boundaries.

Understanding a Separate Microsoft 365 Tenant

A separate Microsoft 365 tenant approaches the problem from a different direction. Rather than defining a smaller assessment boundary within an existing environment, it creates an entirely separate cloud environment with its own identities, administration, workloads, security policies, and operational boundaries.

Organizations often consider this approach when they have distinct business operations, such as commercial and government contracting, or when contractual obligations, operational requirements, or long-term strategy justify maintaining complete separation between different parts of the business.

It’s important not to think of an enclave and a separate tenant as competing solutions. An enclave is commonly used to reduce the assessment scope around CUI, while a separate tenant is an architectural decision that may also provide organizational and administrative separation. In some cases, the two concepts overlap. In others, they solve entirely different business problems.

Microsoft’s Perspective

Microsoft addresses this question directly in its CMMC guidance under the heading “Should I build a data enclave or should I go all in?” Rather than recommending a single architecture, Microsoft presents the tradeoffs organizations should consider.

For some organizations, a data enclave can reduce costs by limiting the number of users and workloads that require migration into Microsoft 365 GCC High. At the same time, Microsoft cautions that organizations need to think carefully about where information flows outside that enclave. Email, file sharing, collaboration platforms, and personal storage locations can all affect the assessment boundary if they allow CUI to move beyond the intended environment.

That balanced approach reflects the reality facing most organizations. There is rarely a single correct answer. The right decision depends on the organization’s business model, contractual obligations, operational complexity, existing investments, and long-term strategy.

CMMC Doesn’t Require an Enclave

This is one of the biggest misconceptions I encounter. Many organizations assume that achieving CMMC Level 2 automatically means building an enclave or deploying a separate Microsoft 365 tenant. The official guidance doesn’t say that.

The Department of Defense requires organizations to clearly define their CMMC assessment scope and demonstrate that the applicable security requirements have been implemented within that scope.

For some organizations, that assessment boundary may include the entire enterprise. For others, it may consist of a dedicated business unit, an enclave within an existing environment, or another well-defined area for handling CUI. The architecture itself is not the requirement. The requirement is to protect CUI within a clearly defined assessment scope.

What Actually Belongs Inside a CMMC Enclave?

Once organizations understand that an enclave is really about defining an assessment boundary, the next question naturally becomes, “What actually belongs inside it?”

The answer is surprisingly straightforward. Anything that stores, processes, or transmits Controlled Unclassified Information (CUI), along with the people and supporting systems required to perform that work, should be considered when defining the enclave. The emphasis is not on placing as much as possible inside the boundary, but rather on ensuring that everything necessary to securely handle CUI is included while avoiding unnecessary expansion of the assessment scope.

That doesn’t mean every employee, every application, or every server suddenly becomes part of the enclave. If a department has no interaction with CUI, there may be little reason for it to fall within the assessment boundary. Likewise, users who never need access to CUI generally don’t need to be included simply because they work for the same organization.

This is one of the reasons the official CMMC Level 2 Scoping Guide categorizes assets based on their relationship to CUI and the assessment boundary. Rather than viewing the environment as a single collection of systems, the guidance encourages organizations to identify which assets directly handle CUI, which support those systems, and which fall completely outside the assessment scope. That structured approach allows organizations to make informed decisions about what should, and just as importantly, should not, become part of the enclave.

Ultimately, the objective isn’t to build the smallest enclave possible. The objective is to build the correct enclave. A boundary that is too large increases cost, operational complexity, and assessment effort. A boundary that is too small may fail to include systems that genuinely support the handling of CUI. Finding the right balance is one of the most important architectural decisions an organization will make during its CMMC journey.

When Does a Separate GCC High Tenant Make Sense?

One question that often follows is whether an organization should move directly to a separate Microsoft 365 GCC High tenant or build an enclave within its existing environment.

There isn’t a universal answer because this decision is driven far more by business requirements than by technology. Some organizations have only a relatively small number of users working with CUI, making an enclave an effective way to reduce the assessment scope while allowing the remainder of the business to continue operating in its existing Microsoft 365 environment. For others, particularly those whose primary business centers on Department of Defense contracts, maintaining separate environments may offer a cleaner operational model.

A separate GCC High tenant may also make sense when an organization wants clear separation between commercial and government operations, has contractual obligations that require stronger isolation, or is planning for long-term growth in its defense business. In these situations, maintaining independent identities, administration, collaboration services, and security policies can simplify governance by creating an obvious boundary between different areas of the business.

However, it’s important not to assume that a separate tenant automatically makes an organization more compliant. A separate tenant is simply another architectural approach. It still requires careful planning, governance, identity management, data protection, and operational processes. Likewise, an enclave inside an existing tenant isn’t inherently better or worse. Both approaches can be successful when they are designed around clearly defined business objectives and an accurate understanding of the organization’s CMMC assessment scope.

Rather than asking whether GCC High is always the right answer, organizations should first ask a much simpler question:

“What is the most appropriate architecture for the way our business operates?”

Once that question has been answered, the technology decisions become significantly easier.

Looking Beyond CMMC

This is where I think the conversation becomes much more interesting. The principles behind enclaves have value even if your organization has absolutely no intention of pursuing CMMC certification. Every business has information that deserves a higher level of protection than everything else. Financial information, legal documents, executive communications, intellectual property, customer records, and employee data all carry different levels of business risk.

Many organizations already apply these principles without referring to them as enclaves. Human Resources naturally limits access to personnel files. Finance teams restrict payroll systems. Legal departments protect privileged communications. Research and development teams often work within secure environments separate from day-to-day business operations.

None of those decisions is driven by CMMC. They’re driven by sound governance and an understanding that not all information should be treated the same.

Security Should Follow the Data

In my experience, one of the best ways to think about security is to follow the data rather than the technology.

Organizations often begin by asking how to secure an application or a platform, but the more useful questions are usually much simpler.

• What information are we trying to protect?
• Who genuinely needs access to it?
• Where does it live?
• How does it move?
• What would happen if it were exposed?

Answering those questions naturally leads to better security decisions. Instead of applying the strongest possible controls everywhere, organizations can apply the appropriate controls where they provide the greatest risk reduction.

That way of thinking isn’t unique to CMMC. It’s a principle that aligns with many modern security frameworks, including Zero Trust, in which protecting sensitive information and minimizing unnecessary access are primary design goals.

Reducing Risk Without Increasing Complexity

One unintended consequence of compliance programs is that organizations sometimes believe every security control should be applied equally across the entire business. While that may sound like the safest approach, it often introduces unnecessary complexity without providing meaningful reductions in risk.

A well-defined assessment boundary allows organizations to focus resources where they matter most. Users who never interact with CUI don’t necessarily need to operate under the same restrictions as those who work with sensitive defense information every day. By aligning security controls with business risk, organizations can strengthen security while avoiding unnecessary operational overhead.

That balance between protection and productivity is something every organization should strive for, regardless of whether CMMC is a business requirement.

Final Thoughts

Whether you’re considering a CMMC Level 2 enclave or a completely separate Microsoft 365 tenant, don’t start by asking which architecture is better. Start by asking what you’re trying to achieve.

• Are you trying to reduce the scope of your CMMC assessment?
• Are you separating commercial and government operations?
• Are you protecting Controlled Unclassified Information?
• Are you simplifying administration?
• Are you reducing organizational risk?

Those answers will naturally guide the architectural decisions that follow.

Perhaps the biggest takeaway is this: the concepts behind enclaves are valuable far beyond CMMC. Defining clear security boundaries, reducing unnecessary exposure, limiting access to sensitive information, and aligning security controls with business risk strengthen almost every organization.

CMMC has certainly brought the concept of enclaves into the spotlight, but the underlying principle isn’t unique to defense contractors. Protect the information that matters most, define clear boundaries around it, and apply the appropriate security controls where they have the greatest impact. That’s simply good security.

Official References

Microsoft Learn

Microsoft and the Cybersecurity Maturity Model Certification (CMMC)
Microsoft’s official guidance for organizations evaluating CMMC, including the section “Should I build a data enclave or should I go all in?” and considerations around Microsoft 365 GCC and GCC High.
https://learn.microsoft.com/en-us/compliance/us-government/gov-cmmc

Cybersecurity Maturity Model Certification (CMMC) for Azure
Overview of how Azure services support organizations working toward CMMC requirements.
https://learn.microsoft.com/en-us/azure/compliance/offerings/offering-cmmc

Department of War

CMMC Resources and Documentation
The official repository for CMMC guidance, assessment guides, scoping guides, and supporting documentation.
https://dodcio.defense.gov/CMMC/Resources-Documentation/

CMMC Level 2 Scoping Guide
The definitive guidance on defining the assessment scope, assessment boundary, and asset categorization for a Level 2 assessment.
https://dodcio.defense.gov/Portals/0/Documents/CMMC/ScopingGuideL2v2.pdf

32 CFR Part 170 – Cybersecurity Maturity Model Certification Program
The official regulation that establishes the CMMC Program and its associated assessment requirements.
https://www.ecfr.gov/current/title-32/subtitle-A/chapter-I/subchapter-D/part-170