External Identities for AVD and Windows 365: Public Preview

Microsoft has opened the door for secure, managed collaboration with non‑employee accounts by adding external identity support for Azure Virtual Desktop (AVD) and Windows 365 in public preview — a change that lets organizations invite partners, contractors, and other guest users into their Entra ID tenant to access virtual desktops and Cloud PCs without creating full internal accounts.

Background / Overview​

Microsoft’s move extends the Entra External ID and federation model into desktop-as-a-service and VDI scenarios. Historically, accessing Cloud PCs or AVD sessions required accounts that were part of the organization’s primary directory landscape (either cloud-only Entra accounts, hybrid identities, or AD‑backed identities). The new public preview enables an organization to invite identities that originate outside its tenant — including other Azure AD/Entra tenants and supported social or third‑party identity providers that federate via OpenID Connect — and grant those external identities access to AVD app groups or Windows 365 Cloud PCs.
This capability is delivered as a preview and comes with explicit requirements and limitations that will shape how, when, and where enterprises adopt it. The first commercial rollouts are reflected in the Azure Virtual Desktop and Windows 365 documentation and are already noted in industry coverage.

---

What Microsoft actually shipped (the essentials)​

• External identities can be invited into an organization’s Entra tenant and then assigned to AVD app groups or Windows 365 Cloud PCs, enabling access with the external account’s credentials.
• Session hosts (AVD) and Cloud PCs (Windows 365) that host these external users must be Microsoft Entra joined and run Windows 11 Enterprise, version 24H2 with the September 2025 cumulative updates (KB5065789) or later.
• Single sign‑on (SSO) must be configured on the host pool / Cloud PC and external users must connect using the Windows App on Windows or a web browser.
• The preview does not support FSLogix profile containers for external identities; profiles are created locally on each session host instead.
• Intune device configuration policies assigned to the external identity won’t apply to the user’s session; policies must be applied to the device instead.
• The feature is available only in the Azure public cloud — invitations from Azure Government or Azure operated by 21Vianet and cross‑cloud invites aren’t supported in this preview.
• External identities cannot use Kerberos or NTLM to authenticate to on‑premises resources from the session.

These items summarize the most consequential operational constraints administrators will encounter in the preview.

---

Why this matters: benefits and business value​

Expanding external identity support to AVD and Windows 365 is more than a convenience — it addresses several real operational and security needs for modern hybrid enterprises:

• Faster partner onboarding: External partners can be invited and given desktop or app access using their existing credentials, removing the need for new corporate accounts or long federation projects.
• Reduced account proliferation: Organizations avoid creating shadow internal accounts or managing temporary AD objects for contractors and external consultants.
• Improved user experience: When SSO is enabled, invited users can authenticate using modern methods such as passwordless sign‑in, providing a smoother connection flow while reducing credential risk.
• Centralized access control: Invitations and access assignments remain under Entra governance, enabling admins to leverage existing Conditional Access, entitlement, and audit controls (subject to the limitations that apply to external identities).
• Simplified federation with IdPs: With Entra External ID and OIDC support maturing, enterprises can tap into a broad range of identity providers to authenticate guests without bespoke federation plumbing.

For organizations that collaborate frequently with outside entities, these capabilities can materially shorten project ramp‑up times and simplify secure desktop delivery models.

---

Technical requirements — what you must have in place​

Successful use of external identities for AVD or Windows 365 requires careful platform alignment. Key technical prerequisites include:

• The session host (AVD) or Cloud PC (Windows 365) must be Entra joined (cloud join). Hybrid or AD‑joined hosts will not meet the preview’s external identity flow unless specifically documented otherwise.
• Hosts must run Windows 11 Enterprise, 24H2, with the 2025‑09 cumulative update (KB5065789) or later applied. This requirement covers both AVD session hosts and Cloud PCs delivered by Windows 365.
• Single sign‑on must be enabled and configured for the host pool or Cloud PC so Entra tokens are accepted and seamlessly used for Windows sign‑in. Microsoft’s SSO configuration guide remains the canonical step‑by‑step reference for enabling this.
• External users must connect via the Windows App for Windows or a web browser. Legacy Remote Desktop client paths are not part of the supported preview path.

Administrators should validate host imaging, updates, and join state before inviting guest users. Because the preview relies on modern Entra authentication primitives and token protection behavior, keeping hosts patched and SSO configured is non‑negotiable.

---

Limitations and operational trade‑offs to plan for​

The preview contains several restrictions that are especially meaningful for teams running mature VDI estates. These are not minor footnotes — they change how you design profiles, policy, and access to on‑prem resources.

Profile and user state​

