Windows Hello PIN Resets After Every Reboot Following KB5121003: What To Try First

A Windows 11 machine that installed KB5121003 can boot to the lock screen, reject the PIN that worked the day before, and insist on setting up a new one. The new PIN works for the rest of the session. Then the next restart asks for enrollment again. That loop is the symptom this article addresses, and the most important thing to know before touching anything is that the fastest-looking fixes circulating for it are also the least reversible.

Start with the supported sequence below. It takes about two minutes and resolves the ordinary version of this failure. Only move to the deeper section if the PIN disappears again after a second restart.

The two-minute attempt

Do this first, in this order, without skipping the restart test at the end.

1. At the lock screen, select Sign-in options and pick the password icon. Sign in with the account password rather than enrolling yet another PIN at the prompt.
2. Open Settings > Accounts > Sign-in options. That page is the supported location for every step that follows, and it is the only place these steps should be carried out.
3. Find the PIN section on that page. If a change option is offered and the existing PIN is still accepted, use that path first. Changing the PIN rewrites the credential without discarding the container behind it.
4. If the change fails, or the existing PIN is no longer accepted, use the forgotten-PIN option offered on that same page and complete the identity verification it asks for.
5. Choose Restart from the Start menu — an actual restart, not shutdown followed by power-on. Sign in with the new PIN.
6. Restart a second time. This step is the whole test. A single successful sign-in proves nothing here, because the reported failure regenerates a credential that works once and breaks on the following boot.

If the PIN survives two consecutive restarts, the problem was an ordinary credential fault and the job is finished. If enrollment is demanded again on the second boot, stop repeating this cycle. Running the same reset a third and fourth time produces the same result and adds nothing diagnostic.

Telling this apart from an ordinary PIN failure

Windows Hello breaks for many mundane reasons, and most of them look identical at the lock screen. The distinguishing feature of the post-update loop is not the error text. It is reproducibility across reboots.

Three checks separate the two cases.

• Does the account password still work? If password sign-in succeeds every time while the PIN fails every time, the account itself is healthy and the problem is confined to the Hello credential store on this device.
• Does a fresh PIN work for the rest of the session? A PIN that enrolls cleanly, unlocks the desktop, unlocks again after a screen lock, and then vanishes at the next boot is behaving differently from a PIN that is simply refused.
• Does the count of restarts match the count of enrollment prompts? One prompt per boot, every boot, with no other pattern, is the shape reported after this update. Intermittent failures — some boots fine, some not — point elsewhere.

Check the installed build before assuming any connection to the update at all. Run winver. KB5121003 lands on build 26100.9168 for Windows 11 24H2 and build 26200.9168 for 25H2. A machine on some other build has a different problem, and the steps aimed at this update will not apply.

Why repeating the reset does not converge

One published user account of this loop is worth reading closely, because it explains why repetition is futile rather than merely slow. In that description the credential key was deleted at each reboot and recreated under a different identifier, and the newly created key was itself corrupted by the following boot.

If that is what a given machine is doing, then every reset produces a fresh credential already travelling the same path as the one before it. The number of attempts is not the variable that matters. Nothing about the fourth reset differs from the first except the time spent on it.

Two cautions attach to that account. It is one person's description of one machine, not a confirmed mechanism, and it should not be repeated to a help desk as though it were an established explanation. Its useful content is narrower than an explanation anyway: it supplies a stopping rule. One reset, two restarts. If the symptom returns on the second boot, additional resets are not the missing ingredient, and the decision moves to the sections below.

What is confirmed and what is not

This distinction matters more than usual here, because it determines how much risk is worth accepting.

Confirmed by Microsoft. KB5121003 was released on 11 August 2026 for Windows 11 version 24H2 and version 25H2, producing builds 26100.9168 and 26200.9168 respectively.

Not confirmed by Microsoft. The Windows Hello behaviour described in this article comes from user reports that followed the update. It is not an acknowledged known issue. Two related patterns appear in those reports: a PIN that has to be re-enrolled after every reboot, and an existing Windows Hello container that fails to load. Reports about other behaviour on the same update circulated separately and are a different matter, not covered here.

The practical consequence: treat the update as a plausible correlation, not a proven cause. Exhaust the supported repairs before considering anything that removes a security update from the machine, and do not describe this to a colleague or a help desk as a known Microsoft bug, because it is not one.

There is a second-order reason the distinction is worth holding onto. Advice written as though the cause were settled tends to justify stronger remedies than the evidence actually supports, and that is exactly how a reversible annoyance turns into an unbootable machine. The strength of a fix should track the strength of the diagnosis. Here the diagnosis is a pattern in user reports, which is enough to guide an ordering of supported steps and not enough to warrant anything drastic.

The deeper sequence, ordered by what it costs to undo

Every action below is reversible, but not equally. Work down the list and stop at the first step that survives two restarts.

Step 1 — Remove the other Hello enrollments first

In Settings > Accounts > Sign-in options, remove any facial recognition and fingerprint enrollments that are present. Face and fingerprint credentials sit alongside the PIN in the same Windows Hello arrangement. Clearing them narrows the problem to a single credential before the next reset, and they take under a minute to enroll again afterwards.

Step 2 — Perform the reset from a signed-in session, not the lock screen

The forgotten-PIN flow is reachable in two places: below the PIN box at the lock screen, and inside the sign-in options page. Prefer the second. Running it from a signed-in desktop means a failure leaves the machine usable, and the verification prompts are easier to complete when a browser is already available for account challenges.

Step 3 — Establish which kind of account this is

Before going any further, determine whether the device is signed in with a personal account or with a work or school account. The Accounts area of Settings shows which identity is in use.

This is the most important branch in the whole article, and it is the one people skip. It does not change the symptom or the first repair attempt. It changes whether the remaining options are available at all, and whether taking them is the reader's decision to make.

