Category filter

Policy Drift Detection: Implementing Self-Healing Automation in UEM

Self-Healing Automation is a “set-and-forget” security mechanism that ensures a device always stays in compliance with corporate policy. In a standard UEM setup, if a user (or a malicious script) finds a way to disable a setting—like turning off FileVault or removing a required app—the device remains “drifted” until the next manual audit.

By leveraging Hexnode’s profile enforcement, Compliance Engine, and localized scripting, the device continuously compares its local state against the assigned “Desired State.” If Policy Drift is detected, Hexnode automatically flags the device and triggers remediation workflows (like auto-reinstalling apps or executing local fix scripts) to force the device back into compliance without human intervention.

1. The Self-Healing Cycle

  1. Monitor: The Hexnode agent checks at regular intervals or relies on local OS schedulers to check specific states (e.g., “Is the required app installed?”).
  2. Detect: The engine notices a state change (e.g., the app has been deleted).
  3. Remediate: Hexnode (or a local script) immediately again deploys the missing application.
  4. Report: The event is logged in the Hexnode console’s Action History and Compliance Reports.

2. The Four Layers of Self-Healing Automation

Layer 1: Preventing Drift (Profile Enforcement)

The best way to handle policy drift is to prevent the user from altering the desired state in the first place. Hexnode relies on OS-level enrollment programs to lock down management profiles.

  • Apple Devices (macOS/iOS): Enroll devices via Apple Automated Device Enrollment (ADE). During the ADE setup in Hexnode, ensure the MDM Profile is non-removable. This gray-outs the “Remove Profile” button on the Mac or iPhone, preventing users from deleting Wi-Fi, FileVault, or Passcode policies.
  • Android Devices: Use Android Enterprise (Device Owner mode) or Samsung Knox Mobile Enrollment (KME). These modes grant Hexnode root-level management access, preventing end-users from deleting the management app or its associated configurations.

Layer 2: Detecting Drift (The Compliance Engine)

When a device falls out of your defined baseline, Hexnode’s Compliance Engine acts as the detection trigger.It monitors the device state and automatically changes its status to “Non-Compliant,” which can trigger administrative alerts.

How to configure Compliance Rules?

  1. Navigate to Policies > Compliance Policies.
  2. Click New Policy (or choose an existing template).
  3. Define your baseline rules utilizing the Basic Settings or Advanced Settings tabs. Common rules include:
    • Application Compliance: Mark the device non-compliant if a required app is missing.
    • Encryption: Mark non-compliant if FileVault or BitLocker is turned off.
    • Passcode: Mark non-compliant if the device lacks a complex passcode.
  4. Save and assign the compliance policy to your target groups. If a user alters these settings, the device immediately flags as non-compliant in the Hexnode dashboard.

Layer 3: Automated Remediation (Required Apps)

If a user deletes a critical business application, Hexnode can automatically detect the missing binary and force a re-installation.

How to enforce App Remediation?

  1. Navigate to Policies > New Policy > App Management > Required Apps.
  2. Add the required applications to the list.
  3. If a user uninstalls one of these apps, the Hexnode agent detects the absence during its next sync and automatically prompts or forces the re-installation of the application to restore compliance.

Layer 4: Advanced Self-Healing (Local Scripting)

For granular OS settings (like modifying a Windows Registry key or a macOS Plist file) that require a “Check-and-Fix” loop every few hours, UEM platforms require local daemons.

Since Hexnode deploys scripts as a one-time execution, you must use Hexnode to deploy a script that creates a persistent scheduled task directly on the endpoint.

The Self-Healing Script Workflow:

  1. Write a script (PowerShell for Windows, Bash for macOS) that performs two actions:
    • The Logic: Evaluates the current OS state (e.g., If Firewall == Off, turn On).
    • The Scheduler: Registers itself with the local OS task scheduler (Windows Task Scheduler or macOS launchd) to run automatically every 4 hours.
  2. Navigate to Manage > Select target devices > Actions > Execute Custom Script.
  3. Deploy the script.

3. Self-Healing Matrix (Common Scenarios)

Policy Type Detection Trigger (Policy Drift) Hexnode Healing Action
Full Disk Encryption Encryption is “Paused” or turned off locally. Compliance engine flags device; strict MDM profiles block the user from disabling it if enrolled via Apple ADE/KME.
Required Software Application binary is missing or deleted. Hexnode agent detects the missing app and triggers a background download and silent re-installation.
Custom OS Settings Registry key or Plist file is modified. Local scheduled task (deployed via Hexnode’s Execute Custom Script) detects the change and overwrites the key back to the desired state.

4. Monitoring & Reporting

  1. Go to Reports > Compliance Reports to see which devices have drifted out of your defined baseline.
  2. Go to the Action History tab on an individual device’s summary page to see logs of apps being automatically re-pushed or scripts executing successfully.

5. Troubleshooting

  • Infinite Loop: If a Check-and-Fix script keeps executing but the state never changes, verify that the user doesn’t have a local admin tool (like an aggressive antivirus) that is fighting the script’s commands.
  • Agent Offline: Self-healing requires the UEM agent to be active or local tasks to be running. If the Hexnode agent itself is tampered with, the device will fall into an “Out of Sync” status and fail to remediate.
Solution Framework