• No FSLogix support for external identities (preview): External users connecting to pooled session hosts will generate local profiles on each host. This means:
• No roaming FSLogix VHD(X)-based profiles for external identities during the preview.
• External users may lose persistent state across non‑dedicated pooled sessions unless you implement alternative profile persistence strategies.
• The absence of FSLogix undermines many organizations’ user experience expectations for VDI where roaming profiles are standard. Evaluate whether dedicated Azure Virtual Desktop personal host pools or Windows 365 Cloud PCs (which deliver persistent disks) are a better fit for external users in this period.

Device management and Intune​

• Intune device configuration policies assigned to the user do not apply to external identities in session hosts. You must assign policies to the device instead, or adopt device‑based conditional access and compliance checks.
• In practice, this means you cannot rely on user‑scoped device configuration to enforce things like BitLocker or configuration baselines for external accounts; your governance has to be device‑centric.

On‑premises authentication and protocols​

• Kerberos and NTLM are not supported for external identities when authenticating to on‑premises resources from a session. External users cannot leverage Entra Kerberos to access SMB shares or legacy services that require Kerberos tokens in the preview.
• If your AVD or Cloud PC workloads need to access on‑prem file shares, line‑of‑business apps, or resources depending on Kerberos delegation, you must plan alternative authentication paths (proxy services, modern authentication APIs, or hybrid architectures with hybrid identities). This limitation is potentially the single most impactful blocker for organizations with deep on‑prem dependencies.

Cloud availability and cross‑cloud restrictions​

• The preview is limited to the Azure commercial public cloud. Users invited from Azure Government or Azure operated by 21Vianet are excluded, and cross‑cloud user scenarios are not supported. This is a hard constraint for public sector and China‑region customers.

Token protection and device binding​

• Microsoft Entra token protection and token binding behaviors have some restrictions for external identities — platform support varies, and admins should test Conditional Access policies (including token protection requirements) with invited users. Expect nuances in device token protection depending on client OS and app platform.

---

Security and governance considerations​

Adding external identities opens administrative flexibility, but also increases the attack surface and governance complexity. The preview’s constraints complicate some security controls, so these actions are recommended:

• Use just‑in‑time access and least privilege when assigning AVD app groups or Cloud PCs to external identities.
• Apply Conditional Access policies scoped to external users and require device or session‑level controls where possible (e.g., require MFA, compliant device, or approved client app).
• Use entitlement reviews and automated cleanup policies for guest accounts to avoid stale access.
• For high‑risk or sensitive resources, prefer Windows 365 Cloud PCs with persistent storage and stricter device enrollment over pooled AVD session hosts for external collaborators.
• Validate audit and sign‑in logs for invited users; ensure monitoring and SIEM ingestion covers external identity events.

Because Intune user‑applied policies don’t carry over to external accounts on session hosts, rely on device‑side controls and host‑level configuration management to enforce baseline security.

---

Deployment scenarios and recommended patterns​

Below are practical deployment patterns depending on typical partner and contractor use cases.

Scenario A — Short‑term contractor needing desktop apps (best fit: Windows App + browser)​

• Invite contractor as an external identity in Entra.
• Assign to an AVD pooled app group or Cloud PC resource.
• Use Windows App (Windows) or browser access.
• Accept that FSLogix is not available; advise contractors about non‑persistence on pooled hosts or use a Cloud PC if state must persist.

Scenario B — Long‑term external consultant requiring persistent environment (best fit: Windows 365 Cloud PC)​

• Provision a Windows 365 Cloud PC for the consultant (Cloud PC supports persistent disks).
• Ensure Cloud PC is Entra joined, patched to Windows 11 24H2 + required cumulative update, and SSO is configured.
• Enforce device controls and conditional access at the Cloud PC level.

Scenario C — External partner needing access to on‑prem resources (complex)​

• Do not rely on external identities in the preview if Kerberos/NTLM access to on‑prem resources is required.
• Consider hybrid identity (guest with synced/hybrid account) or VPN/Reverse proxy that uses modern auth (OAuth/OIDC) for the on‑prem application.
• Alternatively, provision a dedicated Cloud PC with preconfigured access methods that use modern authentication gateways.

These patterns provide a practical starting point for most organizations evaluating the preview.

---

Step‑by‑step checklist for pilot deployments​

• Confirm host images are running Windows 11 Enterprise 24H2 and have the 2025‑09 cumulative update (KB5065789) or later installed.
• Ensure session hosts or Cloud PCs are Microsoft Entra joined.
• Configure single sign‑on for the host pool or Cloud PC following Microsoft’s SSO guidance.
• Validate the Windows App or browser access flow for invited external users in a test tenant.
• Decide how you will handle user profiles (FSLogix not supported for external identities in the preview).
• Rework Intune or device management policies so that device‑based policies cover external identity sessions.
• Create Conditional Access policies specifically for external identities, including MFA and device requirements.
• Run a staged pilot with a small set of external users and monitor authentication logs, session behavior, and application access.
• Document rollback and support procedures for incidents, especially for on‑prem authentication failures.

---

Licensing, cost, and product fit (what to verify)​

