I spent the better part of a week figuring out why FIDO2 sign-in fails on hybrid joined devices in my environment while the same YubiKey worked fine everywhere else. The root cause — an unverified UPN suffix that Entra Connect silently rewrites — is documented by Microsoft, just never anywhere near the FIDO2 documentation. This is the troubleshooting story, the fix, and a second discovery about Staged Rollout that turned out to matter even more for getting the whole thing into production on a federated domain.

Key Takeaways

• If Windows FIDO2 sign-in fails with AADSTS50034 on a hybrid joined device, check UPN alignment between Active Directory and Entra ID before touching the Kerberos plumbing.
• Entra Connect rewrites the UPN of any user whose on-premises UPN suffix is not a verified domain in the tenant to mailNickName@tenant.onmicrosoft.com, which breaks the user-to-cloud mapping hybrid join depends on.
• dsregcmd /status is the single most valuable diagnostic here: IsUserAzureAD and AzureAdPrt tell you whether the device could map the logged-on user to an Entra identity at all.
• Staged Rollout lets pilot users on a federated domain authenticate directly against Entra ID, per security group, without converting the domain to managed.
• Staged users bypass the external identity provider and its MFA policies — cover the pilot group with a Conditional Access policy requiring phishing-resistant authentication before adding anyone.

Environment

• On-premises Active Directory (corp.contoso.com), users synced to Entra ID via Microsoft Entra Connect.
• Windows clients that are Microsoft Entra hybrid joined.
• fabrikam.com verified in the tenant and federated to an external identity provider; most AD users carry fabrikam.com UPNs.
• contoso.local as a second UPN suffix that exists only in AD and is not verified in the tenant — this detail is the entire post.
• Hardware FIDO2 security keys (YubiKeys), the Microsoft Entra Kerberos server object for cloud Kerberos trust, and FIDO2 sign-in enabled via GPO.

The Problem

The goal was passwordless Windows sign-in with YubiKeys. The complication was federation: FIDO2 sign-in to Windows authenticates directly against Entra ID, but fabrikam.com routes authentication to an external identity provider that has never heard of WebAuthn. So the plan for the test phase was to put the FIDO2 users on a different UPN suffix — contoso.local, which already existed in AD — keeping their sign-ins away from the federation endpoint. That decision is where the trouble started.

The plumbing went in by the book. I created the Microsoft Entra Kerberos server object per the official passwordless security key guide — the same cloud Kerberos trust machinery I poked at in my post on FIDO2 key writeback to AD — enabled the FIDO2 credential provider via GPO, and registered a YubiKey for a test user. The key showed up correctly under the user's Authentication methods in Entra ID.

Windows sign-in failed anyway. The logon screen reported that the credentials could not be verified, and Event Viewer logged it as a wrong username or password. Not much to go on, so I worked through the usual suspects, all of which turned out to be fine:

• The RODC-style allow/deny lists on the AzureADKerberos object: the user was in msDS-RevealOnDemandGroup and not in msDS-NeverRevealGroup. Side note: privileged accounts such as Domain Admins are blocked by the Password Replication Policy by default and cannot use cloud Kerberos trust by design.
• The Kerberos server key versions: Get-AzureADKerberosServer showed KeyVersion and CloudKeyVersion in agreement.
• The synced identity attributes onPremisesSamAccountName, onPremisesDomainName, and onPremisesSecurityIdentifier were all present and correct on the Entra user.
• Domain controller patch level and AES256 Kerberos encryption types were in order.

Everything checked out, and sign-in still failed with the same useless error.

The Solution — Fixing FIDO2 Sign-In on Hybrid Joined Devices

Step 1 — Get the real error out of dsregcmd /status

The breakthrough came from dsregcmd /status, run in the context of the affected user after a password logon. The output contained what the logon screen would not say:

+----------------------------------------------------------------------+
| User State                                                           |
+----------------------------------------------------------------------+

                    NgcSet : NO
           WorkplaceJoined : NO
             WamDefaultSet : NO
             IsUserAzureAD : NO

+----------------------------------------------------------------------+
| SSO State                                                            |
+----------------------------------------------------------------------+

                AzureAdPrt : NO

Acquire PRT Diagnostics
                    Status : 0xc0000072
              Server error : invalid_grant
  Server error description : AADSTS50034: The user account does not
                             exist in the directory ...

