/
/

How to Audit and Clean Up Orphaned Endpoints Across Multiple Tenants or Clients

by Stela Panesa, Technical Writer
How to Audit and Clean Up Orphaned Endpoints Across Multiple Tenants or Clients blog banner image
How to Audit and Clean Up Orphaned Endpoints Across Multiple Tenants or Clients blog banner image

Key Points

  • Orphaned Endpoints: Inactive or abandoned devices that still appear in RMM, PSA, or other asset management systems.
  • Device Criteria: MSPs should define clear criteria for orphaned devices before cleanup.
  • Endpoint Identification Methods: Use a combination of PowerShell, Registry audits, CMD validation, and Group Policy/Scheduled Tasks to identify inactive or unmanaged endpoints across tenants.
  • Cross-System Verification: Perform cross-system reconciliation to eliminate false positives and confirm true decommission candidates.
  • Cleanup Best Practices: Uninstall agents, archive logs, remove from AD/RMM, and tag devices as decommissioned to improve asset hygiene and reduce risk.

If endpoints are powered off, reimaged, lost, or abandoned without proper offboarding, they become orphaned devices.

These unmanaged systems linger in your RMM and PSA tools. They can create blind spots in your security posture, inflate your licensing spending, and clutter client data.

To prevent these devices from becoming a major liability to your MSP, you need to conduct regular endpoint audits across all your tenants.

This process will help you reclaim unused licenses and generate accurate client billing and reporting. It can also complement broader audit workflows, such as a physical configuration audit process or a network audit checklist review.

In this guide, we’ll show you how to do orphaned endpoint audits and cleanups. Keep reading to learn more about the difference between managed and unmanaged devices.

For a visual breakdown of this topic, watch How to Audit and Clean Up Orphaned Endpoints Across Multiple Tenants or Clients.

Strengthen your security by removing unmanaged endpoints.

Sign up for a NinjaOne free trial.

Identifying, auditing, and cleaning up orphaned endpoints across multiple tenants

Prerequisites:

  • Access to RMM and PSA systems to track endpoint activity, status, and ownership
  • PowerShell version 5.1 or higher is required to run scripts for querying system information and checking device status
  • Group Policy and Registry access to verify endpoint configurations
  • Device baseline documentation per client or department to compare endpoint inventories
  • Network monitoring data to detect active endpoints that are not included in your RMM and PSA tools. This data is optional, but it can help reduce blind spots during cleanup.

Recommended deployment strategies:

Click to Choose a Method

💻

Best for Individual Users

💻💻💻

Best for Enterprises

Method 1: Query device activity using PowerShell
Method 2: Track device activity or agent status using Registry
Method 3: Use CMD to verify device connectivity or agent presence
Method 4: Use Group Policy or Scheduled Tasks to flag dormant devices
Method 5: Cross-check RMM, domain, and PSA data

Step 1: Define what qualifies as an orphaned endpoint

First, you need to establish a clear criterion for an orphaned endpoint. Some of the most common indicators that a device has been abandoned include:

  • The device hasn’t checked into the RMM platform for over 30 days.
  • The device has no recent user login or domain authentication on record.
  • Expected antivirus, backup, or patching agents are missing or no longer reporting.
  • The device has duplicate entries due to OS reinstallation or imaging.
  • The device has been decommissioned, but has yet to be removed from systems.

Tip: To make identifying and tracking potential orphaned devices easier, tag them based on the last check-in date, user activity, AV status, and hostname validation.

Step 2: Choose one or more methods to audit device activity.

Next, audit your endpoints’ device activity using one or more of the methods listed below. You can also use any combination that works best for your needs.

Method 1: Query device activity using PowerShell

Use Case: Quickly assess whether a device has been used recently by checking device activity indicators, such as last boot time, user logon, and system uptime.

  1. Check the last boot time.

Use Case: This allows you to check when a system was last restarted.

(Get-CimInstance Win32_OperatingSystem).LastBootUpTime

  1. Determine the last user logon.

Use Case: This helps determine if any local user has logged in on a system recently.

Get-LocalUser | Select Name, LastLogon

  1. Review system uptime.

Use Case: These logs show you how long the system has been running since the last boot.

(New-TimeSpan -Start (Get-CimInstance Win32_OperatingSystem).LastBootUpTime).Days

You don’t have to run all these checks together. You can focus on one specific metric or any combination and cross-reference it with your RMM or domain activity logs.

Method 2: Track device activity or agent status using Registry

Use Case: Automate stale device detection using PowerShell or RMM-based scans. This method is ideal for MSPs with a standardized registry logging policy.

If your organization uses scripts or agents to log registry activity, check for custom keys such as:

HKEY_LOCAL_MACHINE\SOFTWARE\Org\DeviceAudit

Look for values, such as:

  • LastLoginDate (String) = “2025-07-01T10:05Z”
  • LastBackupStatus (String) = “Success”
  • LastCheckIn (String) = “2025-07-01T09:00Z”

Method 3: Use CMD to verify device connectivity or agent presence

Use Case: Manually validate potential unmanaged systems before clean-up.

  1. Ping test:

