Windows Hello for Business – Phishing-Resistant Authentication for Small Businesses in Berlin
Passwords are the weakest link in enterprise authentication not because they’re hard to create, but because they’re hard to protect at scale. They get phished, sprayed, stuffed, and dumped from memory. Multi-factor authentication adds friction for attackers but doesn’t eliminate the password as a target. Windows Hello for Business (WHfB) eliminates the password entirely for Windows sign-in, replacing it with a device-bound cryptographic key pair authenticated by a PIN or biometric. Because the private key never leaves the device and there’s no password to steal, phishing attacks against Windows sign-in become structurally impossible.
How Windows Hello for Business Works
WHfB is not a PIN replacement for passwords — it’s a fundamentally different authentication mechanism:
- During enrollment, WHfB generates a public/private key pair on the device’s Trusted Platform Module (TPM). The private key is hardware-bound to that specific device and TPM — it cannot be exported
- The public key is registered in Entra ID (for cloud trust) or Active Directory (for on-premises scenarios) against the user account
- When the user authenticates, they unlock the private key using their PIN or biometric (fingerprint/face). The TPM signs an authentication challenge from Entra ID using the private key
- Entra ID verifies the signature against the registered public key and issues an access token
The PIN is a local device secret that unlocks the TPM — it never traverses the network. A stolen PIN from one device is useless without that specific device’s TPM. A phishing page that captures a user’s PIN cannot use it to authenticate to anything outside the victim’s device.
Cloud Kerberos Trust vs. Key Trust vs. Certificate Trust
For hybrid environments (Entra ID + on-premises AD), WHfB supports three trust models:
| Trust Model | PKI Required | AD Domain Controllers | Best For |
|---|---|---|---|
| Cloud Kerberos Trust | No | 2016+ with patch | Hybrid — simplest deployment |
| Key Trust | No | 2016+ required | Hybrid — older DCs not supported |
| Certificate Trust | Yes (PKI required) | Any supported version | Older AD environments with PKI |
For Berlin SMBs on Entra-joined devices (cloud-only, no on-premises AD), only the Entra ID key is registered — there’s no Kerberos consideration. Cloud Kerberos Trust is the recommended model for hybrid environments because it avoids PKI requirements while providing full on-premises resource access.
Deployment via Intune
For Entra-joined devices managed by Intune, WHfB is configured under:
Intune → Devices → Windows → Windows enrollment → Windows Hello for Business
Or via a Configuration Profile: Device configuration → Create → Windows 10 and later → Identity protection template.
| Setting | Recommended Value |
|---|---|
| Configure Windows Hello for Business | Enabled |
| Use a Trusted Platform Module (TPM) | Required |
| Minimum PIN length | 6 digits |
| Maximum PIN length | 127 |
| Allow biometric authentication | Enabled |
| Use enhanced anti-spoofing | Enabled (for facial recognition) |
| Require security key sign-in | Optional (for shared devices or kiosk scenarios) |
Require TPM: this is the critical setting. If TPM is not required, WHfB can be configured to use software-based key storage, which is exportable and significantly weaker. Always require hardware TPM. Modern Windows 11 devices all ship with TPM 2.0.
User Enrollment Experience
After WHfB is enabled via policy:
- On next sign-in, Windows prompts the user to set up Windows Hello (PIN or biometric)
- The user authenticates with their current password/MFA one final time
- WHfB enrollment completes: the key pair is generated in the TPM, the public key is sent to Entra ID
- From this point, the user signs into Windows using PIN or biometric — the password is no longer prompted for Windows sign-in
The user still has an account password in Entra ID (it’s not deleted). But for Windows sign-in specifically, the credential used is the WHfB key, not the password. If the user wants to change their Windows sign-in to a different PIN, they authenticate with their existing PIN — the Entra password is not involved.
WHfB and Phishing Resistance
WHfB meets FIDO2/WebAuthn’s definition of phishing-resistant authentication because:
- The private key is bound to the device and TPM — it cannot be extracted and used elsewhere
- Authentication is tied to the specific Relying Party (Entra ID tenant) — a fake authentication request from a different domain cannot be satisfied with the WHfB credential
- No credential is ever typed into a browser or application where it could be intercepted
This makes WHfB suitable for satisfying Conditional Access policies that require phishing-resistant MFA strength (the Authentication Strength feature in CA that you can configure to require passkey or Windows Hello for Business specifically, rather than accepting any MFA method).
Relationship to SSPR and Password Reset
One confusion point: if a user is signed into Windows with WHfB and their Entra ID password has expired, they’ll be prompted to change their password at next cloud application sign-in — not at Windows sign-in. WHfB insulates Windows sign-in from the password lifecycle, but the Entra ID password still exists and its expiration/self-service reset policies still apply for other authentication contexts (legacy apps, browser sign-ins that haven’t transitioned to passkeys).
For Berlin SMBs looking to move toward a fully passwordless posture, WHfB on endpoints combined with FIDO2 security keys for shared devices and Entra passwordless phone sign-in for mobile users delivers a comprehensive passwordless strategy. WHfB on endpoints is the highest-impact component because it covers the primary workstation authentication use case that represents the majority of daily sign-in events.