Windows 365 Enterprise Architecture · Part 3

Identity is the most important design decision in a Windows 365 deployment because mistakes in this layer are expensive to correct later. Some other design choices can also require reprovisioning, but identity errors tend to propagate into every other part of the service: authentication, access, compliance, provisioning, and device lifecycle.

That is what makes identity different. If the identity model is wrong before the first Cloud PC is provisioned, the remediation path is usually not a small correction. It is redesign, user disruption, and often reprovisioning for the affected users.

Everything else in Windows 365 should be understood in that context. App delivery can change through Intune. Many device settings can change after go-live. Cloud PCs can be resized without reprovisioning in supported scenarios. Identity does not offer that same level of operational flexibility. The model you design before provisioning begins is the model you are most likely to live with.

This post covers the identity decisions that should be locked before provisioning starts, why changing them later is expensive, and what to validate before anything is built.

If you are joining the series here, Part 1 covers the Windows 365 mental model and Part 2 covers provisioning policy design in detail. Both are worth reading before this one.

Identity is the stable anchor

In Windows 365, the provisioning chain starts with identity and ends with a managed device.

User identity
  → License assignment
    → Provisioning policy
      → Cloud PC
        → Intune-managed device

The user identity is not just the starting point. It is the stable anchor for the lifecycle.

The Cloud PC exists because a licensed identity is targeted for provisioning. Access decisions are evaluated in the context of that identity. Compliance and conditional access outcomes are tied back to that user and device relationship. Operational actions such as reprovision, resize, and restore apply to a Cloud PC that is persistently associated with a named identity.

This means flaws in identity design do not stay isolated. A UPN mismatch affects sign-in. The wrong join model affects access to on-premises resources. A weak separation model affects security posture. These are not post-deployment tuning problems. They are architecture problems.

The join model decision

The most consequential identity decision in Windows 365 is the join model. There are two primary options, and the choice should be made before provisioning begins.

Microsoft Entra joined Cloud PCs join directly to Microsoft Entra ID and are managed through Intune. This is the cloud-native path and the default design choice for new deployments where on-premises dependencies have been removed or are no longer required.

Microsoft Entra hybrid joined Cloud PCs join both on-premises Active Directory and Microsoft Entra ID. This model requires connectivity to on-premises Active Directory through an Azure Network Connection and depends on directory synchronization for the hybrid identity model. It is appropriate when users genuinely need dependency on on-premises AD backed services or authentication patterns that still require that architecture.

The join model is defined in the provisioning policy. For existing Cloud PCs, moving from one join model to the other is not an in-place conversion. In practice, that change should be treated as reprovision-bound.

The design rule is straightforward. If users require access patterns that still depend on on-premises Active Directory, hybrid join may be necessary. If the workload is cloud-first and those dependencies are gone, Entra join is the cleaner design. Do not choose hybrid join as a precaution. It adds dependency, infrastructure, and operational complexity.

UPN alignment

UPN alignment matters more than many teams expect.

In hybrid identity environments, the user sign-in identity needs to be consistent and predictable across on-premises Active Directory and Microsoft Entra ID. If the on-premises environment still uses a non-routable suffix such as contoso.local, that should be corrected before rollout by adding and using a verified routable UPN suffix.

The clean design is simple: the user should have a routable and aligned UPN before Cloud PC provisioning begins.

This is safer than trying to build around identity mismatches later. Alternate sign-in methods exist in Microsoft identity platforms, but they should not be used as a substitute for clean Windows 365 identity design unless there is a clear and validated reason to do so.

A simple validation step before provisioning is to confirm that the intended on-premises sign-in identity and cloud sign-in identity are aligned for every user in scope.

Get-ADUser -Identity username -Properties UserPrincipalName

The returned value should match the UPN used for the same user in Microsoft Entra ID.

Persona modelling and identity

The persona model determines what kind of Cloud PC a user receives, but the constraint sits at the identity layer.

For Windows 365 Enterprise, provisioning honors the first assigned provisioning policy for each Cloud PC license. That means a single identity should be designed around one primary Cloud PC build unless there is a deliberate and governed exception.

This surprises many organizations because it means identity is not just who the user is. It is also the anchor for how that user’s device model is expressed.

When a user appears to need more than one persona, there are two valid approaches.

Option A: Persona hierarchy

This is the preferred model for most organizations. The dominant persona wins. A user who qualifies as both a standard knowledge worker and a higher-spec power user receives the higher-spec build, and application differences are layered on through Intune or other delivery methods. This avoids creating multiple Cloud PCs unnecessarily.

Option B: Separate identities

This is the correct model when hard isolation is a real security requirement. The user has separate identities for separate trust boundaries. Each identity has its own license, provisioning path, Cloud PC, Intune enrollment, and compliance posture.

Multiple licenses on a single identity are technically possible in supported scenarios, but they do not give you a clean way to create different Enterprise builds from different provisioning policies for the same identity. If the requirement is different builds with hard separation, separate identities are the safer architecture.

The persona model should therefore be finalized before provisioning begins. If you need to shift a user to a materially different Cloud PC build later, that is usually a reprovisioning event, not a lightweight policy adjustment.

Separation models

Not all isolation requirements are equal, and Windows 365 design needs to reflect that.

Logical separation uses policy. Intune configuration, Conditional Access, application controls, and access rules differentiate what users can do while they remain within the same broader trust boundary. This is appropriate when the requirement is controlled access, not strict session isolation.

Hard separation uses different identities, different Cloud PCs, and different trust boundaries. This is the right model when one session must not have any trusted path to the resources available from another. Privileged access scenarios and tightly regulated workloads usually fall into this category.

Conditional Access is important, but it is not a replacement for identity isolation. If the security requirement is true separation between work contexts, the defensible design is separate identities backed by separate Cloud PCs.

What the Primary Refresh Token means for Cloud PCs

The Primary Refresh Token, or PRT, is central to how Microsoft Entra joined and hybrid joined Windows devices achieve single sign-on and satisfy identity-based access decisions.

For a Cloud PC, a user may appear to have a working desktop while identity state is still incomplete. That is why “the user can sign in” is not enough validation on its own.

A healthy PRT state matters because it affects access to Microsoft resources and interacts with device-based Conditional Access evaluation. If the PRT is missing or unhealthy, the user may experience repeated prompts, blocked access, or failed sign-ins to protected resources.

For hybrid join scenarios, there are additional dependencies in the chain. Device registration, synchronization state, network reachability to required services, and overall hybrid identity health all matter. This is why Cloud PC provisioning status alone should never be treated as full sign-off for identity readiness.

The practical validation step is to check device join and PRT state using:

dsregcmd /status

That validation should be paired with a real access test to a Conditional Access protected resource.

Identity design checklist

These items should be confirmed before the first Cloud PC is provisioned.

• The join model decision is documented and the on-premises dependency question has been explicitly answered for every user group in scope.
• UPN suffixes are routable and aligned between on-premises Active Directory and Microsoft Entra ID for all affected users.
• For hybrid join deployments, the identity synchronization model is in place and operating as expected.
• For hybrid join deployments, the Azure Network Connection is configured and healthy.
• The persona model is finalized and each identity maps to one primary Cloud PC design unless an explicit exception exists.
• Users who require hard isolation between work contexts use separate identities rather than relying on policy alone.
• Conditional Access has been reviewed so that device registration and sign-in flows are not blocked by unintended policy design.
• At least one test Cloud PC has been provisioned for each join model in scope, PRT state has been validated with dsregcmd /status, and access to a Conditional Access protected resource has been confirmed before pilot rollout begins.

That last point is the one teams skip most often. Provisioning a Cloud PC and confirming that a user can log on is not enough. The real validation is that identity state is healthy, the PRT is present, and protected resources are accessible under the intended access model.