AC.L2-3.1.18 mobile device connection requirements

What AC.L2-3.1.18 mobile device connection requires before an assessment

AC.L2-3.1.18 asks you to identify every mobile device that processes, stores or transmits CUI, authorize each of those connections, and monitor and log them. If CUI can reach a phone or tablet, whether through email, a collaboration app or a file sync client, an assessor will expect a device-level record of what connected, who approved it and what the system logged. It is the CMMC Level 2 version of NIST SP 800-171 Rev. 2 requirement 3.1.18, a derived requirement in the Access Control family. Its origin is the SP 800-53 Rev. 4 control AC-19 (Access Control for Mobile Devices), which Appendix D of SP 800-171 Rev. 2 maps to it. The requirement carries 5 points under the CMMC Scoring Methodology, so it must be MET. It cannot sit on a plan of action and milestones (POA&M), and a contractor that leaves it open will not reach Conditional or Final Level 2 status.

The risk is straightforward: an unmanaged phone or tablet can copy, screenshot, sync or forward CUI outside the boundary you have documented, and nobody sees it happen. The requirement is harder to meet than it sounds for three reasons. Device inventories are often incomplete because phones are issued, bought or brought in outside the normal asset process. Bring-your-own-device arrangements blur who owns the device and therefore who can enforce settings or wipe it. Finally, the requirement expects identifiers and logs, not only a policy document. The CMMC Assessment Guide Level 2 calls for mobile devices that handle CUI to carry a device-specific identifier so that monitoring and logging can be tied to a specific device.

Before an assessment, confirm three things. First, decide which mobile devices are in scope, and record the decision in your system security plan. Second, write the authorization procedure and the usage restrictions, then keep dated approvals for each device or device class. Third, test whether your mobile management and logging tools produce records that name the device, the user and the connection. The Phase II suspension announced on 13 July 2026 changes certification timing, but it does not change the self-assessment and affirmation obligations for this requirement. Ask your assessor or consultant to show you the evidence format they will accept for mobile connections before you rely on it.

Which mobile devices and connections fall in scope for AC.L2-3.1.18

The first decision for AC.L2-3.1.18 is which devices and connections touch CUI at all. Scope drives the inventory, the authorization records and the monitoring evidence an assessor will ask for, so each category below should be decided and documented before any control is tested.

Smartphones and tablets holding CUI

Any smartphone or tablet that processes, stores or transmits CUI is in scope, including devices used to open CUI email, documents or internal portals. Build the list from where CUI actually goes, not from the device types the organization issues. Check for local caches, downloaded attachments, screenshots and messaging apps that could carry CUI. Each in-scope device needs a device-specific identifier so that connections can be monitored and logged.

E-readers and other mobile devices

E-readers and similar devices are easy to overlook, yet they can store downloaded technical manuals or drawings that contain CUI. Ask engineering, program and contracts staff whether they load controlled documents onto personal reading devices. If a device can open or cache CUI, it belongs in the mobile device inventory with its identifier and authorization status, even when it is rarely used.

Personally owned devices syncing company data

Personally owned phones that sync company email, calendars, files or chat are in scope when any of that content is CUI. Bring-your-own-device arrangements need a written agreement covering device enrollment, monitoring limits, wipe rights and what happens on departure. HR should be part of that agreement because employment terms, consent and offboarding steps determine whether the organization can enforce the controls at all.

Devices used for MFA

A phone that receives one-time codes or runs an authenticator app may never store CUI itself, but it sits in the authentication path to systems that do. Assessors may treat it as part of the environment that protects CUI, so document whether it is in scope, how it is identified and how its use is authorized. Confirm the position with your assessor and the scoping documents for your environment rather than assuming it is outside the boundary.

MDM and cloud management consoles

Mobile device management servers and cloud admin consoles hold device inventories, compliance states, user mappings and sometimes CUI-adjacent data such as file names or policy records. Treat the console as a system whose access, logging and administration you must control, and confirm where its data is stored. Third-party MDM or cloud providers must be reviewed for how they handle this data and whether they fall within your assessment scope.

Boundary documentation and enforcement

A device with no CUI path is out of scope only if the boundary is written down and technically enforced. Record the scope decision, the network or mail segregation that keeps CUI off the device, and the checks that show it is working, such as blocked sync or containerized apps. Review the boundary after changes to mail, file sharing or device policy. Responsibilities should be assigned across IT, security, HR and any MDM or cloud provider so that each control has one owner.

How an assessor tests the three objectives of mobile device connection

