CMMC Level 2 Practice 3.1.18: Control connection of mobile devices

CMMC level 2 practice 3.1.18 requires you to control which mobile devices can connect to your environment that processes, stores, or transmits CUI, and to enforce those controls technically (not just by policy). Operationalize it by defining “authorized mobile,” blocking everything else by default, and retaining repeatable evidence that the controls work. (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance; 32 CFR Part 170)

Key takeaways:

• Treat mobile connections as “deny-by-default” unless the device, user, and connection method are explicitly approved. (NIST SP 800-171 Rev. 2)
• Your assessor will look for technical enforcement plus artifacts that show the control operates continuously, not only on paper. (DoD CMMC Program Guidance)
• Scope matters: apply controls to any boundary where mobile can touch CUI systems, including VPN, Wi‑Fi, email, MDM enrollment, and USB data paths. (NIST SP 800-171 Rev. 2)

Mobile devices expand your attack surface because they move between networks, install apps outside your control, and frequently store credentials that can reach controlled unclassified information (CUI). CMMC Level 2 ties directly to NIST SP 800-171 Rev. 2, so assessors will expect you to implement the NIST intent, document your approach, and produce evidence that it runs in practice. (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance)

For most defense contractors, “control connection of mobile devices” becomes a boundary control problem: where can phones/tablets connect, under what conditions, and what is technically blocked. The fastest path is to define a small set of allowed connection patterns (for example, “corporate-managed iOS/Android devices enrolled in MDM may access email and VPN with MFA; all other mobile access is blocked”), then implement those patterns in identity, network, and endpoint tooling. (NIST SP 800-171 Rev. 2)

This page is requirement-level guidance for a Compliance Officer, CCO, or GRC lead who needs to turn 3.1.18 into a working control with assessment-ready artifacts. It prioritizes actions, evidence, and common assessor hangups, so you can close gaps without rewriting your whole security program. (DoD CMMC Program Guidance)

Regulatory text

Practice statement (as provided): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.1.18 (Control connection of mobile devices).” (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance; 32 CFR Part 170)

Operator interpretation: You must decide which mobile devices are allowed to connect to systems that handle CUI, document the rule, and enforce it through technical means at the connection points you control (identity, network, endpoints, and cloud access paths). Your goal is to prevent unmanaged or unknown mobile devices from becoming a path into CUI. (NIST SP 800-171 Rev. 2)

Plain-English interpretation of the requirement

“Control connection” means you do not allow ad hoc mobile access. You define authorized mobile device types and states (managed, encrypted, screened, compliant), then gate access based on those states. If you cannot verify a device meets your standard, the device does not connect to CUI resources. (NIST SP 800-171 Rev. 2)

In practice, this requirement covers:

• Mobile endpoints: smartphones, tablets, and “phablets,” plus ruggedized field devices if they function as mobile compute.
• Connection methods: Wi‑Fi, VPN, mobile email, SaaS access, remote desktop/VDI from mobile, and any other pathway that can reach CUI systems.
• Associated data movement: attachments, downloads, caching/offline storage, and clipboard sharing from mobile into unmanaged apps. (NIST SP 800-171 Rev. 2)

Who it applies to (entity and operational context)

Applies to organizations pursuing CMMC Level 2 for DoD work where the environment processes, stores, or transmits CUI, including primes and subcontractors. (32 CFR Part 170; DoD CMMC Program Guidance)

Operationally, it applies wherever mobile access could touch:

• Your CUI enclave (on-prem or cloud)
• Corporate identity (SSO/IdP) used to reach CUI apps
• Network edges (VPN concentrators, Wi‑Fi controllers, ZTNA)
• Messaging and collaboration platforms where CUI could appear
• Admins: privileged access from mobile is a high-risk path you should explicitly allow or explicitly prohibit and enforce. (NIST SP 800-171 Rev. 2)

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

Step 1: Define scope and “connection points”

Create a short list of where mobile devices can connect:

• Email and calendar
• VPN / ZTNA
• Wi‑Fi (corporate SSID, guest SSID)
• SaaS apps used for CUI workflows
• VDI/RDP gateways
• File transfer paths (managed app storage, browser downloads) (NIST SP 800-171 Rev. 2)

Deliverable: a one-page Mobile Access Architecture diagram/table showing each connection point and the control owner.

Step 2: Write an “authorized mobile” standard

