"I forgot my PIN" sounds trivial until you realise what the default reset actually does: it throws the credential away and re-enrols from scratch. On a Microsoft Entra hybrid joined device using key trust, that re-enrolment can leave the user unable to sign in above the lock screen until Entra Connect syncs the new key - which is exactly when they need to sign in. There is a better way, it is free, and almost nobody turns it on. This post covers destructive vs non-destructive PIN reset, how to deploy the Microsoft PIN Reset Service, and how to prove which mode a device is in.
The problem: the default PIN reset is destructive
Windows Hello for Business (WHfB) has two kinds of PIN reset, and the default is the blunt one:
- Destructive PIN reset (the default, no configuration): the user's existing PIN and the underlying credential - every key and certificate in their Windows Hello container - are deleted, and a brand-new sign-in key and PIN are provisioned. It is a full re-enrolment wearing a "reset PIN" label.
- Non-destructive PIN reset: the user's Hello container and keys are preserved. Only the PIN that authorises use of those keys changes. Nothing is re-provisioned.
The destructive default is fine on a Microsoft Entra joined device. It is a genuine problem on a hybrid joined, key-trust device: because the freshly provisioned key has to sync from Entra ID down to Active Directory before it can be used on-premises, destructive reset from the lock screen is not supported there. The user resets their PIN, then cannot get to their desktop. Non-destructive reset sidesteps the whole issue because no new key is created.
Why it happens: how non-destructive reset actually works
When you enable it, the client generates a 256-bit AES key locally and adds it to the user's Hello container as the PIN reset protector. That protector is encrypted with a public key retrieved from the Microsoft PIN Reset Service and stored on the device. When the user resets their PIN, they authenticate and complete multifactor authentication (MFA) to Microsoft Entra ID; the encrypted protector is sent to the service, decrypted, and returned; the client uses it to re-authorise the existing keys under a new PIN, then wipes the decrypted protector from memory. The keys never change - so there is nothing to re-sync.
How to verify: dsregcmd tells you the mode
This is the field nobody knows about. Run dsregcmd /status and look in the User State block for CanReset. It reports exactly which reset modes the device supports:
Read it like this: CanReset : DestructiveOnly means the policy has not applied and users still get the blunt re-enrolment. CanReset : DestructiveAndNonDestructive means the PIN Reset Service and client policy are both in place and non-destructive reset is live.
ConfigureWebSignInAllowedUrls) to a semicolon-delimited list such as signin.contoso.com;portal.contoso.com.The fix, part 1: register the two service applications
Non-destructive reset depends on the Microsoft PIN Reset Service, which is two Microsoft Entra enterprise applications you consent to once per tenant. Sign in as at least an Application Administrator and grant admin consent to each:
- Microsoft Pin Reset Service Production - consent at
aka.ms-style admin-consent URL for client IDb8456c59-1230-44c7-a4a2-99b085333e84 - Microsoft Pin Reset Client Production - consent for client ID
9115dd05-fad5-4f9c-acc7-305d08b1b04e
Then confirm both service principals actually landed in your tenant:
You should see both Microsoft Pin Reset Service Production and Microsoft Pin Reset Client Production listed.
The fix, part 2: enable PIN recovery on the clients
Intune (Settings Catalog)
You can also reach it via Endpoint security › Account protection › Create Policy. Prefer raw CSP? Use a custom policy (replace TenantId with your directory GUID):
Group Policy
| Group policy path | Setting | Value |
|---|---|---|
| Computer Configuration \ Administrative Templates \ Windows Components \ Windows Hello for Business | Use PIN Recovery | Enabled |
The user experience
Both modes start the same way. If the user can still get in with another method, they go to Settings › Accounts › Sign-in options › PIN (Windows Hello) › I forgot my PIN. If they are stuck at the lock screen, they pick the PIN credential provider and choose I forgot my PIN there. Either way they authenticate, complete MFA, and set a new PIN. With non-destructive reset enabled, that is all that happens - no re-provisioning, no waiting for a key to sync, no lockout on hybrid key-trust devices.
EnablePinRecovery, then spot-check a device with dsregcmd /status and confirm CanReset : DestructiveAndNonDestructive before you close the ticket.Proof it worked: the mode the user actually gets
You have deployed this correctly when dsregcmd /status reports CanReset : DestructiveAndNonDestructive on a target device, both PIN Reset Service applications appear under Enterprise applications, and a test user can choose I forgot my PIN, complete multifactor authentication, and set a new PIN without the credential being re-provisioned - no key re-sync, no lockout on hybrid key trust.
References
- Windows Hello for Business PIN reset (Microsoft PIN Reset Service)
- PassportForWork CSP (EnablePinRecovery)
- Policy CSP - Authentication (ConfigureWebSignInAllowedUrls)
- Troubleshoot devices by using the dsregcmd command (CanReset)
Script for this post is in Daily-Tasks.