CMMC Level 2 Practice 3.1.19: Encrypt CUI on mobile devices and mobile computing platforms.23

To meet cmmc level 2 practice 3.1.19: encrypt cui on mobile devices and mobile computing platforms.23 requirement, you must ensure any CUI stored on, processed by, or accessible from phones, tablets, laptops, and similar mobile platforms is encrypted using approved device or container encryption, and you can prove it with configuration and inventory evidence. Treat this as an engineering control backed by policy and repeatable evidence collection.

Key takeaways:

• Encrypt CUI at rest on mobile endpoints (full-disk, file-based, or approved container) and enforce it centrally.
• Control the CUI boundary: either prevent CUI from landing on mobile devices, or encrypt it wherever it can land.
• Retain assessor-ready evidence: device inventory, encryption status reports, MDM policies, and exception handling.

CMMC Level 2 aligns to NIST SP 800-171 Rev. 2 for protecting CUI in contractor environments ¹. Practice 3.1.19 is one of the fastest ways an assessment can go sideways because “mobile” is broader than many teams assume. It includes corporate laptops used offsite, tablets used on shop floors, phones used for email, and contractor-owned endpoints allowed under BYOD. If any of those endpoints can store or cache CUI, you need encryption that is enforced, monitored, and evidenced.

Operationally, you have two viable patterns: (1) allow CUI on mobile devices and encrypt it, or (2) disallow CUI on mobile devices and implement technical controls that prevent local storage (for example, VDI with copy/paste and download restrictions), while still encrypting what remains (like device caches). Either way, assessors will look for consistency between your stated CUI handling rules, your technical enforcement (MDM/UEM, endpoint management, disk encryption), and the proof you retain over time.

This page translates the requirement into a buildable control, with concrete steps, artifacts, and assessment traps to avoid, based on the CMMC program and the mapped NIST requirement ².

Regulatory text

Requirement (mapped): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.1.19 (Encrypt CUI on mobile devices and mobile computing platforms.23).” ³

Operator meaning: If a mobile device or mobile computing platform can store, process, or access CUI, you must apply encryption to protect that CUI on the device. In practice, assessors expect (a) a defined scope of in-scope mobile endpoints, (b) encryption enforced through technical policy, and (c) evidence that encryption is active and remains active.

Plain-English interpretation (what the practice is really asking)

You need a defensible answer to two questions:

1. Where can CUI land on mobile endpoints? (email attachments, synced folders, offline files, local app storage, cached web content, screenshots, exported reports)
2. If it can land there, is it encrypted by default and enforced? “We tell users not to” is not enough.

Encryption can be satisfied through:

• Native full-disk encryption (common for laptops and many managed mobile OS configurations).
• File/folder encryption where full-disk is not feasible.
• Approved secure containers for CUI apps and storage (common for BYOD patterns), if the container is enforced and CUI does not escape the container.

The control must be operational: encryption on day one, and proof every day after.

Who it applies to (entity + operational context)

Applies to:

• Defense contractors and other federal contractors that handle CUI and must meet CMMC Level 2 ⁴.
• Any environment boundary where CUI is stored, processed, or transmitted and where mobile devices/mobile computing platforms are used.

In-scope assets typically include:

• Corporate laptops used remotely or on travel.
• Tablets used for production, QA, maintenance, or logistics where CUI documents may be viewed.
• Smartphones used for email, messaging, MFA approval flows that may display or store CUI.
• BYOD endpoints if allowed to access CUI (even read-only access can create cached copies).

Key scoping decision: If you claim “CUI never resides on mobile endpoints,” you must back it with technical controls that make that true (not just training).

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

Step 1: Define “mobile endpoints” and the CUI handling boundary

• Publish a short standard: “Which device types are allowed to access CUI, and under what conditions?”
• Document allowed use cases (examples: “CUI allowed in managed email container only,” “CUI allowed via VDI only,” “No local downloads”).
• Align this to your system security plan and CUI data flow diagrams so the story is consistent ⁵.

