Enforcing Device Compliance at Scale: A Practical Guide to MDM for Security Teams

Last quarter, a contractor's personal tablet—unpatched for seven months—connected to our corporate SharePoint and exfiltrated 12,000 records before anyone noticed. The device had been "enrolled" in our MDM, but enrollment without enforcement is just inventory management with extra steps. That incident rewired how I think about device compliance, and this post captures the framework I've since built.

Why Enrollment Alone Isn't Compliance

Most organizations conflate MDM enrollment with device compliance. They are fundamentally different. Enrollment means the device is known. Compliance means the device meets a defined security baseline—OS version, encryption status, jailbreak detection, password complexity, and more—and is continuously evaluated against that baseline.

The real power of MDM emerges when you couple compliance policies with conditional access: non-compliant devices are denied access to corporate resources automatically, with zero manual intervention.

Defining a Compliance Policy: What Actually Matters

A practical compliance policy should cover these baseline signals at minimum:

• OS minimum version (patching posture)
• Disk encryption enabled (BitLocker, FileVault, or hardware encryption)
• Screen lock enforced with timeout ≤ 5 minutes
• Device not jailbroken/rooted
• Threat detection agent active (e.g., Microsoft Defender, CrowdStrike)

In Microsoft Intune, you can define these as a JSON-based compliance policy. Here's an example using the Microsoft Graph API:

# Create a Windows 10+ compliance policy via Graph API
curl -X POST https://graph.microsoft.com/v1.0/deviceManagement/deviceCompliancePolicies \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "@odata.type": "#microsoft.graph.windows10CompliancePolicy",
    "displayName": "Corp-Win-Baseline-v2",
    "osMinimumVersion": "10.0.22621",
    "bitLockerEnabled": true,
    "secureBootEnabled": true,
    "passwordRequired": true,
    "passwordMinimumLength": 12,
    "scheduledActionsForRule": [{
      "ruleName": "PasswordRequired",
      "scheduledActionConfigurations": [{
        "actionType": "block",
        "gracePeriodHours": 24
      }]
    }]
  }'

The gracePeriodHours field is critical—it gives users 24 hours to remediate before access is revoked, reducing helpdesk friction while maintaining enforcement.

Wiring Compliance to Conditional Access

A compliance policy without enforcement is a suggestion. In Azure AD (Entra ID), create a conditional access policy that requires device compliance:

Policy: Require Compliant Device for Cloud Apps
├── Assignments
│   ├── Users: All employees, excluding break-glass accounts
│   └── Cloud apps: All cloud apps
├── Conditions
│   └── Device platforms: Windows, iOS, Android, macOS
└── Grant
    └── Require device to be marked as compliant

This single gate ensures that every authentication request is evaluated against real-time device posture. A device that falls out of compliance—say, a user disables BitLocker—loses access within minutes, not days.

Automated Remediation: Closing the Loop

Blocking users isn't the end goal—getting them compliant is. Push remediation actions through your MDM:

# Intune remediation script: Re-enable BitLocker silently
$BLV = Get-BitLockerVolume -MountPoint "C:"
if ($BLV.ProtectionStatus -eq "Off") {
    Enable-BitLocker -MountPoint "C:" -EncryptionMethod XtsAes256 `
      -RecoveryPasswordProtector
    BackupToAAD-BitLockerKeyProtector -MountPoint "C:" `
      -KeyProtectorId $BLV.KeyProtector[0].KeyProtectorId
}

Deploy this as a proactive remediation script in Intune, scheduled every 4 hours. The device self-heals before the user even notices a problem.

Monitoring and Reporting for SOC Teams

Feed compliance state into your SIEM. Intune exports device compliance logs via Diagnostic Settings to Log Analytics:

// KQL: Devices non-compliant for more than 48 hours
IntuneDeviceComplianceOrg
| where ComplianceState == "NonCompliant"
| where TimeGenerated < ago(48h)
| summarize by DeviceName, UserPrincipalName, OS, ComplianceState

This query becomes an automated alert—any device non-compliant beyond 48 hours triggers an incident for investigation.

Final Takeaway

Device compliance isn't a checkbox. It's a continuous feedback loop: define policy, enforce access, remediate automatically, and monitor exceptions. Treat every unmanaged or non-compliant endpoint as an active threat vector—because to an attacker, that's exactly what it is.

Have questions about device compliance and mobile device management? I'm always happy to talk shop — reach out or connect with me on LinkedIn.