CMMC Level 2 Practice 3.13.4: Prevent unauthorized and unintended information transfer via shared system resources

CMMC Level 2 Practice 3.13.4 requires you to stop data from “bleeding” between users, sessions, or workloads through shared resources like memory, storage, printers, clipboards, VM hosts, or multi-tenant services. Operationalize it by identifying shared resources in your CUI environment, enforcing isolation and secure clearing, and retaining proof that these protections are configured and tested. ¹

Key takeaways:

• Shared resources are broader than file shares; include memory, VM snapshots, spooling, containers, caches, and SaaS tenant boundaries.
• You need both technical isolation (segmentation, access controls, secure erase) and operational proof (configs, test results, change control).
• Assessors look for repeatable evidence that protections apply to the full CUI boundary and to third-party services in scope.

For a CCO or GRC lead, Practice 3.13.4 is one of those requirements that looks “technical” but fails during assessment for a very non-technical reason: the team can’t clearly describe where shared resources exist in the CUI environment and can’t show consistent evidence that controls prevent unintended transfer. The intent is straightforward. If two users, processes, or systems share an underlying resource, you must prevent one from seeing residual data from the other or moving information through that resource outside of authorization.

This comes up in common places: shared multifunction printers and their spools, shared VDI farms, hypervisors hosting multiple workloads, container platforms, shared jump hosts, shared NAS/SAN storage, shared collaboration tenants, shared clipboard/drive redirection in remote access tools, and even shared “gold images” and snapshots. If your CUI boundary includes third-party hosted systems (cloud, MSP, SaaS), shared resources are still in play; you must ensure tenancy isolation and secure lifecycle handling are contractually and technically addressed.

CMMC Level 2 aligns to NIST SP 800-171 Rev. 2, and you should treat 3.13.4 as a “show me” practice: show the architecture, show the configurations, show the tests, and show the recurring checks. ^{1 2 3}

Regulatory text

Requirement (excerpt/summary): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.13.4 (Prevent unauthorized and unintended information transfer via shared system resources).” ¹

Operator interpretation: You must implement controls so information cannot be transferred (intentionally or accidentally) between users or processes through shared components of the system. This includes:

• Preventing residual data exposure (for example, data left in memory, spools, caches, temp directories, VM snapshots, or shared storage blocks).
• Preventing cross-boundary transfer through shared services (for example, clipboard, shared folders, shared print services, shared admin tools, shared container hosts).
• Ensuring only authorized flows occur, aligned to your access control and system boundary definitions.

Tie your implementation to your CUI scoping decisions under the CMMC program and be prepared to show the assessor where shared resources exist and how they are controlled within that boundary. ^{2 3}

Plain-English interpretation (what this really means)

If two people (or two workloads) touch the same underlying thing, you need guardrails that stop one from getting the other’s data.

Think of “shared system resources” as anything that multiple accounts, sessions, or workloads can touch:

• Compute: RAM, GPU memory, CPU caches, hypervisors, VDI hosts, container nodes
• Storage: SAN/NAS blocks, shared volumes, object buckets, temp folders, swap space
• Peripherals/services: printers and spooling, shared scanners, shared fax services
• Remote access conveniences: clipboard sharing, drive mapping, copy/paste into remote sessions
• Virtualization artifacts: snapshots, golden images, templates, deprovisioned disks

Your job is to reduce the chance that CUI leaks via those mechanisms and to prove it with evidence. ¹

Who it applies to (entity and operational context)

Applies to any organization pursuing CMMC Level 2 for contracts involving CUI, including defense contractors and other federal contractors handling CUI. ^{3 2}

Operationally, it applies to:

• In-scope systems that store, process, or transmit CUI, plus supporting components inside the CUI boundary (identity, logging, management tooling).
• Shared infrastructure used by multiple users or workloads where at least one handles CUI.
• Third parties operating or hosting in-scope systems (MSPs, cloud providers, SaaS providers). You inherit shared-resource risk through their architecture; address it via contracts, configurations, and assurance evidence.

What you actually need to do (step-by-step)

Step 1: Enumerate shared resources inside the CUI boundary

Create a “Shared Resource Register” for the CUI environment. Minimum fields:

• Resource type (hypervisor, VDI pool, print server, NAS, Kubernetes node, SaaS tenant, jump host)
• Location/owner (team, system name, environment)
• Who/what shares it (users, service accounts, workloads, tenants)
• CUI touchpoint (stores/processes/transmits CUI; yes/no; where)
• Existing isolation/clearing controls
• Evidence source (config page, policy, script output)

This register becomes your assessment map for 3.13.4 and reduces missed scope. ¹

