CMMC Level 2 Practice 3.1.21: Limit use of portable storage devices on external systems

CMMC Level 2 Practice 3.1.21 requires you to restrict when and how portable storage devices (for example, USB drives) can be used with external systems, so controlled information is not exposed through uncontrolled media movement. To operationalize it fast, define “external system,” set an allowlist-based rule for portable media use, enforce it technically where possible, and retain evidence that the restriction is working (NIST SP 800-171 Rev. 2).

Key takeaways:

  • Treat “external systems” as a defined boundary decision, then enforce portable media rules based on that boundary (NIST SP 800-171 Rev. 2).
  • Move from policy to enforcement: allowlist, approvals, scanning, encryption, and blocking where feasible.
  • Evidence wins assessments: show configurations, logs, exceptions, and recurring reviews mapped to 3.1.21 (NIST SP 800-171 Rev. 2).

The fastest way to fail 3.1.21 in a CMMC Level 2 assessment is to have a “USB policy” that is not enforced, or to rely on informal practice (“we don’t really use thumb drives”) without proof. The practice is narrow, but assessors expect it to be operational: you define the rule, you implement the rule, and you can demonstrate that the rule is followed over time.

This requirement sits in the Access Control family and is mapped to NIST SP 800-171 Rev. 2. The risk is straightforward: portable storage devices are a high-friction control point where data can cross boundaries without network monitoring, DLP coverage, or normal identity controls. External systems increase the risk because you typically do not manage them, cannot validate their security posture, and cannot guarantee malware protection or logging.

Your implementation should read like an operator’s playbook: identify which systems are “external,” limit portable media use with those systems to explicit cases, and create an exception process that is rare, documented, and reviewable. Then capture evidence continuously so your SSP and assessment package stays current (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance; 32 CFR Part 170).

Requirement: cmmc level 2 practice 3.1.21: limit use of portable storage devices on external systems requirement

Objective: Prevent uncontrolled movement of CUI and reduce malware/data exfiltration risk by restricting portable storage device interactions with systems outside your control boundary (NIST SP 800-171 Rev. 2).

Plain-English interpretation

You must set and enforce limits on using portable storage devices when the other system is external (for example, a personal computer, a third party’s laptop, a supplier kiosk, or any device outside your managed environment). If a portable device must touch an external system, it should happen only under defined, approved, and controlled conditions, with protections like scanning and encryption and with records that prove it happened as intended (NIST SP 800-171 Rev. 2).

What this is not: a generic “don’t use USBs” memo. Assessors look for boundary definitions, technical controls where feasible, and an exception mechanism that does not become the default.

Regulatory text

CMMC Level 2 Practice 3.1.21 is mapped to NIST SP 800-171 Rev. 2 requirement 3.1.21: “Limit use of portable storage devices on external systems.” The operator outcome is to restrict portable media interactions with systems outside your control so sensitive data is not exposed through unmanaged endpoints (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance; 32 CFR Part 170).

Who it applies to

Entity scope

  • Defense contractors and subcontractors that handle CUI and are seeking or maintaining CMMC Level 2 alignment (32 CFR Part 170; DoD CMMC Program Guidance).

Operational scope

  • Endpoints (laptops/desktops), servers, and specialized devices where users can connect removable media.
  • Users who transfer files for manufacturing, engineering, field service, incident response, or data exchange with third parties.
  • Third-party interactions: on-site work at customer locations, supplier facilities, or any environment where an external system is in the workflow.

Define “external system” for your program

Your assessment hinges on this definition. Document it in your SSP and supporting policy. A practical, assessable definition is:

  • Internal/managed systems: owned or controlled by your organization and administered under your security baseline (patching, EDR, logging, access control).
  • External systems: not administered under your baseline, including personal devices (BYOD), third-party owned endpoints, customer machines, test kiosks at partner sites, and any unmanaged loaner device.

Tie the definition to your CUI boundary decisions (DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2).

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

Use this sequence to operationalize quickly and produce assessor-ready evidence.

1) Inventory the portable storage device paths

Build a short list of where portable media is used or could be used:

  • USB mass storage, external SSD/HDD
  • SD/microSD cards (often missed in engineering workflows)
  • Portable optical media if still used
  • Smartphones acting as storage (if your environment treats them that way)

Capture: owner team, business need, systems involved, and whether any “external system” is in the path.

2) Set an allowlist rule for external-system use

