03.01.18 Access control for mobile devices: evidence

What 03.01.18 access control for mobile devices requires in plain terms

If a contract requires NIST SP 800-171 and staff use phones or tablets to reach systems that hold CUI, 03.01.18 asks the organization to control those devices as a deliberate access path, not as an afterthought. In plain terms, the requirement has three parts. First, the organization sets usage restrictions and configuration and connection rules for mobile devices, such as which device types are allowed, what must be enabled on them, and what they may do once connected. Second, each mobile device must be authorized before it connects to the system, so the organization knows which devices exist and which ones it has approved. Third, CUI on those devices must be protected with full-device or container-based encryption. The first two parts are about who and what may connect. The third is about what remains readable if a device is lost, stolen or compromised.

The risk is concrete. A lost phone with a cached mail client, a tablet with a synced document folder, or a personal device that was never enrolled can each hold CUI outside the managed boundary, and the organization may not learn of the exposure until much later. Policy documents alone do not close this gap, because an assessor will look for evidence that the connection rules are enforced and that the encryption is actually active on each device. A written policy that says devices must be encrypted is weak evidence if the organization cannot show which devices are enrolled, which are compliant and which are blocked. Confirm with your assessor which evidence they expect for container versus full-device encryption, since the choice affects what you must demonstrate. Also note that Rev. 3 folded Rev. 2 requirement 3.1.19, the separate mobile device requirement, into 03.01.18, so the Rev. 2 wording you may already have mapped needs to be rechecked against this combined requirement.

Which mobile devices, apps and teams fall under 03.01.18

Before an assessor can test 03.01.18, the organization has to decide which devices, apps and people count as mobile access to the system. Each decision below changes how many devices need usage restrictions, connection authorization and encryption. The organization defines the boundary in its system security plan, and the assessor checks that the boundary matches how the system is actually used.

Company-owned versus personal (BYOD) devices

Company-owned phones and tablets can be enrolled, configured and wiped centrally, so the organization sets the encryption and connection rules directly. Personal devices bring the owner's apps, backups and browsing into the same hardware that touches CUI, which makes full-device encryption and remote wipe harder to guarantee. Decide which ownership models are allowed, document each one in the plan, and confirm which device settings the organization can enforce on each. Ask whether personal devices can be used at all, or only through a container.

Email-only access versus CUI repository access

A device that only reads corporate email may hold CUI in messages and attachments, yet it reaches a narrower part of the system than a device that syncs document libraries or engineering repositories. Each access path needs its own connection authorization and encryption decision. Map every mobile route to the data it can open, including caches, offline copies and sync clients. Email-only access is often the first scope to define, but attachments containing CUI still count.

Managed versus unmanaged browsers

A managed browser can enforce settings such as blocked downloads, disabled copy and paste, and session limits, while an unmanaged browser on the same device cannot. When users open CUI in a web application from a phone, the browser choice determines whether the organization can control what is stored locally. Identify which browsers are approved, which are blocked, and how web sessions to the system end. Confirm with the platform vendor which controls each browser type actually supports.

Mobile apps and containers

Mobile apps that open CUI can keep data in their own storage, and a container separates work apps and data from personal content on the device. Container-based encryption protects CUI only inside that boundary, so apps that run outside it or copy data into a shared area fall outside the protection. Inventory each app that reaches the system, record whether it runs inside a container, and document how the organization verifies that. Check that the chosen containers and app settings meet the encryption requirement as written.

Third-party and contractor devices

Devices owned by subcontractors, consultants, or visiting staff can connect to the system without passing through the organization's enrollment process. Each such device is still a path to CUI, so the organization must decide whether it may connect at all and under what authorization. Require written connection terms, confirm which settings the owner must keep, and set how access is revoked when the engagement ends. Coordinate these terms with the supply chain and personnel controls that apply to the same people.

Whether devices are inside the SSP boundary

The system security plan defines what is inside the boundary of the assessed system, and mobile devices count only if the plan says they do. A device that reaches CUI but sits outside the documented boundary creates an inconsistency an assessor will question. Record each mobile access route, its owner, and its controls in the plan, then confirm the boundary with the people who manage the devices. The organization defines the boundary, and the independent assessor checks that the documented boundary matches reality.

How an assessor tests 03.01.18 and which evidence they ask for

This table walks through the five SP 800-171A Rev. 3 determination statements for 03.01.18 and shows, for each one, what the assessor examines, whom they interview, what they test and what evidence to prepare. Read each row as a checklist of what your team must be able to show before the assessment starts.

Assessment element	What the assessor does	Evidence to prepare	Where it usually fails
Examine: policy and procedures	Reads the access control policy and the mobile device procedures to confirm they define usage restrictions, configuration and connection requirements for mobile devices.	Approved access control policy, mobile device procedures with a revision history and owner, and an approval record for each.	Policy covers laptops only, or mobile devices are mentioned in the policy but no procedure states how connections are authorized.
Examine: system design documentation	Checks whether the system design shows which mobile devices can reach CUI, through which access points, and how encryption is applied.	Current architecture diagrams, data flow diagrams for mobile access, and a list of the connection paths to CUI repositories.	Diagrams are out of date, omit mobile email or sync clients, or do not match the live environment.
Interview: staff with access control responsibility	Asks administrators how they authorize devices, set configuration requirements and handle non-compliant devices.	Named owners for mobile device access, documented approval steps, and sample tickets showing authorization decisions.	Administrators describe informal practice that the written procedure does not reflect, or cannot name who approves a new device.
Interview: users who connect from mobile devices	Asks users which devices they use, how they connect to organizational systems and what they are required to do before connecting.	Acceptable use or rules of behavior acknowledgments, and a sample of user onboarding records for mobile access.	Users connect personal devices through unmanaged apps or describe a connection method that is not in the approved list.
Test: access control capability for mobile connections	Attempts or observes connections from mobile devices to confirm that only authorized devices can connect and that the required encryption is in place.	Device enrollment or inventory reports, configuration policy exports, encryption status reports, and records of rejected connection attempts.	Unauthorized devices can still sync, encryption is enabled on some devices but not enforced, or no record exists of rejected connections.
Test: full-device or container-based encryption	Confirms that CUI on mobile devices is protected by full-device encryption or a container that encrypts CUI, and that the setting is enforced rather than advised.	Encryption configuration settings, compliance reports for each device, and evidence that noncompliant devices are blocked or quarantined.	Encryption is documented but not verified on each device, or CUI is copied to unencrypted local storage outside the container.
Evidence of monitoring over time	Looks for proof that the device requirements are checked after initial setup, not only at the time of the assessment.	Periodic compliance reports, change records for mobile policies, and remediation tickets for failed checks.	Compliance is checked once at rollout and never again, so drift goes unnoticed.
Scoring impact in CMMC Level 2	Where CMMC Level 2 applies, 3.1.18 carries a point value in the scoring methodology and cannot be placed on a POA&M for Conditional status.	A requirement-level finding record showing the status of 03.01.18 and the supporting evidence for each determination statement.	Teams plan to close a gap later with a POA&M, which the scoring rules do not permit for this practice under Conditional status.

How to implement 03.01.18 in the order that produces evidence

This sequence moves from defining what mobile access is allowed to do, through configuration, authorization and encryption, to testing and documentation. Each step leaves a specific artifact that an assessor can examine, interview against or test.