Document the minimum conditions for a device to connect. Keep it testable:

• Must be company-managed or explicitly approved BYOD under a defined program
• Must be enrolled in MDM/UEM
• Must enforce screen lock, encryption, and OS patch level
• Must block jailbroken/rooted devices
• Must enforce approved apps for email/file access where CUI could appear (NIST SP 800-171 Rev. 2)

Deliverable: Mobile Device Connection Standard (what qualifies, who approves exceptions, and which resources are reachable).

Step 3: Choose your enforcement model (and deny by default)

Pick one of these patterns and document it:

Model	What you allow	What you block	Typical control points
Corporate-owned only	Managed devices only	All BYOD	MDM compliance + Conditional Access + VPN/Wi‑Fi NAC
BYOD with container	Personal devices with managed workspace	Device-wide access	MAM/MDM + Conditional Access + DLP/app controls
No mobile to CUI	Mobile for MFA only, no CUI apps	Email/SaaS/VDI to CUI	Conditional Access rules; app allowlists

Assessors usually want a clear story: “If the device is not known and compliant, it cannot authenticate to CUI apps or networks.” (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance)

Step 4: Implement technical gates

Implement at least the controls that match your access paths:

Identity (IdP / Conditional Access)

• Require compliant/managed device for CUI app access
• Require MFA for mobile sign-ins
• Block legacy authentication and high-risk sign-ins per your policy (NIST SP 800-171 Rev. 2)

Network (Wi‑Fi / VPN / ZTNA)

• Separate guest Wi‑Fi from corporate Wi‑Fi
• Restrict corporate Wi‑Fi to known devices (certificate-based access is common)
• Restrict VPN to compliant devices; block split tunneling if it undermines monitoring for CUI workflows (document your decision) (NIST SP 800-171 Rev. 2)

Endpoint/mobile management

• Enforce baseline configurations (encryption, lock, OS version)
• Prevent copy/paste and unmanaged app sharing for CUI-handling apps where feasible
• Remote wipe for lost/stolen corporate devices; for BYOD, wipe the managed container if that is your model (NIST SP 800-171 Rev. 2)

Step 5: Add an exception process that doesn’t break the control

Exceptions are where 3.1.18 fails in practice. Define:

• Valid reasons (mission need, field ops)
• Time-bound approval
• Compensating controls (VDI-only access, read-only access, increased logging)
• Revocation steps when the exception ends (NIST SP 800-171 Rev. 2)

Step 6: Build recurring evidence capture (assessment-ready)

Map 3.1.18 to a routine that generates artifacts without heroics:

• Monthly export of device compliance and enrollment totals
• Quarterly access review of mobile-enabled groups/apps
• Ticket evidence for exceptions and terminations
• Screenshots/config exports of Conditional Access/VPN/Wi‑Fi policies (DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2)

If you use Daydream, treat 3.1.18 as a control “packet”: link the policy, the technical configurations, and a scheduled evidence task so you can hand an assessor a consistent bundle instead of assembling proof during the assessment window. (DoD CMMC Program Guidance)

Required evidence and artifacts to retain

Keep evidence that proves design + operation:

Policy and standards

• Mobile Device Connection Standard (authorized vs prohibited, approval authority)
• BYOD policy (if applicable) and acceptable use terms
• Exception procedure and templates (NIST SP 800-171 Rev. 2)

Technical configuration evidence

• Conditional Access / IdP rules showing device compliance requirements
• MDM/UEM compliance policies and screenshots/exports
• VPN configuration showing device/user restrictions
• Wi‑Fi/NAC configs for corporate SSID access controls (NIST SP 800-171 Rev. 2)

Operational evidence

• Device inventory list (mobile endpoints) tied to owner and status
• Sample of compliance reports (pass/fail, remediation actions)
• Access review outputs for mobile-enabled access paths
• Exception tickets with approval and closure proof (DoD CMMC Program Guidance)

Common exam/audit questions and hangups

Expect assessors to probe these areas:

1. “What counts as a mobile device here?” Have a definition aligned to your asset inventory categories, and show where it is controlled. (NIST SP 800-171 Rev. 2)
2. “Can a personal phone access CUI email or files?” Answer with a rule and a config screenshot/export that enforces it. (DoD CMMC Program Guidance)
3. “How do you block unknown devices?” Show deny-by-default at IdP/VPN/Wi‑Fi, not only a user policy. (NIST SP 800-171 Rev. 2)
4. “How do you know this is working today?” Provide current compliance reports and sign-in logs demonstrating blocks for noncompliant devices. (DoD CMMC Program Guidance)

