In an earlier blog, I hinted at the need to manage inactive devices in Microsoft Defender for Endpoint. Managing inactive devices is a concept for which little documentation is available, and it can be confusing for an administrator just starting with Microsoft Defender for Endpoint. In this article, I want to deep dive into this scenario and provide insights on how organizations can handle inactive devices within Microsoft Defender for Endpoint.
Before starting, it is important to introduce Microsoft Defender’s device inventory, which contains information about our device estate.
Navigating the Device Inventory
The device inventory is available in the Microsoft Security portal, Figure 1 is a typical overview.
When navigating the device inventory, the ‘sensor health state’ is an important column. It provides insights into the current state of the device. There are a couple of different states:
- Active: Defender has seen the device in the past 7 days.
- Inactive: Defender has not seen the device in the past 7 days.
- Impaired communications: Some URLs/ports are blocked on the network, impeding the access Defender has to the device. The device is sending some, but not all, events.
- No sensor data: The device has stopped sending data.
Besides knowing the different statuses, it is important to know that Defender for Endpoint can display duplicate devices. This is because each onboarding (adding the device onto Microsoft Defender for Endpoint) generates a unique signature, even on the same computer. In effect, Defender generates a new record for a device every time you reimage a device or offboard and re-onboard it.
The Definition of Inactive and Its Impact
A device enters the inactive state when it has not been online/reported to Microsoft Defender for 7 days. This could be due to a few reasons:
- It is turned off.
- It was wiped and reimaged.
- An attacker was able to sever the connection between the device and Defender for Endpoint
When a device is inactive, it remains in the device inventory list based on the data retention configuration for Endpoint. The retention period can range between 30 and 180 days (Figure 2).
It is important to note that there is no way to force the removal of devices from Microsoft Defender for Endpoint. Inactive devices remain in the inventory until the configured retention period lapses. As an IT admin, this might sound strange. After all, administrators can remove devices from Azure AD and Intune, but why not from Microsoft Defender? The reason is simple: if an administrator can permanently remove devices, an attacker can too. If an attacker gets a foothold into the environment, they could remove all devices to cover their tracks. No one would be able to verify what the attacker did, as the logs of a device disappear when the device is removed.
Although the logic makes sense, it can be tricky to manage inactive devices, especially if you reimage devices regularly and issue new laptops regularly. This kind of process will increase the number of duplicates significantly.
Offboarding devices is a potential solution. This sounds interesting at first, but it won’t work in our case.
Two different ways exist to offboard devices:
- Locally, by running an offboarding script on a device (supported for macOS, Linux, and Windows (Server)).
- Through the offboarding API (supported for Windows 10 and Windows Server 2019).
It is important to understand that offboarding a device does not remove a device from the inventory. Instead, the device switches to an ‘inactive’ state 7 days after offboarding. This means that offboarding is not an efficient way to manage reimaged/repurposed devices.
The main goal of offboarding is to sever the connection between Microsoft Defender and the device. This is useful in several scenarios, including:
- A device encounters compatibility issues because the scanning process impacts performance and the standard operation of the server or legitimate processes are being blocked
- You are moving away from Microsoft Defender to a different EDR solution.
- The device is no longer in scope.
The last scenario is something I regularly encounter with customers: by accident, the customer onboarded personal devices into Microsoft Defender for Endpoint due to a misconfiguration. By using the offboarding API, I could block the device from sending data to Microsoft 365 Defender by moving it out of scope for the company. So offboarding devices do have a use case, but it is not a solution for managing inactive devices.
The Impact of Inactive Devices
Now that we know how a device can enter the inactive state, let’s look at what the impact of this behavior is. There are two main issues that you might run into:
- You should follow up on which devices turn up ‘inactive’ as an attacker might breach these after they disable connectivity to Microsoft 365 Defender. If all reimaged/old devices remain in the same list, following up on which devices have an expected state and which don’t, can be a labor-intensive task.
- Microsoft Defender Vulnerability Management considers inactive devices as ‘unpatched’ because the devices haven’t received a certain security patch. This is expected, as a device that is turned off cannot receive an update. But having a lot of inactive devices will influence your vulnerability reporting. A device only disappears from reports and Vulnerability Management after 30 days of inactivity.
A Potential Solution
While no ideal solution exists for managing inactive devices within Microsoft Defender for Endpoint, I recommend using a combination of tags and device groups. Do this by adding the tag ‘Offboarded’ to inactive devices and creating a device group based on the tag value.
Throughout the portal and different reports, you can filter the data based on the group a device is in. By excluding devices tagged as inactive, these devices won’t skew your reports or interfere with other maintenance work.
The first step is to add the tag. This can be done manually (as seen in Figure 3) on the device page or through the API. The most interesting case is where you can automate this process through an API. Some organizations have achieved this by connecting their asset lifecycle workflow with Defender to automatically execute the API call when the state of the device changes.
After you tag the inactive devices, you can create a new device group by navigating to Settings > Endpoints > Device Groups. Here, create a device group using the tag to filter devices (Figure 4).
Bringing the Solution Together
Handling and managing inactive devices might not be high on your priority list, but it is something you should consider. When you reimagine many computers, your reports can become skewed if you don’t take any action. By ensuring you tag old devices, you can identify them later and differentiate between devices that are retired/reimaged by support staff or machines that should be up and running but are experiencing a connection issue.