The Autopilot PIN nobody can reset: Windows Hello recovery on day two

A Windows Autopilot deployment is usually judged on day one. The device arrives, the user signs in, the Enrollment Status Page runs, and the desktop appears. Shortly after that the machine asks the user to create a Windows Hello PIN. Everyone declares the deployment a success and moves on.

Day two is where the design gets tested. The user comes back from a weekend and stares at a PIN pad. They cannot remember the six digits they invented while a progress bar was spinning at them. On a device that has never shown them a password prompt, that PIN was effectively their only credential. What happens next depends entirely on recovery infrastructure that most projects never scheduled.

The problem: a credential with no recovery path behind it

Start with what a user-driven Autopilot enrolment actually gives the user. They authenticate once during the out-of-box experience, which is abbreviated as OOBE. They might authenticate with a password. They might authenticate with a Temporary Access Pass, abbreviated as TAP, which is a time-limited passcode an administrator issues. Either way, that single authentication carries them through Microsoft Entra join and Intune enrolment.

Then the Enrollment Status Page, abbreviated as ESP, takes over. Microsoft documents that the ESP tracks three phases: device preparation, device setup and account setup. It tracks applications, security policies, certificate profiles and network connections. It does not track Windows Hello for Business enrolment. Hello provisioning starts after the ESP has finished with the user.

So the PIN prompt is the last thing that happens in the build. It is also the one thing nobody watched. The user picks a PIN, confirms it, and reaches the desktop.

Microsoft's provisioning documentation is explicit about what has just been created. A key pair is generated on the device. The public key is registered with the Azure Device Registration Service. The PIN is the gesture that authorises use of the private key.

That is a good credential. It is hardware-bound and phishing-resistant. It is also, on a brand new corporate device, frequently the only credential the user has ever successfully used to unlock that machine.

Now break it. The user forgets the PIN. Microsoft documents two forms of PIN reset, and the default is the destructive one. In a destructive reset the existing PIN and the underlying credentials are deleted. That includes any keys or certificates that other services added to the Windows Hello container. A new sign-in key and a new PIN are then provisioned from scratch.

Destructive reset needs no configuration, which is exactly why teams never think about it. It also has requirements the day-two user may not be able to meet. Microsoft states that on Microsoft Entra hybrid joined devices the user must have corporate network connectivity to a domain controller to complete a destructive reset. A remote user on home broadband does not have that.

Why it happens: provisioning is automatic, recovery is opt-in

The gap exists because two switches that belong together live in different places and have opposite defaults.

The first switch is provisioning. Microsoft's configuration guidance states plainly that Windows Hello for Business is enabled by default for devices that are Microsoft Entra joined. You do not have to assign anything for a PIN prompt to appear. If you want to prevent it, you have to actively disable it. That is done with the Use Windows Hello for Business policy or the tenant-wide enrolment setting.

The second switch is recovery. Non-destructive PIN reset depends on the Enable Pin Recovery setting. That setting is backed by the EnablePinRecovery node in the PassportForWork configuration service provider, abbreviated as CSP. The CSP reference documents its default value as False.

Microsoft's description of the disabled state is unambiguous. When the policy is disabled or not configured, Windows does not create or store the PIN recovery secret. The user's only route to a working PIN is to delete the existing one and create a new one.

Read those two defaults together. Provisioning is on by default. Recovery is off by default. A tenant that has configured nothing at all will still hand a PIN to every Autopilot user, and will still have no non-destructive way to reset it.

What non-destructive reset actually needs

Microsoft documents the mechanism. When PIN recovery is enabled on a client, a 256-bit AES key is generated locally. That key is added to the user's Windows Hello container as the PIN reset protector. It is encrypted with a public key retrieved from the Microsoft PIN reset service and stored on the client.

At reset time the encrypted protector is sent to the service, decrypted, and returned. The returned protector is used to change the PIN that authorises the existing keys. The container survives. Nothing is re-registered.

Two things follow from that design. First, the service side must exist. Microsoft requires two applications to be registered in the tenant, named Microsoft Pin Reset Service Production and Microsoft Pin Reset Client Production. Second, the client side must be enabled. Neither happens by accident.

The trust type changes the answer

The PIN reset comparison table in Microsoft's documentation is worth reading line by line. The destructive path is not uniformly available. For Microsoft Entra joined devices, destructive reset is supported across certificate trust, key trust and cloud Kerberos trust.

