I'm trying to create a passwordless sign-in experience for devices that are Microsoft Entra hybrid joined. The Intune passwordless experience appears to work only with Entra-joined devices, so I'm looking for a practical workaround for hybrid-joined machines.
We're using Windows Hello for Business with multifactor device unlock through a PIN and biometrics. However, we still need password-based elevation through Run As and LAPS, so completely disabling the password credential provider isn't an option. Ideally, I'd like to hide the password option from the normal logon screen while still retaining a way for administrators or support staff to use LAPS and for users to sign in as another account when necessary. Has anyone implemented this successfully?
3 Answers
A common approach is to enable Smart Card Required for Interactive Logon (SCRIL) on user accounts. This randomizes the account password while preserving compatibility with LAPS and administrative workflows, effectively forcing normal users to authenticate with Windows Hello or another certificate-based method. Some organizations issue a short-lived certificate or smart card for the initial setup, then enroll the user’s FIDO2 key. Users never need to know their underlying password.
You generally can’t fully remove the password provider because password sign-in is still needed in scenarios such as first-time registration on a new device or signing in as another user. Even if it’s disabled for the normal user flow, Windows may still expose password sign-in when another account needs to authenticate.
That’s acceptable in this case. The goal is only to hide password sign-in from the everyday logon screen; it should still appear when someone explicitly chooses to sign in as a different user.
Windows Hello for Business can be enforced on hybrid-joined devices, and LAPS can still be used by remote support staff when administrative access is needed. For shared computers, FIDO2 security keys may help avoid the Windows Hello TPM limit on the number of enrolled users. One limitation is that FIDO2 support with some traditional RDP or gateway configurations can be inconsistent, so test it with your exact remote-access setup.
FIDO2 and Windows Hello can work with RDP and web sign-in on hybrid-joined servers, but they may not work with older or more traditional connection brokers and gateways.
We use a similar process: accounts get an automatically generated password that isn’t disclosed to the user, then a short-term certificate is used for initial authentication before the user is set up with a FIDO2 token.