We're piloting Windows Hello for Business in a hybrid Active Directory environment and want a genuinely passwordless sign-in experience. Windows remembers the last-used method, such as a PIN or biometric, but users can still select the password option. Is there a supported way to prevent users from signing in with a password while preserving practical recovery and administrative workflows?
4 Answers
The usual approach is to combine Windows Hello for Business with SCRIL (Smart Card Required for Interactive Logon). SCRIL changes the account password to a long random value and requires a smart card or Hello-style credential for interactive sign-in. Also consider enabling the passwordless experience policy, but treat that as a convenience feature rather than the actual security control: users may still be able to choose another sign-in method in some situations.
Test the operational impact carefully. Removing or hiding the password provider can interfere with UAC, LAPS, account selection during elevation, and some recovery scenarios. Smart cards or security keys with certificates can help with administrative elevation.
Hiding the password option is not the same as eliminating password authentication. A PIN or biometric is device-bound, so it reduces the risk of a stolen reusable password, but the underlying account password may still be needed by legacy applications and recovery processes. Before enforcing this everywhere, inventory those dependencies and test Web Sign-In, PIN recovery, help-desk elevation, LAPS, and shared or multi-user devices.
You can enforce “Require Windows Hello for Business or a smart card” through policy. That prevents ordinary username-and-password interactive logon on the device. For a hybrid setup, SCRIL is still useful because it ensures the user does not possess a usable password in the first place. Keep a documented recovery process for forgotten PINs, broken Hello provisioning, and offline scenarios.
We use Hello sign-in and phishing-resistant passkeys or security keys, then assign each account a very long randomly generated password that users never receive. This gets close to passwordless in day-to-day use without removing the password credential provider, which avoids breaking tools such as Run as, UAC, or LAPS. Disable user-controlled password reset if the goal is to ensure they cannot create a password they know.
The passwordless experience policy mainly hides the password option on the normal lock screen. Someone who knows the password may still be able to select Other user or another credential path, so the account password should remain unknown and password reset options such as self-service password reset should be restricted.