Frequent implementation mistakes and how to avoid them

• Mistake: Policy-only control. Fix: implement Conditional Access/VPN/Wi‑Fi enforcement that makes the policy true. (NIST SP 800-171 Rev. 2)
• Mistake: BYOD allowed “temporarily” forever. Fix: enforce time-bound exceptions with automatic expiry and periodic review. (DoD CMMC Program Guidance)
• Mistake: Email is controlled, SaaS is not. Fix: list all CUI apps and apply the same mobile gate to each, or document why mobile access is blocked entirely. (NIST SP 800-171 Rev. 2)
• Mistake: No artifact trail. Fix: schedule evidence capture and store config exports and reports in a controlled repository tied to 3.1.18. (DoD CMMC Program Guidance)

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this specific practice, so you should treat enforcement expectations as assessment-driven: CMMC Level 2 assessments test whether the practice is implemented and institutionalized, and missing evidence is a common failure mode. (DoD CMMC Program Guidance; 32 CFR Part 170)

Risk-wise, uncontrolled mobile connections create credible paths for credential theft, data exfiltration through unmanaged apps, and access from compromised devices. The operational risk you must reduce is “mobile becomes an unmonitored endpoint into CUI.” (NIST SP 800-171 Rev. 2)

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and blocking decisions)

• Inventory mobile access paths to CUI (IdP apps, VPN, Wi‑Fi, VDI).
• Decide your model: corporate-owned only, BYOD container, or no mobile to CUI.
• Publish the Mobile Device Connection Standard and exception workflow.
• Turn on deny-by-default rules in a report-only mode if your tooling supports it; document the rollout plan. (NIST SP 800-171 Rev. 2)

Days 31–60 (implement enforcement)

• Enroll authorized mobile devices in MDM/UEM and set compliance baselines.
• Enforce Conditional Access rules for CUI apps (compliant device + MFA).
• Restrict VPN and corporate Wi‑Fi to authorized devices/users.
• Create the evidence pack template for 3.1.18 and assign owners. (DoD CMMC Program Guidance)

Days 61–90 (prove operations and harden)

• Run an access review for mobile-enabled groups/apps and remediate drift.
• Test blocks: attempt sign-in from noncompliant/unenrolled devices and retain logs/screenshots.
• Exercise lost-device response (wipe/lock) and document the ticket trail.
• Establish recurring evidence capture in Daydream or your GRC system so the artifacts stay current. (DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2)

Frequently Asked Questions

Does 3.1.18 require MDM for all mobile devices?

The requirement is to control mobile connections; MDM/UEM is a common way to prove a device is known and compliant. If you don’t use MDM, you still need a technical method to prevent unmanaged devices from connecting to CUI resources. (NIST SP 800-171 Rev. 2)

Can we allow BYOD if CUI might be accessed?

Yes, but only if you can enforce connection controls and prevent unmanaged app/data paths consistent with your policy, typically through a managed container and Conditional Access. Document the model and keep exception evidence tight. (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance)

Are laptops “mobile devices” for this practice?

3.1.18 focuses on mobile devices; many programs treat laptops under broader endpoint controls. For assessment clarity, define “mobile device” in your standard and show how laptops are handled under your endpoint access controls. (NIST SP 800-171 Rev. 2)

What’s the minimum evidence an assessor will accept?

Provide (1) the written standard, (2) configuration evidence showing mobile access gates, and (3) operational proof such as compliance reports and logs showing noncompliant devices are blocked. Assessors commonly reject narratives without artifacts. (DoD CMMC Program Guidance)

How do we handle field teams with limited connectivity?

Use a bounded exception path: restrict to specific apps, prefer VDI/remote access over local storage, require MFA, and add heightened monitoring. Make the exception time-bound and keep approval and closure records. (NIST SP 800-171 Rev. 2)

If we block all mobile access to CUI, do we still need 3.1.18?

Yes. Blocking is a form of control, but you must document the prohibition and show the technical enforcement that prevents mobile devices from connecting to CUI systems. Keep evidence that the block applies across your CUI access paths. (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance)