Mobile Devices in CMMC Scope and How to Protect Them

An employee checks a contract email on a personal phone. A technician photographs a controlled drawing with a tablet. A manager opens a project file from a mobile app. Those everyday actions can bring mobile devices into your CMMC assessment scope.

Start with the information and the workflow: does the device process, store, or transmit Federal Contract Information (FCI) or Controlled Unclassified Information (CUI)? Then determine which safeguards, systems, and people support that activity. Company ownership, a passcode, or an MDM subscription alone does not settle the question.

Level 1 and Level 2 have different requirements

CMMC Level 1 addresses safeguarding FCI. Level 2 addresses CUI and uses the 110 security requirements in NIST SP 800-171 Revision 2 under the CMMC rule. Although NIST has published Revision 3, do not substitute its requirement numbering for the Level 2 assessment baseline. Confirm your contract’s applicable obligations.

This guide focuses on Level 2 mobile security. Its mobile encryption requirements should not be presented as standalone Level 1 requirements. Source: 32 CFR 170.14.

When is a mobile device in scope?

Smartphones and tablets that handle CUI are CUI Assets. Ownership does not change the data flow. Consider these examples when reviewing your environment:

Level 2 also includes Security Protection Assets and Contractor Risk Managed Assets. The latter are capable of handling CUI but are not intended to do so under the organization’s policies and practices. They remain in scope. Document the category that matches actual capabilities and use. Source: Level 2 Scoping Guide.

The Big Catch Policy vs Technical Enforcement

A written policy saying “Mobile devices are not allowed to access email containing FCI” is a useful starting point. But a handbook rule does not itself block a phone from opening that mailbox.

If your plan is to keep mobile devices away from FCI or CUI, verify that the access restrictions actually work. Test mobile browsers and native mail apps, not just the approved work app. A successful login is a warning to investigate: can that session read, download, cache, or send the protected information?

Keep the Level 1 and Level 2 scope rules distinct

For Level 1, systems that process, store, or transmit FCI are in scope. The mere theoretical ability to enter a password is not, by itself, the rule’s test for declaring every mobile device in scope. However, unrestricted access to an FCI mailbox undermines a claim that mobile devices are excluded from that workflow.

For Level 2, Out-of-Scope Assets must be unable to process, store, or transmit CUI and must not provide security protection for CUI Assets. A device capable of handling CUI but prohibited by policy may instead be a Contractor Risk Managed Asset, which remains in scope. Source: 32 CFR 170.19.

Turn the policy into enforceable access controls

• Block prohibited access: configure identity and application access policies to reject the mobile workflows your organization does not authorize.
• Enforce approved access: where mobile use is permitted, require the appropriate device compliance or app protection conditions.
• Check alternative paths: test browser access, native mail clients, unmanaged apps, and any enabled legacy authentication paths.
• Keep evidence: retain relevant policy settings, assignments, sign-in results, and dated tests showing permitted access succeeds and prohibited access fails.

For supported Microsoft environments, Conditional Access and Intune can help enforce device compliance and app protection conditions. Confirm the policies cover the intended users, applications, and access paths. Source: Microsoft Conditional Access guidance.

The policy states what is allowed. Technical controls help enforce it. Testing shows whether the controls work.

What if the device is already in scope?

Give it a defined place in your security program. Identify its owner and unique device identifier, approve its connections, establish its configuration, and show how those connections are monitored and logged. Address the applicable Level 2 requirements across the assessed system; mobile security extends beyond two mobile-specific controls.

Prepare evidence such as authorization records, policy assignments, configuration reports, encryption verification, relevant connection logs, and tests showing unauthorized access is blocked. A policy document describes expectations; assessment evidence shows implementation. Source: Level 2 Assessment Guide, AC.L2-3.1.18.

Key Level 2 requirements affecting mobile devices

This is a starting point, not the complete control set. Configuration management, auditing, incident response, physical protection, and system integrity also matter. Source: NIST SP 800-171 Revision 2.

Practical protections for approved phones and tablets

Build a mobile security baseline suited to the device and its approved use:

• Manage the device: enroll approved devices in an appropriate management system and track their security status.
• Keep it supported: maintain operating system and app updates; block unsupported or compromised devices.
• Protect access: enforce screen locking, suitable authentication, and least privilege.
• Limit data movement: restrict personal cloud backups, unmanaged apps, and unauthorized sharing.
• Protect the device: evaluate mobile threat defense and application vetting based on risk and platform capability.
• Prepare for loss: define reporting, access revocation, and remote lock or wipe procedures. A wipe may not execute while a device is offline.
• Retire it safely: remove access and sanitize business information before reassignment or disposal.

NIST mobile guidance supports these measures, but the particular products and settings must be evaluated against your CMMC obligations. Source: NIST SP 800-124 Revision 2.

Encryption needs verification

For CUI confidentiality, an “AES-256” claim alone does not establish FIPS validation. Verify the actual cryptographic module, supported version and platform, and required operating configuration against its validation documentation. Full-device or container-based encryption can be appropriate, but verify coverage of every location where CUI is stored. Source: Level 2 Assessment Guide, AC.L2-3.1.19 and SC.L2-3.13.11.

For the basic distinction between confidentiality and verification, read Hashing vs Encryption.

How MDM, app protection, and Conditional Access help