Step 2: Build an authoritative inventory for mobile endpoints that can touch CUI

Minimum fields you need:

• Device identifier, OS version, owner (corporate/BYOD), management state (enrolled or not), user, and whether the device is in the CUI authorization boundary.
• Tie inventory to access: only enrolled/managed devices can authenticate to CUI systems.

Practical note: If you cannot list the devices, you cannot credibly claim encryption coverage.

Step 3: Choose the encryption pattern per endpoint class

Use a simple decision matrix:

Endpoint type	Recommended pattern	What assessors will want to see
Corporate laptops	Full-disk encryption enforced centrally	Policy + management reports showing encryption “on”
Corporate phones/tablets	Device encryption + managed app/container for CUI	MDM/UEM compliance policy + device compliance reports
BYOD phones/tablets	Container-based encryption + data loss restrictions	BYOD enrollment rules + container policy + proof CUI stays in container
Contractor-provided laptops	Either prohibit CUI locally, or require managed encryption	Contract language + technical enforcement + exception tracking

Step 4: Enforce encryption through central management

Implement controls that do not rely on user action:

• Configure MDM/UEM or endpoint management to require encryption as a compliance condition.
• Block access to CUI systems (email, file shares, collaboration tools, VDI) from devices that are not encrypted or not enrolled.
• Prevent configuration drift: restrict local admin rights where feasible; alert on encryption suspension or degraded posture.

Step 5: Control common “CUI escape paths”

Encrypting the disk is necessary but you still need to reduce spillage:

• Disable or restrict unsanctioned cloud sync for CUI directories.
• Limit “save as” and offline access for CUI in collaboration tools where possible.
• Set rules for screenshots, copy/paste, and exports in managed containers (particularly on BYOD).

Step 6: Handle exceptions with a formal process

You will have exceptions (legacy devices, specialized tablets, field scenarios). Make them survivable:

• Require documented risk acceptance, compensating controls (for example, VDI-only access), and time-bound remediation.
• Track exceptions in a register with an owner and closure criteria.

Step 7: Capture recurring evidence (make it boring and repeatable)

Don’t scramble before an assessment. Set a recurring cadence:

• Export encryption compliance reports from MDM/UEM and endpoint tools.
• Keep a snapshot of the device inventory and enrollment status.
• Retain access control policy settings that show blocked access for noncompliant devices.

Daydream fit (where it earns its place): Use Daydream to map practice 3.1.19 to a documented control, assign owners, and schedule recurring evidence capture so you always have assessor-ready artifacts rather than point-in-time screenshots ².

Required evidence and artifacts to retain

Keep evidence in a form that shows scope, enforcement, and ongoing operation:

Core artifacts

• Mobile device and mobile computing platform inventory (in-scope boundary clearly marked).
• Encryption policy configuration from endpoint management/MDM/UEM (exported settings).
• Compliance reports showing encryption status across in-scope devices.
• Conditional access rules showing non-encrypted or non-enrolled devices are blocked from CUI access points.
• CUI handling standard for mobile endpoints (what’s allowed, what’s prohibited).
• Exception register with approvals and compensating controls.

Helpful supporting artifacts

• Sample device compliance screenshots (use sparingly; prefer exports/reports).
• Helpdesk/IT procedures for device enrollment and remediation steps.
• Training snippet that reinforces “CUI on mobile requires managed/encrypted devices” (training alone is not the control, but it supports it).

Common exam/audit questions and hangups

Expect assessors to probe these areas ⁶:

• “Show me the list of all mobile devices that can access CUI.”
• “Prove they are encrypted today, not last quarter.”
• “How do you prevent a personal phone from accessing CUI email?”
• “Where is CUI stored on these devices (email, files, app caches) and how is it protected?”
• “What happens if encryption is disabled or a device falls out of compliance?”
• “Do you allow offline access to CUI? If yes, where does it persist and is that encrypted?”

