Skip to main content
Get a demo Try it free

That's a wrap! See all the announcements and debuts in our NerdioCon 2026 recap!

Blog

Windows 365 security guide: MFA, conditional access, SSO, and encryption

Configure Windows 365 security with MFA, Conditional Access, SSO, and encryption for regulated enterprise Cloud PCs.

Table of Contents

Your Cloud PCs are live. Users are connecting from personal laptops, hotel Wi-Fi, and branch offices across three time zones. The questions your auditor will ask are whether you can prove which controls you configured, which gaps you accepted, and which ones you did not identify.

This guide is for GRC leads, security architects, and IT directors responsible for securing Windows 365 Cloud PC environments in regulated enterprises.

Windows 365 ships secure by default, but your Cloud PC security posture is only as strong as the controls you configure on your side of Microsoft's shared-responsibility line: MFA, conditional access, SSO, and encryption.

Windows 365 security starts with Zero trust

Windows 365 is built on Zero Trust as a foundational design principle. Microsoft maps its Cloud PC security controls to three categories aligned to Zero Trust pillars:

  • securing access (identity)
  • securing the device itself (endpoint)
  • securing data (data protection)

Every Cloud PC session requires two authentication events: one to the Windows 365 service and one to the Cloud PC itself. That dual-authentication architecture is where your Conditional Access policies, MFA enforcement, and SSO configuration do their work.

Cloud PCs can be deployed with Trusted Launch, which includes options to enable virtual Trusted Platform Module (vTPM) and Secure Boot. Windows 11 gallery images add Hypervisor Code Integrity (HVCI) and Microsoft Defender Credential Guard. Microsoft provides controls for redirection settings in Windows 365 provisioning policies. Those settings cover file transfer, clipboard transfer, printer redirection, and USB redirection.

Those defaults apply only to newly provisioned and reprovisioned Cloud PCs. Existing Cloud PCs with active provisioning policies keep their current redirection settings. Organizations with provisioning policies that predate the new secure-by-default posture typically need an audit against the new baseline. The gap between "new default" and "what's running in production" creates risk.

What you manage vs. what Microsoft manages

Microsoft is responsible for the Windows 365 service infrastructure. That includes the network, storage, compute, and hypervisor layers, as well as datacenter physical security and service resiliency.

You own everything else that matters for an audit:

  • Conditional Access policies
  • MFA enforcement
  • Microsoft Intune compliance policies
  • Microsoft Defender for Endpoint integration
  • OS update rings
  • local administrator rights
  • Microsoft Purview DLP configuration

This responsibility model means your Windows 365 security posture is only as strong as the controls you configure on your side of the line. MFA configuration is one of the first and most consequential of those controls.

Configuring MFA that actually protects Cloud PC access

In Microsoft's 2025 Digital Defense Report, they state that MFA can reduce the risk of identity compromise by 99%. Effective Cloud PC MFA enforces the right cloud apps with the right authentication strength.

Cloud PC MFA depends on targeting the correct cloud app IDs

A common Windows 365 MFA configuration gap is incomplete or incorrect cloud app targeting. The Windows 365 Cloud PC app ID is 0af06dc6-e4b5-4f28-818e-e78e62d137a5. Many organizations also include Azure Virtual Desktop (9cdead84-a844-4324-93f2-b2e6bb768d07) to cover all connection paths. Using an incorrect or incomplete app ID means MFA is not enforced for Cloud PC access, regardless of what your policy says.

The selected authentication strength determines the compliance posture

Entra ID offers authentication strengths. The differences matter for compliance:

Strength level

FIDO2

Windows Hello for Business

Authenticator phone sign-in

Password + second factor

Multifactor authentication

✅

✅

✅

✅

Passwordless MFA

✅

✅

✅

❌

Phishing-resistant MFA

✅

✅

❌

❌

For some regulated environments and high-risk roles, phishing-resistant MFA is the target authentication strength. Only FIDO2 security keys, Windows Hello for Business or platform credential, and certificate-based authentication (multifactor) qualify.

Legacy per-user MFA can create issues in Entra-joined Cloud PC environments

For Entra-joined Cloud PC access, Microsoft guidance recommends using MFA through Conditional Access rather than legacy per-user MFA. If legacy per-user MFA is enabled, it should be disabled in favor of Conditional Access MFA for Entra-joined Cloud PCs, as using both can cause sign-in or connection issues. For Entra-joined Cloud PCs, Conditional Access policies are the recommended MFA approach.

Microsoft guidance indicates organizations should migrate authentication method management from legacy MFA and SSPR policies by September 2025. Organizations should migrate to the unified Authentication methods policy in the Entra admin center before that date.

Effective MFA for Cloud PCs targets the correct app IDs, enforces the right authentication strength, and uses Conditional Access instead of per-user MFA.

Once those identity controls are in place, Conditional Access decides how and when access is allowed.

Conditional access policies for Cloud PCs

Conditional Access enforces Windows 365 access decisions. For Cloud PCs, those policies need Cloud-PC-specific settings.