This table compares the three assessment objectives in NIST SP 800-171A for AC.L2-3.1.18, showing how an assessor tests each one, what evidence to have ready and where organizations most often fall short. Read each row as a checklist for your own evidence set. A requirement is MET only when all three objectives are satisfied with final, not draft, evidence.

Assessment objective	Test approach and assessment objects	Evidence requested	Common finding
Identify mobile devices that process, store or transmit CUI	Assessor checks the device inventory against the CUI boundary and samples devices that reach CUI systems, email or repositories. Assessor reviews whether each mobile device is recorded with a device-specific identifier.	Current mobile device inventory with device identifiers, owner and CUI access status, plus the configuration management plan entries that cover mobile devices	Phones and tablets used for CUI email or file access are missing from the inventory, or are recorded without a unique identifier
Authorize mobile device connections	Assessor reviews the written authorizations and the procedures for mobile device usage and restrictions, then tests whether the capability that authorizes connections blocks unapproved devices.	Signed authorizations for each connected device, usage procedures and restrictions, and a test record showing an unregistered device is refused or quarantined	Authorization is granted by informal approval or in a draft policy, or the connection capability accepts devices that were never authorized
Monitor and log mobile device connections	Assessor pulls audit records for a sample period and checks that connection events, device identifiers and user associations are captured and can be reviewed.	Audit records of connection and disconnection events tied to device identifiers, log review evidence, and the audit configuration that retains these records	Logs exist for the mail or VPN gateway but do not identify the device, or no one can show that connection events were reviewed
Final evidence across all three objectives	Assessor confirms that every applicable objective is satisfied before scoring the requirement as MET, since partial satisfaction does not count.	Final, approved versions of each artifact with dates and owners, and a traceable link from each objective to its evidence	Evidence is in draft form, mixes current and outdated versions, or covers only one of the three objectives

How to implement mobile device connection controls in order

This sequence turns AC.L2-3.1.18 from a policy statement into evidence an assessor can test, moving from defining which mobile devices may touch CUI through to proving the controls work over time.

Define which mobile devices may handle CUI
Start by deciding which smartphones, tablets and e-readers may process, store or transmit CUI, and which may only reach non-CUI resources. Owners are usually the security lead with IT and the system owner, and the decision should be recorded in the system security plan boundary. Write a mobile device usage procedure covering permitted device types, operating system expectations, acceptable apps, and what users must do when a device is lost. The output is an approved scope statement and usage procedure that an assessor can compare against what users actually do.
Build an inventory with device-specific identifiers
Create an inventory of every mobile device in the approved scope, recording a device-specific identifier, the owner, the assigned user, the operating system version and the CUI access it has. The CMMC Assessment Guide expects each in-scope mobile device to carry an identifier that supports monitoring and logging, so the identifier must be stable enough to match against connection logs. Confirm with your mobile device management or directory tooling how identifiers are generated and kept current. Done means every in-scope device can be traced from a log entry to a named owner and an inventory record.
Set authorization rules and record each approval
Define the conditions under which a mobile device may connect to a CUI system, such as enrollment, encryption status, supported operating system version and an approved user. Each device that meets the rules should receive a documented authorization that names the approver, the date and the connection scope. Unauthorized devices should be blocked or routed to a non-CUI network. The output is a signed authorization record for each approved connection, which is the evidence an assessor will sample first.
Enforce the rules technically where possible
Translate the written rules into technical controls wherever your platforms support them, such as conditional access, device enrollment requirements, network admission checks or certificate-based access. Where a rule cannot be enforced technically, document the compensating procedure and who checks it. Configuration details depend on your identity provider, mobile management platform and network design, so confirm capabilities with each vendor before relying on them. The output is configuration evidence showing that a non-authorized device cannot reach CUI resources.
Turn on logging and review connection events
Enable logging of mobile device connection events, including successful and failed connections, device identifiers, user identities and times, and send those records to a central log store where they can be retained and searched. Assign a reviewer and a review cadence in the procedure, and keep evidence that reviews happened, with any anomalies investigated and documented. Logs from the identity platform, mobile management tool and network gateway should be correlated by device identifier. The output is retained log records and dated review evidence.
Test the capability and confirm it works
Test the connection controls the way an assessor would. Attempt connections from an authorized device, an unenrolled device and a device that fails the rules, then confirm the outcome matches the procedure and that each attempt appears in the logs with the correct identifier. Document the test steps, results and any defects, and fix and retest anything that fails. The assessment objectives in NIST SP 800-171A focus on identification, authorization, and monitoring and logging, so the test record should show all three.
Retain records and keep them current
Keep the procedure, inventory, authorization records, configuration evidence, logs, review records and test results in a controlled repository, and update them when devices, users or platforms change. Records should be final, not drafts, because the scoring methodology counts a requirement as MET only when evidence is in final form. Ask your assessor, or the independent certification body if applicable, which record formats and retention periods it accepts before you finalize the evidence set.

