Azure Active Directory (Azure AD), the cloud-based identity management service that Microsoft 365 and other cloud-native apps rely on for user authentication, supports passwordless sign-in. Microsoft has been pushing IT professionals and consumers to stop using passwords in recent years. Social engineering techniques, like phishing and malware, make passwords vulnerable. And around 80 percent of successful attacks originate from compromised passwords.
Passwordless sign-in replaces passwords with something you have, like a security key, plus something you are or know. Something you are might be a biometric gesture like a fingerprint. Something you know might be a PIN. Microsoft supports three different passwordless sign-in methods in Azure AD:
Microsoft Authenticator is the easiest of the three methods to implement, providing that users have access to a smartphone. But in this article, I’m going to focus on choosing between Windows Hello for Business and FIDO2 security keys. While the end goal is the same, passwordless sign-in for users, there are some important differences to understand.
Windows Hello is ideal for users that are assigned a fixed device. I.e. they don’t often need to log in to different devices. That’s because Windows Hello registers the device itself as ‘something you have’. If a user moves to a different device, then they need to go through the registration process again. Windows Hello can be used to sign in to Windows 10 and it provides single sign-on capabilities for cloud services like Microsoft 365.
There are different ways that devices can register with Windows Hello for Business but the most common is during the out-of-box experience (OOBE) for Azure AD joined devices. For organizations that are cloud only, or if there is a hybrid deployment, Azure AD is the identity provider for Windows Hello. In on-premises only deployments, Active Directory Federation Services (AD FS) acts as the identity provider.
Windows Hello for Business can be complex to deploy. There are several different deployment models – cloud, hybrid, and on-premises – and each has their own requirements. There are also two trust models: key trust and certificate trust.
The key trust model is for organizations that don’t want to issue certificates to users and that have enough domain controllers in each site for authentication. While you won’t need to issue certificates to users, the key trust model still requires a public key infrastructure (PKI) to act as a trust anchor for authentication. It’s also worth noting Remote Desktop (RDP) doesn’t support key trust deployments.
The certificate model is for organizations that don’t mind issuing certificates to end users. The model has the benefit of supporting certificate expiration and renewal, not that different from how smartcards work.
Windows Hello for Business provides strong multifactor authentication (MFA). But the provisioning process requires a second factor in addition to a username and password. For cloud only deployments, the MFA that comes free with Office and Microsoft 365 subscriptions is enough to provision users in Windows Hello. If you have a hybrid Windows Hello deployment, Azure MFA or AD FS can be used during provisioning.
FIDO2 (Fast IDentity Online) is an industry standard, which includes the web authentication (WebAuthn) standard. FIDO2 security keys provide an unphishable passwordless sign-in method. Security keys can use different interfaces to connect to devices, like USB, Bluetooth, and NFC. Unlike Windows Hello, FIDO2 security keys are portable and they are suited to situations where users need to regularly log in to different devices. FIDO2 security keys can provide single sign-on to cloud and on-premises apps, and they can be used to sign in to Windows 10 Azure AD joined and hybrid Azure AD joined deices.
While Windows Hello for Business requires quite a lot of infrastructure, FIDO2 security keys are simpler to implement. Security keys must be registered before they can be used to log in. Providing the FIDO2 security key method is enabled in your Azure AD tenant, users can register security keys in the Security Info section of their profile. Once registered, users can start using security keys to log in.
For more information on enabling FIDO2 security keys in Azure AD and the user registration process, check out Microsoft’s website here.
There’s always a catch. And of course, here it is that organizations must purchase compatible FIDO2 security keys for each user. So, while no complicated infrastructure is required, there is an extra cost to organizations in purchasing and managing the keys.
Many large organizations will already have the infrastructure in place to support Windows Hello for Business. And assuming that users are assigned a permanent device, then it makes sense to consider it a viable option. If the cost of purchasing FIDO2 security keys isn’t a barrier, and you would like to avoid all the infrastructure pieces required for Windows Hello, then security keys could be a good alternative regardless of whether users are assigned a permanent device. FIDO2 security keys are better suited to front line workers, or any users that need to log in to different devices, because of the portability that keys provide.