Define allowed device types and usage restrictions
Start by listing every mobile device type that may reach the system, such as organization-owned phones and tablets, and any personally owned devices you will permit. For each type, write the usage restrictions: which applications, data types and locations are allowed, and what is prohibited. The security or compliance lead owns this decision and the system owner signs it. The output is a mobile device access standard that names the permitted device types and restrictions, which the assessor will examine alongside the access control policy and procedures. Confirm the organization-defined parameter values for 03.01.18 in the NIST OSCAL catalog and ask the contracting agency whether it has set any values it expects you to use.
Set configuration and connection requirements
Translate the standard into concrete configuration requirements for each device type: screen lock, operating system version floor, required management profile, disabled features and approved connection methods. Write them as testable settings, not general intent. Your mobile device management or endpoint tooling should apply them, and you should record which settings are enforced by policy and which depend on the user. The output is a configuration baseline document and the exported policy profile, which the assessor will examine and then test on sample devices. Where you use open-source endpoint tooling such as Fleet, its policies can ask yes or no questions of devices through osquery, and its policies page shows which devices pass or fail each check.
Decide how devices are authorized before connecting
Decide who approves a device before it connects to the system, what evidence that approval requires, and how the approval is recorded. Typical choices include enrollment in device management, a unique device identifier linked to a named user, and a sign-off by an authorized role. Document the approval workflow and the roles allowed to approve. The output is an authorization procedure and a sample enrollment record showing an approval, the approver and the date, which an assessor will interview personnel about and check against actual records.
Choose full-device or container encryption and verify it
Select full-device encryption or container-based encryption for CUI on each mobile device type, and document why the choice protects CUI. Container encryption keeps CUI inside a managed workspace, while full-device encryption covers the whole device. Then verify encryption on every enrolled device, not only on the reference model. Record the check method and results per device. The output is an encryption decision record plus a per-device compliance report, which the assessor will test. Where the platform stores its own keys, such as OpenBao's transit secrets engine for application data, document key ownership and rotation separately from device encryption.
Configure a response to noncompliant devices
Define what happens when a device fails a configuration, encryption or authorization check. Options include blocking access to the system, quarantining the device, requiring remediation within a set period, or notifying the administrator. Set the response in the management tooling so it runs automatically, and document who is alerted. Confirm the noncompliance response with the contracting agency if it has specific expectations. The output is a noncompliance procedure and an automated rule or alert, with test records showing that a failing device was blocked or flagged. An assessor will test this path, so run it on a deliberate test device first.
Test with a sample of devices
Select a sample of enrolled devices across device types, operating systems and user groups. For each sampled device, confirm the configuration, authorization record and encryption state against the baseline, and confirm the noncompliance response works. Record each result, including exceptions and how they were resolved. The output is a dated test log tied to the sample, which the assessor will use in the test method for this requirement. Keep the sample method written down so it can be repeated at each assessment cycle.
Record ODP and procedure decisions
Finish by consolidating every decision into the system security plan and the procedures that support it: the device types, usage restrictions, configuration baseline, authorization process, encryption choice, noncompliance response and test sample method. Record each organization-defined parameter value and the reason for it. Assign an owner and a review trigger for each document. The output is a current set of documents that matches what the systems do, which the assessor will examine. If the agency or your own environment changes the device model, operating system or management tooling, update these records before the next assessment.

Evidence that passes 03.01.18 and how to keep it current

An assessor testing 03.01.18 looks for a written policy, an accurate device inventory, enforced configuration, and proof that the controls operated over time. Each artifact below answers one part of the requirement, and each needs a stated refresh cadence and a named owner who signs it off, because a single screenshot shows a device was compliant once, not that the control runs continuously.

Mobile device access control policy and procedures

This is the written policy and the procedures behind it, covering usage restrictions, configuration and connection requirements, the authorization step for connecting devices, and the encryption expectation for CUI on devices. Assessors examine it first, so every requirement in the policy should name the system, the device types it covers and the person who enforces it. Review it at least once a year and after any change to the mobile management platform or to the device types allowed. The approving official, usually the system owner or CISO, signs each version and the revision history shows who approved what and when.

Approved device and usage list

This list records every phone and tablet allowed to reach the system, the owner, the operating system version, the assigned user and the permitted usage, such as email, document access or CUI viewing only. It is the reference an assessor compares against enrollment records to test whether unknown devices are present. Refresh it on a fixed schedule and whenever a device is added, reassigned or retired. The system owner approves additions, and the security lead confirms the list matches the mobile management console at each review.

Configuration and connection baselines

A baseline states the required settings for each approved device type, such as screen lock, minimum operating system version, restrictions on backup of CUI, and rules for connecting to the system over approved channels. Record the baseline as code or a policy export so changes are visible. Compare live device settings against it, and treat drift as a finding. Revalidate the baseline when operating system versions change and at a defined review interval, with the security engineering lead approving changes before they take effect.

Device enrollment and authorization records

These records show when each device was enrolled, who authorized the connection, which policies were applied and when access was granted or revoked. They prove the authorization step is real and not assumed. Export them from the enrollment system on a regular cycle, and keep records for departing users so revoked devices are traceable. The approving manager or system owner signs each authorization, and the security team reviews exceptions monthly.

Encryption status reports per device

