Key Takeaways:
- Compare network discoveries with ITAM, MDM, and EDR records to identify missing controls.
- Classify devices as unknown, unmanaged, unauthorized, or exposed before deciding how to respond.
- Use reliable identifiers and recent check-ins to prevent duplicate or misleading findings.
- Prioritize confirmed vulnerabilities, missing security controls, network access, and business criticality.
- Close findings after verifying remediation through the responsible system or documenting an approved exception.
An employee’s laptop connects to company resources but doesn’t appear in the endpoint management platform. A server remains active even though its security agent stopped reporting weeks ago.
Both situations raise questions. Are these devices already known to IT? Do they meet the required management policies? Has a security control failed, or is the information simply outdated?
Network discovery can reveal connected devices, but it cannot independently establish their management or security status. IT teams need to connect those discoveries with existing IT asset records and evidence from endpoint management and security platforms.
This guide explains how to detect unmanaged devices across distributed IT environments, assess endpoint exposure, and verify corrective actions using reliable evidence.
What is an unmanaged device?
An unmanaged device is an endpoint that lacks one or more management or security controls required by an organization’s IT policies.
For example, a company-owned laptop may be missing from Microsoft Intune, a server may no longer report to its endpoint detection and response (EDR) platform, or a personal device may access corporate applications without meeting the required security conditions.
Unmanaged, unknown, unauthorized, and exposed devices represent different conditions.
| Device classification | What it means | Example |
|---|---|---|
| Unknown | IT teams cannot confidently identify the device or its owner | An unfamiliar laptop appears during network discovery |
| Unmanaged | The device lacks a required management or security control | A corporate laptop is missing from the required MDM platform |
| Unauthorized | The device does not have approval for its current access | An unapproved endpoint connects to a restricted network |
| Exposed | A vulnerability, misconfiguration, or unsafe access condition creates security risk | A server runs vulnerable software accessible from an untrusted network |
A device can fall into more than one category.
A company-issued laptop might have an accurate IT asset record and a known owner, but its EDR agent may have stopped reporting. Another endpoint may initially appear unknown because its hostname changed after reimaging, even though it remains properly managed.
These distinctions affect the response. An unidentified device requires investigation, missing controls may require enrollment or restored agent coverage, and confirmed security exposure may demand immediate intervention.
CIS Controls v8.1 Safeguards 1.3 and 1.4 recommend running active discovery daily or more frequently and reviewing DHCP logs at least weekly, respectively, for organizations implementing those safeguards.
What do you need before detecting unmanaged endpoints?
Effective detection starts with identifying which devices belong in the environment and the controls they are expected to meet.
Gather the following information before beginning:
- IT asset records: Known devices, hardware identifiers, assigned users, operating systems, locations, lifecycle states, and synchronization history.
- Discovery and management sources: Network scanners, ITAM agents, mobile device management (MDM) platforms, EDR systems, and available network connection records.
- Security requirements: Policies governing device approval, management enrollment, endpoint protection, encryption, software updates, and access permissions.
- Responsible personnel: IT teams that maintain asset records, endpoint administrators who manage device enrollment, and security personnel who handle exposure assessment and response.
Confirm that the necessary scanning permissions, credentials, and approved network ranges are available.
AssetSonar’s hardware asset management connects IT devices with custody and lifecycle information, helping IT teams establish which hardware is already accounted for.
Maintain a shared investigation record for unresolved discoveries. Each entry should capture the available device identifier, discovery source, latest observation, responsible owner, and next action.
This allows ITAM, endpoint administration, and security personnel to work from the same findings.
How to detect unmanaged devices and respond to endpoint exposure
To detect unmanaged devices, IT teams should compare network discoveries and IT asset records with endpoint management and security data. Match devices using reliable identifiers, then investigate those missing required controls or reporting information. Prioritize confirmed risks, take corrective action, and verify remediation.
The following eight steps explain how to carry out this process across distributed IT environments.
Step 1: Establish a reliable baseline of known IT assets
Start by reviewing the active devices recorded in your IT asset management platform.
The baseline should reflect equipment currently in use and flag records that need further confirmation.
Look for issues that could distort the results:
- Missing or outdated device ownership information.
- Assets that haven’t synchronized recently.
- Duplicate or invalid hardware identifiers.
- Devices still marked active despite potentially being retired.
- Conflicting information across existing records.
For example, a laptop reassigned to another employee may still show its previous custodian. Similarly, an endpoint that stopped reporting to its ITAM agent may appear inactive despite remaining in use.
These discrepancies can lead to incorrect device classifications or duplicate asset records.
AssetSonar’s IT Asset Accuracy indicators identify three specific issues affecting discovered assets:
- Devices that haven’t synchronized within the last 30 days.
- Devices with invalid BIOS serial numbers.
- Devices sharing duplicate valid BIOS serial numbers.
In AssetSonar, IT teams can review these indicators under Items > Overview and take the appropriate corrective action, including synchronization, serial-number correction, merging, or retirement.
Step 2: Discover devices across network and endpoint sources
Next, identify devices that may be missing from existing IT asset records.
Active network scanning can reveal connected devices across configured network ranges. However, offline endpoints, remote laptops outside those ranges, and devices that block scanning probes may not appear.
Additional discovery sources can extend coverage beyond what network scanning alone can observe.
| Discovery method | What it helps identify | Important limitation |
|---|---|---|
| Active network scanning (AS Network Scanner or external tools) | Devices reachable through configured network scans | Offline devices, blocked probes, and out-of-range networks may be missed |
| Passive network discovery (external tools) | Devices communicating through monitored network segments | Visibility depends on available network traffic |
| ITAM Agent (AssetSonar) | Hardware and software details from supported endpoints | Requires successful installation and reporting |
| MDM/UEM integrations (supported integrations) | Devices enrolled in connected management platforms | Cannot independently identify every unenrolled device |
| EDR discovery (external security tools) | Devices observed through supported security sensors | Coverage depends on deployed sensors and network visibility |
Consider a remote employee’s laptop that reports to Intune and EDR but doesn’t appear in an office network scan. A server on the corporate network may present the opposite situation: a scanner can reach it, but no endpoint agent is installed.
Both devices require information from different sources to establish their status.
AssetSonar supports IT asset discovery integrations with supported endpoint management and network discovery platforms.
IT teams can use AS Network Scanner to discover devices across configured network ranges. Discovered devices enter the Provisioning queue, where IT teams can review them before adding them as IT Assets or Network Assets.
AS Network Scanner uses a Linux-hosted connector and supports SNMP, SSH, and Windows credentials. Without suitable credentials, discovery may return limited information, such as IP and MAC addresses. The connector synchronizes with AssetSonar hourly by default and cannot run alongside the Cisco Meraki network integration.
CIS Safeguard 1.3 recommends running active discovery daily or more frequently for organizations implementing that safeguard. Safeguard 1.4 also recommends using DHCP logs to identify connected devices and reviewing that information at least weekly.
Discovery frequency should reflect the environment’s rate of change, security requirements, and each source’s capabilities.
Step 3: Match discovered devices with existing IT asset records
New discovery results may contain hardware that already exists in the IT asset register.
Reimaging, hostname changes, network reassignment, and outdated records can make familiar devices appear under different identities.
Compare each discovery with existing IT assets before creating new records.
Start with reliable hardware identifiers, such as valid serial numbers. Hostnames, MAC addresses, IP addresses, and user assignments can provide additional evidence when a match is uncertain.
These identifiers don’t carry equal weight. Hostnames may change, IP addresses can be reassigned, and some devices use randomized MAC addresses.
Classify the results according to the available evidence.
| Result | What it means | Next action |
|---|---|---|
| Matched device | The discovery corresponds to a known asset | Check its management and security status |
| Unmatched device | No reliable existing record has been found | Investigate identity, ownership, and authorization |
| Conflicting records | Information suggests a duplicate or uncertain match | Verify identifiers before updating or merging records |
Include retired assets in the matching process.
In AssetSonar, under Settings > Company Settings & Addons > ITAM Discovery Agent, administrators can enable Make Retired Devices Available if Discovered Again. This returns previously retired assets to Available when the ITAM Agent rediscovers them.
Devices found through network scanning should still be checked against existing and retired records before changing their lifecycle status.
Example: An unknown laptop turns out to be a retired asset
Suppose a network scan detects a laptop whose hostname doesn’t match any active IT asset record.
Instead of immediately creating a new record, the IT administrator checks its serial number against existing and retired assets.
The serial number matches a laptop previously assigned to an employee and marked as retired. After reviewing its assignment history, the administrator confirms that it was reassigned without an accompanying lifecycle update.
The administrator can now correct the existing record, and the laptop can proceed to the required management and security checks.
This prevents duplicate asset records while ensuring that the unexpected activity is investigated.
Step 4: Identify devices missing required management or security controls
Once an endpoint has been identified, determine whether it meets the controls required for its role.
A corporate laptop may have an accurate IT asset record but remain unenrolled in Microsoft Intune. Another endpoint may report to Intune but lack required EDR protection.
Compare known corporate endpoints in ITAM with devices reporting to the required MDM and EDR platforms. Reconcile their identifiers and investigate missing matches or outdated reporting information.
The following table illustrates common discrepancies.
| ITAM record | MDM record | EDR record | What to investigate |
|---|---|---|---|
| Present | Present | Present | Confirm required controls are current and functioning |
| Present | Missing | Present | Check whether MDM enrollment is required and why the device is absent |
| Present | Present | Missing | Investigate endpoint security coverage |
| Missing | Present | Present | Determine why the IT asset record is missing |
| Missing | Missing | Missing | If another source observed the device, investigate its identity and authorization |
Management requirements also differ by device type. A network switch, for example, may not be expected to run the same security software as a Windows workstation.
Before confirming a gap, check the latest successful synchronization in each relevant platform. A device may have been enrolled or repaired, but the updated status may not appear in every source yet.
In Intune-managed environments, IT teams can import enrolled devices into AssetSonar and configure synchronization by asset type (IT Assets or Mobile Assets) and ownership (company-owned or employee-owned).
This brings supported Intune device information into IT asset records while Intune remains responsible for enrollment and device policies.
Classify each confirmed gap according to the missing requirement and assign it to the personnel responsible for that control. Where identity, authorization, or reporting remains uncertain, retain the finding for further investigation.
Step 5: Assess endpoint exposure and prioritize the findings
Not every unmanaged device poses the same risk.
Consider two findings:
- A company-issued laptop with a known owner hasn’t reported to its management agent recently.
- An unidentified server communicates with a network segment that contains sensitive business systems.
The laptop has an established ownership trail but isn’t being reported. The server raises additional questions about authorization, network access, and security posture.
Assess each finding using the available evidence.
| Assessment factor | Question to ask |
|---|---|
| Security coverage | Are the required endpoint security controls installed and reporting? |
| Confirmed vulnerabilities | Is there current evidence of vulnerable software or unsafe configurations? |
| Business criticality | Does the device support essential operations or sensitive data? |
| Network access | Can the device reach exposed services or restricted resources? |
| Evidence quality | Is the finding recent and supported by reliable information? |
A device with missing EDR protection and access to critical systems may require urgent action. A known laptop affected by a temporary synchronization failure may warrant routine investigation instead.
Validate vulnerability findings before assigning remediation. A scan may reference outdated software information or a configuration that no longer applies.
AssetSonar’s vulnerability management capabilities use ITAM Agent data from supported managed endpoints to identify known software CVEs and associate them with affected devices and software versions.
Because this information depends on supported agent-managed endpoints, it does not establish vulnerability status for devices identified only through network scanning.
For confirmed vulnerabilities, IT teams can prioritize patches based on CVSS severity, asset importance, and available evidence of exploitation.
Where security information remains incomplete, investigate the device’s exposure before assigning a final risk classification.
Step 6: Restrict access when a device presents an immediate risk
Some findings require containment before routine management or patching can begin.
An unauthorized laptop connected to a restricted network may need its access revoked. A supported endpoint showing signs of compromise may require isolation through the organization’s EDR platform.
The response should reflect the confirmed or reasonably suspected risk, the available enforcement mechanisms, and the device’s business function.
Depending on the situation, IT teams may need to:
- Restrict unauthorized network connections.
- Revoke access to corporate VPN or applications.
- Move eligible endpoints into a limited network segment.
- Isolate supported devices through an EDR platform.
- Escalate suspected compromise through incident-response procedures.
Production systems require additional care.
Disconnecting a server without understanding its dependencies could interrupt critical applications. Coordinate potentially disruptive changes with the responsible infrastructure owners and security personnel.
If active compromise is suspected, follow established incident-response procedures and preserve evidence for investigation.
AssetSonar’s device assignment and custody information can help identify the responsible personnel and coordinate the response. Network security and EDR platforms perform the relevant access enforcement or endpoint isolation actions.
Step 7: Bring approved devices under management and resolve security gaps
Corrective action depends on the specific requirement the device failed to meet.
A legitimate corporate endpoint may need restored agent coverage, MDM enrollment, endpoint protection, or a software patch. Unauthorized devices may require access removal, while equipment unable to support standard security controls may need an approved alternative.
For missing ITAM coverage: Restore or install the required discovery agent and confirm successful reporting.
AssetSonar’s ITAM Agent supports hardware and software discovery on compatible Windows, macOS, and Linux devices, helping maintain current IT asset records.
The ITAM Agent provides IT asset discovery and does not replace EDR software.
For missing management or endpoint protection: Use the relevant MDM, endpoint management, or EDR platform to deploy the required controls. Investigate enrollment failures, deployment errors, and configuration issues that prevent successful reporting.
For confirmed software vulnerabilities: Identify the affected software, determine the appropriate remediation, and follow the organization’s patch approval process.
For devices that cannot support standard controls: Evaluate alternative safeguards based on their technical limitations and operational requirements.
An older production server, for example, may require restricted network access, configuration hardening, or additional monitoring if its operating system cannot support the required endpoint security software.
The selected controls should address the relevant exposure without unnecessarily disrupting essential operations.
Step 8: Verify remediation and close findings
A corrective action is complete only when evidence confirms that the original issue has been addressed.
Use the system responsible for the failed requirement to validate the result:
- EDR coverage: Confirm that the endpoint is reporting successfully to the security platform.
- MDM enrollment: Verify enrollment and compliance with the applicable management policies.
- Software vulnerabilities: Check the remediated software version or reassess the original security finding.
- Access restrictions: Confirm that the intended network or application control is enforced.
If different systems report conflicting results, review their latest successful synchronization before reopening a corrected finding.
Findings that fail validation should retain their investigation history and be assigned for further action.
How to handle unmanaged devices that remain unresolved
Not every investigation produces a definitive result during the initial review.
Some devices cannot be reached for verification, while others remain subject to technical or operational constraints that prevent immediate remediation.
These findings should follow a defined escalation and exception-management process rather than remaining indefinitely open without an accountable owner.
| Situation | Appropriate response | Evidence needed for closure |
|---|---|---|
| Unknown device identity | Escalate identity and authorization checks to the relevant IT or security personnel | Identity confirmed or an authorized access decision recorded |
| Offline endpoint | Assign follow-up and establish when its status must be reassessed | Device status verified or handled through an approved policy |
| Unsupported security agent | Submit the proposed alternative controls for risk review and approval | Verified controls and documented exception approval |
| Repeated enrollment failure | Escalate unresolved deployment issues to the responsible endpoint administrator | Successful enrollment and agent check-in |
| Critical system cannot be patched | Record the remediation plan, risk owner, and approval for continued operation | Vulnerability resolved or risk formally accepted |
An endpoint disappearing from discovery results does not establish that it has been removed from the environment. Its disposition must be supported by appropriate evidence.
For equipment permanently withdrawn from corporate use, device retirement and disposal tracking should preserve the relevant custody history, lifecycle changes, and evidence of final disposition.
Formal exceptions should include an approval authority, responsible owner, expiration or reassessment conditions, and the criteria for reopening the finding.
This prevents temporary decisions from becoming permanent exemptions without review.
Which tools help detect unmanaged devices and manage endpoint exposure?
Evaluate unmanaged device detection tools by the evidence they produce and the corrective actions they support. Key considerations include discovery coverage, management and security-control visibility, reporting capabilities, and integration requirements. For example, ITAM platforms help establish device ownership, while endpoint security platforms provide evidence of protection and security exposure.
| Tool | What it helps IT teams investigate | Key capabilities | What to consider |
|---|---|---|---|
| AssetSonar | Which discovered devices are unaccounted for, incorrectly recorded, or missing ownership information? | Network discovery, review-before-provisioning, ITAM Agent and MDM discovery, lifecycle tracking, and IT Asset Accuracy indicators. | Establishes IT asset accountability but does not independently verify EDR coverage or enforce network restrictions. |
| Microsoft Defender for Endpoint | Which devices may lack required endpoint protection? | Sensor-based device discovery, onboarding classifications, security investigation, and exposure assessment. | Discovery requires supported licensing and depends on onboarded sensors and network coverage. |
| Lansweeper | Which devices are present across networks, remote environments, and cloud infrastructure? | Active and passive discovery, credentialed scanning, endpoint agents, and supported cloud discovery. | Device identification depth varies with scanning methods, credentials, and sensor placement. |
| Tenable Vulnerability Management | Which discovered devices have vulnerabilities, and which still require assessment? | Discovery and assessment scans, authenticated checks, vulnerability findings, and remediation prioritization. | Discovering a device does not mean it has undergone a vulnerability assessment. |
| Axonius | Which devices appear in one IT or security platform but are missing from another? | API-based integrations, device correlation, cross-platform queries, and security-control gap analysis. | Accuracy depends on connected systems, adapter permissions, and source-data freshness. |
AssetSonar: Connect discovered devices with IT asset records
AssetSonar helps IT teams determine whether discovered hardware is already accounted for and what to do with devices without an existing asset record.
Its network discovery provisioning workflow lets administrators review discovered hardware before adding it as an IT Asset or Network Asset. Available discovery information, including detection history and provisioning status, can support the investigation.
This is particularly useful when IT teams need to distinguish newly identified equipment from hardware that requires record corrections or ownership updates.
Microsoft Defender for Endpoint: Identify missing endpoint protection
Microsoft Defender for Endpoint uses onboarded sensors to discover devices that may not have Defender protection.
Its device inventory distinguishes between endpoints that can be onboarded, unsupported devices, and discoveries with insufficient information to determine onboarding eligibility.
These classifications help security personnel decide whether to initiate onboarding, investigate a device further, or consider alternative protection measures. Device discovery requires Defender for Endpoint Plan 2 and suitable sensor coverage.
Lansweeper: Extend discovery across different environments
Lansweeper Network Discovery combines active scanning with passive network observation. Its traffic sensors can examine mirrored network traffic, helping identify communicating devices that may not respond to conventional scan probes.
IT Agent Discovery and supported cloud discovery methods extend collection to additional endpoint and infrastructure environments. Lansweeper is particularly useful when the challenge is identifying devices across different network segments, locations, and technologies. The information collected depends on the configured discovery methods and available access.
Tenable Vulnerability Management: Verify security assessment coverage
Tenable Vulnerability Management helps distinguish discovered devices from those that have undergone vulnerability assessment. Authenticated assessments can examine operating system and software information that unauthenticated scans may not access.
IT teams can review assessment coverage and findings to identify systems requiring additional scanning or remediation. This is useful when the priority is understanding which devices have been evaluated for vulnerabilities, not simply whether they are present.
Axonius: Investigate gaps between management and security platforms
Axonius connects to existing IT and security platforms through API-based adapters and correlates device information across them. IT teams can build queries to identify endpoints present in an MDM platform but missing from EDR data, or devices that have stopped reporting to a required system.
Source-specific observation dates help investigate whether a discrepancy reflects a genuine coverage gap or outdated information.
Axonius is useful when device information is spread across multiple established systems and IT teams need to assess its consistency.
How to choose the right tools for unmanaged device detection
The appropriate tools depend on where visibility breaks down and what action must follow the finding.
Consider three questions:
- What information is missing? Is the challenge identifying unknown hardware, establishing ownership, confirming endpoint protection, assessing vulnerabilities, or finding discrepancies between platforms?
- Which systems already provide relevant evidence? Existing ITAM, MDM, EDR, network discovery, and vulnerability management systems may already contain the necessary information. Determine whether better integration or an additional discovery method is required.
- What action should follow the finding? The investigation may require creating an IT asset record, correcting a device match, enrolling an endpoint, remediating a vulnerability, or restricting unauthorized access.
For example, if the primary challenge is establishing which devices belong to the organization and who is responsible for them, ITAM capabilities are central. If devices are already accounted for but security coverage remains uncertain, endpoint security and cross-platform correlation tools become more relevant.
Choosing tools around the missing evidence and required corrective action helps IT teams turn unmanaged device findings into measurable improvements rather than disconnected discovery results.
Best practices for preventing unmanaged device gaps
Detection helps identify devices that have already fallen outside the required controls. Preventive measures address the processes that allow those gaps to develop.
Include enrollment in device deployment. Corporate endpoints should receive required management and security controls before granting routine access. Validate successful enrollment and reporting during deployment rather than treating installation as proof of compliance.
Review discovery scope when the environment changes. New offices, network segments, remote work arrangements, and infrastructure changes may create additional discovery requirements. Update scanning configurations and management coverage when these changes occur.
Investigate recurring failures at their source. When several endpoints experience the same agent connectivity, enrollment, or configuration problem, determine whether a shared deployment or infrastructure issue is responsible. Fixing the underlying cause may prevent failures across additional devices.
Review approved exceptions regularly. Reassess alternative security arrangements regularly, especially when a device’s business function, access requirements, or technical capabilities change.
Track recurring findings across large IT environments. The same endpoint may appear in multiple discovery cycles, management reports, or security investigations.
Opening a separate case for every observation can inflate finding counts and obscure the device’s remediation history.
Instead, associate repeated detections with an existing investigation using reliable identifiers. Record subsequent observations, changes in risk, remediation attempts, and the current owner in the same case.
Consistent metrics also help IT teams evaluate whether detection and remediation are improving.
| Metric | What it measures |
|---|---|
| Unmanaged device rate | Confirmed unmanaged devices relative to distinct in-scope devices observed |
| Security-control coverage | Eligible endpoints with verified required controls |
| Time to classification | Time from first observation to confirmed management status |
| Time to remediation | Time from confirmed finding to verified corrective action |
| Open high-risk exceptions | Unresolved high-risk findings awaiting remediation or approved disposition |
Use consistent data sources, device populations, and reporting periods when comparing these metrics.
For example, a declining unmanaged device rate may indicate better management coverage. However, if a scanner has stopped reaching part of the network, the apparent improvement may result from missing discovery data instead.
AssetSonar Custom Reports support analysis of available IT asset and network discovery information. IT teams can use ITAM dashboards and custom reports to organize relevant KPIs, assign reporting responsibilities, and track changes over time.
These practices help reduce preventable management gaps while keeping discovery procedures aligned with changes in the IT environment.
Checklist for verifying unmanaged device remediation
Use this checklist to confirm that an investigation has sufficient evidence for closure.
| Check | Evidence to retain |
|---|---|
| Discovery coverage established | In-scope networks, discovery sources, and last successful observations |
| Device identity verified | Reliable identifiers and matching asset record |
| Ownership confirmed | Assigned user, custodian, or responsible IT administrator |
| Management gaps assessed | Required controls and latest reporting status |
| Exposure prioritized | Risk decision and supporting vulnerability or access evidence |
| Corrective action validated | Verified enrollment, patch remediation, or access restriction |
| Exceptions documented | Approval, compensating controls, and reassessment requirements |
| Ongoing monitoring arranged | Discovery frequency and recurring review process |
Make unmanaged device detection part of ongoing IT control
Knowing how to detect unmanaged devices is only the first part of maintaining IT control. IT teams must also determine which findings require action, assign responsibility, and establish what constitutes a satisfactory resolution.
ITAM provides the device identity, ownership, and lifecycle context, while MDM, EDR, and network security platforms enforce and verify the applicable controls.
When these functions share evidence and maintain a traceable investigation history, unmanaged device detection becomes a repeatable operational control rather than an occasional cleanup exercise.
