1Overview
AC.L2-3.1.18 opens the mobile-device pair of the Access Control family. It requires that the connection of mobile devices to the environment be controlled, so that phones, tablets, and laptops do not attach to the systems handling CUI without the organization deciding they may.
Mobile devices are difficult precisely because they move. They leave the building, join other networks, are carried home and abroad, and are lost and stolen at rates that fixed equipment is not, which makes an uncontrolled mobile device that connects to the environment a moving, poorly bounded piece of the attack surface. The control asks the organization to establish which mobile devices may connect and under what conditions, and to enforce that, so a personal phone or an unmanaged tablet cannot simply join and reach CUI. It pairs with 3.1.19, which governs the encryption of CUI on the mobile devices once they are permitted.
Control connection of mobile devices.
A mobile device in this context is a portable computing device that can connect to the environment, a smartphone, a tablet, a laptop used as a mobile endpoint. "Control connection" means the organization governs which of these may attach and enforces conditions on them, rather than allowing any device an employee owns to connect freely. The control does not necessarily forbid mobile devices; it requires that their connection be a governed act, with the conditions the organization sets applied before and while they connect.
2The Assessment Objectives
NIST SP 800-171A decomposes 3.1.18 into three objectives: identify mobile devices, define the connection controls, and enforce them.
Mobile devices that process, store, or transmit CUI are identified. The organization knows which mobile devices touch CUI, so their connection can be governed.
Mobile device connections are authorized. The organization has defined which mobile devices may connect and under what conditions.
Mobile device connections are monitored and logged. The connections are visible and recorded, so their access can be reviewed and there is a log of what attached and when.
The three objectives move from identifying the devices to authorizing and then controlling their connection. The common gap is at objective [c], where an organization has a mobile-device policy on paper but no enforcement, so the intended conditions do not actually prevent an unmanaged device from connecting. The assessor looks for enforcement that admits only the permitted devices.
3Failure Patterns
The failures center on personal devices reaching CUI and on mobile connection that was never brought under management.
Personal phones reaching CUI email
The most common mobile exposure is the personal phone configured to receive company email that contains CUI, with no management over the device. The device is unmanaged, may be shared within a household, and travels everywhere, yet it holds CUI, so the connection is neither identified nor controlled. Bringing that mail access under device management or a controlled app is the usual resolution.
Unmanaged laptops as mobile endpoints
A laptop that leaves the building and connects back to the environment is a mobile device, and where it is not managed, its connection is uncontrolled. Personal or unmanaged laptops used for remote work fall under this control as much as phones, and their connection has to be governed rather than assumed safe because they belong to staff.
Policy without enforcement
A mobile-device policy may state that only approved devices may connect while no technical control enforces it, so objective [c] fails even though [a] and [b] are documented. Conditional access or device management has to make the policy real, admitting compliant devices and refusing the rest.
No line drawn between managed and personal use
Where the organization has not decided whether personal devices may be used for work at all, mobile connection grows without boundaries, and every employee's device becomes a potential path to CUI. Drawing that line, whether through issued devices, enrollment of personal ones, or a controlled application boundary, is the decision the control depends on.
4Ownership
This control is owned by IT, with a policy decision from leadership about whether and how personal devices may be used, since that choice shapes what has to be enforced.
| Role | Responsibility for this control |
|---|---|
| IT and system administrator | Identifies mobile devices touching CUI, enforces connection conditions through device management and conditional access, and monitors mobile connections. Owns the technical evidence. |
| Executive sponsor | Decides the mobile-device posture, whether the organization issues devices, enrolls personal ones, or confines CUI to managed applications, since that policy choice governs the whole control. |
| Security or compliance lead | Defines the connection conditions and confirms enforcement admits only permitted devices, and reviews mobile connection records. |
| Program lead | Includes mobile devices in periodic review, since personal devices and mail access proliferate quietly, and retains the records. |
5Tooling
The control is built with mobile device management and conditional access, which together identify the permitted devices and enforce the conditions of their connection.
| Objectives | Tooling | What it provides |
|---|---|---|
| [a] | Mobile device management enrollment, device inventory | Identification and inventory of the mobile devices permitted to handle CUI, so the set is known. |
| [b], [c] | Conditional Access, device compliance policies | Authorizing connection only for enrolled, compliant devices and refusing others, making the connection a governed act. |
| [c] app boundary | Mobile application management, protected mail and file apps | Confining CUI to managed applications on the device, an alternative to full device management that still controls where CUI can go on the phone. |
| Monitoring | Sign-in and device connection logs | Visibility of which devices connect, so mobile access can be reviewed. |
The caveat is that the policy decision precedes the tooling. The organization first decides its mobile posture, issued devices, enrolled personal devices, or a managed-application boundary, and the tooling then enforces that choice; buying device management without deciding the posture leaves the enforcement aimed at nothing in particular. The assessor tests objective [c] by attempting to connect an unmanaged device and observing whether it is refused, so the enforcement has to actually distinguish permitted devices from the rest.
6Evidence
The satisfied version of 3.1.18 shows the identified mobile devices and the enforced control over their connection.
| Evidence | What it demonstrates |
|---|---|
| Mobile device policy | Objective [b]. The defined posture and the conditions under which mobile devices may connect. |
| Mobile device inventory | Objective [a]. The identified devices permitted to handle CUI. |
| Conditional access and compliance configuration | Objective [c]. The enforcement admitting only compliant, enrolled devices. |
| Managed application configuration | Objective [c]. Where used, the app boundary confining CUI on the device. |
| Mobile connection logs | Objective [c]. Records of which devices connect, showing the control in operation. |
The evidence should demonstrate that only permitted devices can connect and that unmanaged devices are refused, which rests on enforcement rather than policy language. Configuration showing conditional access and device compliance in force, paired with the device inventory and the mobile posture decision, is the clearest demonstration of the control.
The phone in every pocket is the question
The mobile gap that most often surfaces is personal phones pulling in CUI-bearing email with no management at all, and closing it starts with deciding the organization's mobile posture. Working out whether to issue devices, enroll personal ones, or confine CUI to managed apps, and enforcing that choice, is part of the onsite readiness work this practice does.
Start CMMC Readiness or call 802-335-26627Sources
- NIST Special Publication 800-171 Rev 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, requirement 3.1.18. csrc.nist.gov
- NIST Special Publication 800-171A, Assessing Security Requirements for Controlled Unclassified Information, assessment objectives 3.1.18[a] through 3.1.18[c]. csrc.nist.gov
- 32 CFR 170.21, Plan of Action and Milestones Requirements, governing which requirements may remain open at a Level 2 assessment. ecfr.gov