Windows Hello for Business Provisioning Failure Preventing RDP Logon

Complete UserA’s Windows Hello for Business provisioning from a local console session on the target Windows 11 device; Events 358/359 show that post-logon provisioning is being invoked before the desktop appears, while the remote-session eligibility check is failing.

What the events indicate

Windows Hello for Business (WHfB) provisioning starts after the user profile loads but before the desktop becomes available. It proceeds only after its prerequisite checks pass.^1^

Therefore:

• Event 358 confirms UserA is in the post-logon provisioning path.
• Event 359, with WinStationIsSessionRemoteable, indicates failure while evaluating whether that RDP session can support the operation.
• This can interrupt completion of the initial sign-in because provisioning occurs before desktop access.
• The successful Entra sign-in proves primary authentication succeeded, but does not prove that local WHfB key creation and registration succeeded.

Normal WHfB enrollment/PIN creation and WHfB authentication to an RDP destination are separate operations. Microsoft’s supported WHfB RDP sign-in model uses an authentication certificate deployed into the source device’s WHfB container and redirected through RDP’s smart-card capability; it does not make an RDP session a general-purpose WHfB enrollment session.^2^

Recommended remediation

1. Sign in to the target device locally as UserA, using the Microsoft Entra password or another available credential.
2. Allow the WHfB prompt to appear and complete MFA and PIN creation locally.
3. After reaching the desktop, open a non-elevated Command Prompt as UserA and run:

      dsregcmd /status
   

4. Check these user-context values:
   • NgcSet : YES — a Hello key exists for UserA on this device.
   • WamDefaultSet : YES — a default Web Account Manager account exists.
   • WamDefaultAuthority : organizations
   • AzureAdPrt : YES in the SSO section.
   dsregcmd /status must run in the affected user’s context; running it elevated can produce misleading WAM results.^3^
5. Sign out, then retry RDP. The expected result is that Windows no longer launches initial WHfB provisioning during the remote logon.

The Hello enrollment on UserA’s source device does not provision Hello on the target device: a WHfB PIN and its key material are device-specific.^4^

Supported single-user reset

If local-console provisioning still returns 0x80090010, reset UserA’s WHfB container on the target device, under UserA’s context:

1. First check Settings → Accounts → Passkeys.
2. Ensure UserA has an alternative sign-in method and copies or registers elsewhere any passkeys that are still required.
3. Open Command Prompt as UserA and run:

      certutil.exe -DeleteHelloContainer
   

4. Sign out; deletion completes during sign-out.
5. Sign in locally again and provision WHfB from scratch.

This is the supported container-reset method. It removes that user’s locally stored WHfB credentials and, on current Windows 11 versions, also removes WebAuthn/FIDO credentials and passkeys stored in the same container.^5^ Deleting the profile or recreating Hello on the source computer does not substitute for deleting UserA’s container on the target computer.

Microsoft maps 0x80090010 to NTE_PERM and provides no code-specific mitigation beyond escalation when standard remediation does not resolve it.^6^

Why only UserA can be affected

User-specific behavior can result from:

• A missing, incomplete, or inaccessible local WHfB container.
• A user-context WAM or Primary Refresh Token inconsistency.
• A user-scoped WHfB policy assignment.
• UserA being newly brought into policy scope while other users have already completed enrollment.

Check Intune and GPO assignments specifically for UserA. A device-scoped GPO causes every user of the device to attempt enrollment; a user-scoped GPO affects only targeted users, and user policy takes precedence when both are applied.^1^ If both Intune and Group Policy configure WHfB, Group Policy takes precedence.

Do not disable WHfB through an ad hoc local registry change where Intune manages the setting; Microsoft warns that conflicting MDM and local policy can produce unexpected results.^7^

If local provisioning remains impossible

Capture the User Device Registration/Admin events generated by one local-console attempt together with UserA’s dsregcmd /status output, then open a Microsoft Support case. 0x80090010 has no documented error-specific repair, so avoid clearing the TPM or disconnecting/rejoining the entire Entra-joined device solely on the basis of this code; those actions affect more than UserA.

If the intended goal is to authenticate to RDP using WHfB itself, separately deploy Microsoft’s certificate-based RDP configuration and verify:

certutil -store -user my

The applicable certificate should show Microsoft Passport Key Storage Provider.^2^

References

1. Configure and enroll in Windows Hello for Business in a hybrid key trust model
2. Remote Desktop sign-in with Windows Hello for Business
3. Troubleshoot devices by using the dsregcmd command
4. Common questions about Windows Hello for Business
5. certutil
6. Windows Hello errors during PIN creation
7. Configure Windows Hello for Business