Reset Forgotten Windows Hello Pin

[Lu Rounsaville]

Whennondestructive PIN reset is enabled on a client, a 256-bit AES key is generated locally. The key is added to a user's Windows Hello for Business container and keys as the PIN reset protector. This PIN reset protector is encrypted using a public key retrieved from the Microsoft PIN reset service and then stored on the client for later use during PIN reset. After a user initiates a PIN reset, completes authentication and multifactor authentication to Microsoft Entra ID, the encrypted PIN reset protector is sent to the Microsoft PIN reset service, decrypted, and returned to the client. The decrypted PIN reset protector is used to change the PIN used to authorize Windows Hello for Business keys, and it's then cleared from memory.

Using Group Policy, Microsoft Intune or a compatible MDM solution, you can configure Windows devices to securely use the Microsoft PIN reset service, which enables users to reset their forgotten PIN without requiring re-enrollment.

You must replace TenantId with the identifier of your Microsoft Entra tenant. To look up your Tenant ID, see How to find your Microsoft Entra tenant ID or try the following, ensuring to sign-in with your organization's account::

To configure a device with group policy, use the Local Group Policy Editor. To configure multiple devices joined to Active Directory, create or edit a group policy object (GPO) and use the following settings:

The PIN reset configuration can be viewed by running dsregcmd /status from the command line. This state can be found under the output in the user state section as the CanReset line item. If CanReset reports as DestructiveOnly, then only destructive PIN reset is enabled. If CanReset reports DestructiveAndNonDestructive, then nondestructive PIN reset is enabled.

PIN reset on Microsoft Entra joined devices uses a flow called web sign-in to authenticate users in the lock screen. Web sign-in only allows navigation to specific domains. If web sign-in attempts to navigate to a domain that isn't allowed, it displays a page with the error message: We can't open that page right now.

If you have a federated environment and authentication is handled using AD FS or a non-Microsoft identity provider, then you must configure your devices with a policy to allow a list of domains that can be reached during PIN reset flows. When set, it ensures that authentication pages from that identity provider can be used during Microsoft Entra joined PIN reset.

For Azure Government, there is a known issue with PIN reset on Microsoft Entra joined devices failing. When the user attempts to launch PIN reset, the PIN reset UI shows an error page that says, "We can't open that page right now". The ConfigureWebSignInAllowedUrls policy can be used to work around this issue. If you are experiencing this problem and you are using Azure US Government cloud, set login.microsoftonline.us as the value for the ConfigureWebSignInAllowedUrls policy.

Destructive and nondestructive PIN reset scenarios use the same steps for initiating a PIN reset. If users have forgotten their PINs, but have an alternate sign-in method, they can navigate to Sign-in options in Settings and initiate a PIN reset from the PIN options. If users don't have an alternate way to sign into their devices, PIN reset can also be initiated from the Windows lock screen with the PIN credential provider. Users must authenticate and complete multifactor authentication to reset their PIN. After PIN reset is complete, users can sign in using their new PIN.

For Microsoft Entra hybrid joined devices, users must have corporate network connectivity to domain controllers to complete destructive PIN reset. If AD FS is being used for certificate trust or for on-premises only deployments, users must also have corporate network connectivity to federation services to reset their PIN.

Key trust on Microsoft Entra hybrid joined devices doesn't support destructive PIN reset from above the Lock Screen. This is due to the sync delay between when a user provisions their Windows Hello for Business credential and being able to use it for sign-in. For this deployment model, you must deploy non-destructive PIN reset for above lock PIN reset to work.

You may find that PIN reset from Settings only works post sign in. Also, the lock screen PIN reset function doesn't work if you have any matching limitation of self-service password reset from the lock screen. For more information, see Enable Microsoft Entra self-service password reset at the Windows sign-in screen.

Have him do a PIN reset, it will re-initialize the whole process. There's a difference between On-Prem and Hybrid environment PIN resets though, as noted here: -us/windows/security/identity-protection/hello-for-business/hello-faq#w...

Hi all, I onboarded a non-technical friend to Enpass Windows and Android. She used Biometric sign-in for a while - until Enpass simply stopped offering to use Windows Hello and biometrics on Windows AND Android for no obvious reason.

(Why does that even happen?)

She always signs in to her device using biometrics, so she is authenticated and trusted. Also, her device is trusted. And Windows Hello is, by definition, MFA. So it should be significantly safer than the master password alone. How can we force Windows Hello unlock instead of Master-Password?

2. I understand the master password is gone, permanently. And no one on the planet can help us recover it. Which is why I didn't ask to recover the master password, I asked to restore biometric sign-in, which is already established on trusted devices and works fine for all other apps.

3. I am quite familiar with Windows Hello. AFAIK, it does not signal failed sign-in attempts to the requesting service, only successful ones. Enpass can't know whether sign-in failed or not. Especially not on devices with Hello Face Recognition, where there is always a fall-back to the device PIN, making Hello sign-in 100% successful every time.

5. Windows Hello is, by definition SAFER than Enpass Master Password. Device-based biometrics (on Android also) are, by definition, Multi-Factor, whereas the Master Password is single-factor. So by turning Biometric MFA off without user consent, you weaken security. Also without user consent.

Claiming that you are improving security by periodically requiring the master-password and defaulting to single-factor-auth. seems counter-intuitive.

a.) Provide an unsupported private build (!) for me/us that has Windows Hello force-enabled. We will use this to re-gain access and set a new master-password. After that, we re-install a supported public build from the Store/Play.

b.) Change Enpass to NEVER disable biometric MFA without user consent. At the very least, provide a user-configurable option, which, by default, is set to NEVER disable biometric MFA, regardless of the circumstances. Make sure that when this update rolls out, it will automatically re-enable biometric sign-in wherever it was turned off.

Alternatively, move the vault-unlock sign-in into the app, so that we can start the app and access the settings without unlocking the vault. Require vault sign-in when the user wants to access their vault, not before the app starts.

Due to the nature of Enpass being an offline password manager, it is important to create a strong but memorable password that you do not store anywhere that it could be discovered. Enpass cannot recover lost or forgotten Master Passwords. All your data is under your exclusive control. If your Master Password is lost, Enpass should be reset so you can start over as a new user.

Although we provide our users with the advantage of accessing the app through various means like PIN/Face ID/biometrics, we strongly recommend remembering your master password and keeping it safe. Having said that, I have duly noted your comments for future consideration.

However, I don't see how turning Windows Hello off will let us re-gain access to the app? We do not remember the master password, since, for a long time, it was not necessary. And users being human tend to forget stuff they don't use for a longer time.

Also, if my data is under my exclusive control, then do not meddle in the authentication mechanisms I choose for my data. Turning off biometrics without warning, user consent or any recourse is highly disruptive to say the least, and ultra-destructive in the worst case.

Do you realize this is like my bank removing access to my money and other valuable property without my consent?

The moment I switch my authentication of choice to the OS' biometric MFA framework (based on your advertised functionality), the master password became obsolete. With Enpass unilaterally reverting that choice, you have blocked access to valuable (potentially vital!) data. Selecting my authentication method to my data should not be Enpass' choice, it should be mine.

No place in your documentation, guides, FAQ or even this forum seem to indicate that Windows Hello simply turns off ever so often. Your claim above "For security purposes, Enpass may occasionally prompt you to enter your master password or in certain situations, like after unsuccessful verification attempts via Face ID/biometrics/Windows Hello." is undocumented. Hence, you took a supported feature away.

3a8082e126