Evidence that passes AC.L2-3.1.18 and how to keep it current

An assessor testing AC.L2-3.1.18 looks for a chain of records: a procedure that defines mobile use, an authorization for each connection, an inventory that identifies each device, configuration entries that carry the rules, logs that show the connections, and proof that the authorization capability works. Each artifact must be final, dated and consistent with the others, and each needs an owner who refreshes it on a schedule.

Mobile device usage procedure

This is the written procedure and restrictions that define which mobile devices may process, store or transmit CUI, which connection types they may use, and what users must do. Assessors check that it names the device types in scope, the approval path, and the restrictions for personally owned devices. Confirm that the document is approved, versioned and matches what the system actually enforces. Review it after any change to mobile management tooling or to the CUI boundary, and record the review date and approver.

Authorization record for each connection

Each mobile device or connection that touches CUI needs a recorded authorization, with the device identifier, the owner, the approver, the date and the conditions of use. Assessors sample these records and compare them against connection logs, so any device that connected without a matching entry is a finding. Keep the record current by tying approval to onboarding and revocation, and remove entries when a device is retired or lost.

Device inventory with identifiers

The inventory lists every mobile device identified as processing, storing or transmitting CUI, using a device-specific identifier so monitoring and logging can tie events to a single device. Assessors check that the inventory is complete against connection logs and that identifiers are unique and traceable to a user. Tools such as GLPI can hold phone records, and the Wazuh Syscollector module can report endpoint hardware and software where agents are installed. Confirm which devices those tools cannot see and document how they are tracked.

Configuration baseline and management plan

Configuration baseline entries and the configuration management plan record the approved settings that govern mobile connections, such as enrollment requirements, allowed platforms and logging settings. Assessors look for a baseline that matches the device policy in force and a plan that explains how changes are reviewed. Store each baseline version with its approval, and reconcile it against the actual configuration at each review so the two never drift apart.

Connection and audit logs

Logs record when each identified device connected, what it accessed, and when it disconnected, and they are the main proof that monitoring and logging operate. Assessors pick events and trace them back to an authorization and an inventory entry. Confirm log sources, retention and time synchronization, and check that records are protected from alteration. Osquery can schedule queries across hosts, and Velociraptor hunts can collect artifacts from groups of endpoints, but confirm each one captures the mobile connection events you need.

Records of an authorization capability test

Assessors expect evidence that the capability which authorizes mobile connections has been tested. The record should describe the test objective, the steps, an unauthorized device attempt and an authorized one, the results and the corrective actions. Run the test before an assessment and after significant changes, then keep the completed record. A plan or draft test script does not satisfy this, so store the executed results with dated sign-off.

Who does what for mobile device connection: your team, a partner and the assessor

Your organization owns the control. Leadership and the system owner decide whether mobile devices may process, store or transmit CUI at all, and if so, which device types, operating systems and management methods qualify. Those decisions belong in a written mobile device policy and in authorization records that name the people who approved each connection pathway. A partner can draft these documents, but your team must adopt, approve and enforce them.

Policy decision: Decide whether personally owned phones, tablets and e-readers may connect to CUI resources, or whether only organization-issued devices may do so.
Authorization records: Approve each mobile connection method and keep the approval dated, signed and tied to the system security plan.
Usage procedures: Define acceptable use, restrictions and what users must do when a device is lost or changes ownership.
Accountability: Assign a named owner for the device inventory, for reviewing connection logs and for removing unauthorized devices.
Retention of decisions: Keep the approvals and exceptions current as devices and platforms change.

Before assessment, confirm with your own counsel and contracting team which devices your contracts and CUI handling rules allow, because that answer drives the scope of everything else.

Where mobile device connection controls usually fall short

Most failures against AC.L2-3.1.18 come from gaps between what the organization says it does and what its records show. The cards below cover the gaps assessors see most often, from unrecorded personal phones to a configuration management plan that ignores mobile devices. Each card gives one fix you can check before an assessor arrives.

Personal phones syncing CUI without authorization

Employees often set up mail, chat or file sync on personal smartphones without any record that the connection was approved. Under AC.L2-3.1.18 the authorization step must exist for every mobile device that processes, stores or transmits CUI. Start by checking mail and collaboration logs for mobile clients, then compare the device list against a written authorization record. Each device that appears in logs without a matching approval needs either a formal authorization or a block on access.

