Securing Your Fleet: Why You Must Remove Inactive Devices

In a massive enterprise fleet, “Zombie Devices”—endpoints that are no longer in use but remain enrolled in the UEM—are more than just an administrative nuisance. They represent license leakage, inflated security risks, and distorted compliance reporting.

The Expiry Watchdog defines the automated logic within Hexnode UEM for identifying, restricting, and eventually decommissioning inactive devices. By leveraging Hexnode’s Native Inactivity Settings, Compliance Policies, and Dynamic Groups, IT ensures the fleet stays lean, secure, and cost-effective.

1. The Strategic Logic: “Cleanliness as Code”

The Watchdog operates on a time-based workflow. Instead of an admin guessing which devices are dead, the system monitors the time duration for which the enrolled device has lost communication with the Hexnode UEM server.

• License Recovery: Automatically reclaims seats from lost or discarded hardware, preventing unnecessary subscription costs.
• Security Hardening: Reduces the “Attack Surface” by ensuring only active, compliant devices have access to corporate data.
• Reporting Accuracy: Provides leadership with a “True North” view of active assets, untainted by devices sitting offline for months.

2. Implementation Workflow: The Step-by-Step Hexnode Watchdog

To build the Watchdog in Hexnode UEM, administrators must chain together a specific sequence of configurations:

Step A: Define the Threshold (Inactivity Settings)

Before a device can be acted upon, Hexnode needs to know what “Inactive” means for your organization.

• Where: Admin > General Settings > Inactivity Settings
• Action: Check Mark Inactivity. Set the duration (Days/Hours/Minutes) after which a device is flagged. (e.g., Mark devices as inactive after: 30 Days).

Step B: Trigger the Violation (Compliance Policy)

Inactivity alone is just a status. To enforce security, we must tie inactivity to a Compliance Violation.

• Where: Policies > Compliance Policies > New Policy > [Platform] > Basic Settings (or Advanced Settings based on platform).
• Action: Enable Device becomes inactive.
• Result: If the device has not scanned in for the number of days specified in Step A, Hexnode instantly marks the device as Non-Compliant.

Step C: The Quarantine Group (Dynamic Device Groups)

Instead of hunting for inactive devices, Hexnode can automatically corral them into a specific bucket the moment they go dark.

• Where: Manage > Device Groups > New Dynamic Group
• Action: Configure the Condition Filter as: Compliance info -> Device Status -> is -> Inactive.
• Result: As soon as a device hits the 30-day mark, it dynamically populates into this group. You can now associate restrictive policies to this group (e.g., removing Wi-Fi profiles, hiding corporate apps, or removing email access) to secure the device while it’s offline.

Step D: The Warning Window (Broadcast Message)

Before taking destructive action, attempt to reach the user.

• Where: Manage > Device Groups (Filter by the Dynamic Group).
• Action: Select the devices and choose the Broadcast Message remote action.
• Message: “Your device hasn’t synced with the network recently. Please power it on and connect to Wi-Fi to maintain corporate access.”
• Note: If the device is completely dead, the message stays queued. If someone boots it up and connects to a network, the message will immediately appear, acting as a final warning.

Step E: The Clean Up (Wipe & Disenrollment)

If the device remains in the Dynamic Group indefinitely (e.g., hits Day 60 or 90), it is time to remove it and reclaim the license. This can be scheduled to run automatically or done in bulk:

• Automated Scheduled Cleanup: You can automate the wipe action using Hexnode’s Automation feature. Go to the Automate tab, set the trigger to Time, and choose Repeat at a set schedule. From here, configure the Scheduled Day and Scheduled Time (e.g., set it to run monthly). You can target your Inactive Dynamic Group so that the system routinely scrubs dead devices based on your required schedule without manual intervention.
• Manual Bulk Action: Navigate to the Manage tab, choose your Inactive Dynamic Group, and apply a final Remote Action:
  • Corporate Data Wipe: Removes only the managed corporate apps, configurations, and accounts. (Best for BYOD).
  • Device Wipe: Initiates a full factory reset. (Best for Corporate-Owned hardware).
  • Disenroll and Delete Device: Instantly removes the device from the Hexnode portal, deleting it from the inventory and freeing up the license seat.

3. Comparison: Manual Cleanup vs. The Expiry Watchdog

4. Security & Compliance Guardrails

• Exclusion Groups: Always ensure high-priority users (Executives) or specialized hardware (e.g., industrial sensors that only check-in quarterly) are excluded from the Inactivity Compliance Policy to prevent accidental wipes.
• The “Safety-Net” Policy: Before executing a Day-90 Device Wipe, run a Scan Device Location remote action. If the device briefly checked in and reported a known branch office location, the watchdog can alert the local site manager to physically recover it.
• Action History: Every remote action (Broadcast, Wipe, Disenroll) is logged in the Action History and Reports tab, providing a clear audit trail for asset management.

5. Troubleshooting: Recovering a “Zombie”

• Accidental Disenrollment: If a user returns from a long sabbatical and their device was subjected to a “Disenroll and Delete” action, the device must go through the entire initial Enrollment process again to regain access.
• Sync Failures: If a user claims the device has been powered on but it was still flagged as Inactive, check the following.
  • For Apple Devices: Verify that your Apple Push Notification service (APNs) certificate hasn’t expired, as this requires manual annual renewal in the Hexnode portal.
  • For Android/Windows Devices: Check the status of the Firebase Cloud Messaging (FCM) or Windows Push Notification Services (WNS) pushes to see if they are marked as Success or Failed.