Login with security key fails instantly when trying with Office 365 & Teams app

Question

Due to tenant conditional policy, users need to login with security key (Yubikey or QR code) but when we tried on Office 365 and Teams app the login process fails instantly and we cannot proceed.

Using Microsoft 2022 server non-persistent shared desktop

We tried removing any old files on AppData folders but the problem still remains

Any ideas what to check in terms of registry key or something else would be appreciated.

Answer 1

Hello Dimitrios,

Thank you for posting question on Microsoft Windows Forum!

Based on the issue description. Well! An instant login failure when invoking a FIDO2 security key (like a YubiKey or a passkey QR code) inside native Microsoft 365 and Teams apps might indicate an underlying authentication broker breaking or being blocked from talking to the client machine's hardware. Because native apps use the Windows Web Account Manager (WAM / Microsoft.AAD.BrokerPlugin.exe) to orchestrate modern auth, an immediate failure usually means the WebAuthn API call hit a hard wall.

If your Server 2022 golden image has been hardened via CIS Benchmarks or standard corporate baselines, WebAuthn redirection over RDP is often explicitly disabled. When blocked, any native application attempting a FIDO2 prompt will fail instantly. The suggestion here is to check is WebAuthn redirection on the session host. You can navigate to this path Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Device and Resource Redirection with the policy “Do not allow WebAuthn redirection”; to allow passkeys/security keys, it should be Disabled or Not configured.

On the other hand, the RDP client initiating the session must request the WebAuthn virtual channel. If users are connecting via standard mstsc.exe or the newer Windows App, the connection configuration needs to explicitly pass this capability. Making sure the .rdp file or your RDS/AVD deployment properties include this string redirectwebauthn:i:1 Also, Ensure the physical endpoint from which the user is connecting supports WebAuthn redirection (Windows 10/11 with up-to-date Remote Desktop clients).

One useful testing you can consider is to try a simple WebAuthn sign-in inside the remote session in an InPrivate browser window. If WebAuthn redirection is working, you should see a Windows Security prompt and be able to complete the security-key / Windows Hello step.

You can consult the following articles for further reference regarding your concerns.

• https://learn.microsoft.com/en-us/microsoft-365-apps/deploy/deploy-microsoft-365-apps-remote-desktop-services
• https://learn.microsoft.com/en-us/azure/virtual-desktop/redirection-configure-webauthn?tabs=intune&pivots=azure-virtual-desktop

Hope the above information is helpful! If it is. Free feel to hit "Accepted" for benefitting others in community having the same issue too.

Answer 2

Check three main areas: Conditional Access, Windows authentication components on the shared desktop, and security/WFP software on the image.

1. Validate Conditional Access policies for security keys
   • In Microsoft Entra admin center, go to Entra ID → Enterprise apps → Conditional Access and review the policies that enforce security key (FIDO/passkey) sign-in.
   • Confirm there are no conditions or assignments that block desktop clients such as Office/Teams on your shared desktops.
   • Temporarily disable the relevant Conditional Access policy (set Enable policy to No) and test sign-in from Office/Teams. If sign-in works when the policy is disabled, adjust the policy conditions so it allows those clients.
   • Also check the Conditional Access configuration on the specific Office/Teams enterprise apps: Entra ID → Enterprise apps → All applications → [Office/Teams app] → Conditional Access and verify no app-specific policy is blocking access.
2. Check for WAM / AAD Broker issues on the non-persistent desktop Non-persistent/shared desktops often roam or reset user profile data, which can break the Windows Web Account Manager (WAM) and AAD Broker components that Office/Teams use for modern auth.
   • Ensure profile management tools are not roaming or capturing any data under %localappdata% for the following paths and keys (these must stay local on each device):
     • %localappdata%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy
     • %localappdata%\Packages\Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy
     • %localappdata%\Packages\<any app package>\AC\TokenBroker
     • %localappdata%\Microsoft\TokenBroker
     • HKEY_CURRENT_USER\SOFTWARE\Microsoft\IdentityCRL
     • HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\AAD
     • HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WorkplaceJoin
   • If any of these are being roamed or reset between sessions, adjust the profile tool configuration so they are excluded.
3. Exclude WAM-related components from security/WFP software Security software or Windows Filtering Platform (WFP) drivers on the shared desktop can block the AAD Broker and TokenBroker processes, causing instant sign-in failures.
   • Work with the security/WFP vendor to configure exclusions for:
     • Package family names:
       • Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy
       • Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy
     • Folders:
       • %windir%\SystemApps\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy
       • %localappdata%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy
       • %windir%\SystemApps\Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy
       • %localappdata%\Packages\Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy
       • %localappdata%\Microsoft\TokenBroker
       • %localappdata%\Microsoft\OneAuth
       • %localappdata%\Microsoft\IdentityCache
     • Processes:
       • %windir%\SystemApps\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\Microsoft.AAD.BrokerPlugin.exe
       • %windir%\System32\backgroundTaskHost.exe for packages:
         • Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy
         • Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy
       • %windir%\System32\svchost.exe loading NT service TokenBroker as TokenBroker.dll
4. If the issue persists
   • Capture logs and open a support ticket from the tenant admin so Microsoft can review authentication logs and Conditional Access evaluation for the affected users and devices.

---

References:

• Problems signing in to a Microsoft application
• Can't sign in to Microsoft 365 desktop applications
• Error “Something Went Wrong [1001]” signing in to Microsoft 365 Desktop Applications