BYOD is a frequent assessment question because the answer depends on architecture, not on a specific BYOD-named practice in the rule. CMMC applies its requirements to whatever assets fall in scope; ownership does not change the requirement.
The rule's position
NIST SP 800-171 Rev 2 does not contain a practice that says "BYOD is prohibited." The standard applies to systems that process, store, or transmit CUI (and to SPAs that protect them). If a personal device falls into one of those categories, the personal device is in scope and the relevant practices apply to it.
What "BYOD as a CUI Asset" requires
If you allow personal devices to handle CUI, those devices must satisfy at minimum:
- AC family — access control to the device, account management, separation of duties.
- IA family — identification and MFA, including 3.5.3.
- MP family — media protection including marking and sanitization on offboarding.
- SC family — including FIPS-validated cryptography for CUI at rest and in transit (3.13.11).
- SI family — flaw remediation, malicious code protection, malicious code definition updates.
- CM family — baseline configuration, configuration settings, software allowlisting.
- AU family — audit logging from the device.
This generally requires MDM enrollment, conditional access enforcement, app-level controls, and offboarding sanitization. Most users won't accept the level of OSA control that requires.
The cleaner pattern: technically prevent personal devices from accessing CUI
Most contractors I work with adopt this pattern. The implementation depends on the platform:
- Identity-provider conditional access: Require compliant device (managed by your MDM and meeting compliance policy) for access to CUI applications. Require domain-joined, hybrid-joined, or directory-joined device for privileged operations. Block unmanaged device access to CUI mailboxes, file storage, and collaboration locations.
- Network-level controls: Allow CUI environment access only from corporate-managed networks or VPN connections that require compliant-device authentication.
- Application-level controls: Restrict CUI applications and data to managed devices only.
Personal devices are then technically excluded from the CUI environment, which removes them from scope. Document the technical control and the policy that backs it.
The middle ground: app protection without full device enrollment
Many MDM platforms offer app protection policies that can apply to personal devices without full device enrollment — commonly called Mobile Application Management without Mobile Device Management (MAM-WE). These policies can encrypt app data, prevent copy/paste to unmanaged apps, and wipe app data on offboarding. Whether this satisfies the relevant NIST 800-171 practices depends on what data flows through the app and how the controls are evaluated — this is a judgment call the C3PAO will assess on a per-implementation basis.
Common errors
- BYOD policy that says "users should not put CUI on personal devices" without technical enforcement. Policy alone makes the personal device a CRMA at best, not Out-of-Scope.
- Allowing personal devices to access webmail or mobile email apps for CUI mailboxes. If CUI emails arrive on a personal device, the device is processing CUI.
- Unmanaged personal phones receiving MFA push notifications for privileged accounts. Some assessors take a hard line that this makes the personal phone an SPA (it provides authentication to a CUI environment).
- Not addressing BYOD in the SSP at all. The SSP should explicitly state the OSA's BYOD posture and the controls that enforce it.
Sources
Choose and document your BYOD posture.
The CMMC Compliance Engine includes the AGR-BYOD-01_Bring_Your_Own_Device_Agreement and the PRO-CM-04_Mobile_Device_MDM_Procedure.
Get the CMMC Compliance Engine