Securing Azure Virtual Desktop with Entra ID and Passwordless MFA

The Problem with Passwords in VDI Environments

Traditional Virtual Desktop Infrastructure relies on Active Directory and password-based authentication. In a cloud-first world, that model has three critical failure points: password spray attacks, stale credentials in hybrid sync, and no conditional access at the session level.

When we deployed Azure Virtual Desktop for a 200-seat enterprise client, passwordless authentication wasn't optional — it was a compliance requirement under their cyber insurance policy.

Entra ID vs. Active Directory: The Architecture Decision

Azure Virtual Desktop supports two identity models:Entra ID-joined (cloud-native) and Hybrid Entra ID-joined (synced from on-premises AD). The right choice depends on your existing identity footprint.

Entra ID-Joined (Pure Cloud)

Best for: greenfield deployments, remote-first orgs, no on-premises DC.

Key configuration: the session hosts must be joined to Entra ID, not a local domain. This means your Azure Files share for FSLogix profiles needs Kerberos authentication via Entra ID — a step that's easy to miss.

Hybrid Entra ID-Joined

Best for: organisations with existing AD DS, line-of-business apps requiring Kerberos, or complex GPO requirements.

We went hybrid because the client had 15 years of Group Policy Objects managing software deployments that were not worth rewriting.

Configuring MFA-Enforced Authentication

Step 1: Conditional Access Policy

Create a policy targeting the Windows Virtual Desktop cloud app:

The application ID

is the Windows Virtual Desktop service principal. Do not confuse it with the Azure Virtual Desktop ARM resource. Both need to be targeted for full coverage.

Step 2: Passwordless Credential Options

We rolled out FIDO2 security keys (YubiKey 5) for privileged users and Microsoft Authenticator passkeys for standard users.

Entra ID configuration:

Authentication Methods Policy → Enable FIDO2 Security Keys + Authenticator passkeys
Named Locations — restrict AVD access to corporate IPs for non-compliant devices
Sign-in risk policy → Block High, require MFA on Medium

Step 3: FSLogix + Azure Files with Entra Kerberos

This is the configuration step that most guides skip. FSLogix stores roaming user profiles on Azure Files via SMB. For Entra ID-joined hosts, you need Kerberos tickets issued by Entra ID, not an on-prem DC.

The Nuances Nobody Tells You

Single Sign-On requires the AVD feed to be enrolled via Intune or a compliant device. If a user's personal device isn't Intune-managed, they'll get a second authentication prompt when launching a session app — even with SSO configured.

Conditional Access re-evaluation at session level is enabled via the

setting. We set it to 4 hours for privileged roles and 8 hours for standard users. Without this, a stolen session token is valid until the session terminates.

Break-glass accounts must be excluded from passwordless policies. We maintain two emergency accounts with long passwords, hardware TOTP, and Entra ID Privileged Identity Management activation — and they've never been used outside of quarterly DR drills.

Security Outcomes

Post-deployment security metrics (90-day window):

Phishing-related credential compromise attempts: 0 (down from 3 in prior quarter)
Password reset tickets: down 87% (from 42/month to 5/month)
MFA fatigue attack surface: eliminated — no push notifications, only presence-based FIDO2
Conditional Access policy coverage: 100% of AVD app access