AC.L2-3.1.18 (Policy-to-Device Implementation) requires that organizational policies governing access and acceptable use be implemented on devices — in practice this means using your Mobile Device Management (MDM) solution to translate policy statements into enforceable device configurations, enrollment workflows, monitoring, and evidence collection to support NIST SP 800‑171 Rev.2 / CMMC 2.0 Level 2 compliance.
Understanding the control and what to map
Start by mapping your written policies (acceptable use, access control, mobile device security, BYOD/CYOD rules) to specific, enforceable MDM settings. For Compliance Framework evidence you will show the policy document, a mapping matrix (policy → MDM profile/policy name → devices/groups targeted), and artifacts such as policy push logs, compliance reports, and screenshots of applied settings. Typical policy elements to map: device enrollment requirements, minimum OS and patch levels, passcode and authentication rules, encryption requirements, remote wipe/lock behavior, application controls, and restrictions on rooted/jailbroken devices.
Practical MDM implementation steps
1) Enrollment and inventory
Implement a controlled enrollment workflow: require enrollment before corporate data access, use platform-specific enrollment: Apple Automated Device Enrollment (ADE/ABM), Android Enterprise (Work Profile or Fully Managed), and Windows Autopilot + Intune. Require certificates (SCEP/PKCS) or certificate-based authentication where possible. Capture device metadata (serial, OS, IMEI, last check-in, owner, corporate/employee-owned) and ensure your MDM inventory report is exportable for audits.
2) Create policy profiles and test-change control
Define granular configuration profiles that map exactly to policies, using naming conventions like "AC-L2-3.1.18-Passcode-v1". Example settings: passcode minimum length 8, alphanumeric, maximum of 10 failed attempts before wipe, auto-lock after 5 minutes, require device encryption (iOS/Android FDE; BitLocker for Windows), disable developer/ADB mode, and block jailbroken/rooted devices. Use a staged rollout: pilot group (5–10 devices), remediation window, then broad deployment. Maintain change control and version history for each profile as evidence.
3) Enforce app and data controls
Use managed app containers (iOS Managed Open In, Android Enterprise work profile) or App Configuration Policies to prevent data leakage. Configure Managed Browser, restrict copy/paste between work and personal profiles, block backups of managed app data to personal cloud accounts, and whitelist corporate apps. Where email is used, require MDM-managed email profile with conditional access so unmanaged devices are blocked.
4) Device health attestation and rooted/jailbreak detection
Require device attestation before granting access: SafetyNet/Play Integrity for Android, APNs device tokens and DeviceCheck for iOS, and Device Health Attestation (DHA) for Windows. Configure your conditional access rules (e.g., Azure AD Conditional Access) to block devices that fail attestation, are jailbroken/rooted, or do not meet minimum OS levels (define minimums in policy and document the business/technical rationale).
Real-world small business scenarios
Scenario A — 25-employee engineering firm with mixed BYOD and company devices: Use Microsoft Intune and Azure AD. Create a "CUI-Access" compliance policy that requires enrollment, BitLocker, and Intune-managed email. Block access to SharePoint and Teams unless device is compliant (intune compliance + conditional access). Log and export compliance reports weekly for audit evidence.
Scenario B — Small defense contractor with 12 iPhones and 6 Androids: Use Jamf for iOS/macOS and Android Enterprise for Android. Enroll devices via Apple ADE for company phones; create an "ACL2-3118" profile enforcing device encryption (iOS: Data protection classes are native), disable screenshots for managed apps, and use Managed Open In to keep CUI inside managed apps. Capture screenshots of configuration profiles and enrollment logs to accompany the policy-to-device mapping in your System Security Plan (SSP).
Compliance tips, technical specifics, and risks
Technical specifics to include in your implementation evidence: profile names and versions, targeted device groups, exact policy settings (e.g., minimum OS: iOS >= 15.6, Android >= 11, passcode length and complexity), enrollment logs, attestation failure logs, and remediation tickets. Implement automated remediation: noncompliant devices receive an email instructing re-enrollment or update; after X days, access is revoked and device is marked for selective or full wipe. Don't forget to enable MDM logging/retention (365+ days recommended) and export logs regularly for audits.
Risk of not implementing: without policy-to-device enforcement you face uncontrolled access to Controlled Unclassified Information (CUI), increased attack surface from unpatched/jailbroken devices, data leakage via unmanaged apps, and failed audits that can lead to lost contracts and financial penalties. From an operational perspective, inconsistent application of policies results in gaps that attackers can exploit to bypass network controls or exfiltrate sensitive data.
Summary: To meet AC.L2-3.1.18 you must convert written access and acceptable use policies into concrete, versioned MDM profiles, deploy them through controlled enrollment (ADE, Android Enterprise, Autopilot), use device attestation and conditional access to enforce compliance, and produce traceable evidence (mapping matrix, policy versions, logs, and screenshots). For small businesses this is achievable with commercial MDM offerings by following a staged rollout, documenting changes, and automating remediation — all of which reduces risk and creates clear audit artifacts for NIST SP 800‑171 Rev.2 / CMMC 2.0 Level 2 compliance.