Step 4 — Re-test with the restart discipline intact

Two restarts, both from the Start menu. Sign in fully each time, not just to the lock screen. Record which boot the failure returns on. That detail is the only genuinely useful thing to hand to a support channel, and it is also the trigger for the decision in the sections that follow.

The folder-deletion advice circulating in forums

Search results for this symptom converge quickly on a procedure that takes ownership of a protected system folder holding Windows Hello credential material and then deletes its contents. It appears in forum threads, in aggregator articles, and in video walkthroughs.

That procedure is not documented in Microsoft's own support material for PIN problems, and it is deliberately not written out here. Two reasons carry the decision.

First, taking ownership of a protected directory changes permissions that Windows set deliberately, and restoring the original access control entries afterwards is not a one-click operation. The step that is easy to perform is not the step that is easy to reverse, and those are different properties that forum instructions rarely separate.

Second, the supported forgotten-PIN reset already replaces the credential through a documented path. On many machines the unsupported route is chasing the same outcome through a riskier door, which is a poor trade even when it happens to work.

If a support engineer with visibility into the specific machine directs that step, that is a different situation, and someone is accountable for the result. Reading it in a comment thread is not that situation.

Work and school accounts change the available options

On a device signed in with a work or school account, the PIN may not be a convenience layer sitting over a password. It can be the credential the organisation expects to be used, and the password route may be restricted. Removing the PIN on such a device can leave no way in at all.

What changes on managed hardware is mostly a question of who owns the decision, and that is the part worth internalising before touching anything.

• The recovery options that appear on the sign-in options page are shaped by organisational configuration rather than by the person at the keyboard. An option present on a personal machine may simply be absent here, and its absence is a policy outcome, not a fault to troubleshoot.
• Management software can re-issue or revoke credentials on its own schedule. A prompt that looks identical to the one described here may be routine policy activity that has nothing to do with any update.
• Uninstalling a security update on a managed endpoint is generally a compliance problem regardless of whether it would resolve the symptom.
• A device that cannot sign in is a support ticket. Organisations have recovery routes that are not reachable from the lock screen, and escalating early is faster than discovering that hours later.

The operational conclusion for a managed device is short. Note which boot the symptom returns on, note whether password sign-in still works, and send both to the help desk. Do not remove the PIN, do not uninstall the update, and do not run unsupported folder procedures on hardware someone else is responsible for.

When uninstalling the update becomes a defensible choice

On a personally owned device, removing a quality update is done from the update history in Windows Update, where installed updates are listed by KB number. Not every update offers removal, and a missing removal option is a real outcome rather than a sign of user error. Confirm the current procedure in Microsoft's documentation for the installed build rather than from a forum post.

Removal is defensible only when several conditions hold together.

1. The supported reset sequence above has been completed at least once and the symptom returned on the second restart.
2. The device is personally owned and not subject to a corporate compliance requirement.
3. Sign-in is genuinely blocked or badly degraded — not merely inconvenient. A working password is a working sign-in.
4. The build number confirms KB5121003 is actually installed, and the symptom began at the first boot after it.

The cost side deserves equal weight. This is a security update, and removing it drops every fix it carried, not the one behaviour in question. Windows Update will offer it again, so the update has to be paused or deferred, extending the exposure window. And because the symptom is not a confirmed defect, removal may change nothing — leaving the device unpatched and still broken, which is worse than where it started.

A better intermediate step for many people: keep the update, sign in with the password, and leave the PIN unenrolled until a later cumulative update ships. That preserves the security fixes and costs a few extra seconds per sign-in. It also leaves the machine in a state where the next update can be evaluated cleanly — enroll a PIN then, restart twice, and the answer is immediate.

Where the reboot test stops being evidence

The framing in this article rests on one assumption: that the symptom starts with the update and reproduces on every boot. Several situations break that assumption, and the steps above are the wrong tool in each.

• The symptom predates 11 August 2026. If PIN enrollment was already unstable before the update installed, the correlation is imaginary. Check when the behaviour actually started rather than when it became annoying enough to search for.
• The security processor was cleared, or the device was reset. Either of those is a far more ordinary explanation for a credential prompt than an update is, and it should be ruled out first by checking whether anything of that kind happened near the same date.
• A management policy is re-provisioning the device. On enrolled hardware, configuration can revoke and re-issue credentials on a schedule. That produces prompts identical in appearance and unrelated in cause.
• The failure is intermittent. Any pattern other than one prompt per boot points away from this diagnosis. Two good boots followed by a bad one is a different investigation entirely.
• Password sign-in also fails. That moves the problem to the account or the user profile rather than the Hello credential store, and none of the credential-level steps here address it.
• The device is a virtual machine, or lacks a usable security processor. Windows Hello's guarantees depend on hardware that may not be present, and reasoning about credential-container corruption does not transfer cleanly to that case.

One further limit is worth stating plainly. Because Microsoft has not acknowledged this behaviour, there is no published fix date, no confirmed root cause, and no assurance that a later update addresses it. Anyone presenting a timeline for it is guessing, and the sensible posture is a machine that remains usable by password while the situation clarifies.

The short checklist

1. Sign in with the password. Do not enroll a new PIN at the prompt.
2. Run winver and confirm build 26100.9168 or 26200.9168.
3. Open Settings > Accounts > Sign-in options.
4. Note whether the account is personal, or work or school.
5. Remove face and fingerprint enrollments.
6. Try changing the PIN; if that fails, use the forgotten-PIN reset from the signed-in session.
7. Restart twice. Note which boot the symptom returns on.
8. Work or school device: send those details to the help desk and stop there.
9. Personal device, still broken: weigh the uninstall against staying on password sign-in.
10. Skip the folder-deletion procedure from the forums.