This chapter covers Windows Hello for Business and FIDO2 security key authentication, two cornerstone technologies for passwordless identity in Microsoft's ecosystem. For the SC-900 exam, these topics appear in roughly 10-15% of questions under objective 2.2 (Identity Access). You must understand the cryptographic mechanisms, deployment prerequisites, and how they eliminate password-related vulnerabilities. We will dissect the protocol flows, default configurations, and common exam traps.
Jump to a section
Imagine a hotel where each guest receives a physical key card to access their room. That key card is like a traditional password—something you have and know. But if you lose the card, anyone can use it. Now upgrade to a biometric room lock that scans your fingerprint. You don't carry a card; your finger is your key. The lock stores a mathematical hash of your fingerprint, not the actual image. When you place your finger, the lock computes the hash and compares it to the stored one. If it matches, the door unlocks. This is Windows Hello for Business: your biometric (or PIN) is the key, and it never leaves your device. The hash is stored in the Trusted Platform Module (TPM) chip, which is like a tamper-proof safe inside the lock. Even if someone steals the door, they cannot extract your fingerprint. For FIDO2, imagine the hotel has a digital key stored on your phone that uses Bluetooth to unlock the door. The door verifies the key using public-key cryptography. Your phone proves possession of the private key without revealing it. This eliminates the need for a password altogether. Both methods share the same principle: the secret never leaves your possession, and the server only stores a public key, not a password.
What Are Windows Hello for Business and FIDO2?
Windows Hello for Business (WHfB) is a passwordless authentication method integrated into Windows 10/11 and Azure AD. It replaces passwords with a PIN or biometric gesture (fingerprint, facial recognition). The key insight: the PIN or biometric is used only to unlock a private key stored in the device's Trusted Platform Module (TPM) chip. The private key never leaves the device. The corresponding public key is registered with Azure AD or on-premises Active Directory. When authenticating, the device proves possession of the private key via a cryptographic challenge-response, not by sending the PIN or biometric over the network.
FIDO2 (Fast IDentity Online 2) is an open standard for passwordless authentication using external security keys (USB, NFC, Bluetooth) or platform authenticators (e.g., Windows Hello, Apple Touch ID). It consists of the WebAuthn (Web Authentication) API and CTAP (Client-to-Authenticator Protocol). Microsoft supports FIDO2 for Azure AD join and hybrid Azure AD join devices. Users can sign in with a FIDO2 security key that contains a private key generated on the device. The server only stores the public key.
Why Passwordless? The Problem with Passwords
Passwords are the weakest link in identity security. They are:
Phishable: Users can be tricked into entering credentials on fake sites.
Reused: 65% of people reuse passwords across multiple sites.
Weak: Many passwords are easily guessable.
Stolen: Databases of password hashes are frequently breached.
Passwordless methods like WHfB and FIDO2 eliminate these risks because:
The secret (private key) never leaves the device.
The PIN or biometric is local only and never transmitted.
Phishing attacks are ineffective because the cryptographic challenge is bound to the specific relying party (RP) origin.
How Windows Hello for Business Works Internally
WHfB uses asymmetric key pair generation. The process is:
Key Generation: When a user enrolls, Windows generates a public/private key pair inside the TPM. The TPM is a hardware security module that protects the private key from extraction. If no TPM is available, software-based key storage is used (less secure, not recommended for enterprise).
PIN or Biometric Binding: The user sets a PIN or provides a biometric sample. This gesture is used to encrypt the private key. The PIN is hashed and stored as a hash in the TPM. The biometric template is stored as a mathematical representation (not the original image) in the TPM or a secure enclave. The gesture unlocks the private key for use.
Registration: The public key is sent to Azure AD or Active Directory during registration. The server stores the public key and associates it with the user's account. The server never receives the private key or the PIN.
Authentication: When the user signs in:
The device sends a request to the server.
The server sends a cryptographic challenge (a random nonce).
The device prompts the user for their PIN or biometric.
The TPM uses the PIN/biometric to decrypt and access the private key.
The device signs the challenge with the private key.
The signed challenge is sent to the server.
The server verifies the signature using the stored public key.
If valid, the user is authenticated.
This is a challenge-response protocol. The PIN or biometric is never sent over the network, preventing credential theft.
Key Components and Default Values
TPM: Required for enterprise-grade WHfB. TPM 2.0 is recommended. TPM 1.2 is supported but deprecated.
PIN Complexity: Default policy requires a minimum of 4 characters, but enterprise policies can enforce length, complexity, and expiration. The PIN can include letters, numbers, and special characters.
Biometric: Windows Hello supports fingerprint, facial recognition (IR camera), and iris scan. The biometric data is stored locally in the TPM or secure enclave, never in the cloud.
Certificate vs. Key: WHfB can use either a certificate (for on-premises AD) or a key (for Azure AD). The key-based approach is more common for cloud scenarios.
Hybrid Deployment: For hybrid scenarios, WHfB requires Azure AD Connect to sync the public key to on-premises AD. The key is stored in the user's msDS-KeyCredentialLink attribute.
How FIDO2 Works Internally
FIDO2 authentication follows a similar asymmetric key model but is standardized across platforms.
Attestation: During registration, the authenticator (security key or platform) generates a new key pair. It sends the public key to the server along with an attestation certificate that proves the authenticator is genuine (e.g., from a trusted manufacturer). The server stores the public key.
Assertion: During authentication, the server sends a challenge. The authenticator signs the challenge with the private key. The user must provide a gesture (e.g., touch the key, enter PIN, use biometric) to authorize the operation. This is called user verification.
3. User Verification Methods: - None: Just touch the key (no PIN). Less secure. - PIN: Enter a PIN on the key itself. - Biometric: Fingerprint on the key.
4. Resident vs. Non-Resident Keys: - Resident (discoverable) credentials: The private key is stored on the authenticator. The user can sign in without a username by selecting the credential from a list. - Non-resident credentials: The private key is derived from a master key and a relying party ID. The user must provide a username to locate the credential.
Microsoft's Implementation of FIDO2
Microsoft supports FIDO2 for Azure AD joined and hybrid Azure AD joined devices. The security key must be FIDO2 certified (e.g., YubiKey, Feitian, Microsoft-compatible keys). The key can be used to sign in to Windows, Microsoft 365, and Azure AD applications.
Azure AD Registration: Users register their FIDO2 key via the Microsoft Authenticator app or the Security Info page in My Security Info. The public key is stored in Azure AD.
Windows Sign-In: On a Windows 10/11 device that is Azure AD joined, the user can insert the FIDO2 key and touch it to sign in. This requires the key to support FIDO2 and the Windows Hello sign-in option to be enabled.
Browser-Based Authentication: FIDO2 works in browsers that support WebAuthn (Edge, Chrome, Firefox). The user can authenticate to websites without a password.
Configuration and Verification Commands
For WHfB, administrators can configure policies via Group Policy or Microsoft Intune. Key settings include: - Enable Windows Hello for Business: Policy setting under Computer Configuration > Administrative Templates > Windows Components > Windows Hello for Business. - Use biometrics: Policy setting to allow or disallow biometric authentication. - PIN complexity: Policy settings for minimum length, expiration, history, etc.
To verify WHfB status on a client:
Get-WmiObject -Namespace root\cimv2\Security\MicrosoftTpm -Class Win32_TpmTo check if TPM is ready:
Get-TpmFor FIDO2, administrators can enable or disable via Azure AD blade > Security > Authentication methods > FIDO2 security keys. They can target specific users or groups. The policy allows setting: - Allow self-service registration: Users can register their own keys. - Enforce attestation: Require security keys to have attestation certificates from trusted manufacturers.
Interaction with Related Technologies
Microsoft Authenticator App: Can serve as a passwordless authenticator using phone sign-in (similar to WHfB but on mobile). The app generates a key pair and uses the phone's biometric or PIN to unlock.
Azure AD Passwordless: WHfB and FIDO2 are two of three passwordless methods (the third is Microsoft Authenticator). They can be used together or individually.
Conditional Access: Administrators can require passwordless authentication for specific apps or locations using Conditional Access policies. For example, require FIDO2 for all cloud apps when accessing from untrusted networks.
Security Considerations
TPM Requirements: If a device lacks TPM, WHfB falls back to software-based key storage, which is less secure. The exam may test that TPM 2.0 is the recommended minimum.
PIN vs. Biometric: Biometric data is more convenient but can be spoofed with high-quality replicas. PINs are generally more secure because they are not biological and can be changed. The exam may ask which is more secure: PIN (because it's not biometric).
Attestation: FIDO2 attestation ensures the security key is genuine. Without attestation, a rogue key could be used. The exam may test that attestation is optional but recommended.
Resident Keys: For roaming scenarios (signing in on different devices), resident keys allow the user to authenticate without typing a username. Non-resident keys require the username. The exam may ask about this difference.
Exam-Specific Details
WHfB requires TPM for enterprise use: The exam may present a scenario where a device lacks TPM and ask if WHfB can be used. The answer is yes, but with reduced security.
WHfB PIN is not a password: The PIN is tied to the specific device and cannot be used on another device. This is a key distinction.
FIDO2 keys can be used across multiple devices: Because the private key is stored on the physical key, the user can plug it into any compatible device.
Both methods protect against phishing: Because the challenge is bound to the relying party origin, a fake website cannot reuse the authentication.
Common Misconfigurations
Not enabling TPM in BIOS: Some systems have TPM disabled by default. WHfB will fail to enroll.
Using software TPM: Virtual machines may have a software TPM, which is acceptable but less secure.
Not syncing public keys to on-prem AD: In hybrid deployments, if Azure AD Connect is not configured to sync the msDS-KeyCredentialLink attribute, on-premises authentication will fail.
Setting PIN policy too restrictive: If the PIN policy requires symbols that the TPM does not support, enrollment may fail.
Summary of Protocol Flow (WHfB)
User enrolls: Device generates key pair in TPM. PIN/biometric binds to private key. Public key sent to Azure AD.
User signs in: Server sends challenge. User provides PIN/biometric. TPM signs challenge with private key. Server verifies with public key.
The PIN/biometric never leaves the device. The private key never leaves the TPM.
Summary of Protocol Flow (FIDO2)
User registers security key: Key generates key pair. Public key sent to server with attestation. Server stores public key.
User authenticates: Server sends challenge. User inserts key and provides gesture. Key signs challenge with private key. Server verifies with public key.
The private key never leaves the security key. The gesture authorizes use of the key.
User initiates enrollment in Windows Hello for Business
The user opens Settings > Accounts > Sign-in options and selects 'Windows Hello PIN' or 'Fingerprint' etc. The system checks for TPM availability. If TPM 2.0 is present, it initializes the TPM for key generation. If no TPM, it falls back to software key storage. The user is prompted to create a PIN (minimum 4 characters by default, but enterprise policy may require more). The PIN is hashed and stored in the TPM. A biometric sensor may be enrolled at this stage, capturing multiple images to create a template stored in the TPM. The system then generates an asymmetric key pair (RSA 2048-bit or ECDSA P-256) inside the TPM. The private key is encrypted with the PIN hash. The public key is exported and sent to Azure AD during registration.
Public key registration with Azure AD
The device sends the public key along with a device identifier and user identifier to Azure AD. Azure AD stores the public key in the user's authentication methods. The key is associated with the specific device. The server also stores metadata like the key ID and attestation if available. This step completes enrollment. The user can now use WHfB to sign in. The server never receives the private key or the PIN. The registration is secured by TLS. If the user is hybrid, the public key is also synced to on-premises Active Directory via Azure AD Connect, stored in the msDS-KeyCredentialLink attribute.
User initiates sign-in with WHfB
The user locks or restarts the computer. On the login screen, they select the Windows Hello sign-in option (PIN or biometric). The system sends an authentication request to Azure AD. Azure AD generates a random challenge (nonce) and sends it to the client. The client presents a prompt to the user for their PIN or biometric. The user provides the gesture. The TPM uses the PIN hash to decrypt the private key. The private key signs the challenge. The signed challenge is sent back to Azure AD. Azure AD retrieves the user's public key and verifies the signature. If valid, Azure AD issues an access token. The user is logged in. The entire process takes less than a second.
User registers a FIDO2 security key
The user goes to My Security Info (https://mysecurityinfo.microsoft.com) and selects 'Add sign-in method' > 'Security key'. They insert the FIDO2 key and touch it. The browser initiates WebAuthn registration. The security key generates a new key pair. The private key is stored on the key. The public key is sent to Azure AD along with an attestation certificate (if the key supports attestation). Azure AD stores the public key. The user may be prompted to set a PIN on the key if not already set. The key is now registered and can be used for passwordless sign-in.
User signs in with FIDO2 security key
On a supported device (Azure AD joined, Windows 10/11), the user inserts the FIDO2 key and touches it. The device sends an authentication request to Azure AD. Azure AD sends a challenge. The key signs the challenge using the private key. The user may need to enter the key's PIN or touch a biometric sensor on the key (user verification). The signed challenge is sent to Azure AD. Azure AD verifies the signature with the stored public key. If valid, the user is authenticated. The key can be used across multiple devices as long as the key is inserted. FIDO2 supports both local and remote authentication via WebAuthn.
Enterprise Scenario 1: Large Organization Migrating to Passwordless
A multinational corporation with 50,000 employees wants to eliminate passwords to reduce phishing risks. They deploy Windows Hello for Business on all Windows 10/11 devices using Microsoft Intune. They require TPM 2.0 on all new devices and enable biometric authentication for convenience. They configure PIN policies: minimum 6 characters, no expiration, but with lockout after 5 failed attempts. They also enable FIDO2 security keys for users who need to sign in on shared kiosks or non-Windows devices. The deployment is phased: first IT staff, then executives, then general users. Common issues: users forgetting PINs (solved by self-service recovery via Microsoft Authenticator), TPM not enabled in BIOS (solved by remote configuration via Intune), and hybrid users unable to authenticate on-premises because Azure AD Connect was not syncing the msDS-KeyCredentialLink attribute. The organization sees a 90% reduction in password reset tickets within 6 months.
Enterprise Scenario 2: Healthcare Provider with Shared Workstations
A hospital uses shared workstations for nurses and doctors. Passwords are frequently shared, leading to audit failures. They deploy FIDO2 security keys (YubiKey 5 NFC) for each staff member. The keys are registered in Azure AD and are used to sign in to Windows 10 devices and electronic health record (EHR) applications. The keys require a PIN for user verification. Because the keys are portable, staff can sign in at any workstation by inserting their key and entering their PIN. This ensures individual accountability. The IT team configures Conditional Access to require FIDO2 for access to the EHR app. Performance is excellent; sign-in takes under 3 seconds. The main challenge is key loss: users are trained to report lost keys immediately, and admins revoke the key from Azure AD. The hospital also uses biometric WHfB on fixed workstations for faster access, but FIDO2 is preferred for roaming.
Common Misconfigurations and Pitfalls
Not enabling TPM in firmware: Many enterprise PCs ship with TPM disabled. Without TPM, WHfB uses software keys, which are less secure and may not meet compliance. Admins must enable TPM via BIOS or remote management.
Overly restrictive PIN policies: Setting PIN complexity too high (e.g., requiring special characters and 8+ characters) leads to user frustration and increased support calls. Microsoft recommends a balance: minimum 4-6 characters, no forced expiration.
FIDO2 key attestation not enforced: Without attestation, users could register non-compliant keys. In regulated industries, attestation is required to ensure keys are from trusted manufacturers. Admins should enable attestation in Azure AD authentication methods policy.
What SC-900 Tests on This Topic
SC-900 objective 2.2 covers 'Describe the capabilities of Azure AD authentication including Windows Hello for Business and FIDO2 security keys.' The exam tests your understanding of:
The mechanism: asymmetric key pair, challenge-response, private key never leaves device.
The difference between WHfB (device-bound) and FIDO2 (key-bound).
The requirement of TPM for enterprise WHfB.
The fact that both methods are phishing-resistant.
That WHfB PIN is device-specific, while FIDO2 key can be used on multiple devices.
That WHfB supports biometrics, but the PIN is the fallback.
Common Wrong Answers and Why Candidates Choose Them
'Windows Hello for Business requires biometric hardware.' Wrong. WHfB works with a PIN alone. Biometrics are optional. Candidates confuse consumer Windows Hello (which requires biometric) with WHfB.
'FIDO2 security keys store the private key in Azure AD.' Wrong. The private key is stored on the security key. The server only stores the public key. Candidates think of traditional password storage.
'WHfB sends the PIN to Azure AD for verification.' Wrong. The PIN is used locally to unlock the private key. The signature is sent, not the PIN. Candidates don't understand the challenge-response flow.
'Both WHfB and FIDO2 require Azure AD Premium P1.' Wrong. WHfB and FIDO2 are available with any Azure AD license (free, P1, P2). However, some advanced policies like Conditional Access require P1/P2. Candidates often overestimate licensing requirements.
Specific Numbers and Terms on the Exam
TPM 2.0 is the recommended version. TPM 1.2 is supported but deprecated.
PIN minimum length default is 4 characters, but enterprise can set higher.
FIDO2 stands for Fast IDentity Online 2.
WebAuthn is the W3C standard for web authentication.
Attestation is the proof that the security key is genuine.
Resident key (discoverable credential) allows passwordless sign-in without username.
Edge Cases and Exceptions
If TPM is not available, WHfB can use software key storage, but it's less secure and not recommended for enterprise. The exam may ask if WHfB can be used without TPM: answer is yes, but with security caveat.
FIDO2 on mobile devices: Mobile devices can act as FIDO2 authenticators via Bluetooth or NFC. Microsoft Authenticator supports this.
Hybrid deployments: WHfB public keys must be synced to on-prem AD for hybrid users. The exam may test that Azure AD Connect is required.
How to Eliminate Wrong Answers
If an answer says the private key is stored in the cloud, eliminate it.
If an answer says the PIN is transmitted over the network, eliminate it.
If an answer says biometric is required for WHfB, eliminate it.
If an answer says FIDO2 keys are tied to one device, eliminate it (they are portable).
If an answer says WHfB requires Azure AD Premium, eliminate it (free tier works).
Windows Hello for Business uses asymmetric key pairs; private key stored in TPM, never leaves device.
FIDO2 security keys generate key pairs on the key; private key never leaves the key.
Both methods are phishing-resistant because the challenge is bound to the relying party origin.
WHfB requires TPM 2.0 for enterprise-grade security; software fallback is less secure.
WHfB PIN is device-specific; FIDO2 key is portable across devices.
WHfB supports biometrics but does not require them; PIN is always available.
FIDO2 attestation verifies the security key is genuine; optional but recommended.
Both methods work with Azure AD free tier; Conditional Access policies may require Premium.
These come up on the exam all the time. Here's how to tell them apart.
Windows Hello for Business
Private key is stored in device TPM; tied to a specific device.
Uses PIN or biometric (fingerprint, face) to unlock key.
Integrated into Windows; no external hardware required.
Best for single-user devices (laptops, desktops).
Public key registered in Azure AD or on-prem AD.
FIDO2 Security Keys
Private key is stored on the physical security key; portable across devices.
Uses touch, PIN on key, or biometric on key to authorize.
Requires external hardware (USB, NFC, Bluetooth key).
Best for shared workstations, kiosks, or multi-device users.
Public key registered in Azure AD; supports WebAuthn.
Mistake
Windows Hello for Business requires a biometric sensor.
Correct
WHfB works with a PIN alone. Biometrics (fingerprint, facial recognition) are optional. The PIN is the default and most secure method because it is not biometric and can be changed.
Mistake
FIDO2 security keys store the private key in Azure AD.
Correct
The private key is generated and stored on the security key itself. Only the public key is sent to Azure AD during registration. This is fundamental to the asymmetric key model.
Mistake
Windows Hello for Business sends the PIN to Azure AD for verification.
Correct
The PIN is used locally to unlock the private key stored in the TPM. The device signs a challenge with the private key and sends the signature to Azure AD. The PIN never leaves the device.
Mistake
FIDO2 security keys can only be used on one device.
Correct
FIDO2 keys are portable. The private key is stored on the physical key, so it can be inserted into any compatible device (Windows, macOS, Linux, mobile) to authenticate.
Mistake
Windows Hello for Business requires Azure AD Premium P1 or P2.
Correct
WHfB is available with any Azure AD license, including the free tier. However, advanced features like Conditional Access policies that require WHfB may need Premium licenses.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, but with reduced security. Without TPM, the private key is stored in software, making it more vulnerable to extraction. Microsoft recommends TPM 2.0 for enterprise deployments. The exam tests that TPM is required for the most secure implementation.
A WHfB PIN is tied to the specific device and is used to unlock the private key stored in the TPM. It is never sent over the network. A password is shared across devices and is transmitted during authentication. The PIN is local; the password is network-based.
Yes, on Azure AD joined or hybrid Azure AD joined devices. The user inserts the key and touches it. The device must support FIDO2 authentication. This is enabled via the Windows Hello sign-in option.
No, both are available with any Azure AD license, including free. However, Conditional Access policies that enforce their use may require Azure AD Premium P1 or P2.
Attestation is a certificate from the security key manufacturer that proves the key is genuine. During registration, the key sends an attestation certificate along with the public key. The server can verify the certificate against a trusted list. This prevents rogue keys.
No. Biometric data (fingerprint template, face mesh) is stored locally in the TPM or secure enclave. It never leaves the device. Only the public key is sent to Azure AD.
Yes. A user can register multiple authentication methods. They can choose which to use at sign-in. This provides flexibility: WHfB for their primary device, FIDO2 for shared or temporary devices.
You've just covered Windows Hello for Business and FIDO2 — now see how well it sticks with free SC-900 practice questions. Full explanations included, no account needed.
Done with this chapter?