You wouldn’t serve a flat white with instant coffee granules. So why trust a single password to protect your cloud desktops? Multi‑Factor Authentication (MFA) is the second shot your security posture needs. It takes that weak, often reused password and tops it up with something the bad actors can’t easily steal, something you have or are.

Whether your users connect to Azure Virtual Desktop (AVD), Windows 365, M365 Services or third‑party SaaS apps, MFA keeps every session secure without making sign‑ins unbearable. Think of it as your bouncer at the café door checking ID before anyone grabs a seat.

What is Multi‑Factor Authentication?

Under the Essential Eight Maturity Model Level 2 (ML2), the purpose of MFA is to stop a compromise of any single factor, like a password, from leading straight to a breach.

MFA requires two or more of the following:

• Something you know: password or PIN
• Something you have: phone, passkey, or hardware token
• Something you are: fingerprint or facial recognition

At Level 2, MFA must be enforced for:

• All users (privileged and unprivileged) accessing any online services that process sensitive data
• All third‑party or SaaS platforms federated through your identity platform
• Internet‑facing remote access and VDI environments like AVD and Windows 365
• Authentication of all privileged accounts
• Any sign‑ins that must be phishing‑resistant
• MFA events logged, secured, and analysed

How it Works in Cloud VDI

Both Azure Virtual Desktop and Windows 365 authenticate through Microsoft Entra ID (Azure AD). MFA enforcement sits within Entra’s Conditional Access framework, applied consistently across Microsoft 365 and federated third‑party services.

Azure Virtual Desktop

When a user signs in through the AVD client or browser, credentials first pass through Entra ID. Conditional Access evaluates user, device, and location, and won’t issue a session token until MFA is satisfied.

Windows 365 (Cloud PC)

Identical logic applies here. The sign‑in prompt is evaluated by Entra ID before the Cloud PC session is launched.

Third‑Party and Customer‑Facing SaaS

Entra ID can federate external services (Salesforce, ServiceNow, GitHub Enterprise, etc.). Conditional Access policies extend to these apps automatically, giving one place to enforce phishing‑resistant MFA across all cloud assets.

Phishing‑Resistant Options in Entra ID

No keys? No dramas. Microsoft Entra ID supports multiple passwordless, phishing‑resistant methods that satisfy Essential Eight ML2 without the need for physical FIDO2 devices (Because days of carrying around RSA tokens is gone):

• Windows Hello for Business:
  Uses asymmetric keys secured by the device TPM. The private key never leaves the endpoint and can only be unlocked by a local PIN or biometric, making it resistant to credential theft.

• Microsoft Authenticator with Number Matching:
  Adds in‑context verification — users match numbers between login prompt and Authenticator app. This blocks replay, man‑in‑the‑middle, and push‑fatigue attacks.

• Entra ID Passkeys:
  Based on WebAuthn, users store a cryptographic credential in their device or OS passkey manager (Windows, iOS, Android). Supports cross‑device sign‑in through the same asymmetric model as FIDO2.

Use Conditional Access → Authentication Strengths to enforce these phishing‑resistant MFA types across AVD, Windows 365, and SaaS applications. Select “Phishing‑resistant MFA” to ensure only the approved methods above are accepted.

Real‑World Impact

Passwords are the weakest brew in the pot, a little social engineering and they’re gone. MFA blocks over 99 percent of credential‑based attacks and gives solid assurance even when users are entirely remote.

For AVD and Windows 365, MFA is essential because both services are directly reachable from the internet. One weak password could hand over network‑level access.

Implementation Examples

Azure Portal: Conditional Access

1. Navigate to Microsoft Entra ID > Security > Conditional Access > Policies.
2. Select + New Policy.
3. Assign to All Users (including privileged and unprivileged).
4. Target All Cloud Apps or limit to AVD, Windows 365, and key SaaS connections.
5. Under Access Controls > Grant, check Require Multi‑Factor Authentication.
6. Under Authentication Strengths, select Phishing‑resistant MFA.
7. Enable and save the policy.

Centralised Logging with Microsoft Sentinel

1. Enable Diagnostic Settings under Entra ID > Audit Logs.
2. Send both Sign‑in Logs and Audit Logs to a Log Analytics Workspace linked to Sentinel.
3. Build analytics rules for repeated MFA denials, impossible‑travel sign‑ins, and push‑fatigue.
4. Forward incidents to your SOC workflow and CISO delegate for escalation.

Gotchas & Edge Cases

• Legacy RDP or LDAP applications: Use Azure AD Application Proxy for pre‑auth protection or maintain documented exceptions with timeline to modernise.
• Service and automation accounts: Move to Managed Identities instead of user credentials.
• Customer portals: Use External ID with optional or enforced phishing‑resistant methods for customer MFA.
• Log protection: Apply RBAC to audit data and enable immutable storage in Azure Monitor.

Best Practices

• Enforce phishing‑resistant MFA using Authentication Strength policies.
• Prefer Windows Hello for Business, Authenticator Number Matching, or Passkeys — not SMS or email codes.
• Apply MFA to all connected SaaS and third‑party services federated via Entra ID.
• Centralise MFA and sign‑in logs in Microsoft Sentinel for correlation.
• Protect logs with immutable retention and restricted admin access.
• Integrate detection with Defender for Cloud Apps for extra visibility.
• Test and rehearse incident response including MFA‑related anomalies.

Learn More

• Authentication Strengths and Phishing‑Resistant MFA – Microsoft Learn
• Configure Conditional Access Policies – Microsoft Learn
• Collect Entra ID Logs in Microsoft Sentinel
• Azure Virtual Desktop Security Guide
• Windows 365 Security and Compliance
• Essential Eight from the ACSC