CMMC Scoping Guide: Asset Categories, Enclaves and Service Providers Done Right

In a CMMC Level 2 assessment, scope decides cost: every asset placed in the wrong category either adds assessment effort or hides a gap the assessor will find. The CMMC Program rule, 32 CFR Part 170, defines five asset categories for Level 2, sets out how each is documented and assessed, and treats external service providers and cloud service providers differently depending on what data they handle. This guide explains those categories, how to build a CUI enclave that keeps most of the business out of scope, how to handle managed service providers and cloud platforms, and where identity systems and service accounts sit. It is for compliance leads, IT managers and MSPs in the defence industrial base. For the requirements and the programme overview, see the NIST SP 800-171 and CMMC 2.0 Guide; this page goes deeper on scope.

Key takeaways

• Five Level 2 categories, five treatments. CUI Assets and Security Protection Assets are assessed; Contractor Risk Managed Assets and Specialized Assets are reviewed through the SSP; Out-of-Scope Assets are not assessed but must be justified.
• Security protection assets come with the data they protect. Identity providers, SIEM, EDR consoles, vulnerability scanners and password vaults that serve the CUI environment are in scope even if they never hold CUI.
• An enclave shrinks scope only if separation is real. Out-of-scope status requires that an asset cannot process, store or transmit CUI, for example through physical or logical separation; shared admin accounts and credentials break that quickly.
• Service providers follow the data. An ESP that handles CUI or Security Protection Data is in scope; a cloud provider handling CUI must meet FedRAMP Moderate or an equivalent under DoD policy.
• Check the programme status. The DoD CIO states that Phase 1 began on 10 November 2025 and that Phase 2 requirements, originally scheduled for 10 November 2026, were suspended on 13 July 2026 (checked 27 October 2026). DFARS 252.204-7012 obligations still apply.

How CMMC defines scope

The rule defines the CMMC Assessment Scope as the set of all assets in the organisation seeking assessment (OSA) environment that will be assessed against CMMC security requirements. Section 170.19 then sets the rules per level.

• Level 1: information systems that process, store or transmit Federal Contract Information (FCI) are in scope and self-assessed. Specialized Assets are excluded, there is no Contractor Risk Managed Asset category, and out-of-scope assets need no documentation. OSAs should consider the people, technology, facilities and ESPs that handle FCI.
• Level 2: five asset categories (below) for environments handling Controlled Unclassified Information (CUI), assessed against the 110 requirements of NIST SP 800-171 Revision 2, either by self-assessment or by a Certified Third-Party Assessment Organization (C3PAO).
• Level 3: the scope must be equal to or a subset of the Level 2 scope. The rule gives the example of "a Level 3 data enclave with greater restrictions and protections within a Level 2 data enclave". At Level 3, Contractor Risk Managed Assets are treated as CUI Assets and Specialized Assets are assessed. See the NIST SP 800-172 Rev 3 Guide.

The five Level 2 asset categories

The rule adds that an asset in any in-scope category cannot also be out of scope, and gives one specific example: an endpoint hosting a Virtual Desktop Infrastructure (VDI) client is out of scope if it is configured so that nothing beyond keyboard, video and mouse input and output reaches the client.

Choosing between CRMA and out of scope

• CRMA suits corporate laptops that could technically open CUI but are prevented by policy, training, DLP or labelling. It is cheaper than full assessment, but the assessor can perform a limited check, and policy failures found there become findings.
• Out of scope needs a technical reason the asset cannot handle CUI. If you cannot explain the barrier in one sentence (no network path, no credentials, VDI with clipboard and file transfer disabled), it is probably CRMA.
• Small organisations often find a single well-defined enclave plus CRMA for everything else simpler than arguing out-of-scope status for many assets.

Security Protection Assets and Security Protection Data

The rule defines Security Protection Data (SPD) as data stored or processed by Security Protection Assets that are used to protect the assessed environment, including configuration data, logs, vulnerability status data and passwords that grant access to the in-scope environment. That definition drives most of the identity scope decisions.

The practical consequence: a shared corporate identity platform or SIEM brings its admin plane into scope for the requirements relevant to what it does. Many organisations therefore give the enclave its own tenant or a dedicated, separately administered instance of these services.

Where identity and NHIs sit in scope

Credentials are the most common way an enclave boundary is quietly crossed. Plan these explicitly in the SSP.

• Admin accounts: enclave administrators should use dedicated accounts that cannot sign in to out-of-scope systems, with MFA (32 CFR 170.24 deducts 3 or 5 points for IA.L2-3.5.3 gaps). See the Privileged Access Management Guide.
• Service accounts and API keys: any account that can read enclave data or change enclave systems, including backup, monitoring, scanning, CI/CD and integration accounts, is part of the in-scope identity population. Record owner, purpose and rotation for each. See the Service Account Security Guide.
• Credentials held outside the enclave: a password for an enclave account stored in a corporate password manager makes that password manager hold SPD. Either bring it into scope or use a separate vault.
• MSP access: remote monitoring and management agents and the MSP's own admin accounts are paths into the enclave; treat them under the ESP rules below. See the GDAP and MSP Delegated Admin Access Guide.
• Device identity: enclave endpoints should be uniquely identified and authenticated before connecting (device certificates or managed device compliance), which also supports the VDI out-of-scope argument.

The wider identity picture for defence contractors is covered in the Defence Industrial Base Identity Security Guide.

Enclave patterns

