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 Experts Conference 2023 European Roadshow
Join us April 17-21 for practical security insights into hybrid AD and Microsoft 365.See the Agenda
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.
Cybersecurity Risk Management for Active Directory
Discover how to prevent and recover from AD attacks through these Cybersecurity Risk Management Solutions.Learn More
How is the licensing works for inactive devices. Does MS count licences for inactive devices.?
There is no clear public documentation on this. I assume inactive devices are not taken into account, but I would suggest you check with your Microsoft licensing liaison just to be sure
If Device sesnsor state is inactive in security portal for some reason, but device is online. will defender protect the device and issue is only with the sensor.
The issue is with the communication to the portal. The AV will still protect the machine. If there are network connections, no EDR logs will be uploaded to the cloud and thus you will loose protection.
Having an active internet connection is of paramount importance.
Thank you to share you knowledge ! I’m stll perplex with the concept where we cannot remove a computer from the inventory. Why ? Because we also use MDE365 to discover vulnerabilities… And when a computer is reported vulnerable and you want to fix this vulnerability in your environment but it’s impossible to reach a success because some computers still reported vulnerables and it’s not true because they simply no more exist.
The reason for not allowing removals is to ensure a malicious actor cannot delete devices and make your secops teams blind
If you want to remove devices from MDVM, exclude them from the device page
I’d like to change the retention period, but when I click on the link to take me to https://security.microsoft.com/preferences2/general I am denied. Fair enough, I don’t have privileges. However, I am unable to find this area if I manually navigate in Defender. Any direction, please?
It’s in settings => endpoints => retention. Can you find that navigation?
Thanks， This post is really helpful to me
Thanks for the post. very helpful. From what I have been seeing within my environment, after a computer was reimaged, the old one still had “onboarded” status while showing “inactive”. I would like to remove/delete/ these old computer accounts. any suggestion?
Hi Dean, that’s indeed the issue.
When you reimage a computer, it will stay ‘onboarded’, but with the status ‘inactive’.
There is no way to delete/remove them, you can filter them out using the methods I mentioned in this blog.
Nice write-up Thijs; you have affirmed my thinking and research on the case of duplicate devices in DfE.
To confirm the only reason DfE should generate a new signature (duplicating device names in the portal) is:
– The device is offboarded and then re-onboarded
– The device is re-imaged.
What if the DfE software is uninstalled and re-installed (for example, desktop troubleshooting)? I assume that if the client is merely upgraded, the DfE Device Id should remain the same and is recorded in the registry?
I had a similar case this week and from my testing, this does not create a new device. But this is only the case when no new image is deployed
why are you not using the “Exclude” functionallity for device management. Is there a specific reason for that?
It’s too limited IMO. Because there is no way to add categories etc. Because an exclude could happen for out of date devices or old devices.
Device Groups allows for more granularity