Write a rule that is binary and testable:

  • Default: portable storage devices may not be used on external systems for any transfer involving CUI or systems in the CUI enclave.
  • Allowed: specific, documented scenarios (examples below) with required safeguards and approvals.

Common allowed scenarios (if you truly need them):

  • Field service workflows where data must be carried into a restricted facility.
  • Controlled data exchange where a third party cannot accept secure transfer methods.
  • Forensics/IR handling under a controlled procedure.

3) Require an approved method before portable media is allowed

Create a “decision order” that users and IT can follow:

  1. Approved secure file transfer channel inside your boundary (preferred).
  2. Approved third-party exchange channel with contractual controls (if applicable).
  3. Portable media only by exception, with safeguards and documentation.

This supports consistency and reduces exceptions over time.

4) Implement technical enforcement where feasible

Assessors typically expect you to block or restrict removable storage via centralized endpoint management when possible. Examples of enforceable controls:

  • Device control policies to block unapproved USB mass storage.
  • Allow only encrypted corporate-issued drives.
  • Read-only mode for certain roles.
  • Require malware scanning on insertion.
  • Disable autorun and similar risky behaviors.

If you cannot enforce on every asset (for example, certain OT systems), document compensating controls and boundaries clearly in your SSP (NIST SP 800-171 Rev. 2).

5) Build a tight exception process (and keep it rare)

Your exception process should include:

  • Request ticket with business justification, data classification, and target external system.
  • Approval by data owner and security (or delegated approver).
  • Required safeguards checklist (encryption, scan, labeling, chain-of-custody).
  • Expiration and closure steps.

Keep exceptions auditable: every exception should have an owner, timeframe, and post-activity confirmation.

6) Add handling requirements for approved portable media

For permitted cases, define minimum handling requirements:

  • Corporate-issued media only (or explicitly approved media).
  • Encryption requirement for media that may store CUI.
  • Pre- and post-use malware scanning steps.
  • Physical labeling and storage requirements (locked cabinet, controlled access).
  • Sanitization/disposal procedure at end of life.

7) Train and verify

Train the users who touch media in real workflows (engineering, field service, IT). Then verify with:

  • Spot checks of endpoint device-control logs.
  • Ticket review for exceptions.
  • Walkthrough interviews with users to confirm they understand “external system” and the escalation path.

8) Map to documented control operation and recurring evidence capture

Turn the above into an operating rhythm: monthly/quarterly log review, exception review, and configuration checks. If you use Daydream to manage control mapping and recurring evidence requests, set 3.1.21 as a discrete control with tasks for device-control exports, exception register updates, and policy attestation. This reduces scramble work before an assessment and directly addresses the “missing evidence” risk for 3.1.21 (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance).

Required evidence and artifacts to retain

Keep artifacts that prove design and operation. A practical evidence list:

Governance

  • Portable media policy with “external system” definition and explicit limits.
  • Standards/procedures for exceptions, scanning, encryption, and sanitization.
  • SSP entries mapping the implementation to 3.1.21 (NIST SP 800-171 Rev. 2).

Technical

  • Endpoint management/device-control configuration screenshots or exports showing blocking/allowlisting.
  • EDR or device-control logs demonstrating enforcement events (blocked attempts, allowed devices).
  • Encryption configuration proof for approved drives (policy settings, management console evidence).

Operational

  • Exception register (tickets) with approvals, safeguards completed, and closure.
  • Training records for roles permitted to use portable media.
  • Periodic review records (meeting notes, log review sign-offs, corrective actions).

Common exam/audit questions and hangups

Expect these lines of questioning:

  1. “Define external system.” If your answer is fuzzy, the rest collapses.
  2. “Show me you enforce it.” Policies alone rarely satisfy.
  3. “How do you prevent CUI from being copied to a USB?” Demonstrate technical controls or tightly bounded compensating controls.
  4. “What happens when someone needs an exception?” Show ticketing, approvals, and evidence of safeguards.
  5. “Prove it’s ongoing.” Provide recent logs, recent exceptions, and recent reviews (NIST SP 800-171 Rev. 2).

Frequent implementation mistakes (and how to avoid them)

  • Mistake: banning USB in policy, but allowing it technically. Fix by implementing device-control policies and testing on representative endpoints.
  • Mistake: allowing personal encrypted drives “if they promise.” Fix by requiring corporate-issued, centrally managed media for approved use.
  • Mistake: treating “external system” as only “internet-facing.” Fix by explicitly including third-party and personal endpoints in the definition.
  • Mistake: exceptions without expiration. Fix by adding time-bound approvals and closure steps.
  • Mistake: no evidence trail. Fix by scheduling recurring evidence capture (config exports, logs, exception register) and storing it with your assessment artifacts (DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2).

