Flamingo Raises $4.5M Seed Round · Led by Vertex Ventures, bringing total funding to $6.7M to build the open, AI-native layer for IT and security.
Dmytro Koval
Why Windows says your PIN isn't available after a firmware update, a rename or a policy change, and the fix order from a password sign-in to a TPM clear.
The user says their PIN stopped working and the sign-in screen offers to set it up again. Nothing on the device looks broken, the password still works, and the ticket lands on your desk twice a week. This guide explains why "something went wrong and your PIN isn't available" appears, how to tell the five causes apart, and which fix to run first so you stop reaching for the TPM clear button.
A Windows Hello PIN is not a password with fewer characters. Microsoft's how it works page lays out the chain: during setup Windows generates a key pair, the TPM holds the private key, and the PIN is "user-provided entropy" that unlocks it. The PIN itself is never stored on the device and never sent to the identity provider. What the PIN unlocks is a protector key, which unwraps an authentication key, which opens the user's ID keys. Those ID keys sign the request that Microsoft Entra ID or the domain controller validates against the public key it recorded at enrollment.
That chain is why the PIN is better than a password and also why it is brittle. Every link depends on something that can change underneath it: the TPM that holds the key, the identity the key was registered to, the service that reads the container, and the policy that allowed the PIN in the first place. Change any of them and Windows cannot prove the PIN belongs to this user on this device, so it refuses the PIN and offers a new enrollment. The folder that stores the container metadata is C:\Windows\ServiceProfiles\LocalService\AppData\Local\Microsoft\Ngc, and it appears in nearly every fix for a reason.
The message is the same every time. The cause is not, and the first five minutes of the ticket should go on telling them apart.
The TPM was cleared. A UEFI update, a firmware reset or a motherboard swap can reset the TPM, and Microsoft's TPM troubleshooting page is blunt about the result: clearing it "causes you to lose all created keys associated with the TPM, and data protected by those keys, such as a virtual smart card or a sign-in PIN." The private half of the Hello key is gone, so the PIN has nothing to unlock. BitLocker will ask for its recovery key on the same boot, which is the tell. If the firmware update happened through your RMM, every device in that batch is about to open the same ticket.
The identity changed. Rudy Ooms at Patch My PC documented a case in August 2025 where PINs failed after the Windows 11 24H2 upgrade, with error 0xc000006d on screen. The Hello key had been registered to the user's old UPN, the UPN was renamed later, and 24H2 enforces the binding more strictly. The check is dsregcmd /status /verbose: in the Ngc Prerequisite Check section, 0xC0000064, AADSTS50034 or AADSTS135010 means the credential no longer matches the identity it was provisioned for. A device that has lost its domain trust produces a cousin of this failure, covered in our trust relationship guide.
A Windows update changed the rules. Two from 2025 are worth knowing by number. The April 8, 2025 update KB5055523 broke PIN and face sign-in after a "Reset this PC, keep my files" on devices where System Guard Secure Launch or DRTM was enabled after the update, and the fix landed in KB5055627. The June 2025 security update KB5060842 made PIN setup fail with 0x80090010 (NTE_PERM) on Entra-joined devices, per IBM's September 2025 support note, but only where the UsePassportForWork policy was assigned at user scope rather than device scope. Microsoft's September 29, 2025 preview update KB5065789 lists the fix. Microsoft's own PIN creation error table still files 0x80090010 under "no known mitigation," so the KB number is the answer, not the table.
A policy or device mode turned Hello off. Shared PC mode, a removed Windows Hello for Business policy, or a tenant setting that disables Hello globally while a user-scoped policy enables it. The container survives but nothing is allowed to use it. A July 2026 r/Intune thread below is the clean example: a disk-quota policy flipped devices into shared mode, and Hello stayed broken after the policy was reversed.
A service is not running. The PIN depends on the CNG Key Isolation (KeyIso) and Credential Manager (VaultSvc) services. Both are off in Safe Mode, which is why the PIN never works there, and a device booting with CSM or legacy mode enabled in firmware can block it too. Get-Service KeyIso, VaultSvc takes two seconds and rules this out.
Every fix below works by throwing away the broken container and enrolling a new one. The difference is how much else you throw away with it, so run them in this order and stop at the first one that holds.
Sign in with the password and let Windows re-enroll. On the lock screen, pick Sign-in options and the key icon. On an Entra-joined device the password has to be the current UPN, not the one the PIN was registered under. Once in, open Settings, Accounts, Sign-in options, remove the PIN and add it again. For a cleared TPM or a renamed user this is often the whole fix.
Delete the Hello container for that user. Microsoft documents certutil -DeleteHelloContainer on the certutil reference: it "deletes the Windows Hello container, removing all associated credentials that are stored on the device, including any WebAuthn and FIDO credentials," and the user has to sign out for it to complete. Run it as the affected user, not as the technician, sign out, sign in with the password, and enroll again. It is the command the r/Intune thread settles on, and it only touches the one user.
Clear the Ngc folder for every user on the device. This is the fix the consumer guides lead with, and it is the right one when nobody can sign in with a PIN or the container is damaged for more than one account. Do it from the recovery environment or an elevated prompt, with Windows on C:
codetakeown /f C:\Windows\ServiceProfiles\LocalService\AppData\Local\Microsoft\Ngc /r /d y icacls C:\Windows\ServiceProfiles\LocalService\AppData\Local\Microsoft\Ngc /grant *S-1-5-32-544:F /t rd /s /q C:\Windows\ServiceProfiles\LocalService\AppData\Local\Microsoft\Ngc md C:\Windows\ServiceProfiles\LocalService\AppData\Local\Microsoft\Ngc icacls C:\Windows\ServiceProfiles\LocalService\AppData\Local\Microsoft\Ngc /T /Q /C /RESET
The folder is owned by the LocalService account, which is why the takeown and icacls lines come first and why File Explorer fails on it. Every Hello credential on the machine is gone afterwards: PIN, fingerprint and face for every profile. The first method in the walkthrough below shows the same steps on a locked-out machine.
Re-register the device. When the container is fine but Entra ID rejects the key, the device record is the problem. Microsoft's mitigation list for PIN creation errors is the same four moves in order: try again, sign out and in, reboot, then disconnect the device from the organization and rejoin it. On an Intune device that is a reset through Autopilot, so confirm the user's data is in OneDrive before you start. A device that shows the TPM as missing in Device Manager has a different problem, covered in TPM device not detected.
Clear the TPM last. It fixes a PIN that nothing else will fix, and it costs the BitLocker key, every other TPM-bound credential on the device, and on an Entra-joined machine possibly the device trust itself, which is the caveat the second-most-voted reply in the thread above raises. Suspend BitLocker and record the recovery key, clear it from Windows Security (Device security, Security processor details, Security processor troubleshooting), never from UEFI, and expect to re-enroll everything. Microsoft's PIN error table reserves this step for 0x80090031, when a reboot has not cleared it.
The link under the PIN box runs a different process from the fixes above, and on an Entra-joined device it is often the fastest route. Microsoft's PIN reset page describes two versions. The default, destructive reset deletes the container and provisions a new key and PIN after the user authenticates with MFA. The non-destructive version keeps the keys and changes only the PIN, but it needs the Microsoft PIN Reset Service consented in the tenant and the Enable Pin Recovery setting pushed to devices. dsregcmd /status reports which one a device has under CanReset: DestructiveOnly or DestructiveAndNonDestructive.
Two limits catch people. On a hybrid-joined device with key trust, the lock-screen reset does not work at all because of the sync delay between enrollment and the key landing in Active Directory, and the user has to reset from Settings with line of sight to a domain controller. On an Entra-joined device with a federated identity provider, the reset page can fail with "We can't open that page right now" until the provider's domain is added to the ConfigureWebSignInAllowedUrls policy. If the sign-in screen instead says the option is temporarily unavailable, the key has not synced to AD yet, or an unpatched Server 2019 domain controller is dropping it, which Microsoft's known-issues page covers build by build.
One broken PIN is a ticket. Thirty on a Monday is a firmware rollout, a UPN cleanup or a policy change, and the fix is to find the batch rather than work the queue. Three checks catch nearly all of it.
Before a BIOS or firmware push, read the vendor notes for a TPM clear and check for a prompt that clears it during the update, because that is the step that turns one firmware job into a PIN reset on every device. The process is in our guide to updating firmware and belongs in the same change ticket. Suspend BitLocker for one reboot across the batch and the recovery prompts vanish with the PIN tickets.
Scope Windows Hello for Business policy to the device, not the user. Beyond the KB5060842 bug, a device-scoped policy survives shared-device modes and user moves between groups. Turn on PIN recovery while you are in the policy, so the user's own "I forgot my PIN" keeps the container and costs nothing.
Collect the state before you fix anything. A script that runs dsregcmd /status and Get-Service KeyIso, VaultSvc across a client's devices, with the output collected in one place, is what OpenFrame's script runner is for, and the join state and Ngc Prerequisite Check lines sort a batch of tickets into causes in a minute. The devices with 0xC0000064 are a rename, the devices whose BitLocker asked for a key are a firmware job, and the ones with Hello disabled in policy are the shared-mode change somebody made on Friday.
The PIN breaks when any link in its chain changes under it, and the fix is always a fresh enrollment. The skill is in choosing the narrowest one: a password sign-in for most tickets, the certutil command for one user, the Ngc folder for one device, and the TPM only when the error code says so. For the other half of this sign-in story, how fingerprint and face data is kept on the device and why it never leaves, read our guide to biometric authentication.
Head of Product Engineering
Hi! My name is Dmytro, but everyone calls me Dima. I’m a Software Developer and together with the development team, I help bring Flamingo to life — putting it on its feet from a technical perspective. Originally from Lviv, Ukraine 🇺🇦, but currently based in Spain, where I’ve been enjoying the blend of great weather, culture, and nature. I’m passionate about the mountains and love traveling — exploring new places and cultures really inspires me. These experiences constantly recharge me and give me a fresh perspective, both personally and professionally.
Still deciding?
Ask Mingo answers from our docs and customer stories.
Still deciding?
Ask Mingo answers from our docs and customer stories.