Introduction

Back in April 2025, I wrote about my experience connecting to Windows 365 and Azure Virtual Desktop from macOS.

For the most part, the experience was very similar to connecting from a Windows device. I could open the Windows App, authenticate using a passkey and connect to my Windows 365 Cloud PC or Azure Virtual Desktop session.

However, once inside the remote Windows session, things became a little more complicated.

If I needed to authenticate again - perhaps to sign into another account, use an InPrivate browser session or activate a privileged role through Microsoft Entra Privileged Identity Management - I couldn’t use my locally available passkeys or FIDO2 security keys properly.

That was a significant limitation for anyone trying to implement phishing-resistant authentication consistently, particularly for privileged access.

Microsoft has now started addressing that limitation.

WebAuthn redirection is coming to macOS

Microsoft has introduced in-session WebAuthn redirection in preview for the Windows App on macOS.

This enables authentication requests generated inside a Windows 365 or Azure Virtual Desktop session to be redirected to the local Mac.

Using the preview capability, users can complete Microsoft Entra WebAuthn authentication challenges with:

  • A passkey stored on the Mac
  • A physical FIDO2 security key connected to the Mac
  • A passkey stored on another device using cross-device authentication and a QR code

This is the capability that was missing when I originally tested the Windows App on macOS.

At the time, I could use a passkey to authenticate to the Windows App and establish the remote connection. However, I couldn’t use that passkey when another authentication challenge occurred inside the remote session.

These are two separate authentication scenarios:

  1. Authenticating to establish the Windows 365 or Azure Virtual Desktop connection
  2. Authenticating to an application or service from inside the remote Windows session

The first scenario already worked. It was the second one that caused the problem.

WebAuthn redirection is intended to close that gap.

What is WebAuthn redirection?

WebAuthn is a standard developed by the World Wide Web Consortium and the FIDO Alliance. It allows applications and websites to authenticate users using public-key cryptography rather than relying on passwords.

It underpins authentication methods such as:

  • Device-bound passkeys
  • Synced passkeys
  • Physical FIDO2 security keys
  • Windows Hello for Business
  • Cross-device passkey authentication

When a WebAuthn authentication request occurs inside a remote Windows session, the session might not have direct access to the authenticator available on the physical device.

WebAuthn redirection sends that request through the remote connection to the local device. The user can then complete the authentication using an authenticator available locally.

For someone accessing a Cloud PC from a Mac, that could mean responding to an authentication challenge using a passkey stored on the Mac rather than requiring the passkey to exist inside the Cloud PC.

Why does this matter?

Once connected to a Windows 365 Cloud PC or Azure Virtual Desktop session, users will frequently benefit from Single Sign-On. However, there are still situations where another authentication challenge can occur.

For example:

  • Signing into an InPrivate browser window
  • Signing into a different Microsoft Entra account
  • Accessing an application protected by Conditional Access
  • Satisfying a Conditional Access authentication context
  • Activating a privileged role through PIM
  • Performing a sensitive or privileged administrative operation

If the organisation requires phishing-resistant authentication, the user must be able to satisfy that requirement from inside the remote session.

Without WebAuthn redirection, someone connecting from a Mac might be unable to use their passkey or physical FIDO2 security key.

Organisations could then be tempted to introduce exceptions, permit weaker authentication methods or create separate Conditional Access policies for these users.

Those approaches might get around the immediate problem, but they don’t solve it.

Redirecting the WebAuthn request to the local device provides a much cleaner experience. It allows the user to continue using the phishing-resistant authentication method already available on their Mac.

This limitation changed which device I used

For me, this wasn’t merely a technical limitation that appeared during testing.

It was one of the reasons I moved back from using my Mac as my primary device to using a Microsoft Surface.

I could connect to Windows 365 and Azure Virtual Desktop from the Mac without a problem. However, once inside the remote session, I couldn’t reliably use WebAuthn to satisfy another phishing-resistant authentication challenge.

That mattered because I regularly work with privileged accounts, PIM activation, authentication contexts and environments where passkeys or physical FIDO2 security keys are required.

The Surface provided the more complete end-to-end experience. I could establish the remote session and continue using phishing-resistant authentication from inside it without introducing exceptions or alternative authentication methods.

If this new macOS capability reaches general availability and works reliably, it removes one of the biggest practical reasons I had for choosing Windows over macOS as the client device for Windows 365 and Azure Virtual Desktop.

That could be a genuine game changer for people who prefer working from a Mac but still require a secure, fully passwordless Windows environment.

This is particularly important for privileged access

This change is especially relevant when Windows 365 or Azure Virtual Desktop is used to provide a virtual Privileged Access Workstation.

A virtual PAW needs to support the organisation’s strongest authentication requirements.

It makes little sense to secure an administrative environment with phishing-resistant authentication and then discover that an administrator connecting from macOS cannot satisfy an authentication context or activate a PIM role from inside the session.

Previously, this difference made Windows the more complete client platform for these scenarios.

The new macOS preview doesn’t immediately give us a production-ready answer, but it shows that Microsoft is addressing the gap.

That is a significant step forward.

What does the preview support?