Inventories that omit tablets and e-readers

Asset lists usually track laptops and desktops but leave out tablets, e-readers and other mobile devices that sync CUI. An assessor who finds a tablet in a mail log with no inventory entry will question the whole identification objective. Pull device data from your mobile device management tool or mail platform, then reconcile it with your asset register. Treat the reconciled list as the single source for which mobile devices are in scope.

Device identifiers missing from device records

The CMMC Assessment Guide expects mobile devices that handle CUI to carry a device-specific identifier, because monitoring and logging depend on tying each connection to one device. Records that list only the owner's name or model, without a serial number or unique device ID, break that link. Confirm that every in-scope device record includes a unique identifier and that the same identifier appears in connection logs. Gaps here usually show up as log entries that cannot be traced to a specific device.

Mobile policies that exist only as drafts

Mobile usage rules and connection restrictions are often written, circulated and never approved. Assessors test the procedures for mobile device usage and restrictions, and a requirement is MET only when the evidence is in final form, not drafts. Check the document's approval date, owner and version history, then confirm that the people who connect devices were told about the approved version. Replace the draft in every location where it is stored or linked.

Connections that are never logged or reviewed

Many organizations can show that a device was allowed to connect but cannot show what it did afterward. Monitoring and logging of mobile connections is one of the three assessment objectives for 3.1.18, so a log with no review record is weak evidence. Enable connection logging in your mobile management or mail platform, set a review frequency you can sustain, and keep dated records of each review along with any follow-up on unusual connections.

Configuration management plan silent on mobile devices

The configuration management plan is one of the assessment objects listed for 3.1.18, yet many plans cover servers and workstations only. An assessor will look for mobile devices in the baseline, the change process and the approved configuration settings. Update the plan to name mobile device types in scope, define their baseline settings, and state how changes to those settings are approved and recorded.

Questions about cost, effort and outside help for mobile device connection

Is mobile device connection harder to meet than other CMMC Level 2 access control requirements?

It is usually less work than the broad access requirements, but it is worth 5 points and cannot be placed on a POA&M, so it has to be fully met before a Conditional or Final Level 2 status. The effort depends mainly on how many device types touch CUI and whether any of them are personally owned. Requirements such as AC.L2-3.1.1 and AC.L2-3.1.5 span every account and privilege in the system, so they often take more time. Mobile connection work is narrower: it asks you to identify devices, authorize their connections and show that those connections are logged. Your organization owns the policy and the decisions, and an implementation partner can help build the inventory, configuration and log evidence the assessor will review.

What drives the cost of meeting mobile device connection requirements?

The main cost drivers are the number of mobile devices that process, store or transmit CUI, whether devices are company-owned or personally owned, the number of CUI systems they can reach, and whether you already run a mobile device management (MDM) platform. Each driver adds inventory work, configuration work and log review. Costs fall into two groups: one-time work such as scoping, building the device inventory, writing authorization procedures and configuring logging, and recurring work such as reviewing connection logs, re-authorizing devices and updating the inventory as staff change. When requesting a quote, ask the provider to itemize these pieces, state which are fixed and which are per device, and name the systems in scope. No researched figure is available here for typical costs, so compare written quotes against your own device count.

Can we meet AC.L2-3.1.18 in-house without an outside partner?

Yes, an organization can meet this requirement with its own staff, as long as those staff can produce the evidence the assessment requires. The work involves identifying mobile devices with a device-specific identifier, documenting authorization for each connection type, configuring monitoring and logging, and showing that these controls operate. Your team needs authority to define policy, skill with your MDM or endpoint tools, and time to keep the records current. Teams that lack this capacity often bring in a partner for the build phase and keep ownership of policy and records in-house. Remember that an implementation partner does not issue findings or certifications. An independent assessor must still evaluate the evidence.

What does the requirement ask our staff to do day to day?

Day-to-day work is mostly administrative and operational. Staff must keep a current list of mobile devices that process, store or transmit CUI, approve new connections before they happen, and review logs that show when devices connected and what they did. IT operations need to know how device identifiers are recorded and how a device is removed when an employee leaves or a device is lost. Security staff should be able to explain the authorization procedure and walk an assessor through a sample of connections. Ask any partner to document these routines in a runbook your team can keep using after the engagement ends.

How long does it take to implement mobile device connection controls?