Three cloud apps with matched policies

Microsoft recommends targeting access policies to the Windows 365 cloud app, and in some guidance also to Azure Virtual Desktop, for Windows 365:

App

App ID

What it protects

Windows 365

0af06dc6-e4b5-4f28-818e-e78e62d137a5

Cloud PC list retrieval and management actions

Azure Virtual Desktop

9cdead84-a844-4324-93f2-b2e6bb768d07

Gateway authentication during connection

Windows Cloud Login

270efc09-cd0d-444b-a71f-39af4910ec45

Cloud PC sign-in when SSO is enabled

If you exclude any of these apps from a policy, exclude all three together. Partial exclusions create inconsistent enforcement.

The BitLocker compliance policy conflict

Cloud PCs do not support BitLocker. Applying a standard Windows compliance policy with BitLocker enforcement to Cloud PCs will flag them as non-compliant, even though they are encrypted through Azure encryption guidance. Organizations typically create separate Intune compliance policy scopes that explicitly exclude Cloud PCs from BitLocker requirements. Nerdio Manager can back up and restore these compliance policy scopes. That gives teams a recovery path after accidental deletion or misconfiguration.

This is a common compliance misconfiguration for Windows 365. Organizations with encryption-at-rest requirements under HIPAA guidance or NIST framework typically document their selected Azure encryption controls and how those controls meet their compliance requirements in their compliance assessments.

Location-based controls and IPv6

Location conditions in Entra Conditional Access rely on named locations. If your named locations only include IPv4 addresses and your users connect over IPv6 support, they will be blocked. Organizations typically work with their network team and ISPs to identify public-facing IPv6 addresses and add them to named locations.

For real-time access evaluation (CAE) enforcement, IP-based location conditions are the supported option. Country or region conditions do not support real-time enforcement.

A breaking change coming June 15, 2026

After June 15, 2026, Conditional Access policies targeting "All resources" will enforce against sign-ins requesting only OIDC scopes, even when resource exclusions are present. "All resources" policies with resource exclusions should be reviewed before that date. The upcoming change is described in this change notice.

Conditional Access works for Cloud PCs when policy coverage stays consistent across the right apps, compliance scopes account for the BitLocker gap, and named locations reflect how users actually connect.

After Conditional Access validates the session, SSO determines whether users face a second credential prompt inside the Cloud PC.

How SSO works for Windows 365 and when it's required

Users avoid a second credential prompt when SSO is enabled for a Windows 365 connection. It connects service-level authentication to the remote session login.

SSO relies on Entra ID authentication for single sign-on. When SSO is enabled, the PRT from the initial authentication carries through to the Cloud PC session. No second prompt.

SSO has specific required scenarios

Windows 365 Link devices have Entra account and Conditional Access requirements that include SSO-related configuration. 

External access to Cloud PCs has additional configuration requirements. SSO configuration is one of them.

Hybrid environments need Kerberos configuration

For Entra-joined Cloud PCs accessing on-premises resources, Entra Kerberos needs separate configuration. For hybrid-joined Cloud PCs, organizations should follow Microsoft's supported SSO configuration guidance for hybrid-joined hosts.

If your hybrid SSO uses Entra Connect Sync and Entra Kerberos, careful configuration review is warranted before migration.

SSO planning stays straightforward only in straightforward environments. If you use Windows 365 Link, support B2B guest access, or rely on hybrid Kerberos configuration, SSO becomes a prerequisite that has to align with the rest of your identity design.

Once access and session controls are in place, encryption protects the data itself.

Encryption architecture and the BitLocker gap

Windows 365 Cloud PC disks are encrypted at rest using Azure Storage server-side encryption, and encryption at host can also be enabled for Windows 365 Enterprise Cloud PCs. Both use AES-256, FIPS 140-2 compliant. The encryption covers disks, snapshots, and images automatically.

Host-based encryption closes the gap that SSE alone leaves open. Standard SSE does not encrypt temporary disks or disk caches. Host-based encryption extends coverage so that temp disks and caches are also encrypted at rest and flow encrypted to storage clusters.

Data in transit uses TLS 1.2 for connections to Azure Virtual Desktop infrastructure components, with TLS 1.3 supported for reverse connect transport. Port 3389 is disabled by default for all newly provisioned Cloud PCs.

Customer-managed keys for Enterprise

Windows 365 Enterprise supports customer keys through Microsoft Purview Customer Key. Windows 365 Business does not.

Re-encryption after a key change restarts the Cloud PC and temporarily disconnects users during the restart. Large deployments require batched execution.

Compliance implications of no BitLocker

BitLocker can be enforced on Cloud PCs, though related configuration issues may cause other errors in some environments. For compliance teams, excluding Cloud PCs from BitLocker-enforcing compliance policies, documenting Azure SSE plus host-based encryption as the alternative, and verifying that substitution is acceptable under your specific framework requirements are the key actions. The encryption is equivalent in strength (AES-256), but the mechanism differs, and your auditor needs to see the documentation.