Enforcement context and risk implications

Portable media is a common bridge around network controls. In practice, a single uncontrolled transfer to an unmanaged external system can create multiple reportable issues: CUI exposure, malware introduction, and inability to reconstruct events due to limited logging. CMMC assessments focus on whether practices are implemented and evidenced; weak evidence for 3.1.21 is a predictable finding because teams often implement partial restrictions without documenting boundaries and exceptions (DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2; 32 CFR Part 170).

A practical 30/60/90-day execution plan

First 30 days (stabilize and define)

  • Define “external system” and publish the portable media rule set.
  • Identify who needs portable media for legitimate workflows.
  • Implement a basic exception workflow in your ticketing system.
  • Start evidence capture: current device-control posture, current USB enablement status, and baseline logs (NIST SP 800-171 Rev. 2).

Days 31–60 (enforce and narrow)

  • Deploy device-control restrictions broadly; move to allowlist where feasible.
  • Issue corporate-approved encrypted media for authorized roles only.
  • Roll out role-based training plus a short user job aid (“If you need to transfer data, do this…”).
  • Begin periodic review cadence: exceptions and device-control logs.

Days 61–90 (prove operations and close gaps)

  • Test the control: attempt USB writes on representative endpoints and document results.
  • Audit exceptions for completeness and remove standing exceptions that lack justification.
  • Update SSP and procedures based on what you learned in deployment.
  • If you run Daydream, set recurring evidence tasks and map artifacts to 3.1.21 so the assessment package stays current (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance).

Frequently Asked Questions

What counts as a “portable storage device” for 3.1.21?

Treat any removable media capable of storing files as in-scope, including USB mass storage and memory cards. Document what you include and exclude so assessors see a deliberate boundary (NIST SP 800-171 Rev. 2).

Does 3.1.21 require a total ban on USB drives?

No. It requires limits on use with external systems. Many organizations still permit controlled, approved use with corporate-issued encrypted media and logging, but block ad hoc use.

Are customer-owned laptops “external systems” even if we work on them daily?

Yes, if they are not administered under your security baseline. Treat them as external and require an approved transfer method or a documented exception path (NIST SP 800-171 Rev. 2).

What if an OT machine can’t run endpoint device-control software?

Document it as a constrained environment and implement compensating controls like physical restrictions, locked ports, controlled media issuance, and strict procedures. Make the boundary and rationale clear in the SSP (NIST SP 800-171 Rev. 2).

How do we show evidence if we rarely use portable media?

Show technical controls that would prevent use (policy configurations) and logs showing attempted or blocked events, plus a “no exceptions” register statement reviewed on a defined cadence.

How should we handle third parties who need files via USB?

Prefer approved transfer channels and contractual controls where possible. If USB is unavoidable, issue controlled media, require scanning and encryption, and document chain-of-custody and approval in an exception record.

Frequently Asked Questions

What counts as a “portable storage device” for 3.1.21?

Treat any removable media capable of storing files as in-scope, including USB mass storage and memory cards. Document what you include and exclude so assessors see a deliberate boundary (NIST SP 800-171 Rev. 2).

Does 3.1.21 require a total ban on USB drives?

No. It requires limits on use with external systems. Many organizations still permit controlled, approved use with corporate-issued encrypted media and logging, but block ad hoc use.

Are customer-owned laptops “external systems” even if we work on them daily?

Yes, if they are not administered under your security baseline. Treat them as external and require an approved transfer method or a documented exception path (NIST SP 800-171 Rev. 2).

What if an OT machine can’t run endpoint device-control software?

Document it as a constrained environment and implement compensating controls like physical restrictions, locked ports, controlled media issuance, and strict procedures. Make the boundary and rationale clear in the SSP (NIST SP 800-171 Rev. 2).

How do we show evidence if we rarely use portable media?

Show technical controls that would prevent use (policy configurations) and logs showing attempted or blocked events, plus a “no exceptions” register statement reviewed on a defined cadence.

How should we handle third parties who need files via USB?

Prefer approved transfer channels and contractual controls where possible. If USB is unavoidable, issue controlled media, require scanning and encryption, and document chain-of-custody and approval in an exception record.

Operationalize this requirement

Map requirement text to controls, owners, evidence, and review workflows inside Daydream.

See Daydream