Encryption reports show, for each device, whether full-device encryption is active or whether CUI sits in a container with encryption enforced. The report should flag any device that is unencrypted, jailbroken or rooted, or that has an out-of-date encryption setting. Generate it on a set schedule and keep prior exports so you can show the state across the assessment period. The security operations lead reviews exceptions, and any device that fails is blocked from the system until remediated.

Test records of blocked devices

Test records prove the control works: a noncompliant or unauthorized device is tested against the connection rules and the test shows the device is refused. Keep the test plan, the device used, the date, the result and screenshots or logs from the access point. Repeat the test after baseline changes and at a set interval, and have an independent tester or the assessor observe at least some tests. The tester and the system owner sign the results, and any failed test opens a tracked finding.

What meeting 03.01.18 costs in money and effort

This table separates the cost components of meeting 03.01.18 into license spend, engineering effort, and recurring evidence work, and shows who is paid for each. Read it as a checklist for a written quote: most of the cost sits in people time, and no supplied figures exist for licenses or hours, so ask each provider for the numbers.

Cost component	One-time or recurring	What drives it and how to reduce it
Mobile device management or endpoint tooling licenses	Recurring	Driven by device count and the features the platform needs. Self-hosted open-source tools can remove license spend, but ask whether the chosen tool enforces mobile configuration or only reports on it.
Engineering time for usage policy and encryption setup	One-time, with periodic review	Covers writing usage restrictions, connection rules and full-device or container encryption settings. Reduce it by reusing an existing access control policy and documenting one standard configuration per device type.
Device enrollment and upkeep	Recurring	Grows with the number of phones and tablets, new hires and device replacements. Reduce it with automated enrollment and a documented process for revoking connection authorization when a device is lost or leaves service.
Evidence collection	Recurring	Includes exporting policy compliance status, enrollment lists and encryption settings each assessment cycle. Reduce it by scheduling routine reports, so the evidence is produced as a side effect of normal operations.
External testing or review	Periodic, optional or required by contract	Depends on scope and whether the organization wants an independent check of mobile connection controls before assessment. Ask the provider to state the tests included and the deliverables in writing.
Assessor sampling time	Per assessment	Assessors interview personnel who use mobile devices and test a sample of connections. Reduce it by keeping a current device inventory and connection records that can be produced quickly for any sampled device.

Which open-source tools can produce 03.01.18 evidence

03.01.18 asks for evidence of mobile device usage rules, configuration checks, connection authorization and encryption of CUI on those devices. No single open-source tool covers all of that, so the question is which tool produces which piece of evidence. The four tools below each cover a different slice, and each leaves gaps that the team must confirm for its own mobile fleet.

Wazuh configuration assessment

Wazuh's Security Configuration Assessment (SCA) module scans monitored endpoints against YAML policies, most of them based on CIS benchmarks and extendable with custom policies. It checks files, directories, registry keys and running processes, and it recommends remediation. For 03.01.18, the output can show configuration baselines for endpoints that access the system, but only where the mobile platform is actually an agent-monitored endpoint. Confirm with the vendor whether the agent and policies you need run on your mobile operating systems, since many phone platforms are managed through MDM rather than an agent.

Fleet device policy results

Fleet policies are yes or no questions asked of devices as osquery queries, such as whether disk encryption is on or a screen lock is set. The policies page shows which devices in each fleet pass or fail, which gives an assessor a dated view of compliance across the fleet. This is strong evidence for the configuration and usage conditions in 03.01.18, provided the mobile devices report to Fleet and the queries cover the specific settings your mobile policy names. Confirm which mobile platforms Fleet supports and which settings each query can read on them.

Nextcloud server-side encryption

Nextcloud's server-side encryption protects file contents at rest on local and external storage, with keys held on the server. It does not encrypt file names or folder structure, so a reviewer should not treat it as proof that every CUI artifact on a mobile device is protected. It supports the storage side of 03.01.18 when CUI is synced to a phone and held on server-side storage, but it is not device encryption and does not show that a lost handset is protected. Confirm which data is covered and what the team must add for file names and the device itself.

OpenBao transit encryption

OpenBao's transit secrets engine encrypts and decrypts application data without storing it, signs and verifies data, and supports versioned keys with key rotation. It is a key management service for applications, so it can show that encryption keys are controlled and rotated. It is not a device encryption tool and does not encrypt a mobile device, a container or the data stored on a phone. Use it as supporting evidence for key handling in mobile-facing applications, and confirm that the mobile device encryption itself comes from the platform or an MDM product.