Hangup to anticipate: Teams present a policy that says “encryption required” but cannot produce a system-generated compliance report across the fleet.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating laptops as “not mobile.”
   Fix: Define “mobile computing platform” explicitly in your standard and inventory. If it leaves the facility or connects from untrusted networks, treat it as mobile for this practice.

2. Mistake: Relying on user attestation.
   Fix: Enforce encryption via centrally managed controls and collect machine-generated reports.

3. Mistake: Allowing BYOD access without a container strategy.
   Fix: Require enrollment and a managed container for any BYOD that touches CUI, or block BYOD entirely at the identity layer.

4. Mistake: “CUI never on phones” with no technical controls.
   Fix: Add conditional access, managed app policies, DLP restrictions, and configuration that prevents downloads/offline copies.

5. Mistake: Evidence is screenshots taken right before the assessment.
   Fix: Implement recurring exports and retention. Daydream can track the practice-to-evidence mapping and remind owners when evidence is due.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific practice. The practical risk remains straightforward: unencrypted mobile endpoints increase the impact of loss, theft, or unauthorized access, and they create a common gap during CMMC assessments because they are easy to overlook relative to servers and network controls ².

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and stop the bleeding)

• Define the CUI-on-mobile rule set (allowed/prohibited, BYOD stance).
• Inventory endpoints that can access CUI systems; identify unmanaged access paths.
• Implement conditional access basics: block non-enrolled devices from key CUI entry points.

Next 60 days (enforce encryption and close common gaps)

• Roll out encryption enforcement policies for laptops and managed mobile devices.
• Deploy container controls for BYOD if BYOD remains in scope.
• Implement exception workflow and remediation playbooks for noncompliant devices.
• Start recurring evidence exports (inventory + encryption compliance).

By 90 days (operate the control like an assessor will test it)

• Validate enforcement with spot tests (attempt access from noncompliant device; verify block).
• Review exceptions for closure and verify compensating controls.
• Package artifacts into an assessor-ready evidence set mapped to practice 3.1.19, with clear ownership and refresh cadence ⁶.

Frequently Asked Questions

Does full-disk encryption alone satisfy 3.1.19 for laptops?

It can, if you enforce it centrally and can prove it is enabled on all in-scope laptops. Assessors will still ask how you prevent unencrypted or unmanaged laptops from accessing CUI systems ⁵.

Are smartphones considered “mobile computing platforms” for this practice?

If they can access or store CUI (for example through email, attachments, or synced apps), treat them as in scope and encrypt accordingly. The safest approach is to require managed enrollment and restrict CUI to a managed container ⁵.

We don’t allow CUI on mobile devices. Do we still need encryption?

You must make “no CUI on mobile” true through technical controls, not intent. If any CUI can be cached or downloaded locally, you either need encryption or stronger controls that prevent local persistence ⁷.

How should we handle BYOD access to CUI?

Either block it, or require enrollment with a managed container that enforces encryption and prevents data from leaving approved apps. Document the rule and retain evidence of enforcement via policy exports and compliance reports ⁵.

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

System-generated exports showing device inventory and encryption compliance across the in-scope fleet, plus conditional access rules that block noncompliant devices. Pair that with a short written standard for CUI handling on mobile endpoints ².

How do we operationalize this without creating constant manual work?

Automate evidence capture through scheduled exports and store them with a consistent naming and retention approach. Tools like Daydream help you map 3.1.19 to owners and recurring evidence tasks so the control stays continuously testable ⁵.

Footnotes

1. 32 CFR Part 170; NIST SP 800-171 Rev. 2

2. DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2

3. NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance; 32 CFR Part 170

4. 32 CFR Part 170; DoD CMMC Program Guidance

5. NIST SP 800-171 Rev. 2

6. NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance

7. DoD CMMC Program Guidance