Microsoft’s documentation reminds administrators to check licensing guidance when providing AVD resources to external identities. Licensing for AVD and Windows 365 can be nuanced — for example, Cloud PC licensing, Windows 365 SKUs, and Microsoft Entra External ID/guest licensing may all influence cost. Confirm entitlement model and licensing for guest accounts before scaling beyond pilot users.
Additionally, the choice between AVD pooled hosts (cost efficient but stateless without FSLogix) and Windows 365 Cloud PCs (higher per‑user cost but persistent) will directly affect total cost of ownership for external accounts.

---

Troubleshooting highlights and gotchas​

• If external users report repeated sign‑in prompts or SSO failures, verify the host pool’s SSO configuration and token protection compatibility for external identities.
• If profile data is missing between sessions, remember FSLogix is not supported for external identities in the preview — confirm whether the user was assigned to a pooled host and recommend Cloud PCs for persistence.
• For access failures to on‑prem resources, do not assume Kerberos will work; instead, examine whether modern authentication paths or hybrid identity approaches are required.
• Onboarding external identities with social providers may require configuration in Microsoft Entra External ID and verification of OIDC provider settings. Test end‑to‑end for each identity provider you intend to support.

---

Risk assessment and what to watch for​

This preview delivers strong value but introduces several operational and security risks if deployed prematurely.

• Profile fragmentation: Without FSLogix, external user sessions will be effectively stateless across pooled hosts. If that is unacceptable, do not use AVD pooled host pools for external identities in production.
• Policy gaps: Intune user‑based policies won’t apply. Organizations that rely on user policy assignment need to redesign management to avoid security lapses.
• Authentication traps: The inability to use Kerberos/NTLM for on‑prem resources can break business workflows or produce support escalations; these dependencies must be mapped and mitigated before rollout.
• Cloud availability limitations: Government and China markets are explicitly excluded in the preview. Public sector teams should plan alternative solutions and track Microsoft’s roadmap for expanded support.
• Audit and compliance: Guest accounts change your audit surface. Ensure logging and retention meet regulatory needs before scaling the feature.

Flagging unverifiable or evolving claims: Microsoft’s preview documentation and product roadmaps are living documents. Any plan assuming GA behavior should be conservative — features like FSLogix support, cross‑cloud invite support, or on‑prem Kerberos behavior could change as the service matures. Treat current preview constraints as binding until Microsoft publishes updated documentation or announces GA availability.

---

Strategic recommendations for IT leaders​

• Start small: run a focused pilot with a subset of external collaborators and monitor user experience, policy enforcement, and logging.
• Prioritize Cloud PCs for external users who need persistent storage and a predictable profile behavior.
• Rework device management strategies to be device‑centric (not user‑centric) for guest scenarios and ensure devices meet compliance before granting access.
• Map every on‑prem dependency and consider secure application publishing or modern authentication gateways if Kerberos is required today.
• Maintain a security posture playbook for guest accounts: temporary lifetimes, automated entitlement reviews, and emergency revocation playbooks.

Adopting external identities for desktops is a notable step forward for partner collaboration, but it is a change that must be managed with deliberate policy and technical controls.

---

The bigger picture and what to expect next​

This public preview aligns with Microsoft’s broader investments in Entra External ID, OpenID Connect federation, and modern authentication primitives. Microsoft’s dev blogs and documentation show a steady expansion of external identity integration across services. Expect the following evolution:

• Broader platform support (FSLogix integration or alternative persistent profile mechanisms for external identities).
• Expanded cloud availability and cross‑cloud invites, particularly if customer demand from government and sovereign clouds is strong.
• Deeper token protection and device‑bound authentication enhancements to make external identities fit enterprise security models more cleanly.

Organizations that need partner access to desktops should watch Microsoft’s release notes and roadmap updates closely and keep pilots aligned to the documented constraints.

---

Conclusion​

Microsoft’s public preview of external identity support for Azure Virtual Desktop and Windows 365 represents an important step in making virtual desktops and Cloud PCs more accessible for partners and guest users. The feature simplifies onboarding and broadens identity provider options, but is constrained by notable limitations in profile persistence, Intune policy application, cross‑cloud availability, and legacy authentication support.
For most organizations, the preview is ready for targeted pilots and controlled production use in scenarios that tolerate the current limitations — especially when combined with Windows 365 Cloud PCs for persistent needs. AVD pooled host usage with external identities requires careful acceptance of stateless profiles or the adoption of alternative persistence strategies.
Enterprises should proceed with a pragmatic plan: validate technical prerequisites (Entra join, Windows 11 24H2 + patch, SSO), favor device‑based policy controls, and select Cloud PCs where persistent, secure environments are mandatory. Track Microsoft’s documentation and service updates closely; the preview’s constraints today are the critical design considerations for any rollout.

---

Source: Petri IT Knowledgebase Azure Virtual Desktop, Windows 365 Get External Identity Support