Step 2: Classify risk scenarios per resource

For each shared resource, document which failure modes apply:

• Residual data exposure: leftover temp files, RAM, spool, pagefile, disk blocks
• Cross-session bridging: clipboard, shared folders, shared admin consoles
• Cross-tenant leakage (hosted services): tenant isolation, misrouted logs, shared storage keys
• Privilege bleed: admin access in shared environments causing accidental copy or disclosure

Keep this short and operational. The goal is to justify why a given control is needed and where it is enforced. ¹

Step 3: Implement technical protections (design patterns that pass)

Pick controls that fit the resource type. Common patterns assessors recognize:

A. Isolation and segmentation

• Separate CUI workloads from non-CUI on shared compute where feasible.
• Use separate VDI pools, separate host clusters, separate projects/subscriptions/accounts, or dedicated tenants for CUI-impacting services where justified by risk.
• Apply network segmentation and identity-based access to management planes.

B. Secure clearing and lifecycle handling

• Ensure temporary storage, spools, caches, and local working directories are cleared on logout, job completion, session end, or deprovision.
• Require secure wipe/crypto-erase for reallocated storage blocks and decommissioned media aligned to your media sanitization approach.
• Control VM snapshots/templates; treat them as data-bearing artifacts with access control and retention rules.

C. Restrict data movement features in shared admin/remote tools

• Disable or tightly control clipboard sharing, drive redirection, “shared clipboard,” and file transfer features on jump hosts and remote access gateways used for CUI administration.
• Where business needs require them, scope them to authorized roles and log usage.

D. Multi-tenant/SaaS guardrails

• Confirm tenancy model (single-tenant vs multi-tenant), logical separation, encryption boundaries, and admin isolation for any third party in scope.
• Require contract language for isolation, incident notification, and evidence support for assessments.

These are implementation options, not requirements by themselves. Your obligation is the outcome: prevent unauthorized and unintended transfer through shared resources. ^{1 2}

Step 4: Add operational controls that make it repeatable

Assessors look for repeatability more than heroics.

• Configuration baselines: harden images for shared hosts (VDI gold images, jump host templates, container node configs).
• Change control hooks: any change to shared resource configuration triggers a security review item for 3.13.4 impacts.
• Access reviews: shared admin systems get tighter reviews because they are common transfer points.
• Monitoring: log access to shared resources and privileged actions that could enable transfer (print spool admin, hypervisor admin, storage admin).

Step 5: Test the control in a way you can explain

Create a simple, documented test per resource class:

• Printer/spool test: verify jobs are not accessible to other users; confirm spooled files are cleared; verify admin access is restricted.
• VDI/jump host test: verify clipboard/drive redirection settings; verify session cleanup; confirm no CUI remnants persist in user profile temp after logoff (sample-based).
• Virtualization test: verify snapshot access controls; verify deprovisioning includes secure wipe/crypto-erase steps; confirm tenant separation boundaries.
• SaaS test: verify tenant restrictions, DLP rules (if used), and admin role separation; capture configuration screenshots/export.

Keep the test evidence lightweight and repeatable. ¹

Step 6: Map the practice to documented control operation and recurring evidence capture

Write a short control narrative:

• “Shared system resources in scope”
• “How we prevent transfer”
• “How we verify”
• “How often we re-check”
• “Where evidence is stored”

Daydream (or a similar GRC system) helps by turning this narrative into a control record with assigned owners, a recurring evidence request, and an assessor-ready evidence packet tied to 3.13.4. ²

Required evidence and artifacts to retain

Maintain evidence that proves both design and operation:

Core artifacts

• Shared Resource Register (scoped to CUI boundary)
• Network/system diagrams showing shared infrastructure and separation points
• Configuration baselines (GPOs, MDM profiles, VDI policies, hypervisor settings, storage policies)
• Screenshots or exports showing clipboard/drive redirection settings, tenant controls, role-based access settings
• Deprovisioning/sanitization runbooks for shared storage/compute artifacts
• Change tickets showing review/approval for modifications to shared resources
• Test scripts/checklists and results (dated, signed/approved)

Third-party artifacts (if applicable)

• Contracts/SOWs with isolation and evidence cooperation language
• Shared responsibility notes for hosted platforms
• Attestations or configuration exports from the third party supporting tenant isolation and secure lifecycle handling

Common exam/audit questions and hangups

Expect questions like:

