Identity: Microsoft Entra join for Windows 365 Cloud PCs

Overview

Device identity describes how a Cloud PC joins Microsoft Entra ID. The join type determines how the device is managed, how users authenticate, and whether it depends on on-premises infrastructure.

There are two join type options that you can select from when provisioning a Cloud PC:

  • Microsoft Entra join — recommended deployment option. Joins devices directly to Microsoft Entra ID, enabling cloud-first management, modern authentication, and access to organizational resources without relying on on-premises Active Directory.
  • Microsoft Entra hybrid join — for traditional or specialized requirements. Joins devices to both on-premises Active Directory and Microsoft Entra ID, supporting existing domain-dependent applications, policies, and infrastructure during transition.

At a glance: Microsoft Entra join offers the simpler, cloud-first Zero Trust path, with less infrastructure and operational overhead. Microsoft Entra hybrid join retains compatibility with legacy dependencies but requires additional on-premises connectivity and management.

We recommend starting with Microsoft Entra join when deploying Cloud PCs, for a cloud-native approach built on Zero Trust principles. Only revert to Microsoft Entra hybrid join after first validating that Microsoft Entra join won't meet your organization's needs.

With Microsoft Entra join, Windows 365 joins your Cloud PC device directly to Microsoft Entra ID. All three user identity types are still supported: hybrid, cloud-only, and external. Microsoft Entra join refers to the Cloud PC device identity only — your users can continue to sign in with any of these identity types.

Cloud-native doesn't mean cloud-only. Hybrid identity users can still access on-premises resources such as file shares, or legacy applications that require NTLM or Kerberos authentication with Active Directory. Applications that require a computer account in Active Directory or device authentication may require a hybrid approach instead, but often represent a small percentage of the overall app estate.

For most organizations, Microsoft Entra join meets both modern cloud service requirements and existing on-premises resource access needs, with fewer infrastructure dependencies than hybrid join.

Why Microsoft recommends Microsoft Entra join

Cloud-native doesn't mean cloud-only. These devices are managed through cloud services while retaining the compatibility needed to access on-premises resources where configured.

  • Identity-based access control — cloud-native Windows devices support a Zero Trust architecture through identity-based access and device compliance checks.
  • Faster provisioning of Cloud PCs — provisioning has no dependencies on on-premises infrastructure and doesn't require additional time for the Microsoft Entra Connect sync process to complete.
  • Faster sign-in — the Microsoft Entra joined sign-in process doesn't use an on-premises domain controller for connectivity, and is faster than a traditional domain-based sign-in.
  • Simplified device management — your Cloud PCs don't require a direct connection to any on-premises resources for device management.
  • No requirement for Azure Network Connection (ANC) — use Microsoft Hosted Network (MHN) and benefit from lower operational overhead and egress costs. Access to on-premises resources can be through a VPN or Zero Trust Network Access solution.

Microsoft Entra hybrid join: traditional approach

Microsoft Entra hybrid join results in Cloud PCs that are joined to both your on-premises Active Directory domain and Microsoft Entra ID. Windows 365 provisions the Cloud PC directly into your Active Directory domain while also synchronizing the device identity to Microsoft Entra ID. This enables compatibility with traditional domain-dependent applications, policies, authentication methods, and operational processes.

When should you consider it?

Microsoft Entra hybrid join should only be considered where a documented business, technical, security, compliance, regulatory, application, or operational dependency can't be met through Microsoft Entra join. Examples include:

  • Applications that require a computer account or device identity in Active Directory.
  • Workloads that depend on device-based Kerberos or NTLM authentication.
  • Existing operational processes or tooling that require traditional domain-joined devices.
  • Specific regulatory or business requirements that mandate direct Active Directory device membership.
  • Transitional scenarios where organizations are modernizing toward a cloud-native model but aren't yet able to remove all domain dependencies.

Trade-offs and considerations

While Microsoft Entra hybrid join can address these requirements, organizations should understand the additional complexity and operational overhead involved:

  • Requires Microsoft Entra Connect to be properly configured to synchronize device identities between Active Directory and Microsoft Entra ID.

  • Slower Cloud PC provisioning and sign-in experiences due to dependency on on-premises services and synchronization processes.

  • Requires an Azure Network Connection (ANC) with line of sight to Active Directory domain controllers.

  • Introduces additional networking, infrastructure, and operational dependencies that must be maintained and supported.

  • Persistent network attachment introduces additional network dependencies and infrastructure considerations that cloud-native deployments can often avoid.

  • Increased costs to maintain Azure network infrastructure, and bandwidth costs for outbound egress traffic.

Important

Where Microsoft Entra hybrid join may be required, limit it to the affected users or scenarios. Document the workloads involved, the requirement being met, the trade-offs accepted, and the plan to move to the cloud-native model later. Keeping exceptions narrow lets the rest of the deployment retain the benefits of a cloud-native, Zero Trust approach.

Comparison

Capability or requirement Microsoft Entra join Microsoft Entra hybrid join
Recommended use case Default and preferred option for most use cases Only for traditional or specific use cases
User identity type supported for sign-in Hybrid users, cloud-only users, or external users Hybrid users only
Policy management Intune / Intune Policies Group Policy Objects (GPO) or Intune / Intune Policies
Windows Hello for Business sign-in supported Yes Yes
Access to on-premises file resources such as file shares Yes, for hybrid users. Requires line of sight Yes, for hybrid users. Requires line of sight
Legacy applications that only support NTLM or Kerberos authentication with Active Directory Yes, for hybrid users Yes
Azure subscription Optional Required
Azure virtual network with line of sight to the domain controller Optional Required

Adoption path

Deploying your Cloud PCs with Microsoft Entra join requires minimal or no configuration. This allows you to quickly validate that access to any on-premises resources works as it does on other AD-joined or Microsoft Entra hybrid joined devices.

  1. Start with Microsoft Hosted Network (MHN). This allows you to rapidly deploy Cloud PCs to run a cloud-native pilot.
  2. Decide what type of user identity you need. Most organizations use hybrid user identities, which are needed to authenticate to on-premises resources. Provided your users are already configured with Microsoft Entra Connect to be synchronized from Active Directory to Microsoft Entra ID, you're ready to go.
  3. Give access to on-premises resources line of sight. Consider how your current physical devices, such as laptops, access similar resources when they're away from the office network. The same VPN or Zero Trust Network Access (ZTNA) solution can be deployed to your Cloud PCs from Intune to provide that line of sight without needing to configure an Azure Network Connection (ANC).
  4. Validate NTLM and Kerberos authentication. Authentication to file shares or legacy applications should work without additional configuration. However, for passwordless authentication such as FIDO2 or Windows Hello for Business, you must set up cloud Kerberos trust. Cloud Kerberos trust requires fewer components than earlier Windows Hello for Business trust models.
  5. Move to policy management with Microsoft Intune. Rather than attempting to migrate all your GPOs to Intune, consider starting over with a Zero Trust, cloud-native mindset. The Windows 365 security baseline provides a starting point for a pilot, leaving behind legacy Group Policy Objects that may no longer be relevant to today's Windows operating systems or your business requirements. Use Group Policy analytics in Intune to identify the legacy policies worth carrying forward, rather than migrating everything. Treat this as an opportunity to establish a new baseline.

Related content

Next steps

Once device identity is decided, choose how Cloud PCs connect to the internet, Microsoft services, and your organizational resources.

Network: Microsoft Hosted Network for Cloud PCs

  • Last updated on