IsUserAzureAD: NO, no Primary Refresh Token, and AADSTS50034: "The user account does not exist in the directory". That reframed the whole problem. The FIDO2 ceremony was never failing — Entra ID could not resolve the logged-on user to any identity in the tenant in the first place, and everything downstream of that was irrelevant.

Step 2 — The root cause: an unverified UPN suffix

The user very much existed in the directory — just not under the name the device was asking for. The chain looks like this:

1. contoso.local was never added and verified as a custom domain in the Entra tenant. It only existed as a UPN suffix in AD.
2. Entra Connect has a documented rule for exactly this case: if the on-premises UPN suffix is not a verified domain in the tenant, the synced user's Entra UPN is rewritten to mailNickName@tenant.onmicrosoft.com.
3. So jdoe@contoso.local in AD became jdoe@contoso.onmicrosoft.com in Entra ID. The on-premises session UPN and the Entra UPN no longer matched.
4. On a hybrid joined device, Windows maps the logged-on AD user to an Entra identity via the UPN. With the mismatch, that mapping fails — which is exactly what IsUserAzureAD: NO means — and no Azure AD PRT is issued.
5. Without the user-to-cloud mapping and PRT, the FIDO2 sign-in flow has no valid Entra identity to anchor to, and you get AADSTS50034.

Here is the honesty note, because it is the reason this took a week instead of an hour. Microsoft documents the UPN rewrite rule, and the hybrid join planning guide states that hybrid join has only "limited support" when on-premises and Entra UPNs differ. But no official document connects either fact to FIDO2 sign-in failures end-to-end. The failure mode lives in the gap between two documentation silos: the passwordless docs assume a healthy hybrid identity baseline, and the hybrid join doc explains UPN requirements without ever mentioning FIDO2. If your search terms come from the error you are seeing, you land in the wrong silo every time.

Step 3 — Add and verify a matching UPN suffix

The fix is unglamorous once you know what is broken:

1. Add a new UPN suffix in AD: Active Directory Domains and Trusts → right-click the root node → Properties → UPN Suffixes tab → add contoso.com.
2. Add and verify the same domain in Entra ID under Custom domain names, which means proving ownership with a DNS TXT record — so the suffix has to be a domain you actually own, unlike contoso.local.
3. Switch the affected users' UPN suffix in AD to the new domain.
4. Let Entra Connect sync. The Entra UPN now follows the AD UPN instead of being rewritten.

For more than a handful of users, the suffix change is one pipeline:

