Mobile Device Management for CUI: iOS, Android, and the BYOD Question

Mobile endpoints enter your CUI boundary as soon as users access or store CUI on them. NIST SP 800-171 requires you to protect CUI across all in-scope components, and DFARS 252.204-7012 points you to that standard for adequate security. The DoD CMMC Level 2 Assessment Guide and the Cyber AB CAP both scope assessments to where CUI lives or moves, which includes smartphones and tablets that touch CUI. Treat iOS and Android as first-class endpoints in your boundary, or keep them out by design and enforce that choice.

Scope and assessment expectations

Assessors follow the CMMC Level 2 Assessment Guide and the Cyber AB CAP. Both documents drive scope from the presence of CUI. If users open CUI from Exchange Online or SharePoint on a phone, that device falls in scope. If you restrict mobile clients so they cannot reach CUI resources, you can keep those devices out of scope, but you must prove the restriction.

Your team should align this decision with your system boundary and SSP. If you include mobile, define which device types and ownership models sit in scope. If you exclude mobile, configure access controls that block mobile clients from CUI paths. Our scoping guidance provides a practical frame for this decision: CMMC scoping and the CUI boundary.

NIST SP 800-171 control drivers on mobile

NIST SP 800-171 Rev. 2 sets the floor. Several practices drive mobile requirements:

AC.L2-3.1.1 and IA.L2-3.5.1 require you to limit access to authorized users and devices, and to identify those users and devices. That means you must know which phones and tablets reach CUI.
IA.L2-3.5.3 requires multifactor authentication for network access. Mobile clients that reach CUI must use MFA through your identity provider.
AC.L2-3.1.19 requires usage restrictions and implementation guidance for mobile devices that process, store, or transmit CUI. You need written rules and technical enforcement for iOS and Android use.
SC.L2-3.13.8 requires cryptographic protection in transit. Enforce TLS for app and browser sessions that move CUI over Wi‑Fi or mobile networks.
SC.L2-3.13.11 requires FIPS-validated cryptography for CUI at rest on mobile devices and media. Your baseline needs an encryption policy that meets this requirement.
MP.L2-3.8.3 requires sanitization or destruction of media that held CUI. You must plan for device retirement, device loss, and reuse.
CM.L2-3.4.1 requires baseline configurations. You need standard mobile OS settings for CUI work.
SI.L2-3.14.1 requires flaw remediation. You must keep mobile OS and apps patched on a schedule you can defend.

These controls apply to corporate-owned and BYOD devices once they touch CUI. If you cannot meet them on a class of devices, keep that class out of scope and block access.

Mobile management patterns for iOS and Android

You can choose device-level control or app-level control, and many programs use both.

Mobile Device Management, or MDM, controls the device. Administrators configure device encryption, screen lock, OS version minimums, and block jailbroken or rooted phones. MDM fits corporate-owned devices and COPE models.
Mobile Application Management, or MAM, protects data inside managed apps. Administrators require a PIN to open a corporate app, encrypt app data, control copy or save behavior, and perform a selective wipe that removes organization data while leaving personal data in place.

GSA mobile security guidance aligns with those patterns. It calls for enterprise management to enforce configuration and for clear policy around strong authentication and remote wipe. It also urges a VPN requirement or equivalent protection for untrusted networks. Those expectations map cleanly to MDM and MAM capabilities on iOS and Android.

Common BYOD patterns separate work and personal data. Android Enterprise work profiles create a distinct work container. iOS and iPadOS User Enrollment binds management to the work account with a lighter device footprint. Treat these as techniques you can use within a documented program, not as policy on their own.

BYOD risk and policy choices

BYOD introduces ownership and privacy tension. You hold responsibility for CUI, but users hold the device and personal data. Write the rules before you turn on access.

Adopt a written BYOD policy that defines acceptable use and enforcement. Include consent to selective wipe of organization data and removal of access on policy breach.
Involve legal and HR so you handle privacy, labor rules, and evidence handling with clarity.

You also need a technical floor that you can prove.

Require MFA, app protection, and conditional access for any mobile path to CUI. Block unknown and non-compliant devices.
Require encryption and screen locks on any device that opens CUI, and document how you verify those settings.

NIST AC.L2-3.1.19 expects usage restrictions and monitoring for mobile. If you cannot meet that with BYOD, do not allow BYOD for CUI. Provide a corporate-owned option instead.

Intune controls and Conditional Access enforcement

Microsoft Intune and Entra ID Conditional Access give you enforcement levers that map to the controls above.

Intune device compliance policies for iOS and Android let you require passcodes, encryption, OS version minimums, and block jailbroken or rooted devices. Conditional Access can then allow access only from devices that report compliant status. See our baseline discussion: Intune compliance for CUI.
Intune app protection policies deliver MAM on both managed and unmanaged devices. You can require a PIN to open Outlook, encrypt managed app data, block data transfer to unmanaged apps, and issue a selective wipe of organization data. Conditional Access can require an approved app with app protection to reach Exchange Online or SharePoint.

Pair these controls with Conditional Access policies that enforce your scoping decision. You can require a compliant device for any app that can reach CUI. You can restrict browser access to approved clients. You can block unknown clients from sensitive endpoints and allow them only to low-risk services. For enforcement patterns across cloud and on-prem paths, see Conditional Access for DFARS 7012.

GCC High and tenant selection factors

Microsoft publishes differences across commercial, GCC, GCC High, and DoD environments. GCC High and DoD target defense workloads and data residency needs that often pair with CUI programs. Validate current service availability and feature behavior in your tenant before you commit to a pattern. Some mobile features can arrive in government clouds on a different schedule than commercial. Microsoft provides a Product Placemat for CMMC as a preview reference. Treat it as informational mapping, not as an authorization or a guarantee.

Do not assume a tenant name solves control implementation. You still need scoping, policy, technical enforcement, and evidence. Pick the tenant that aligns with your obligations and then configure the controls listed above.

A practical starting plan

You can frame a mobile decision in two steps and move to build.

Decide scope and ownership. Include or exclude mobile from the CUI boundary. If you include, choose COBO or COPE as the default path. If you allow BYOD for any CUI use, define exact use cases and limits.
Build the baseline. Configure Intune compliance policies and app protection for iOS and Android, and wire Conditional Access to block anything outside that baseline.

Then document how you meet AC.L2-3.1.19 and related controls on mobile, and record evidence. If you exclude mobile, document the Conditional Access rules and any other gates that keep CUI off phones and tablets.