ping device01.domain.local

  1. Check AV status (Windows Defender):

sc.exe query WinDefend

  1. List installed RMM/AV/Backup software:

Get-Package | Where-Object Name -Match “Ninja|Avast|Veeam”

Method 4: Use Group Policy or Scheduled Tasks to flag dormant devices

Use Case: Proactively track device activity across multiple tenants using a GPO or scheduled task.

Configure a GPO or scheduled task to run the command below, which records a timestamp in the Registry:

Set-ItemProperty -Path “HKLM:\SOFTWARE\Org\DeviceAudit” `

-Name “LastCheckIn” -Value (Get-Date).ToString(“u”)

Schedule it to run at user logon or system startup. Devices that have not updated the timestamp within the defined inactivity period (for example, 30 days) can then be identified for review.

Method 5: Cross-check RMM, domain, and PSA data

Use Case: Validate whether a device is abandoned or temporarily offline. Cross-referencing aligns with best practices from a cybersecurity audit checklist.

Triangulate the following data sources:

  • RMM last check-in
  • Active Directory previous logon
  • PSA ticket history (e.g., open/closed asset requests)
  • Antivirus dashboard and backup agent status

Step 3: Create a cleanup process for decommissioning

Once you’ve identified which devices meet your criteria for orphaned endpoints, follow the steps below to start the clean-up process:

  • Uninstall all AV, RMM, and backup agents.
  • Archive the device’s registry and login data.
  • Remove the device from your AD and RMM platforms.
  • Tag the device as Decommissioned in your PSA or asset system.

Tip: Create a checklist for the clean-up process to ensure consistent offboarding.

Common problems you may face when auditing endpoints and how to fix them

False positives

There are instances where a device looks inactive or abandoned when it’s still in use; it’s just not reporting to your system properly.

When this happens, validate its activity using domain authentication logs and backup job records before deleting it. This step will help you avoid accidental deletions.

Missing registry keys

Missing registry keys are often seen as a sign of an unmanaged device. However, some of these registry gaps are caused by failed login scripts.

If you encounter an endpoint missing a few registry keys, check whether the login script responsible for those keys is still active before you decommission it.

Duplicate RMM entries

Some RMM platforms create multiple entries for one device, especially if it has been reimaged or renamed.

In this case, try matching entries using hardware identifiers such as the device’s serial number or MAC address. Serial numbers are generally more stable, while MAC addresses can provide additional matching information. These identifiers can help spot duplicate records and clean up inventory data.

Recently wiped devices

Just because a device appears as a new or unknown endpoint on your system doesn’t necessarily mean it’s been abandoned. Some of these endpoints could have been wiped or reimaged recently.

The good news is you can use the BIOS asset tag or registry recovery to track its history.

Things to look out for

Keep these pitfalls in mind when using this guide:

RisksPotential consequencesReversal
Running PowerShell scripts without administrator privilegesIncomplete or failed data retrievalMake sure to run PowerShell as an administrator before deploying the scripts.
Not validating registry keysMay detect false positives if there are scripts that failed to update keysCross-reference data to RMM or log files.
Misconfigured GPO or task schedulerThe device won’t log timestamps, which may lead to false dormancy.Test deployment and monitor task execution logs.

Additional notes on auditing and cleaning up orphaned endpoints

Since no two abandoned devices are the same, here are a few things you should consider when conducting endpoint audits in large and distributed environments:

Treat BYOD devices differently

Bring Your Own Device (BYOD) policies can add an extra layer of complexity in an endpoint audit.

Personal devices don’t follow the same management protocols as company-owned machines. They’re much harder to track and may appear differently on your system.

That said, it’s a good idea to establish a different set of auditing and cleaning-up rules for BYOD devices. This way, you won’t accidentally remove a personal computer that is still being used for work.

Look out for reused device names

It’s very common for IT teams to use the same device names when reimaging or repurposing hardware. However, this practice can lead to confusion in audit reports.

For example, a freshly wiped laptop may be mistakenly tagged as an abandoned device simply because it’s still using its old device name.

To prevent misidentification, cross-check device names with MAC addresses or serial numbers.

Don’t forget about cloud-managed devices

Cloud-managed devices may be managed through platforms such as Microsoft Intune and provisioned using services such as Windows Autopilot.

These endpoints may not appear in traditional on-premises management sources, depending on how the environment is configured, and can therefore be missed during audits.

Make sure to include relevant data from cloud management platforms, such as Intune, in your audit process.

Set a regular audit schedule

Endpoint audits should not be a one-time thing. Your organization should schedule monthly or quarterly audits to keep its asset inventory up to date.

Creating a regular audit schedule will help you stay ahead of device changes and prevent any abandoned endpoints from slipping through the cracks.

Quick-Start Guide

NinjaOne does have capabilities to help audit and clean up orphaned endpoints across multiple tenants or clients. Key Features for Auditing Orphaned Endpoints:

1. Device Search and Filtering

  • NinjaOne allows you to search and filter devices across all tenants using various criteria
  • You can identify orphaned endpoints by looking for devices that haven’t checked in for extended periods

2. Organization and Location Based Views

  • The platform provides organization and location-based views that help identify devices that don’t belong to active clients
  • You can easily spot devices that are no longer associated with any active organization

3. Manual Identification Process

While NinjaOne doesn’t have an automated “orphaned endpoint” detection feature, you can manually identify them by:

  • Checking device last seen dates
  • Reviewing organization assignments
  • Looking for devices with missing or outdated information

4. Multi-Tenant Support

  • NinjaOne’s architecture inherently supports managing multiple tenants, making it suitable for MSPs and enterprises with multiple client organizations

What’s the difference between managed and unmanaged devices?

Managed devices are systems enrolled in or controlled through a centralized device management solution, such as an RMM tool.

IT administrators monitor, configure, and manage these machines to ensure consistency and compliance with organizational policies. This means that they follow the same standardized policies for system configurations, access controls, and software updates.

Conversely, unmanaged devices are devices that are not enrolled in or controlled through the organization’s device management systems. They may include personal, third-party-owned, or company-owned devices.

IT teams don’t monitor or control these endpoints, so they typically don’t have the same standardized configurations as managed systems do.

Why cleaning up orphaned endpoints matters

Tracking and cleaning up orphaned endpoints is crucial for MSPs because:

They’re a security risk

Abandoned endpoints are easy targets for cyberattackers. They can use these devices to steal sensitive data, especially if they don’t have the latest antivirus or security patches.

Cleaning up these assets can significantly reduce your organization’s attack surface.

They increase license waste

Devices that remain enrolled in RMM, antivirus, or backup systems may continue consuming licenses, depending on the product’s licensing model. Decommissioning unused endpoints can help reduce unnecessary licensing costs.

They lead to inaccurate reports

Unmanaged endpoints in your asset inventory can lead to inaccurate reports, creating misleading QBR or compliance audits.

They compromise inventory hygiene and visibility

Good endpoint hygiene means knowing exactly what devices are in your environment and how they perform.

Orphaned devices will continue appearing in your dashboards, reports, and alerts unless you clean them up, making it harder to get a clear view of your infrastructure.

How NinjaOne can simplify orphaned endpoint audits and cleanup

NinjaOne can help you refine the orphaned endpoint audit and clean-up process by:

  • Tagging endpoints by their last check-in or script execution date
  • Automatically deploying PowerShell scripts to check registry keys or login activity
  • Creating inventory and backup reports that surface devices with missing agent data or backup failures
  • Triggering alert workflows for devices that have been offline for longer than the established policy threshold
  • Automating decommission actions, such as uninstalling software and removing tags

With the NinjaOne platform, MSPs can standardize the manual audit process across clients by tagging devices, scheduling scripted checks, and automating remediation steps once a device is confirmed orphaned, using consistent, repeatable workflows.

For common questions about RMM-based device monitoring, visit the NinjaOne RMM FAQ.

Improve asset hygiene by conducting regular orphaned endpoint audits

For MSPs, auditing and cleaning up orphaned endpoints is not an option, but a must. These devices can create a gap in your organization’s security posture and increase your license spending over time.

Establishing a regular auditing schedule and implementing a comprehensive decommissioning clean-up process for various abandoned devices ensures that no decommissioned endpoint goes unnoticed.

More importantly, it positions your MSP as a proactive, security-focused partner.

Related topics:

FAQs

An endpoint is any device that serves as a connection point to a network. A common example is a laptop used by an employee to access corporate applications and files. Other endpoint examples include desktop PCs, smartphones, tablets, and managed workstations.

Unmanaged devices lack consistent patching, monitoring, and policy enforcement. Attackers often exploit these “forgotten” systems as entry points because they bypass normal security workflows. Removing or properly decommissioning them reduces the avoidable attack surface.

An orphaned-endpoint audit specifically hunts for devices that should be removed from your environment, while a routine inventory audit catalogs everything active and in use. The two overlap in tooling but have different end goals; one confirms what to decommission, the other confirms what to keep tracking.

Before cleanup, verify:

  • AD last-authentication logs
  • Recent AV or backup activity
  • Helpdesk tickets related to imaging or device repair
  • MAC address or serial number matching (to avoid duplicate entries)

Remove it from licensing and billing only after you’ve confirmed the device is truly orphaned and fully decommissioned. Pulling a license too early can trigger a false “device offline” alert if the endpoint is still checking in intermittently, which can muddy your audit data.

MSPs should establish a regular audit schedule based on client size, device turnover, risk, and regulatory requirements. Monthly or quarterly reviews may be appropriate depending on the environment.

Treat contract-end offboarding as a separate decommission trigger, distinct from inactivity-based cleanup. Devices tied to a terminated contract should be flagged and removed from active management according to the agreed client offboarding process.

Tagging, scripting checks, and remediation steps, like uninstalling agents or removing tags, can be automated. Confirming that a device is genuinely orphaned, rather than temporarily offline or newly reimaged, still requires manual review to avoid false positives.

You might also like

Ready to simplify the hardest parts of IT?