How to Ensure Proper Device Enrollment in Azure
Introduction
Managing a clean device inventory is crucial for maintaining security, compliance, and operational efficiency. However, many organizations encounter issues where the same physical device appears multiple times across Microsoft Entra ID (formerly Azure AD), Microsoft Intune, and Microsoft Defender for Endpoint. Since these duplicate assets in Azure are reported as unique and separate instances (often due to different device IDs or registration methods), they will not be treated as a single asset within vScope.
This article explains why devices may appear as duplicates in Azure, why this is problematic, and how to prevent and resolve the underlying causes of this issue.
Why duplicate devices in Azure is problomatic
Having inconsistent device configurations in Azure can lead to several issues. At scale, even minor misconfigurations can create security gaps due to policies not being applied correctly, increase costs due to the consumption of multiple licenses by a single physical device, and result in inaccurate compliance reporting.
Here’s an overview of how duplicate devices in Azure might impact your IT operations:
| Problem Area | Impact |
|---|---|
| Security Policies | Conditional Access may apply to the wrong or outdated device. |
| Compliance Reporting | Compliance dashboards show incorrect or inconsistent statuses. |
| Licensing Costs | The same device might consume multiple licenses. |
| Incident Response | Investigations in Defender are slowed by redundant device entries. |
| User Experience | Users may be forced to re-authenticate or re-enroll devices unnecessarily. |
| Automation Issues | Scripts and policies based on device groups may fail or misapply. |
| Administration Complexity | Unnecessary complexity makes administration less responsive. |
What causes duplicate devices in Azure (and how to prevent them)
Here are the most common misconfigurations that may cause invalid representations of devices in Azure, along with preventative measures:
Independent Registration Paths (prevent with standardized enrollment)
Device enrollment in the different platforms in Azure might not be aligned.
- Microsoft Entra ID: When a device is joined or registered with Azure AD, it creates a device object that manages the device’s identity within Azure. This can happen during the initial setup of a Windows device or when a user adds a work or school account.
- Microsoft Intune: Intune enrolls devices for mobile device management (MDM) and mobile application management (MAM). This process also creates a device object in Intune, which is primarily used for policy enforcement and inventory within Intune.
- Microsoft Defender for Endpoint: When a device is onboarded to Defender for Endpoint for security monitoring and threat detection, it creates a device entry within the Defender portal. This entry focuses on the security posture and reporting of the device.
If these processes occur separately without a coordinated approach, each platform/service will create its own record for the same physical device. For example, a device might be Azure AD Joined by IT, then a user might enroll it in Intune, and finally, the security team might onboard it to Defender for Endpoint – resulting in three (!) separate entries.
How to prevent this from happening…
Standardizing the enrollment process, ideally by using Intune as the central platform to manage Azure AD Join and integrate Defender onboarding, helps to link these registrations and prevent duplicates.
Enrollment timing issues (prevent with correct enrollment sequence)
The order in which devices are enrolled in Microsoft Entra ID, Intune, and onboarded to Microsoft Defender for Endpoint is critical. Deviating from the recommended flow can lead to duplicate records.
The ideal sequence is typically:
- Microsoft Entra ID Join (or Hybrid Azure AD Join): This establishes the device’s primary identity within Azure.
- Microsoft Intune Enrollment: Once the device has an Azure AD identity, it can be enrolled in Intune for management and policy enforcement. Microsoft Entra ID can be configured to automatically trigger Intune enrollment for joined devices.
- Microsoft Defender for Endpoint Onboarding: Intune provides integrated methods to onboard devices to Defender for Endpoint during or shortly after Intune enrollment.
If Defender for Endpoint onboarding occurs before Azure AD Join or Intune enrollment, Defender will create a device record independently. Subsequently joining to Azure AD or enrolling in Intune will generate new, separate records. Similarly, devices that are initially only Azure AD Registered (through user-initiated actions) and later properly joined or enrolled can result in duplicates.
How to prevent this from happening…
Ensuring devices follow the recommended enrollment sequence minimizes timing-related enrollment issues.**
- Learn more about Microsoft Defender for Endpoint onboarding
- Learn more about Azure AD Join
- Learn more about Intune enrollment processes.
User-initiated registrations (prevent with policy and user education)
This often happens when users, intentionally or unintentionally, add their work or school account to a personal device without going through the organization’s standard enrollment process.
When a user adds a work or school account in Windows (e.g., via “Add a work or school account” in settings), the device becomes “Azure AD Registered”. This creates a basic device identity in Azure AD but doesn’t provide the same level of management as an Azure AD Joined device or a device enrolled in Intune.
If the same device is later properly Azure AD Joined or Intune enrolled by IT, you’ll have two entries: the less managed “Azure AD Registered” record and the fully managed joined/enrolled record.
How to prevent this from happening…
Implementing Conditional Access policies that restrict access from Azure AD Registered devices and educating users on the correct enrollment procedures can help prevent this.
Device reimaging or renaming (prevent with consistent procedures)
When a device is reimaged or its hostname is changed, it can sometimes lead to the creation of new device records.
The reimaging process might reset certain hardware identifiers or the operating system installation in a way that the device is seen as new by Azure AD, Intune, or Defender, even if it’s the same physical hardware.
While renaming a device should ideally update the existing records, inconsistencies in how this is handled across the services or during specific stages of the device lifecycle can sometimes result in a new record being created with the new name, while the old record with the previous name persists.
How to prevent this from happening…
Establishing consistent procedures for device reimaging and renaming, ideally integrated with Intune management, can help prevent these duplicates.
Lack of unified management policies (prevent with centralized management)
Using GPO, manual scripts, and Intune independently can fragment device registration.
A lack of clear policies and procedures for device onboarding and lifecycle management across all relevant platforms increases the likelihood of duplicate records.
How to prevent this from happening…
Adopting a unified endpoint management (UEM) strategy, primarily leveraging Intune as the central management platform to manage device configuration and enrollment across Azure AD and integrate with Defender for Endpoint, is a recommended approach to achieving consistent device registration and minimizing duplicates.
Additional resources
The issue with duplicate records in Azure is common, however, there is a lot of missing information in the Microsoft Guides around how to solve the issue. Here are additional resources that we’ve found on the topic that might help you further: