Windows 365 Policy Reranking, Customer-Managed Encryption for Reserve, and Domainless Federation — What's New July 2026

Microsoft dropped three significant Windows 365 updates in the July 6 and June 15 What’s New entries — covering policy management, encryption control, and identity federation. Each addresses a different pain point that IT admins have been asking Microsoft to solve. Let’s break down what’s new, why it matters, and what you need to do about it.

1. Rerank Settings Policies (Public Preview)

The Problem It Solves

If you’ve managed Windows 365 Cloud PCs for any length of time, you’ve hit this scenario: multiple settings policies target the same Cloud PC, they conflict on a particular setting, and you can’t easily control which one wins. Maybe your security team has a policy that enforces BitLocker, but a department-level policy accidentally overrides a related encryption setting. The result is unpredictable policy behavior that’s hard to troubleshoot.

Until now, Windows 365 settings policies followed an implicit precedence model — typically last-writer-wins or based on assignment order — with limited visibility into why a particular setting ended up with the value it did.

What’s New

Windows 365 now supports reranking settings policies in public preview. Administrators can explicitly prioritize which policy takes precedence when conflicting settings are configured. Policies can be reordered by:

• Changing their rank — assign explicit priority values
• Drag-and-drop controls — visually reorder policies in the admin center
• Moving policies up and down the list

When a Cloud PC receives multiple policies that touch the same setting, the policy with the highest rank determines the effective value. This makes policy precedence explicit, visible, and manageable rather than opaque.

How Precedence Works

The typical layering follows this pattern:

1. Hard platform constraints — compliance requirements that cannot be overridden by reranking
2. Highest-ranked Windows 365 settings policy — the rank you assign determines the winner
3. Policy type precedence — security baselines may still override lower-importance configuration policies regardless of rank
4. Scope ties — device-scoped vs. user-scoped policies, with precedence depending on the setting type
5. Same rank, same type — last-writer-wins (rare and discouraged)

What IT Admins Should Do

Immediate actions:

• Review your current Windows 365 settings policies and identify where conflicts exist
• Define a priority scheme for your organization (e.g., security baselines at rank 1, compliance policies at rank 2, standard config at rank 3, department/pilot policies at rank 4+)
• Test reranking in a pilot group before broad rollout

Governance considerations:

• Treat rank changes as change-controlled operations — document who changed rankings and why
• Use policy conflict reports (when available) to verify which settings are being overridden
• Establish a central policy hierarchy document so all admins understand the intended precedence

Roles required: Cloud PC Administrator, Intune Policy Administrator, or equivalent.

Why This Matters

This is a governance feature. It doesn’t add new capabilities to Cloud PCs — it makes existing capabilities more predictable and manageable. For organizations running multiple policies across departments, regions, or business units, this eliminates a real source of configuration drift and troubleshooting headaches.

Learn more in Settings overview.

2. Customer-Managed Encryption for Windows 365 Reserve (Public Preview)

The Problem It Solves

Windows 365 Reserve gives organizations on-demand Cloud PC capacity for scenarios like device failures, travel, or temporary access needs. But until now, Reserve Cloud PCs relied on Microsoft-managed encryption keys — the data at rest was encrypted, but organizations had no control over the encryption keys themselves.

For regulated industries — healthcare, finance, government — this has been a gap. Compliance frameworks like HIPAA, FedRAMP, and certain regional data sovereignty regulations require customer-controlled encryption keys. Organizations that needed CMK for compliance could use it on Enterprise Cloud PCs, but Reserve was left out.

What’s New

Windows 365 Reserve now supports Microsoft Purview Customer Key (CMK) in public preview. This enables administrators to encrypt Reserve Cloud PC disks with customer-managed keys stored in Azure Key Vault.

Here’s how it works under the hood:

• Microsoft encrypts Reserve Cloud PC data at rest using a data encryption key (DEK)
• The DEK is protected (wrapped) by a customer-provided key encryption key (KEK) stored in your Azure Key Vault
• Microsoft cannot decrypt the data without access to your Key Vault key
• If you revoke or delete your KEK, the Cloud PC data becomes irretrievable — effectively a crypto-wipe

Key Capabilities

• Key rotation: Update your KEK in Key Vault, and DEKs are automatically rewrapped. Cloud PCs remain operational during rotation if properly coordinated.
• Key revocation: Disable or delete the KEK to render Cloud PC data unreadable — a powerful containment tool for security incidents.
• Auditing: Full audit trail of key usage via Azure Key Vault diagnostic logs.
• Compliance alignment: Helps meet regulatory requirements for customer-controlled encryption, including HIPAA, FedRAMP, and regional data sovereignty mandates.

Setup Requirements

1. Azure Key Vault with RSA keys meeting Microsoft’s supported key types for Customer Key
2. Soft delete and purge protection enabled on the vault to prevent accidental permanent key loss
3. Managed identity with get, unwrapKey, and wrapKey permissions on the Key Vault key
4. Microsoft Purview Customer Key configuration enabled for Windows 365 workloads
5. Customer Key policy referencing your Key Vault key URI and version
6. Windows 365 Reserve provisioning policy bound to the Customer Key policy

What IT Admins Should Do

If you’re already using CMK for Enterprise Cloud PCs:

