Solving the Endless MFA Loop in Azure Virtual Desktop — What Really Went Wrong

I recently ran into a frustrating issue while working in a domain-joined Azure Virtual Desktop (AVD) environment. Everything appeared to be configured correctly — Conditional Access policies were in place, token folders were cleaned up, and the BrokerPlugin workaround had already been implemented.

Yet, despite all of this, users were still getting stuck in an endless Microsoft Teams and Outlook MFA loop. No matter how many times you authenticated, the apps would immediately prompt again or silently fail to sign in. This wasn’t just annoying — it completely broke the user experience.

So, digging started.

The Clues: Event Viewer Never Lies

My first step was to head straight into Event Viewer on the affected AVD session host. Here’s what stood out:

• Event ID 1098 from the AAD log with the message:

• Error: 0x80090034 Encryption failed.

• Log: 0xcaa5008a Failed to save data to cache.

This immediately raised a flag — the token broker couldn’t store or persist the token. That means even after successful MFA, it had nowhere to save the result. So naturally, Outlook and Teams would never trust the session and just keep prompting.

I also spotted references to TPM-related messages like:

0x80090034 The Trusted Platform Module has malfunctioned.

But this wasn’t a TPM problem per se. It was deeper than that — tied to Windows’ Data Protection API (DPAPI).

Understanding the Root Cause

In domain-joined Windows environments, DPAPI by default tries to back up the user’s encryption keys to a writable domain controller. If no DC is available — a common situation in AVD during startup or in isolated regions — DPAPI won’t store the key at all.

And if it can’t store the key? It can’t encrypt or cache authentication tokens. That’s when you start seeing those encryption errors and the dreaded MFA loop in Teams, Outlook, and other Microsoft 365 apps.

The Fix That Worked (And It’s Beautifully Simple)

After some research and validation through Microsoft’s community forums and internal testing, I applied the following registry change to the affected session host:

New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Cryptography\Protect\Providers\df9d8cd0-1501-11d1-8c7a-00c04fc297eb" `-Name ProtectionPolicy -PropertyType DWord -Value 1 -Force

This key tells Windows:

“If you can’t back up DPAPI to a domain controller, it’s okay — just store the key locally.”

That’s it.

After applying the change and restarting the session host, we tested again — no more MFA loop. Teams signed in. Outlook activated without issue. Tokens were finally being stored as expected.

Related Microsoft Documentation

For those who want to dive deeper into how DPAPI behaves in domain-joined environments and why this registry-based workaround is both valid and supported, here are two key references from Microsoft:

• DPAPI MasterKey Backup Failures When RWDC Is Unavailable
  Explains how DPAPI backup operations depend on access to a writable domain controller and what happens when that access is unavailable. This scenario directly aligns with what we observed in our AVD setup.
• CNG DPAPI Backup Keys on AD Domain Controllers
  Provides technical detail on how backup keys are generated and used in Active Directory environments to support DPAPI key recovery.

These articles support the root cause and resolution outlined in this post, and are helpful if you’re implementing a similar fix across multiple environments.

Remediation Script

To simplify the fix, I’ve created a quick PowerShell script that applies the required registry change to resolve the encryption failure issue causing the MFA loop in Azure Virtual Desktop.

The script sets the necessary ProtectionPolicy key and includes logging, making it easy to deploy across multiple session hosts.

You can find the script here:
🔗 View on GitHub

Feel free to clone, modify, or integrate it into your existing deployment or remediation workflows.

Final Thoughts

This issue wasn’t caused by a misconfigured Conditional Access policy or a broken AAD token folder. It came down to how Windows handles secure token storage in domain-joined environments — and what happens when that process fails silently in the background.

By understanding how DPAPI behaves and applying the right registry key, we were able to resolve the MFA loop completely.

If you’re running Azure Virtual Desktop in a domain-joined setup and seeing repeated MFA prompts in Teams, Outlook, or other Microsoft 365 apps, this fix is worth implementing.

Problem identified. Root cause confirmed. Issue resolved.

— Shaun Hardneck
www.thatlazyadmin.com