Microsoft Entra Device Identity and Grouping
Key Takeaways
- The current MD-102 Prepare infrastructure domain expects you to choose between Microsoft Entra joined, Microsoft Entra registered, and Microsoft Entra hybrid joined device states.
- Use Microsoft Entra joined for organization-owned cloud-first devices, Microsoft Entra registered for BYOD access, and Microsoft Entra hybrid joined only when on-premises Active Directory dependencies still matter.
- A Microsoft Entra device identity is the object that Intune, Conditional Access, and device-targeted groups use to make management and access decisions.
- Security groups can contain devices or users, but Microsoft 365 groups contain users only; dynamic groups can be dynamic user or dynamic device, not both.
- Dynamic device rules should use stable device attributes such as `deviceTrustType`, `managementType`, or enrollment-related values instead of user attributes.
Why device identity is the first infrastructure decision
Microsoft's current MD-102 study guide lists Prepare infrastructure for devices at 25-30% of the exam and starts with adding devices to Microsoft Entra ID. That is not just terminology. Device identity controls how users sign in, whether the device can satisfy device-based Conditional Access, how Intune sees the endpoint, and which groups can target enrollment, compliance, and configuration.
Microsoft Entra ID can represent a device in three main ways: Microsoft Entra registered, Microsoft Entra joined, and Microsoft Entra hybrid joined. The exam usually gives you business constraints, not a direct vocabulary question. Read for ownership, sign-in identity, on-premises dependency, and desired management level.
| Scenario clue | Best device state | Why it fits |
|---|---|---|
| New corporate Windows laptops, cloud-only tenant, users sign in with work accounts | Microsoft Entra joined | The device is organization-owned and joined only to Microsoft Entra ID, which supports modern sign-in and Intune enrollment. |
| Personal Windows, iOS, Android, or macOS device that should keep the user's existing personal sign-in | Microsoft Entra registered | Registration gives the device a workplace identity for resource access without converting it into a fully joined corporate device. |
| Existing domain-joined Windows devices still need Group Policy, domain line-of-sight, or AD machine authentication | Microsoft Entra hybrid joined | The device remains joined to Windows Server Active Directory and is also represented in Microsoft Entra ID. |
| No Microsoft Entra object, no Intune management, local-only sign-in | Workgroup or local-only | This rarely satisfies MD-102 management requirements unless the question is asking what is missing. |
Join and register decisions
Microsoft Entra joined is the modern default for organization-owned Windows endpoints when the tenant can manage devices from the cloud. It is also a strong answer for remote workers because it avoids requiring line-of-sight to domain controllers during normal use. Pair it with Intune automatic enrollment by making sure the user is licensed and in the Microsoft Intune MDM user scope.
Microsoft Entra registered is the lighter BYOD state. A user adds a work or school account to an existing device, and the device receives a Microsoft Entra device object. Registration alone is not the same as Intune enrollment. If the organization requires a compliant BYOD device, the user normally registers the device and enrolls it into Intune so compliance policies can evaluate it.
Microsoft Entra hybrid joined is appropriate when the organization is not ready to leave on-premises Active Directory. Microsoft notes that hybrid joined devices need periodic line-of-sight to domain controllers; if that is a problem, favor Microsoft Entra join. On MD-102, hybrid join is often the right answer only when the scenario explicitly mentions legacy Group Policy, domain-joined computer accounts, on-premises apps that use machine authentication, or an existing Configuration Manager/co-management design.
Grouping for Intune and Conditional Access
Groups are how an endpoint administrator turns identity into targeting. Use security groups for device management, app assignment, compliance policies, Conditional Access scoping, and administrator delegation. Microsoft 365 groups are collaboration groups and can only contain users, so they are not the right answer for device membership targeting.
| Group choice | Use it when | MD-102 trap |
|---|---|---|
| Assigned user group | You need a stable pilot, department, or ring based on people | A user assignment can follow the user across multiple devices. That may be good for apps, but not always for device-specific controls. |
| Assigned device group | You need exact membership for high-risk devices, shared devices, or break-fix targeting | Manual membership is precise but does not scale well. |
| Dynamic device security group | You need automatic membership based on device attributes | Device rules cannot reference the device owner's user attributes. |
| Dynamic user security group | You need automatic membership based on user attributes such as department | This targets users, not a specific hardware population. |
Useful dynamic device rule patterns include all devices with device.objectId -ne null, Microsoft Entra joined devices with device.deviceTrustType -eq "AzureAD", hybrid joined devices with device.deviceTrustType -eq "ServerAD", and registered devices with device.deviceTrustType -eq "Workplace". For Intune-managed devices, device.managementType -eq "MDM" is often more meaningful than only the join state.
Plan groups around the policy lifecycle. A compliance policy might target all managed corporate Windows devices. A Conditional Access policy might target all users but exclude break-glass accounts. An enrollment profile might target a dynamic device group populated by an enrollment profile name or other enrollment-time attribute. The exam rewards understanding that groups are not just containers; they are the control plane for who receives settings and who is evaluated for access.
Exam checklist
- Identify ownership first: corporate, personal, shared, kiosk, or contractor-owned.
- Identify sign-in requirements: work account primary sign-in, personal sign-in with work access, or domain sign-in.
- Identify legacy dependencies: Group Policy, on-premises AD, domain controllers, or Configuration Manager.
- Choose the group type that matches the target: user group for people, device group for devices, security group for management, dynamic group for scale.
- Remember that registration, join, and Intune enrollment are related but separate concepts.
A company is replacing aging domain-joined laptops with new Windows 11 devices. The company has moved file access, apps, and identity to Microsoft 365, and users work remotely most of the time. The endpoint team wants cloud sign-in and Intune management without depending on domain controllers. Which device state should you choose?
You need an Intune assignment group that automatically contains Microsoft Entra hybrid joined Windows devices but does not include Microsoft Entra joined or registered devices. Which dynamic device rule is the best match?
Contractors use personal Windows 11 PCs to access Teams and SharePoint. They must keep their existing personal device sign-in, but the organization wants an identity-aware device object for Conditional Access and optional Intune enrollment. What should the contractors do?