For Microsoft Entra hybrid joined devices it is narrower. Microsoft states that certificate trust and cloud Kerberos trust support destructive reset both from the Settings page and from above the lock screen. Key trust does not support destructive reset from above the lock screen. The documented reason is the sync delay between provisioning a Hello credential and being able to use it for sign-in.

That is the worst case in a hybrid key trust estate. The user has forgotten their PIN. They are sitting at a lock screen. The only reset path Microsoft ships by default does not work from there.

The Temporary Access Pass timing trap

Many Autopilot projects now use a TAP so the user never types a password during OOBE. That is a genuine security improvement, and it creates a specific day-one problem that Microsoft documents directly.

A one-time TAP has a hard constraint. Microsoft states that when a one-time pass is used to register a passwordless method, the registration must be completed within ten minutes of that sign-in. Autopilot enrolment routinely takes longer than ten minutes. So the first pass gets the device enrolled, and by the time Windows asks for a PIN the window has closed.

Microsoft's guidance offers two supported approaches. Issue two single-use passes, one for enrolment and one for Hello registration. Or enable multi-use passes so a single pass covers both steps within its validity period. Choosing neither is how a brand-new device ends up with no credential the user can complete.

How to verify: prove readiness before the first device ships

There are five things worth checking, and only one of them lives in the Intune portal.

1. Read CanReset on the device

This is the authoritative client-side check, and Microsoft publishes it as such. Run dsregcmd /status and look at the User State section. The CanReset line reports DestructiveOnly when only destructive reset is available. It reports DestructiveAndNonDestructive when PIN recovery is working.

Run this in the signed-in user session, not as SYSTEM. The User State section only exists for an interactive user with a Hello container.

2. Look at the PassportForWork policy keys

Microsoft publishes registry mappings for the Use Windows Hello for Business setting, which is the provisioning switch. Those mappings tell you which parent key a given management channel writes into. The shared parents are worth committing to memory.

Note that the two are not the same path with a typo. The CSP parent has Microsoft\Policies. The Group Policy parent has Policies\Microsoft. Mixing them up is a classic wasted afternoon.

An important caveat applies to that table. Those four rows are the mappings Microsoft actually publishes. Microsoft does not publish a registry mapping for every Windows Hello for Business policy, and that includes EnablePinRecovery.

You will very often see an EnablePinRecovery value sitting under those same parents on a managed device, and reading it is useful. Treat it as observed evidence rather than a documented contract. Let CanReset be the deciding vote.

3. Read the provisioning events

Windows records the outcome of Hello provisioning prerequisite checks in the event log. Microsoft's documented channel for the interesting parts is the User Device Registration admin log.

Two honest caveats about this surface. Windows also ships a Microsoft-Windows-HelloForBusiness/Operational channel, and it is genuinely useful when reading a provisioning failure. Microsoft does not publish a per-identifier catalogue for it, so treat identifiers you find there as observed rather than documented.

The second caveat is a privacy one. Event 300 contains a Windows Hello key identifier in its message body. Do not paste that into a ticket.

4. Confirm the tenant side exists

Non-destructive reset is useless without its two service principals. Check them in the Microsoft Entra admin center.

Search the application list for Microsoft PIN. Microsoft's documented expectation is that both Microsoft Pin Reset Service Production and Microsoft Pin Reset Client Production appear. Finding only one of the two is a common half-finished state, because the consent flow involves two separate prompts and ends on a blank page.

5. Or run the companion script

The companion script bundles all of the above into one read-only report. It reads join state, the CanReset value, whatever PassportForWork values exist, and the event channels. With -CheckTenant it also queries Microsoft Graph for the two PIN reset service principals and the state of the Temporary Access Pass policy. It never prints key identifiers, container identifiers or tenant identifiers.

The fix: build the recovery path alongside the deployment

Treat PIN recovery as part of the Autopilot build, not as a follow-up ticket. There are four workstreams, and they are all small.

Step 1: register the PIN reset service applications

1. Sign in as at least an Application Administrator.
2. Open the Microsoft PIN Reset Service Production consent URL from Microsoft's PIN reset article.
3. Review the requested permissions and select Accept.
4. Open the Microsoft PIN Reset Client Production consent URL from the same article.
5. Review the requested permissions and select Next, then Accept.
6. Expect a blank redirect page afterwards. Microsoft documents this as known behaviour, not a failure.
7. Verify both service principals exist under Enterprise applications, as described above.

Step 2: enable PIN recovery on the clients with Intune

The Settings Catalog is the current path, and it is a single setting.

