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.
Cybersecurity Risk Management for Active Directory
Discover how to prevent and recover from AD attacks through these Cybersecurity Risk Management Solutions.
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
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.
Thanks for this article. We just rolled out a new tenant and came across this, however, adding the tags and groups does not impact the devices in the list automatically. They will still need filtered and this also does nothing for defender seeing them as vulnerable and unpatched. Or am I missing something?
Correct – these filters need to be added manaully
Great post. Great comments.
A little light at the end of the tunnel. 😄
Hi,
Thanks for this. Is it possible to increase the inactive threshold from 7 days to 14, 28 etc?
7 days seems very short
Regards,
Michael
Unfortunately, this cannot be changed.
Hi All, if I will have to offboard all computers from MDE, then enroll intune through GPO (they have local AD) and then re-onboard them on MDE.
I know it could take the computers a week to disappear from MDE console.
The question is : If I offboard the computers, will they be still protected by MS Defender antivirus ?
and what is the impact of this for the users ? Will they have a pop up, message or other ?
Why do you want to offboard them before enrolling them into Intune? Is there a reasoning behind this?
If you offboard them, the EDR connection will stop meaning the logs will be sent to the cloud instance. The local antivirus will still work.
There isn’t any user impact for offboarding, they wouldn’t notice
So if your device is onboarded. it can reach MS endpoint servers but sensor is inactive in defender portal and the device SC QC Sense = stopped
is the only way to fix this is to onboard again?
Hi Andrew
If the service has stopped on the device, something else is going on. You will need to dig into the event logs why the service is stopping. Can you check the sense event viewer and tell me what you see?
Thanks for the guide – as an update, Microsoft has now included a exclude button with justifications to remove them from your vulnerability lists.
Hello Thijs
during the deployment of the EDR in block-mode with the existence of another antivirus, we have machines that are not onboarded and they display on the MDE portal the following statuses:
can be onboarded, unsupported, insufficient information
also machines that are invisible or unassigned
do you have an explanation for this?
do you have a definition for each status:
can be onboarded?
insufficient information?
unsupported?
invisible?
unassigned?
THANKS
Hi Lola
Can you provide me more information where you see the following information: unassigned and invisible?
Do you mean they are not seen in the portal. This can happen if the machines are not onboarded or have not been seen by an onboarded device.
Defender has a capability called ‘Device Discovery’ (https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/device-discovery?view=o365-worldwide) which will actively scan the network to identify other, non-onboarded devices.
If a machine is scanned, but not onboarded, it will receive one of the following statuses:
– Unsupported => The device is not supported to be onboarded
– Insufficient => not enough info is available to verify if onboarding is possible
– Can be onboarded => device is supported to be onboarded into MDE
Hello Thijs,
Some of devices already run onboarding script and the status appear Onboarded, but many day later it is appear Can be onboarded, May I know what is the problem.
Can you elaborate on this? I would find it strange that it is changed to ‘Can be onboarded’. This can only happen if it’s manually offboarded.
It can happen, that, if a device is onboarded. It has two entries for a while. One ‘can be onboarded’ and one ‘onboarded’, is this case?
A real oversight in my book is also for device renames. We have existing AzureAD devices that have the randomly generated computer name but our policy is to have the serial number as the computer name. When renaming the computer through Intune and after device restart, rather than the record update in Defender Portal, it creates a new entry.
I the same issue, that’s a mess to handle…
if anyone got a clue
Hi Thijs,
How is the licensing works for inactive devices. Does MS count licences for inactive devices.?
Thank you
Malith
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.
Hi,
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.
Hi
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?
Hi,
I don’t have a Retention menu in the navigation of Settings – Endpoints
Where I can find this ?
I can have this info via powershell script ?
Thank’s
Microsoft updated the setting to retain data 180 days by default, there is currently no way to change it.
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?
Hi Paul
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
Hi there,
why are you not using the “Exclude” functionallity for device management. Is there a specific reason for that?
Regards,
Gunter
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