Get-ADUser -Filter "UserPrincipalName -like '*@contoso.local'" `
    -SearchBase "OU=FIDO2 Pilot,DC=corp,DC=contoso,DC=com" |
    ForEach-Object {
        $newUpn = ($_.UserPrincipalName -split '@')[0] + '@contoso.com'
        Set-ADUser -Identity $_ -UserPrincipalName $newUpn
    }

After the next sync cycle, dsregcmd /status showed IsUserAzureAD: YES and a PRT, and FIDO2 sign-in worked immediately. One caveat: if users registered their passkeys while their Entra identity was still the onmicrosoft.com one, check the key at mysignins.microsoft.com after the change — re-registering may be necessary.

Step 4 — Staged Rollout: piloting FIDO2 on a federated domain

That fixed the test setup, but the production problem was still standing: the real users are on fabrikam.com, which is federated, and FIDO2 direct sign-in to Entra ID requires managed authentication. Converting a federated domain to managed is per-domain and all-or-nothing — a big-bang cutover for every user at once. Or so I thought, until I found Staged Rollout, a built-in Entra feature that is remarkably under-advertised for what it does.

The key insight is where the federation decision actually happens. Authentication requests for a federated domain do not go to the identity provider directly — they land at login.microsoftonline.com first, where Home Realm Discovery decides, per sign-in, whether to redirect to the federation endpoint. Staged Rollout hooks into exactly that decision: if the user is a member of a staged rollout group, Entra ID skips the redirect and authenticates the user in the cloud via password hash sync or pass-through authentication. Everyone else on the same domain keeps federating. Same domain, per-user decision, federation configuration untouched, fully reversible. For FIDO2 it is elegant — the WebAuthn assertion goes straight to Entra ID and the external IdP is never contacted.

Configuration lives in the Entra admin center under Identity → Hybrid management → Microsoft Entra Connect → Connect Sync → Staged rollout: enable Password Hash Sync, then add the pilot security group under Manage groups. The constraints from the official doc that actually bite: PHS or PTA must already be enabled in Entra Connect; use cloud security groups to avoid sync latency; a maximum of ten groups per feature; no nested or dynamic groups; the initial group add is limited to 200 users; applications sending a domain_hint parameter still federate even for staged users; applications pointed directly at the external IdP bypass Entra entirely, so audit for those; and legacy authentication such as POP3 and SMTP is not supported. Staged Rollout is also explicitly a migration bridge, not a permanent state — the final domain cutover to managed still has to happen eventually.

Step 5 — Put Conditional Access in front before staging anyone

One warning deserves its own step, because the official doc states it less loudly than it should. Staged users skip the external IdP — and with it every MFA and security policy enforced there. Stage a group and do nothing else, and those users briefly have password-only cloud sign-in: a security regression, not an upgrade. Before adding anyone, make sure an Entra Conditional Access policy covers the pilot group, ideally requiring phishing-resistant authentication strength — the Conditional Access baseline I wrote up earlier covers the mechanics. That policy conveniently doubles as the FIDO2 enforcement mechanism, and it closes the window in which a staged account is a soft target for password spray.

The resulting rollout sequence:

1. Validate the FIDO2 and Kerberos plumbing with test users on a verified UPN suffix.
2. Create the Staged Rollout group with real fabrikam.com pilot users, covered by a Conditional Access policy requiring phishing-resistant authentication.
3. Expand the pilot group by group.
4. Convert the domain to managed once confident, and retire Staged Rollout.

Frequently Asked Questions

What does AADSTS50034 mean during FIDO2 sign-in on a hybrid joined device?

It means Entra ID could not resolve the signing-in user to any identity in the tenant — usually because the on-premises UPN and the Entra UPN do not match. Check UPN alignment and dsregcmd /status before troubleshooting the FIDO2 or Kerberos configuration.

Why does Entra Connect change my users' UPN suffix to onmicrosoft.com?

Because the on-premises UPN suffix is not a verified custom domain in the tenant. Entra Connect cannot sync a UPN under a domain the tenant does not own, so it substitutes mailNickName@tenant.onmicrosoft.com. Verifying the domain and re-syncing fixes it.

Can I use FIDO2 security keys with a federated domain?

Not through the federation path itself — FIDO2 direct sign-in requires managed authentication. Staged Rollout lets members of a designated group authenticate in the cloud per sign-in, which is enough to pilot FIDO2 without converting the domain.

Do users need to re-register their passkeys after a UPN change?

Sometimes. If the key was registered while the Entra UPN was still the rewritten onmicrosoft.com identity, verify it at mysignins.microsoft.com after the change and re-register if sign-in prompts for it.

Does FIDO2 Windows sign-in work offline?

Only after a successful online sign-in on that device — a security key cannot sign in or unlock offline otherwise, and hybrid joined devices additionally need domain controller line of sight for the partial TGT exchange. Plan for both in VPN and remote scenarios.

Conclusion

The fix was four steps and a sync cycle. Finding it took a week, because every individual fact along the way is documented somewhere and the failure they produce together is documented nowhere. AADSTS50034 during Windows FIDO2 sign-in on a hybrid joined device means UPN misalignment until proven otherwise — check that before the Kerberos plumbing, and make a verified UPN suffix for every suffix in use a pre-flight requirement for any FIDO2 hybrid rollout.

The Staged Rollout discovery is the part worth taking away. The federation redirect is a per-sign-in Home Realm Discovery decision inside Entra ID, not network routing — and once you see it that way, the all-or-nothing domain conversion stops being the only path. You can pilot FIDO2 group by group on a federated domain, with Conditional Access holding the line, and convert the domain when the pilot has earned it.

The broader lesson is about documentation trust. Cross-feature interactions — federation plus UPN suffixes plus hybrid join plus FIDO2 — are often documented nowhere as a whole, and each feature's docs quietly assume the others are healthy. dsregcmd /status does not assume anything, which is why it found the problem and the documentation did not.

Related Posts

• FIDO2 Key Writeback to AD — What msDS-KeyCredentialLink Actually Does — what cloud Kerberos trust actually relies on once the sign-in in this post starts working.
• Essential Conditional Access Policies for Microsoft 365 — the policy layer that has to cover staged rollout users before they skip the external IdP.
• Entra ID Password Spray Detection with Sign-In Logs — the attack staged users are briefly exposed to if Conditional Access is not in place first.

Editorial note: posts on this blog are drafted with AI assistance and then reviewed, edited, and tested against a real environment before publishing. Commands, output, and screenshots come from systems I actually ran the work on.