From Frustration to Functionality: Optimising Conditional Access for AVD (and more!)

Introduction
In today's digital landscape, securing remote work environments is more critical than ever. As explained below, Azure Virtual Desktop (AVD) offers a robust solution for delivering virtual desktops and applications to users, but ensuring secure access is key. This is where Conditional Access comes into play.
In this blog post, we will explore the importance of configuring Conditional Access policies for AVD. We'll start by addressing a common issue where users encounter login errors when policies are not properly configured.
From there, we'll look at the best practices for setting up CA policies for AVD environments, ensuring a balance between security and user experience.
Let's dive in.
What is Azure Virtual Desktop?
AVD is essentially an Azure-hosted Remote Desktop Services (RDS) deployment. AVD is a desktop and application virtualisation service which is funnily enough, hosted on the Azure-cloud platform. Enabling organisations to deliver a secure, scalable and flexible virtual desktop experience to their users or customers. AVD is a cost-effective and accessible platform, allowing users to access from any device.
AVD simplifies the management of virtual desktops and applications, integrating seamlessly with Microsoft 365, supporting both Windows 10 and Windows 11. However, with Windows 10 reaching its end of life in October 2025; AVD deployments should now be Windows 11 based.
What is Conditional Access?
Conditional Access is a security feature in Entra ID that helps organisations manage and control access to their resources. It allows administrators to create and enforce policies based on specific conditions, such as user location, device state and the application being accessed.
By requiring additional verification steps like multi-factor authentication (MFA) or restricting access from certain locations; Conditional Access ensures that only authorised users can access sensitive data and applications, increasing the security posture of your organisation, or your customers.
The Login Dilemma
Picture this: you've deployed your host pool, workspace, joined your session hosts to Entra ID, and the customer Go Live is scheduled.
Everything is in place and ready for the customer to get into their new AVD environment.
It's time - users are starting to log in.
Except, when they enter their credentials, instead of logging into the session hosts, they're repeatedly prompted for their credentials. Despite the username and password being correct, they still can't access the new session hosts.
Support calls come in, project managers are chasing for updates - I needn't go on!
The MFA Challenge
A common issue with Entra ID joined AVD session hosts is related to multi-factor authentication (MFA). Most customers and businesses nowadays use Conditional Access to enhance their security posture.
When users connect to Entra ID joined session hosts and MFA is enabled and required, the authentication process can repeatedly fail. This usually happens because Azure Windows VM sign-ins are considered non-interactive logins, which don't support per-user enabled or enforced MFA. As a result, the authentication process can't complete the MFA step, leading to login failures.
The Login Dilemma: Solved
Ok - you're pushed for time, customer downtime, internal pressures, cut to the chase - on it. Here's what you need, even if you ignore the rest (I wouldn't recommend it).
Exclude Azure Windows VM Sign-In from your CA policies that require MFA.
And now you're probably thinking this is a security risk? I tend to agree - however, this has now been finally documented by Microsoft. Reference link at the bottom!

Balancing Security and Accessibility
You probably came to this blog for two reasons. Users can't access servers, people aren't happy, you need a fix, yesterday! You're expecting me to talk about how to secure your AVD environments with CA Policies. I don't see on that list, how to weaken the security of your customers' AVD environments.
However, there is a caveat to excluding the VM Sign-In from the CA Policies. Users will still need to pass MFA when subscribing to the workspace. Essentially, when a user opens their Remote Desktop application, they will complete MFA to subscribe to the workspace, but they won't be prompted for MFA on the "VM Login."
I've attached some images of the workflow to show this in practice!
Conditional Access - Best Practices


Essential Conditional Access Policies
As this is an AVD-focused post, I won't go into too much detail on how to configure the following policies, but below are the essential Conditional Access policies that should be implemented for any business.
- Enforce Multi-Factor Authentication (MFA): Requiring MFA for all users accessing AVD and cloud applications adds an extra layer of security. This can be configured for different clients, such as web, mobile, and desktop.
- Block Legacy Authentication: Legacy authentication methods (such as POP, IMAP and SMTP) are more vulnerable to attacks. Blocking these protocols prevents attackers from exploiting less secure login methods.
- Compliant Devices: Ensure that only devices meeting your organisations compliance policies or those joined to a domain and/or Entra ID can access your resources.
- Locations: Configure policies to block or limit access from risky locations or allow access only from trusted IP ranges or countries.
Implementing these policies ensures that your customers have a comprehensive approach to securing the organisation's resources, whether using Azure Virtual Desktop or other Microsoft cloud services.
There are other policies which some organisations may consider essential - but listing them all isn't efficient and won't add any value.
What are your thoughts? Get in touch! I'm keen to hear what policies your business and/or customers are using!