Intune Compliance Baselines for Protecting CUI on Managed Devices

Intune serves as the policy enforcement layer for endpoint compliance within Microsoft 365 environments. For organizations handling Controlled Unclassified Information (CUI), Intune compliance policies demonstrate that “only authorized, compliant devices access CUI.” While Conditional Access policies require device compliance upstream, Intune itself defines what compliance means operationally.

Controls Supported by the Baseline

The baseline directly supports these NIST SP 800-171 r2 practices:

• 3.1.18 / 3.1.19 — Mobile device connection control and encryption requirements on mobile platforms.
• 3.4.1 / 3.4.2 / 3.4.6 / 3.4.7 — Configuration management baseline, enforcement, least functionality principle, and restriction of unnecessary programs and ports.
• 3.5.7 / 3.5.8 — Password complexity and reuse restrictions at the device level for local accounts.
• 3.7.5 — Multifactor authentication for nonlocal maintenance sessions via external connections.
• 3.8.7 — Control over removable media usage.
• 3.13.16 — Disk encryption for CUI at rest.
• 3.14.2 / 3.14.4 / 3.14.5 — Malicious code protection mechanisms, updates, and periodic scanning.

Device policy failures trigger Conditional Access blocks to CUI applications, enforcing upstream controls.

Windows Compliance Policy Structure

A baseline Intune compliance policy for Windows 10/11 endpoints handling CUI should enforce:

Device Health Requirements:

• BitLocker enabled.
• Secure Boot enabled.
• TPM 2.0 attestation.
• Code Integrity enabled.
• Windows Defender ATP risk score of “Medium or below” (or stricter with Defender for Endpoint integration).

Operating System Standards:

• Minimum supported version (Windows 10 22H2 or Windows 11).
• OS build within the last N months to enforce patching cadence.

System Security Settings:

• Data storage encryption via BitLocker.
• Active firewall.
• Antivirus and antispyware enabled.
• Real-time protection active.
• Current signature definitions.

Password and Sign-In Requirements:

• Password required.
• Minimum complexity.
• Minimum 14 characters.
• Maximum age of 60 days (for local accounts; cloud accounts follow Entra ID policy).

Threat Protection:

• Microsoft Defender for Endpoint device risk score at “Medium” or below.

Implementation pairs the compliance policy with a configuration baseline that deploys actual settings: disk encryption profiles, attack surface reduction rules, Defender Antivirus configurations, and Windows Update for Business rings. The Microsoft Security Baseline for Windows 11 provides a reasonable starting point, trimmed to remove operational conflicts.

macOS Compliance Requirements

macOS enforcement uses different mechanisms but maintains structural similarity:

• FileVault disk encryption required.
• System Integrity Protection enabled and verified.
• Gatekeeper restricted to App Store and identified developers.
• XProtect and Notarization checking enabled.
• Minimum macOS version (typically current and current-1).
• Password requirements: complexity, 14-character minimum, 60-day maximum age where applicable.
• EDR presence. Microsoft Defender for Endpoint on Mac or third-party equivalent with Defender connector integration.

Additional MDM configuration through Apple’s protocol typically includes restricting iCloud sync to prevent CUI exfiltration, limiting AirDrop access, and managing application allowlists through Intune’s app management capabilities.

iOS and Android Compliance Baseline

Mobile devices accessing CUI through Microsoft 365 apps are themselves CUI Assets requiring compliance posture:

iOS:

• Jailbreak detection enabled.
• Minimum version (current and current-1).
• Device encryption required.
• Passcode required (minimum 6 numeric or 8 alphanumeric).

Android:

• Root detection enabled via SafetyNet or Play Integrity.
• Minimum Android version enforced.
• Play Protect enabled.
• Device encryption required.
• Screen lock with strong PIN or biometric.

Both Platforms:

• Microsoft Defender for Endpoint Mobile installed for threat detection feeding compliance state.

For BYOD scenarios, App Protection Policies (MAM) restrict CUI to managed app sandboxes without full MDM enrollment, supporting a more sustainable pattern for infrequent access on personal devices. Conditional Access requirements shift to “require app protection policy” rather than “require compliant device.”

Integration with Conditional Access

The compliance evaluation flow operates as follows:

• Device enrolls in Intune, triggering compliance evaluation.
• Results written to the device’s Entra ID object as isCompliant: true/false.
• Conditional Access policy CA-003 (“Require compliant device for CUI apps”) enforces this as a grant condition.
• Non-compliant devices lose CUI app access at next sign-in.

A critical design choice involves grace periods. In CUI environments, assessors favor immediate enforcement: grace windows create unaudited access periods that control language does not permit. See the related article on Conditional Access Policy Design for DFARS 252.204-7012 for full coverage of this integration.

Tenant Environment Considerations

Intune availability spans commercial Microsoft 365, GCC, and GCC High environments. Feature parity exists but is not identical; GCC High may lag on third-party integrations and specific mobile threat defense connectors. Tenant selection decisions should account for required Intune features and are detailed in the Migrating to Microsoft GCC High framework article.

When using Microsoft Purview labeling and DLP, the labels and device compliance reinforce each other: labeled CUI files on non-compliant devices face Conditional Access blocking, while compliant devices enforce label protections including encryption, copy-paste restrictions, and watermarking. Refer to Microsoft Purview for CUI Data Classification and DLP for labeling implementation details.

Common Assessment Gaps

• BYOD without compliance enrollment. Justified as “email only,” but email constitutes CUI handling; devices must meet the baseline or cannot access the mailbox.
• User-targeted but not device-targeted policies. Miss shared kiosks and lab equipment; both targeting approaches should apply with careful scoping.
• Overly strict Defender risk thresholds. Setting requirement to “Clear” with no exception process creates false-positive lock-outs; “Medium or below” with an escalation path is more practical.
• Missing removable media controls. NIST 3.8.7 requires implementation through device configuration profiles that disable or whitelist encrypted USB drives.
• Outdated minimum OS versions. Requirements like “Windows 10 1809 or higher” years after release are ineffective; tighten to current and current-1, reviewed quarterly.

Evidence for Assessment Review

Retain the following for auditor examination:

• Exported compliance policy JSON files and screenshots for each platform.
• Configuration profile exports covering BitLocker, ASR, Defender, and app protection settings.
• Intune device compliance reports showing non-compliant counts and remediation history.
• Sample Conditional Access sign-in logs demonstrating compliance signal evaluation.
• Device enrollment reports covering the full in-scope endpoint inventory.

Implementation Steps

• Inventory all devices accessing CUI and confirm Intune enrollment (or App Protection for BYOD mobile).
• Audit compliance policies against the platform-specific gaps listed above, tightening OS versions and adding risk requirements.
• Connect the compliance signal to CUI-app Conditional Access policies and validate through sign-in logs.
• Establish quarterly non-compliance trend reviews to identify policy-to-fleet mismatches requiring remediation.