Who does what for 03.01.18: your team, a partner and the auditor

Your organization owns requirement 03.01.18. That means the usage restrictions, the configuration and connection rules for mobile devices, the decision to authorize each device class, and the choice of encryption approach for CUI on phones and tablets all sit with you. The organization-defined parameters that the requirement leaves open, such as which device types may connect and what counts as an acceptable container or full-device encryption setting, must be decided and approved by named people. Your team also signs off the system security plan entry and accepts residual risk.

Policy and rules of behavior: Write or approve the mobile device access control policy and the procedures that staff follow when they enroll a device.
Device boundary decisions: Decide which mobile operating systems, ownership models (corporate-owned or personal) and apps may touch CUI.
ODP and parameter decisions: Record the values you chose for each open parameter and why, so an assessor can trace them.
Sign-off and ownership: Name the accountable owner and the approver for exceptions.
Operating the control: Monitor compliance, handle lost or departing devices and keep the records current.

Before engaging anyone, confirm that a named owner can explain every decision on this list without help from a vendor.

What changed for 03.01.18 between Rev. 2 and Rev. 3

Rev. 3 merged the old mobile device connection requirement, 03.01.19, into 03.01.18, and NIST classifies the change from Rev. 2 requirement 3.1.18 as significant, with more detail and more foundational tasks. For an assessor, this means the single Rev. 3 requirement now covers three things that Rev. 2 split across two requirements: usage restrictions and configuration and connection requirements for mobile devices, authorization of each mobile device connection to the system, and full-device or container-based encryption of CUI on the device. If your current evidence maps one item to 3.1.18 and another to 3.1.19, reorganize it so that each Rev. 3 determination statement for 03.01.18 has an artifact behind it. Compare the NIST change analysis spreadsheet line by line with your existing assessment worksheet before you assume any old evidence still applies.

The contract picture is less settled than the standard itself. CMMC Level 2 still uses Rev. 2, so the practice AC.L2-3.1.18 remains in scope and is worth 5 points under the scoring methodology in 32 CFR 170.24. Under 32 CFR 170.21, a practice with that point value cannot be carried on a plan of action and milestones to reach Conditional status, so a mobile device connection gap that is not fixed before assessment can block that status. A DoW class deviation signed 3 September 2026 directs contracting officers to a revised DFARS 252.204-7012 that names Rev. 2 explicitly, while a proposed FAR rule published 23 June 2026 would require Rev. 3 with ODP values published by the DoW CIO. The FAR rule was not final as of October 2026, so ask your contracting officer which revision and which ODP values apply to your contract, and get the answer in writing.

Plan for the Rev. 3 wording now, because the ODP values for 03.01.18 that a future contract may specify are not yet known. Ask the contracting officer, and any prime that flows the clause down, which mobile device types, encryption method and connection authorization standard they expect, and whether a container-based approach is acceptable for your environment. Where you have an open decision, record it in the system security plan rather than leaving it implicit. Confirm the status of the FAR rule and any DoW CIO ODP publication directly with the agency or prime before you commit budget to a specific mobile device architecture, since the answer determines which Rev. 3 ODP values you have to meet.

Questions buyers ask about 03.01.18 cost, effort and outside help

How much effort does 03.01.18 take to implement?

The effort depends mainly on how many mobile device types reach CUI, how many of them are already managed, and how much of the requirement is already written down. Most of the work is not technical: it is the usage restrictions, configuration and connection requirements, the authorization step for each device, and the evidence that shows each one was followed. Organizations with a current mobile device policy and an enrolled device fleet usually have less to build than those starting from unmanaged personal phones. Ask any partner to break the effort into policy, configuration, encryption verification and evidence collection, so you can see which parts your team already owns.

Can existing MDM tools meet 03.01.18 on their own?

An MDM platform can enforce many of the configuration and encryption settings the requirement expects, but it does not write the policy, decide which devices are authorized, or prove the result to an assessor. The requirement also covers usage restrictions and the connection rules for mobile devices, so the MDM tool must be configured to match a documented policy. Confirm with your MDM vendor which encryption and connection controls it can enforce and report on, and whether it can show compliance status per device. Where it cannot, a supplementary compliance check, such as an osquery-based policy in Fleet, can report pass or fail results per device.

