CMMC Scoping: Identifying CUI Boundaries in a Microsoft 365 Tenant

The first decision in any CMMC Level 2 engagement is also the most consequential: where the Controlled Unclassified Information (CUI) boundary sits. Get it wrong on the optimistic side and the assessor will redraw it, expanding scope mid-engagement. Get it wrong on the pessimistic side and the organization spends remediation budget hardening systems that never needed to be in scope. Inside a Microsoft 365 tenant the question is rarely “is M365 in scope” — it is “which workloads, identities, and devices are in scope, and where is the boundary drawn on a tenant where almost every user touches almost every workload.”

The scoping categories CMMC uses

The CMMC final rule at 32 CFR Part 170 and the published Level 2 Scoping Guide place every asset on a CMMC assessment into one of five categories. The category an asset lands in determines whether it is assessed against all 110 practices, a reduced set, or only against asset-management practices.

CUI Assets. Systems that process, store, or transmit CUI. Fully in scope; assessed against all 110 NIST 800-171 r2 practices.
Security Protection Assets (SPA). Systems that provide security functions or capabilities to the CUI environment. Examples: identity providers, SIEM, MDM/Intune, vulnerability scanners. Assessed against the 110, but the assessor focuses on whether the SPA is actually performing its security function correctly.
Contractor Risk Managed Assets (CRMA). Systems that are capable of processing CUI but are not intended to and where the contractor’s risk-based decision and policy keeps CUI off them. Documented in the SSP and managed by policy; not assessed against the 110, but the assessor can verify they remain CUI-free in practice.
Specialized Assets. Includes government property, IoT/OT devices, restricted information systems, test equipment. Documented, managed by policy, not formally assessed but subject to risk-based protections.
Out-of-Scope Assets. Systems that cannot process CUI and are logically and/or physically separated from the CUI environment. Not assessed.

The category that swallows most M365 tenants whole is CUI Assets, because by default Exchange Online, SharePoint Online, OneDrive, and Teams are shared services that any licensed user can write into. Without explicit boundary controls, the entire tenant becomes a CUI Asset.

Why a “soft” M365 boundary fails at assessment

A common pattern at first engagement: “CUI only lives in this one SharePoint site; the rest of the tenant is out of scope.” This rarely holds up under examination. The questions an assessor will ask:

What technical control prevents a user from copying a CUI file out of that SharePoint site into their OneDrive, a personal email, or a Teams chat?
What technical control prevents an external recipient from receiving a CUI attachment via Exchange Online?
What technical control prevents an unmanaged device from authenticating to that SharePoint site?
Where are the audit logs that demonstrate those controls are enforced and reviewed?

If the answer to any of these is “policy says they won’t,” the boundary is undefended. Policy is not a technical control. The assessor will either expand the boundary to include the broader tenant or score the relevant practices NOT MET.

Three ways to draw a defensible boundary

Option 1: Move CUI to a separate tenant

The cleanest boundary. A separate Microsoft 365 GCC High tenant for CUI workloads, with commercial M365 retained for non-CUI business operations. Identity is separated (separate Entra ID), data is separated (separate Exchange/SharePoint/OneDrive), and the assessor’s job is structurally easier. The cost is operational: two tenants to administer, federation or sync if any cross-tenant collaboration is needed, and licensing implications. We cover the decision logic in Migrating to Microsoft GCC High: A Practical Decision Framework.

Option 2: Logically segment within one tenant

A single tenant with CUI handling restricted to specific SharePoint sites, Teams, and Exchange-resident mail flows. Defensible only when the segmentation is enforced by technical controls:

Sensitivity labels via Microsoft Purview applied to CUI content with encryption and export restrictions.
SharePoint site sensitivity restricting site access to a security group of authorized users.
Conditional Access policies enforcing compliant device, MFA, and named-location requirements on those CUI-handling apps.
DLP policies blocking egress of labeled CUI content to external recipients or untrusted endpoints.
Audit retention sufficient to support assessor review of historical access events.

This is workable for organizations with mature labeling discipline and tight Conditional Access design. It is also the configuration most prone to silent drift, where a Conditional Access exclusion or a labeling gap re-expands the boundary unnoticed.

Option 3: Treat the whole tenant as CUI

Sometimes the simpler answer. If CUI handling pervades the business (every contract has CUI, every team touches it, every device needs access) drawing a boundary inside the tenant adds operational complexity without materially reducing scope. Treating the entire tenant as a CUI Asset and hardening every workload uniformly can be more sustainable, particularly for smaller contractors with fewer than 100 users.

Assets that are often miscategorized

A few categories that consistently surface in scoping conversations:

Entra ID and the identity stack. Almost always a Security Protection Asset for any tenant with CUI workloads. Conditional Access, MFA enforcement, and Privileged Identity Management are SPAs by function. They are in scope and assessed.
Intune. A Security Protection Asset when used to enforce compliance baselines on CUI-accessing devices. The compliance policies themselves are evidence.
Microsoft Defender (Endpoint, Identity, Office). Security Protection Asset. Its alerts and audit trail are evidence for several SI- and AU-family practices.
Microsoft Purview. Security Protection Asset when used for CUI classification and DLP. See Microsoft Purview for CUI Data Classification and DLP.
Power Platform and shadow apps. Frequently overlooked. A Power Automate flow that reads a CUI-labeled mailbox makes the connected services CUI Assets. Block third-party connectors in CUI environments unless explicitly approved.
Personal devices (BYOD). The hardest category. A BYOD device that accesses CUI is a CUI Asset and must meet the same control requirements. Practically, this means BYOD is either explicitly disallowed for CUI workloads (Conditional Access compliant-device requirement) or fully enrolled in Intune as a managed work profile.

Documenting the boundary in the SSP

The boundary lives in the System Security Plan. The SSP should include a logical network diagram showing CUI flows, a tenant configuration overview noting which Microsoft 365 services are in scope, a list of CUI Assets and SPAs with their roles, and a CRMA list with the risk-based controls that keep them CUI-free. The diagram is the artifact most assessors ask for first; it is also where most pre-assessment work products are weakest. We discuss the SSP structure in Authoring a System Security Plan (SSP) for NIST 800-171.

The same boundary diagram is also what justifies the related NIST 800-171 mapping work in NIST 800-171 to CMMC Level 2: How the 110 Controls Map Together. The controls only mean something against a defined scope.

What to do next

List every information system, application, and device category in the organization. For each, answer: does it process, store, or transmit CUI today.
For each system that does, identify the technical control that keeps the CUI inside it. Where the answer is “policy,” the system is currently undefended.
Draw a one-page logical boundary diagram. Walk it with an engineer who has not seen it; if they can ask a question about a flow you have not labeled, the diagram is incomplete.
Run the GCC High decision conversation before the boundary work hardens. A separate-tenant decision changes the engineering work significantly.