• This is a straightforward extension — review your existing Key Vault setup and determine whether to use the same key or a separate key for Reserve Cloud PCs
• Update your encryption policy documentation to include Reserve

If CMK is new to your organization:

• Engage your security team to design the key management lifecycle (creation, approval, rotation cadence, retirement)
• Establish a Key Vault governance process — who can create, rotate, and delete keys
• Set up monitoring and alerts for near-expiry keys and unexpected access patterns
• Document the rotation procedure and test it in a non-production environment first
• Critical: Understand that key deletion is irreversible and will permanently lock Cloud PC data. Build safeguards accordingly.

Compliance teams:

• Document how CMK for Reserve satisfies your specific regulatory requirements
• Establish key access audit reporting as part of your compliance evidence

This extends the existing CMK experience already available for Windows 365 Enterprise Cloud PCs, bringing the same encryption control to the Reserve tier.

Learn more in Microsoft Purview Customer Key setup and support for W365.

3. External Identity Support for Domainless Federation

The Problem It Solves

Windows 365 has supported external identities — letting users outside your organization access Cloud PCs — for a while now. But there was a catch: federation required domain-based identity. You had to register and verify a DNS domain (like partner.com) in Entra ID, then configure federation for that domain.

This worked fine for established partnerships where you knew the partner’s domain. But it broke down in several scenarios:

• Multi-tenant partners whose identities span multiple domains
• IdPs that don’t map to a single DNS namespace — increasingly common with modern identity providers
• Consultants and contractors whose email domains don’t match their IdP’s configured domain
• B2B collaboration where you need to provision Cloud PCs for users from organizations where you don’t control or verify their DNS

The result was a workaround-heavy process: create shadow accounts, use email aliasing, or force partners to rebrand their identities to fit your federation model.

What’s New

With the general availability of Domainless SAML IdP federation in Entra ID, Windows 365 now supports provisioning Cloud PCs for external identities whose email domain differs from the domain configured on the SAML IdP.

In other words: federation is now configured at the tenant/application level, not tied to a specific DNS domain. The SAML IdP issues assertions with any identifier (NameID, email, subject claim), and Entra ID trusts those assertions without requiring DNS domain ownership.

How Domainless Federation Differs from Domain-Based

Cloud PC Provisioning Flow

1. Configure external IdP in Entra ID — add SAML metadata (entity ID, SSO URL, signing certificates), configure claim mappings
2. Create external identity objects — B2B-style user records in your tenant mapping to the IdP identifiers
3. Assign Windows 365 licenses to external identity objects
4. Target provisioning policies to external identities or groups
5. User sign-in: External user authenticates via their home IdP → SAML assertion → Entra ID validates signature, issuer, audience, and claim mappings → Cloud PC access granted

Important: External users must redeem their invitation to the organization before signing into the Windows App.

Security Implications

Advantages:

• External users authenticate with their home organization’s credentials — no password sync, no shadow accounts
• Stronger separation between internal and external identities
• Reduced identity management overhead for partner organizations

Risks to manage:

• Your trust boundary now extends to the external IdP’s security posture — if they’re compromised, attackers can obtain valid assertions
• Claim mapping misconfiguration can over-grant access or associate assertions with wrong user objects
• Lifecycle management is critical — you need clear processes for removing external users and licenses when partnerships end

Security best practices:

• Require the external IdP to enforce MFA
• Apply Conditional Access policies for external identities (device compliance, sign-in risk, location controls)
• Segment external users into dedicated Cloud PC provisioning policies with reduced privileges and separate network segments
• Conduct periodic access reviews — who still needs Cloud PC access?

What IT Admins Should Do

Identity admins:

• Configure SAML federation metadata in Entra ID for partner IdPs
• Plan certificate rotation procedures with minimal downtime
• Define claim mapping rules carefully — test with a single external user before broad rollout

Windows 365/Intune admins:

• Create dedicated provisioning policies for external identities
• Consider network isolation — external users may not need access to internal corporate resources
• Apply appropriate Conditional Access policies

Security architects:

• Design the trust relationship and document the shared responsibility model with each partner
• Establish monitoring for anomalous external user sign-in patterns
• Create an offboarding process for external identities

Learn more in External identity and Domainless SAML IdP federation.

The Bigger Picture

These three updates collectively address governance, security, and identity — the three pillars that determine how confidently an organization can scale its Windows 365 deployment:

• Policy reranking gives admins explicit control over configuration precedence — essential as deployments grow beyond a handful of policies
• CMK for Reserve closes the encryption control gap for regulated workloads — Reserve is no longer a compliance compromise
• Domainless federation removes the last identity friction for partner and contractor Cloud PC access — no more DNS-domain workarounds

All three are in public preview (or newly GA for domainless federation), meaning now is the time to evaluate them in test environments and plan for production rollout.

Action Items Summary

1. Policy reranking: Audit current policy conflicts, define a priority scheme, pilot in a test group
2. CMK for Reserve: Engage security team, design key lifecycle, set up Key Vault with purge protection, test rotation
3. Domainless federation: Identify partner IdPs, configure SAML metadata, create dedicated provisioning policies for external users, apply Conditional Access

Big Hat Group helps organizations deploy and optimize Windows 365 and Microsoft Intune environments. Need help with policy governance, encryption strategy, or external identity configuration? Get in touch.

Follow us on X @kkaminski for daily Microsoft ecosystem updates.