See the Virtual Desktop (VDI) and DaaS Security Guide for hardening VDI so that the out-of-scope argument holds.

External service providers and cloud service providers

The rule treats an ESP as in scope only if CUI or Security Protection Data is processed, stored or transmitted on its assets. The table follows tables 4 and 6 of section 170.19.

• Documentation: the use of the ESP, its relationship to the OSA and the services provided must be documented in the SSP and described in the ESP's service description and customer responsibility matrix (CRM).
• Connecting infrastructure: for both CSPs and other ESPs, the OSA's on-premises infrastructure that connects to the provider is in scope, and the CRM requirements must be documented in or referenced from the SSP.
• Voluntary ESP certification: an ESP may obtain its own CMMC certification to reduce the effort in its customers' assessments.
• DFARS cloud clause: 252.204-7012 (b)(2)(ii)(D) also requires the contractor to ensure the cloud provider complies with the clause's incident reporting, malicious software, media preservation, forensic access and damage assessment paragraphs.
• Read the CRM line by line: every requirement marked "customer" or "shared" is yours to implement and evidence. See the FedRAMP Guide and the Cybersecurity for MSPs and MSSPs Guide.

Building and proving the scope

1. Find the CUI: identify contracts with CUI, the CUI categories and markings, and where CUI arrives (email, portals, file shares, removable media). See the CUI Guide.
2. Map flows: trace CUI from arrival through processing, storage, backup and disposal, including people and facilities.
3. Choose the enclave pattern: decide what will be CUI Assets and what can be CRMA or out of scope, before buying anything.
4. Classify every asset: build the asset inventory with a category, owner and justification column; include SPAs, Specialized Assets and ESP services.
5. Trace credentials and management paths: list every account, agent and console that can reach CUI Assets, and either bring its source into scope or remove the path.
6. Draw the scope diagram: show the boundary, SPAs, ESP connections and data flows. Assessors use it to test your story.
7. Write the SSP treatment: for each category, describe how it is protected, with CRMA policies and Specialized Asset risk treatment explicit. An up-to-date SSP is mandatory; without it the assessment cannot be completed.
8. Test separation: attempt to reach enclave systems and data from out-of-scope networks and accounts; try file transfer, clipboard and printing from VDI sessions; record results.
9. Self-assess and remediate: score against the requirements using 32 CFR 170.24, close gaps, and remember the POA&M limits in 170.21 (minimum score ratio of 0.8, only certain 1-point items, closeout within 180 days).
10. Maintain: rerun classification on every change to network, identity platform, ESP contracts or CUI flows, and before each annual affirmation.

Detection and metrics

• Boundary monitoring: alert on new network paths, peering, VPN or remote access into the enclave, and on sign-ins to enclave systems from non-enclave devices or accounts.
• Data monitoring: DLP or labelling alerts for CUI markings found on CRMA or out-of-scope systems; each one is a scoping incident.
• Metric: classification coverage, share of discovered assets with a category and justification.
• Metric: credential containment, number of accounts with rights both inside and outside the enclave (target near zero outside named SPAs).
• Metric: CUI spill rate, CUI found outside the enclave per quarter.
• Metric: CRM coverage, share of customer-responsibility items for each ESP with an owner and evidence.

Framework mapping

Common failure patterns

• Logical separation in name only: an enclave VLAN or tenant administered by the same accounts that administer everything else, so the corporate admin plane is effectively in scope.
• Forgotten SPAs: SIEM, EDR, backup, scanning and password vaults left off the inventory, then found during interviews.
• VDI that leaks: endpoints declared out of scope while clipboard, drive mapping, printing or file transfer remain enabled.
• CRMA without evidence: laptops declared CRMA with no policy, training or technical control that actually keeps CUI off them.
• Unread CRMs: cloud or MSP responsibility matrices never mapped to owners, leaving shared requirements unimplemented.
• Scope frozen at assessment: new integrations, AI tools or file-sharing services added to the enclave without reclassification.

Practitioner checklist

• Confirm which contracts require CMMC and at what level, and check the DoD CIO page for current phase status.
• Map CUI flows and choose an enclave pattern before procurement.
• Classify every asset into one of the five categories with a written justification.
• List all Security Protection Assets, including identity, vault, SIEM, EDR, scanning and backup services.
• Give enclave administrators and service accounts dedicated identities with MFA and recorded owners.
• For each ESP and CSP, record what it handles, its FedRAMP or assessment status, and map its CRM to owners.
• Test the boundary from out-of-scope networks and accounts, including VDI data transfer paths.
• Keep the SSP, inventory and scope diagram consistent and update them on every significant change.

Standards and references

• eCFR: 32 CFR 170.19, CMMC Scoping
• eCFR: 32 CFR 170.16, CMMC Level 2 Self-Assessment and Affirmation
• eCFR: 32 CFR 170.4, Acronyms and Definitions
• eCFR: 32 CFR 170.21, Plan of Action and Milestones Requirements
• Acquisition.gov: DFARS 252.204-7012 Safeguarding Covered Defense Information and Cyber Incident Reporting
• DoD CIO: About CMMC
• NIST: SP 800-171 Rev. 3

Related NHI Mgmt Group resources: NIST SP 800-171 and CMMC 2.0 Guide · CMMC 2.0 Level 2 Assessment Guide · NIST SP 800-171A Rev 3 Assessment Guide · System Security Plan Template and Guide · Defence Industrial Base Identity Security Guide. This guide summarises the CMMC scoping rules in 32 CFR Part 170 and is not legal advice.