• “Show me all shared resources inside the CUI boundary. How do you know you didn’t miss any?”
• “Where could residual CUI persist after a user logs off?”
• “Do admins use a shared jump host? Can it copy files out through clipboard or mapped drives?”
• “How do you control snapshots, templates, and backups that may contain CUI?”
• “If your email/collaboration platform is multi-tenant, what prevents cross-tenant data exposure and how do you validate it?” ¹

Hangups that cause delays:

• The boundary is unclear, so nobody can say whether a shared service is “in scope.”
• Controls exist but are inconsistent across pools, projects, or sites.
• Evidence is scattered across IT teams with no single narrative tying it to 3.13.4. ²

Frequent implementation mistakes (and how to avoid them)

1. Treating 3.13.4 as “just file permissions.”
   Fix: include spooling, temp storage, snapshots, clipboard, and management planes in your Shared Resource Register. ¹

2. Relying on “policy says users shouldn’t…” without technical enforcement.
   Fix: disable or restrict transfer features in tooling; enforce isolation by configuration, then back it with policy.

3. Ignoring virtualization artifacts.
   Fix: treat snapshots/templates as data repositories; control access, retention, and deletion with the same seriousness as file shares.

4. Assuming cloud/SaaS provider isolation “covers it” with no evidence.
   Fix: collect configuration exports and contract language that supports isolation and gives you audit support for CMMC.

5. No recurring evidence.
   Fix: schedule periodic checks tied to baseline drift (for example, configuration compliance reports for GPO/MDM and platform policy exports). Daydream can automate evidence requests and track completion against 3.13.4. ²

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific practice. What matters operationally is assessment risk: failure often looks like “controls exist somewhere” but you cannot demonstrate consistent implementation across shared resources in scope, or you cannot prove that a shared service cannot act as an unintended transfer path. ^{2 3}

Practical 30/60/90-day execution plan

Use this as a working plan; adjust to your environment size and current maturity.

First 30 days (stabilize scope + quick wins)

• Confirm the CUI boundary and list in-scope systems and third parties. ²
• Build the Shared Resource Register and validate it with IT (endpoints, infra, cloud, apps).
• Implement immediate controls on common transfer points: shared jump hosts, remote access clipboard/drive redirection, shared printers/spools.
• Create the 3.13.4 control narrative and evidence index (where proofs live).

Days 31–60 (standardize configurations + prove operation)

• Establish configuration baselines for shared hosts (VDI, hypervisors, container nodes, print services).
• Implement lifecycle runbooks for snapshots/templates, deprovisioning, and secure clearing.
• Run and document tests per resource class; remediate findings.
• Centralize evidence capture in a system of record (Daydream or equivalent) with owners and recurring tasks.

Days 61–90 (make it durable)

• Add change-control gates for modifications to shared resources.
• Put monitoring/log review in place for privileged actions on shared platforms.
• Perform an internal readiness review: trace each shared resource to a control, a config, and a test result.
• Package an assessor-ready evidence set mapped to 3.13.4 and your system boundary. ^{1 2}

Frequently Asked Questions

Does “shared system resources” include cloud services and SaaS?

Yes if the service is inside your CUI boundary or supports in-scope processing. Treat multi-tenant SaaS as a shared resource problem and retain configuration and contractual evidence that supports isolation. ¹

Is disabling clipboard sharing required?

The requirement is to prevent unauthorized or unintended transfer through shared resources, not to disable any specific feature. If clipboard/drive redirection creates a plausible transfer path on shared admin or remote access systems, disable it or restrict it to authorized roles with logging and justification. ¹

How do we handle shared printers in facilities where CUI is printed?

Control access to printers, restrict and secure spooler behavior, and ensure jobs and spooled files cannot be retrieved by other users. Retain configuration evidence and a repeatable test record showing spools are cleared and permissions are constrained. ¹

Do we need dedicated infrastructure for CUI to satisfy 3.13.4?

Not always. Dedicated infrastructure is one way to reduce shared-resource risk, but strong logical isolation plus secure clearing and evidence can satisfy the practice if it prevents unauthorized or unintended transfer. ¹

What evidence is most persuasive to a CMMC assessor for 3.13.4?

A complete shared resource inventory for the CUI boundary, clear configuration proof for each resource class, and dated test results showing the controls work. Consistency across sites and environments matters as much as any single screenshot. ²

How do we operationalize recurring evidence without chasing engineers every month?

Convert 3.13.4 into a short control procedure with named owners and scheduled evidence pulls (configuration exports, compliance reports, and test attestations). Daydream helps by assigning ownership, automating evidence requests, and keeping an assessor-ready packet mapped to 3.13.4. ²

Footnotes

1. NIST SP 800-171 Rev. 2

2. DoD CMMC Program Guidance

3. 32 CFR Part 170