Can bring-your-own-device phones comply with 03.01.18?

Personal devices can be brought into scope, but only if the organization can enforce the required settings and encryption on them and authorize their connection before access. Many organizations separate work data into a managed container so the rest of the device stays personal, which is one way to address container-based encryption. Where a device cannot meet the configuration or encryption rules, the usual answer is to deny it access to systems that hold CUI. Confirm with your assessor how they expect personal devices to be documented, since the evidence for each device must still show authorization and enforced settings.

Do we need an outside partner to meet 03.01.18?

Outside help is optional, but it is most useful when internal staff lack time, or when the mobile environment spans several device platforms and tools. Organizations own their controls, and the requirement cannot be delegated to a partner, but a partner can prepare configurations, collect evidence, and document the procedures an assessor will examine. DeployOpen plans, implements and documents self-hosted open-source platforms in your own environment, and does not issue assessment reports or certifications. Ask any firm to state in writing which tasks it performs and which stay with your team.

What does the internal team have to provide for 03.01.18?

The internal team has to make decisions that only the organization can make. These include which mobile device types may connect, which usage restrictions apply, who approves a device before it connects, and which people are responsible for mobile access control. The team also supplies access to the MDM or device management system, existing policy documents, and the people an assessor will interview. Without named owners for these decisions, configuration work often stalls, so confirm the owners before any scope is agreed.

How long does 03.01.18 take from start to finish?

The timeline depends on the size of the mobile fleet, how mature the existing device management is, and how many systems the devices reach. Work usually runs in sequence: policy and authorization rules first, then device configuration and encryption checks, then evidence collection. Engagements of this kind are fixed-scope, so the timeline is agreed in writing once the scope and deliverables are known. Ask for a timeline tied to named milestones and the people who must approve each one, rather than a single overall estimate.

Does one mobile device policy cover both Rev. 2 and Rev. 3?

A single well-written policy can serve both versions because the substance of the access control expectations carries over. Rev. 2 treats this topic as 3.1.18, and Rev. 3 folded 3.1.19 into 03.01.18 while expanding the detail and foundational tasks. Where a contract requires Rev. 2, the CMMC Level 2 practice AC.L2-3.1.18 is what gets scored, so your evidence should map to that practice as well. Confirm with your contracting officer which version applies, because the answer determines how the policy and its evidence are labeled.

What will an assessor ask first about 03.01.18?

An assessor typically starts by reading the access control policy and the procedures for mobile devices, then checks whether the documented rules match what is configured. They will ask who authorizes a device to connect, and they will want to see the record for a sample of devices. Interviews focus on the people who manage mobile access and the people who use it. Tests then check whether the connection controls and encryption actually work on the devices. Prepare the policy, the authorization records, and a current device status report before the assessment begins.

How DeployOpen scopes and prepares 03.01.18 evidence

DeployOpen works on 03.01.18 as a fixed-scope engagement inside your own infrastructure. We prepare the mobile usage rules, connection controls, encryption settings and evidence an assessor will examine, interview against and test, while your organization owns the control and an independent assessor issues any findings or reports.

How we scope

Confirm which mobile devices and operating systems connect to systems that handle CUI, and who uses them.
Identify which connection paths, such as email, VPN and file sync clients, reach the CUI system.
Agree in writing which full-device or container-based encryption approach applies, and which parts remain your responsibility.

How we build

Configure mobile usage restrictions and connection requirements that your access control policy and procedures define.
Set up device authorization before connection, and check that unauthorized mobile devices are blocked from CUI systems.
Deploy endpoint configuration checks, such as Wazuh policies or Fleet queries, and test that encryption and lock settings hold.

How we hand over

Deliver the mobile device access control procedures, system design documentation and configuration records an assessor will examine.
Document test results for each of the five 03.01.18 determination statements, including failing items and remediation steps.
Provide a walkthrough so your access control and mobile administrators can answer interview questions with consistent answers.

How we support

Ongoing support and continuous testing of mobile device settings are available as a retainer, once the initial scope is delivered.
Review changes to device fleets, operating system versions and connection paths against the written scope and documentation.
Ask any partner quoting this work to confirm which assessment method, organization-defined parameter values and evidence owners apply to your environment.