At the time of writing, WebAuthn redirection on macOS requires version 11.4.0 (3066) of the Windows App Beta from Microsoft’s designated preview channel.

The preview supports authentication using:

  • Passkeys stored locally on the Mac
  • Physical security keys connected to the Mac
  • Cross-device authentication using a QR code

Microsoft currently states that only passkey sign-ins to Microsoft Entra ID are supported, using the following endpoints:

  • login.microsoftonline.com
  • login.microsoftonline.us

This means the preview should support the Microsoft Entra authentication scenarios that are most relevant to Windows 365, Azure Virtual Desktop, Microsoft 365 and PIM.

It should not yet be treated as universal WebAuthn redirection for every application, identity provider or relying party.

Enabling WebAuthn redirection

Microsoft provides different settings depending on whether the user connects to a complete desktop or an individual RemoteApp.

For a desktop connection, WebAuthn redirection can be enabled through the connection’s Device & Audio settings.

For RemoteApps, it can be enabled through the Windows App’s general Settings menu.

The remote Windows environment must also permit WebAuthn redirection.

For Azure Virtual Desktop, administrators can control this using the host pool’s RDP properties together with settings applied to the session hosts through Microsoft Intune or Group Policy.

The corresponding RDP property is:

redirectwebauthn:i:1

The effective behaviour depends on the complete configuration path. Enabling redirection in the client won’t override a policy that blocks it on the session host.

As with other forms of device redirection, the most restrictive setting normally determines the resulting behaviour.

It is still a preview

There is an important word throughout all of this:

Preview.

This capability is not currently available in the generally available version of the Windows App for macOS.

Preview capabilities can:

  • Contain known or undiscovered limitations
  • Change before general availability
  • Require a separate beta client
  • Behave differently between client versions
  • Lack the same support commitments as generally available functionality

We also don’t yet know when this capability will become generally available.

It might progress to GA relatively quickly, or it might remain in preview for some time. Microsoft hasn’t provided a committed general-availability date.

For now, this is something to test and evaluate rather than something I would use as the only supported route into a critical privileged environment.

For production designs, I would continue documenting the current limitation and ensure there is a supported alternative until the feature becomes generally available and has been properly validated.

What about browser connections?

In my original testing, I also tried connecting to my Cloud PC through the browser.

The WebAuthn challenge still didn’t redirect correctly, which initially made me question whether the limitation was caused by macOS rather than the Windows App.

The distinction is clearer now.

The native Windows App and the browser-based remote client are separate clients with different redirection capabilities.

The fact that the browser also failed didn’t mean macOS itself lacked WebAuthn support. It meant neither remote client could redirect the in-session WebAuthn request in that scenario.

This new preview specifically adds the capability to the Windows App Beta on macOS.

It should not be assumed that connecting through a browser will provide the same experience.

And then there is the name…

While researching this again, I was reminded of another challenge that hasn’t been fixed:

Microsoft called the product the Windows App.

Not “Microsoft Windows App.”

Not “Windows Remote App.”

Not anything distinctive or remotely searchable.

Just… Windows App.

Try searching for:

Windows App macOS WebAuthn

Depending on the search engine, you’ll get results about WebAuthn support in Windows applications, running Windows apps on a Mac, developing an app for Windows or almost anything else containing the words “Windows” and “app.”

Finding information about the Windows App amongst information about Windows apps can be surprisingly difficult.

What was Microsoft thinking when it named this? 😂

At least the product is becoming more capable, even if searching for information about it continues to be an authentication challenge of its own.

A limitation is beginning to disappear

The lack of in-session WebAuthn redirection was one of the most important differences I found between using Windows and macOS to access Windows 365 and Azure Virtual Desktop.

It was significant enough to influence which physical device I used as my main computer.

Microsoft’s new preview directly addresses that limitation.

It potentially allows Mac users to authenticate inside a remote Windows session using:

  • Locally stored passkeys
  • Physical FIDO2 security keys
  • Cross-device passkeys presented through a QR code

That creates a much more consistent phishing-resistant authentication experience and makes macOS a more practical client for secure Windows 365, Azure Virtual Desktop and virtual PAW scenarios.

It isn’t generally available yet, and we don’t know when it will be.

But it is unquestionably a move in the right direction.

If Microsoft takes this through to general availability and it proves reliable across the common authentication scenarios, it could be a game changer for organisations and users who want the flexibility of macOS without compromising their passwordless and privileged-access strategy.

I’ll be testing the preview to see whether the real-world experience now matches the promise - and whether the authentication scenarios that failed in my original post finally work as expected.

Key Takeaways

  • In-session WebAuthn redirection is now available in preview in the Windows App Beta for macOS.
  • It can redirect Microsoft Entra passkey challenges to passkeys stored on the Mac, connected FIDO2 security keys or another device using a QR code.
  • This addresses a major limitation for Windows 365, Azure Virtual Desktop and virtual PAW scenarios accessed from macOS.
  • The capability is still in preview, requires a specific beta client and does not yet have a committed general-availability date.
  • Browser-based connections should not be assumed to offer the same WebAuthn redirection capability.

References