1. Choose platform Windows 10 and later and profile type Settings catalog.
2. Select Add settings and search the category Windows Hello For Business.
3. Select the setting Enable Pin Recovery and set it to True.
4. Assign the policy to a group containing the devices or users you want configured.
5. Confirm delivery by reading CanReset on a pilot device, not by reading the portal.

Microsoft also documents an Endpoint security route to the same outcome. That suits teams who keep identity hardening separate from device configuration.

If you prefer a custom profile, the CSP node is documented as a boolean with a default of False. It is available from Windows 10 version 1703 onwards.

Step 3: enable PIN recovery with Group Policy

The Group Policy path does exist, so hybrid estates that still manage Hello through Active Directory are not stuck.

1. Open the Group Policy Management Console and edit an object linked at the right scope.
2. Browse to Computer Configuration then Administrative Templates then Windows Components then Windows Hello for Business.
3. Open the setting named Use PIN Recovery.
4. Set it to Enabled and apply.
5. Link, security-filter or WMI-filter the object as usual.

Both channels exist for this setting. That is worth stating plainly, because it is not true of every Hello setting. Turn off smart card emulation, for example, is documented as Group Policy only with no CSP equivalent.

Step 4: give the user a fallback for the day the PIN is gone

PIN recovery still requires the user to authenticate and complete multifactor authentication. So they need a working second factor, and on a brand-new device they may not have one yet. That is what a Temporary Access Pass is for.

1. Sign in as at least an Authentication Policy Administrator.
2. Open the Temporary Access Pass method and select Enable.
3. Include the groups that will onboard through Autopilot, and exclude anything sensitive.
4. Decide the one-time use setting deliberately. Microsoft documents the default as False, which means passes may be reused within their lifetime.
5. If you enforce one-time use, plan to issue two passes per Autopilot build. That is because of the documented ten-minute registration window.
6. Set lifetimes to match your build duration. Microsoft documents a default lifetime of one hour and a maximum of eight hours, both configurable between 10 minutes and 30 days.

Finally, if your tenant is federated or you run Azure Government, configure the allowed URL list for the PIN reset web sign-in flow. Microsoft documents the symptom of not doing so as an error page reading that Windows cannot open that page right now. The setting is Configure Web Sign In Allowed Urls under the Authentication category, and it takes a semicolon-delimited list of domains.

Proof it worked: what a ready device reports

Readiness is a one-line answer. CanReset reports DestructiveAndNonDestructive, and both PIN reset service principals exist in the tenant. Everything else is supporting evidence.

The companion script prints exactly that. The output below is illustrative, using a fictional device with the gap still present, so you can see what a not-ready result looks like before you fix it.

That is four gaps on a device a project would have signed off as a successful Autopilot deployment. The build worked. The recovery story did not exist.

Once the four steps above are done, the same script on the same device returns zero gaps and CanReset flips. That is the moment the deployment is actually finished. Not when the desktop appeared on day one, but when a user who forgets their PIN on day two can fix it themselves.

The planning rule worth adopting

Write it into the Autopilot design document as a dependency, not a nice-to-have. Provisioning a credential and being able to recover a credential are the same project. Microsoft's defaults deliver the first and withhold the second. The gap only becomes visible when a real person is locked out of a real laptop.

References

• PIN reset — the destructive versus non-destructive comparison table, the PIN reset service registration steps, the Intune and Group Policy settings, and the documented CanReset check.
• Configure Windows Hello for Business — states that Hello is enabled by default for Microsoft Entra joined devices, documents the registry mappings for UsePassportForWork, and warns against mixing Group Policy with CSP.
• Windows Hello for Business policy settings — the full settings reference, including Use PIN recovery and which settings have no CSP equivalent.
• PassportForWork CSP — the authoritative node path for EnablePinRecovery, its boolean format and its default value of False.
• How Windows Hello for Business provisioning works — what the PIN prompt actually creates, and the note that recent OOBE multifactor authentication suppresses a second prompt.
• Set up the Enrollment Status Page — the three ESP phases and the list of what is tracked, which does not include Windows Hello.
• Configure a Temporary Access Pass — the device enrolment guidance, the ten-minute registration window for one-time passes, and the Windows device setup behaviour.
• Windows Hello for Business known deployment issues — the documented event 362 prerequisite checklist and the Kerberos event 107 example.
• Windows Hello errors during PIN creation — the error code table to reach for when the PIN prompt itself fails.

Community deep-dives worth reading