For Windows 365, documentation is the key issue. You need to show how Azure SSE, host-based encryption, customer-managed keys where applicable, and the lack of BitLocker fit together in your control narrative.

Which of these controls you can actually deploy depends on your license stack.

Licensing determines which security features you actually have

Your available Windows 365 security controls depend on the license stack of Windows E3, Microsoft Intune, Entra ID P1, and the Windows 365 Enterprise license. That stack establishes the prerequisite licensing for core Windows 365 Enterprise security controls such as Conditional Access and SSO, along with platform security features like Secure Boot, vTPM, HVCI, and Credential Guard. Some other security capabilities used with Windows 365 Enterprise come from the wider Microsoft stack rather than from the base Windows 365 Enterprise entitlement alone.

Security capability

Base W365 Enterprise stack

+ Microsoft 365 E3

+ Entra ID P2 / Microsoft 365 E5

Conditional Access (basic)

✅

✅

✅

Risk-based Conditional Access

❌

❌

✅

Intune security baselines

✅

✅

✅

Device compliance capabilities used with Conditional Access

Depends on your wider Microsoft licensing

More complete support

✅

Defender for Endpoint

❌

❌

✅

Privileged Identity Management

❌

❌

✅

If your security architecture depends on behavioral risk signals or Defender for Endpoint integration, additional licensing such as Entra ID P2 or Microsoft 365 E5 is required.

Regardless of license tier, maintaining consistent policy enforcement across hundreds of Cloud PCs creates a management burden that scales with your deployment.

How Nerdio Manager simplifies Windows 365 security governance

Configuring these controls is one task. Keeping Intune policies, compliance scopes, app deployment, and Cloud PC settings consistent across hundreds or thousands of Cloud PCs, across business units and provisioning cycles, while preserving records of policy changes for auditors, is the operational work that expands with the environment.

Nerdio Manager for Enterprise lets admins manage Windows 365, Microsoft Intune, and Azure Virtual Desktop from one console above Entra ID, Intune admin center, and the Azure Portal. That puts Windows 365, Intune, and Azure Virtual Desktop in one administrative console instead of sending admins between separate portals. Teams using Nerdio for Windows 365 typically use it alongside Intune management rather than as a replacement for Microsoft controls. The capabilities that matter most for security governance fall into three areas.

Policy backup, restore, and faster application delivery

For Windows 365 environments specifically, Nerdio Manager can create, back up, and restore Intune policies, with version history for recovery. That gives teams a recovery path when a compliance scope is accidentally deleted or a configuration policy is overwritten, which native Intune cannot reverse on its own.

Nerdio Manager's unified application management provides centralized application deployment across Cloud PCs and other Windows devices, deploying applications to Cloud PCs in about 30 seconds, compared with native Intune delivery that can take up to 3 hours. Nerdio Manager also provides Cloud PC right-sizing insights and visibility into underused licenses. The City of Corona, a US government agency, used Nerdio Manager to centralize management of its Windows 365, Microsoft Intune, and Azure Virtual Desktop environments from one interface while supporting endpoint security operations and IT efficiency.

Hardened baselines and role-based access control

Policy management is one half of the governance picture. Image and access controls are the other.

Nerdio integrates CIS images directly into the platform, with CIS baselines that can be deployed and centrally maintained without rebuilding images from scratch. Granular RBAC with custom roles controls who can modify security configurations.

One console across Windows 365 and Azure Virtual Desktop

Most enterprise environments include both Cloud PCs and Azure Virtual Desktop session hosts, and the governance controls have to stay consistent across both.

For organizations running both Windows 365 and Azure Virtual Desktop, Nerdio Manager provides one console to manage policies, application deployment, and automations across both platforms.

Nerdio Manager can centralize how teams maintain Intune policies, application deployment, and Cloud PC settings. Your auditor also needs to know where the data lives and how tenants are isolated.

Proving your Windows 365 controls to an auditor

Windows 365 Cloud PCs run on Azure infrastructure with tenant isolation. Data residency follows the Azure region selected during provisioning. Organizations should document which Azure region their Cloud PCs are provisioned in and confirm that it meets data sovereignty requirements. Microsoft's compliance docs covers the infrastructure layer, but organizations must implement and document their own data protection controls, Conditional Access policies, and compliance configurations for their specific regulatory obligations.

The audit question is simple. Can you prove which controls you configured across MFA, Conditional Access, SSO, encryption, and data residency, and where you accepted gaps such as the BitLocker substitution?

Secure defaults are only part of the story. You also need to show what you configured, what you documented, and what is actually running in production. If that proof still depends on checking multiple admin surfaces and reconstructing policy changes by hand, teams can get a demo to see how Nerdio Manager for Enterprise works across your Windows 365 and Azure Virtual Desktop environment, or try it free in your own Azure tenant.

Frequently asked questions about Windows 365 security

Resources

Learn more about Nerdio Manager

Ready to get started?

Get a demo Try it free