Out-of-scope is an architectural conclusion, not a label an organization can apply to reduce assessment effort. Under the Level 2 Scoping Guide, the asset must be unable to process, store, or transmit CUI, must not provide security protection for CUI Assets, and must be physically or logically separated from CUI assets. If it falls into an in-scope category, it cannot simply be renamed out of scope.
The rule also contains a specific virtual-desktop example that is unusually useful for small contractors. An endpoint hosting a VDI client can be considered out of scope when it is configured so no CUI processing, storage, or transmission occurs beyond the keyboard, video, and mouse interaction sent to the VDI client. That wording makes endpoint configuration and redirection controls central to the boundary decision.
VDI is the clearest example of why implementation details matter. The scoping guide identifies a VDI endpoint configured so that no CUI is processed, stored, or transmitted beyond keyboard/video/mouse interaction as out of scope; a client that permits downloads, clipboard transfer, local printing, redirected drives, or other CUI handling needs a different analysis.
The strongest boundary case is one that can be demonstrated from both sides: what the endpoint is allowed to do, and what it is technically prevented from doing.
Start with capability, not user intention
A device does not become out of scope merely because the employee has been told not to download CUI. If the device can open the CUI file share, sync the covered mailbox, mount the approved cloud repository, or receive CUI attachments, the technical capability may put it into an in-scope category. Policy can support a CRMA treatment, but out-of-scope treatment requires the stronger conditions described by the scoping rule.
Inventory the paths a user could take, not only the approved happy path. Check browser downloads, clipboard, local drive mapping, print redirection, USB redirection, offline synchronization, email clients, screenshots, remote-support tools, and file-transfer functions. The boundary is defined by what the architecture permits as well as by what the process intends.
Security Protection Assets are another common trap. A logging server, identity service, firewall, or management platform may never store the engineering drawing, yet it can provide security functions to the CMMC Assessment Scope. That role can make it in scope as a Security Protection Asset rather than out of scope.
Use physical or logical separation that can be tested
Logical separation should produce a clear enforcement point. Examples include identity groups that cannot authenticate to the CUI tenant, network controls that cannot route to the enclave, application policies that deny access to the CUI repository, or a separate managed environment with no cross-tenant synchronization. The design should not depend on an employee remembering which browser tab is safe.
Physical separation can be useful for labs or dedicated work areas, but it still needs a data-transfer rule. A disconnected workstation can become part of the CUI path the moment an approved USB drive transfers files onto it. Document how information moves across the boundary and which media or transfer stations are authorized.
Test the separation periodically. Attempt access using a normal out-of-scope account and device, confirm the connection is denied, and retain the result. After identity, firewall, or collaboration changes, repeat the test. Configuration drift is a more realistic threat to a narrow boundary than the original network diagram.
Understand the VDI keyboard/video/mouse condition
The Level 2 scoping table says an endpoint hosting a VDI client is considered out of scope when configured so it does not process, store, or transmit CUI beyond the Keyboard/Video/Mouse information sent to the VDI client. That condition is narrower than simply saying 'we use VDI.' The client configuration has to prevent local CUI handling outside the remote session boundary.
Review redirection features one by one. Local drive mapping, clipboard transfer, local printing, USB redirection, browser download, file synchronization, camera capture, and copy/paste functions can create a path for CUI to leave the hosted environment. If the design relies on the endpoint being out of scope, the VDI policy should explicitly control those features and the technical configuration should match the policy.
Also examine authentication and endpoint security assumptions. Even an out-of-scope VDI endpoint can be operationally important because stolen credentials or malware can target the remote session. Out-of-scope classification is an assessment-boundary decision, not a statement that the device needs no security. Maintain sensible endpoint protection consistent with business risk.
Keep out-of-scope services from becoming hidden security dependencies
A corporate identity provider, DNS service, device-management platform, SIEM, EDR console, or network appliance may affect the CUI environment even when the service does not directly handle CUI. Determine whether it provides a security function or capability to the assessment scope. If it does, analyze Security Protection Asset or external service provider treatment instead of assuming no CUI equals no scope.
This is especially important in cloud environments where the CUI workload may be isolated but administration still depends on a company-wide identity tenant. If an administrator from the general corporate tenant can change access to the enclave, the shared identity path is security-relevant. The architecture diagram should make that dependency visible.
Use a dependency review whenever a team proposes a new tool. Ask whether it can administer, authenticate, log, scan, back up, route, or remotely support an in-scope system. A service can cross the boundary through security function long before anyone uploads CUI to it.
Document the boundary, then attack your own assumptions
Out-of-scope assets do not need the same detailed control narratives as CUI Assets, but the organization should be ready to justify why the asset cannot process, store, or transmit CUI or why the separation is effective. Keep a boundary register with asset class, reason for exclusion, separation mechanism, dependency check, and last validation date.
For large classes of identical corporate endpoints, document the control pattern rather than writing hundreds of unique narratives. Link the pattern to the identity policy, firewall rule, VDI configuration, or tenant restriction that enforces the condition. Sample devices during review to verify the pattern is actually applied.
Make the network diagram readable enough that someone outside IT can distinguish the CUI zone, the out-of-scope corporate environment, shared services, and controlled transfer points. If every component is connected by undifferentiated arrows, the diagram does not support the claim.
Narrow environments often expand through small convenience decisions: enable clipboard for a user, permit local printing, add a shared mailbox to a normal laptop, let finance reach the engineering repository, or install an enterprise backup agent across every tenant. Each choice can change the technical boundary even if the official scope document remains untouched.
Create a short architecture-change question in the IT ticket process: does this change create a new path to process, store, transmit, administer, or protect CUI? A yes answer triggers a scoping review before the change is approved. This embeds CMMC scope maintenance in normal operations instead of relying on an annual compliance cleanup.
A good out-of-scope design is intentionally boring. Users know which environment is for CUI, transfer paths are constrained, security dependencies are visible, and the team can demonstrate the separation without explaining a long list of informal exceptions. That simplicity is the real value of narrowing scope.
- Try a local download from the VDI session
- Try clipboard and drive redirection
- Check local print and screen-capture behavior where relevant
- Trace DNS, authentication, logging, and security-tool dependencies
- Repeat the test after client or policy upgrades
Before you call the boundary done
- ✓Confirm the excluded asset cannot process, store, or transmit CUI
- ✓Check whether it provides a security function to the CUI environment
- ✓Test physical or logical separation
- ✓For VDI, disable local paths that would move CUI beyond KVM interaction
- ✓Document the exclusion rationale and validation date
- ✓Review scope after identity, network, printing, clipboard, or sync changes
Common questions
Can a device be out of scope just because policy says users must not put CUI on it?
Not by policy alone. The Level 2 out-of-scope definition relies on inability to process, store, or transmit CUI and on appropriate separation; a policy-only case may instead raise CRMA questions.
Does using VDI automatically make the local endpoint out of scope?
No. The scoping rule's example depends on configuration that prevents CUI processing, storage, or transmission outside the keyboard/video/mouse interaction with the VDI client.
Can a system with no CUI still be in scope?
Yes. A system that provides security functions or capabilities to CUI Assets can be a Security Protection Asset even if it does not itself store CUI.
Can a DNS, identity, or monitoring system be in scope even if it never stores CUI files?
Yes. An asset can be in scope because it provides security protection for CUI Assets. Scoping should consider the security function the service provides, not only whether a CUI document is stored on it.
Official sources used for this guide
Open the primary source before making a contract-specific decision. Regulations and program implementation can change.