The timeline depends on the number of device types, the state of your existing inventory and logging, the number of CUI systems involved, and how much policy must be written from scratch. An organization with an accurate asset inventory and a working MDM platform has far less to build than one with unmanaged personal phones and no connection logs. No researched duration is available for this work, so ask any provider to state its schedule in the written scope, list the dependencies it assumes, and identify which milestones your staff must complete. Plan for the assessment date separately, because the assessor's schedule and the Department of War's current CMMC phase timing both affect when evidence must be final.

Can an implementation partner remove the need for an assessor?

No. An implementation partner can plan the controls, configure systems, collect device inventories and prepare evidence, but it cannot assess your organization or issue a CMMC result. Level 2 certification assessments are performed by C3PAOs authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB, and self-assessments are carried out by the organization itself under the applicable rules. Be cautious of any proposal that claims to replace an independent assessment. A useful quote separates the build work from the assessment, names who signs what, and states that the organization remains responsible for its own controls and evidence. The CMMC Program rule sets out these roles.

Which open-source tools can help us inventory and log mobile-connected assets?

Open-source tools can support the inventory and monitoring parts of this requirement, though none of them replaces an MDM platform or your authorization process. GLPI's Assets module can record phones and other devices, either entered manually or pushed by the GLPI Agent, and the GLPI Agent's native inventory has been built into GLPI since version 10. Wazuh's Syscollector collects hardware, operating system and network details from endpoints for inventory views and reports. Confirm with each vendor whether a given device class, such as a tablet or e-reader, can be inventoried and logged in your environment before you commit to a design. Your partner should test that coverage on your actual device mix.

What meeting AC.L2-3.1.18 costs in money and effort

This table compares the cost components of meeting AC.L2-3.1.18 for mobile device connections, showing who is paid, whether each cost is one-time or recurring, what drives it, and how to reduce it. Open-source tooling removes some license spend, but inventory, authorization and evidence work stay with the organization. No prices are published here, so use the rows to build the questions you put to a written quote.

Cost component	One-time or recurring	What drives it	How to reduce it
Tooling or licenses	Recurring for commercial MDM or EDR; one-time setup for open-source tools	Number of mobile devices in scope, feature set and whether the tool runs in a FIPS-validated mode where needed	Choose self-hosted open-source inventory and monitoring where it fits; confirm the tool's device coverage for phones and tablets before relying on it
Engineering and admin time for inventory and authorization	One-time build, then recurring upkeep	Count of mobile devices that process, store or transmit CUI, number of enrollment paths, and how often devices change owners	Limit the CUI-bearing device population through scoping; automate device identifier capture so records are not built by hand
Policy and procedure writing	One-time, with periodic review	Number of mobile device usage rules, how many device types are allowed, and how well existing policies already cover them	Reuse existing remote access and acceptable use policies; write one mobile standard tied to the assessment objectives
Evidence upkeep	Recurring	Frequency of device changes, number of logs retained, and whether evidence is kept in final form rather than drafts	Schedule evidence collection, keep authorization records and connection logs in one location, and date each artifact
External testing or review	Recurring if scheduled; optional before assessment	Scope of the test, number of devices sampled and whether the reviewer tests the authorization step or only the logs	Ask for a fixed-scope review of the mobile connection controls and device inventory rather than a broad engagement
Assessor fees for certification	Recurring where a certification assessment applies	Assessment scope, size of the environment and assessor terms set by the C3PAO	Confirm current requirements for your contract, since the Phase II suspension affects timing; request the assessor's fee schedule in writing

How DeployOpen works on this

DeployOpen plans and implements self-hosted open-source platforms that help an organization identify mobile devices, record their authorized connections and keep the logs that show monitoring. The organization owns its mobile device authorization decisions, and an independent assessor is the only party that judges whether the requirement is met.

How we scope

Confirm which mobile devices process, store or transmit CUI, including smartphones, tablets and e-readers
Define the written scope of systems, asset records and connection logs that will serve as assessment evidence
Agree in writing which mobile device connection decisions the client owns and which steps DeployOpen performs

How we build

Configure asset inventory so each in-scope mobile device carries a device-specific identifier and an owner record
Set up collection of mobile endpoint inventory and connection events into a central place for review and reporting
Test that unauthorized or unidentified devices are flagged, and document the test results for the client

How we hand over

Deliver configuration records, data flow notes and sample reports that map to the three assessment objectives for 3.1.18
Provide an evidence index that shows where each identifier, authorization record and log is kept and who reviews it
Document the procedures the client staff will run, so the evidence stays current after the engagement ends

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
Review new mobile device types and connection changes against the authorization procedure on a schedule the client sets
Ask any implementation partner to confirm its scope in writing, and confirm the assessor who will review your evidence