Mobile Device Management (MDM) manages the device. Mobile Application Management (MAM) focuses on supported work apps and their data. They provide different layers of control.

For example, Microsoft Intune app protection policies can restrict copying work data into personal apps, saving it to personal storage, and access from rooted or jailbroken devices. They can also support selective removal of work data. These controls apply to supported apps and configurations; they do not cover every app or every possible way to capture information.

Conditional Access can enforce access decisions using device compliance or app protection requirements. Test both permitted and blocked paths, including browser access and alternative mail clients. Source: Microsoft Intune app protection guidance; Conditional Access guidance.

“Compliant” in an MDM dashboard means the device meets your configured policies. It is not a CMMC certification.

Can Employees Use Personal Devices? Two BYOD Approaches

Bring Your Own Device (BYOD) can be part of a CMMC safeguarding strategy, but personal ownership does not exempt a phone or laptop from scope. Start by deciding whether the device needs to handle FCI or CUI, then choose controls that match that use.

Approach 1: Block protected information from personal devices

For a small business that only needs Level 1, BCS recommends keeping FCI on a limited set of approved company devices whenever practical. Employees may use personal devices for permitted general tasks, provided those tasks do not expose FCI.

Use access controls to restrict the accounts and resources containing FCI to approved devices. Test mobile browsers, native mail apps, managed apps, downloads, forwarding, sync, and backup paths. An unrestricted work mailbox or chat channel can undermine the boundary if it contains FCI.

This can help keep Level 1 scope small when personal devices do not process, store, or transmit FCI. For Level 2, verify the stricter Out-of-Scope Asset criteria, including separation from CUI Assets and whether the device provides security protection. A device capable of handling CUI but prohibited by policy may remain in scope as a Contractor Risk Managed Asset. See the Level 1 and Level 2 scoping guides.

Approach 2: Allow approved access with app or device management

If personal phones must access protected work information, use supported Mobile Application Management (MAM), a managed work profile, Mobile Device Management (MDM), or a combination suited to the environment. Pair app protection with Conditional Access so users cannot bypass it through an unmanaged access path.

Depending on the platform, app, and configuration, protections can require an app PIN, encrypt corporate app data, restrict copying or saving to personal apps, and selectively remove company data. Verify screenshot, printing, sharing, and backup restrictions on each supported platform rather than assuming every tool provides identical controls.

Selective wipe can protect employee privacy by removing managed company data instead of resetting the entire phone. It depends on the device and app receiving the request; a lost, offline phone may not receive it promptly. Revoke account access and sessions as part of the response. Microsoft Intune app protection documentation explains supported capabilities and limitations.

A work container is a protection layer, not an automatic assessment boundary. A personal device that handles FCI remains relevant to Level 1 scope; one that processes, stores, or transmits CUI is a CUI Asset for Level 2. Evaluate the underlying device and supporting environment against applicable requirements, including verified cryptography for CUI. Do not promise that an assessor will evaluate only the container.

BCS recommendation: Keep FCI off personal devices when mobile access is unnecessary. If BYOD access is needed, approve the devices and apps, enforce and test the controls, and account for that access in your scope. Read CMMC Scoping Explained for Small Businesses for a practical Level 1 starting point.

Choose a mobile access approach your business can support

BCS recommends deciding how much mobile access you actually need before choosing tools:

• Keep FCI or CUI off mobile devices: enforce access restrictions and provide an approved alternative for the work.
• Use company-owned managed devices: standardize models, supported versions, settings, and evidence collection.
• Permit controlled BYOD: define approved uses, required controls, employee consent, business data removal, and offboarding. If the organization cannot verify and enforce the needed controls, restrict that workflow.
• Use a tightly restricted VDI workflow: evaluate the specific endpoint exception rather than assuming any remote access product removes scope.

Company-owned devices are often easier to standardize. BYOD can add privacy and support complications. Neither ownership model guarantees compliance.

Can VDI keep a mobile endpoint out of scope?

The scoping rule includes an exception for a VDI client endpoint configured so no FCI or CUI processing, storage, or transmission occurs beyond keyboard, video, and mouse interaction with the VDI client. The assessed backend remains subject to its requirements.

Validate local download, clipboard, drive redirection, printing, and other transfer paths. Ordinary browser access to a cloud file is not automatically this exception. Screen capture and other capture risks also need review; do not claim a control works without testing the actual platform. Source: 32 CFR 170.19.

Remember the services protecting the device

Your MDM, identity provider, logging, and other security services may also affect scope. Review whether providers handle CUI or Security Protection Data and document responsibilities. A cloud service handling CUI must meet the applicable FedRAMP requirements under DFARS 252.204-7012; a service handling only Security Protection Data has different scoping treatment. Do not assume every MDM service must be FedRAMP authorized simply because it manages a CUI device. Source: 32 CFR 170.19.

A practical first step for your business

List the phones and tablets used for work. Ask which apps they use, which information they access, where files and photos go, and what happens when a device is lost or an employee leaves. Use those answers to map data flows, identify gaps, and decide which mobile workflows to approve.

Business Communication Solutions can help your team evaluate mobile access, implement security controls, and prepare supporting documentation as part of CMMC readiness consulting in Austin and Houston. Readiness support helps you prepare; it does not replace an assessment or guarantee a CMMC status.

Austin: 512-257-1433
Houston: 281-815-8784
Lampasas: 512-865-4000