Going passwordless on Windows, end to end

"Passwordless" sounds like flipping a switch. In practice it's a chain of dependencies where every link has to be in place before the next one is safe to enforce — and the failure mode of getting the order wrong is a user standing at a locked login screen with no way in. This walks the entire deployment: the strategy, user enrollment, Windows enforcement, hiding the password box, and the offline fallback that makes the whole thing survivable.

01The strategy — what "passwordless" actually means

Replace the shared secret with something bound to a person and a device.

The point of passwordless isn't convenience (though it's more convenient) — it's that a password is a shared secret that can be phished, reused, sprayed, and leaked. Passwordless methods replace it with something bound to the user and their hardware, so there's no secret to steal in transit. The supported methods, roughly in order of how you'll deploy them:

Method	What it is	Best for
Authenticator phone sign-in	Approve a number-matched push instead of a password	The broad rollout — everyone has a phone
Windows Hello for Business	Biometric or TPM-backed PIN, device-bound	The Windows sign-in itself + offline fallback
FIDO2 security keys	Hardware key, phishing-resistant	Privileged / high-assurance accounts
Biometrics (Face / fingerprint)	The gesture that unlocks Hello	Devices with the hardware

A realistic deployment layers them: Authenticator phone sign-in for the identity, Windows Hello for Business for the local Windows sign-in and the offline case, and passwords preserved only for a small set of break-glass admin accounts. The rest of this post builds exactly that.

02User enrollment — Authenticator phone sign-in

The self-service flow every user runs once, from their phone.

Before you enforce anything, users need a passwordless credential registered. Phone sign-in is set up entirely in the Microsoft Authenticator app — the user does this once:

# in the Microsoft Authenticator app, on the work account
1. Open the account → "Set up passwordless sign-in requests"
2. Two prerequisite checks appear:
     ✔ Device passcode / Face ID is set
     ⚠ Device registration is required   ← tap Continue
3. Register the device with the organisation when prompted
4. Authenticate once (password + identity verification) to prove it's you
5. Approve the number-matching prompt (type the shown number into the app)
6. Done → "Passwordless sign-in requests" now appears on the account

How to confirm it took

The user can verify under My Sign-Ins → Security info, where Microsoft Authenticator – Passwordless sign-in appears as a registered method distinct from the ordinary push-MFA entry. That's the credential the Windows policy will lean on next. The device-registration step in the middle is the quiet prerequisite — phone sign-in won't enable until the phone itself is registered with the tenant.

03Enforcing it on Windows — the Passwordless Experience policy

An Intune device-configuration profile turns on the passwordless Windows sign-in.

With users enrolled, you enable the passwordless experience on the Windows side via an Intune device configuration profile (Windows), scoped to a pilot group first. Two settings do the work:

Setting	What it does
Enable Passwordless Experience	Lets users sign in to Windows without a password — approving an Authenticator push instead
Enable Web Sign-In	Enables the web-based sign-in screen on Windows — required for Entra ID auth methods (Authenticator, Temporary Access Pass, FIDO2 keys) to work at the lock screen

# Intune → Devices → Configuration → Create profile
Platform:  Windows 10 and later
Type:      Settings catalog (Authentication)
  ✔ Enable Passwordless Experience  → Enabled
  ✔ Enable Web Sign In              → Enabled
Assignments:
  Included groups: "Passwordless Pilot"   ← start scoped, not All users

04Hiding the password box — DisableCredentialProviders

Enabling passwordless doesn't remove the password option. This does.

Turning on the passwordless experience adds passwordless as an option — it doesn't take the password field away. To actually remove the password sign-in UI for scoped users (so they can't fall back to the habit, and the password stops being an attack surface on those machines), you push an OMA-URI custom setting that disables the password credential provider by its CLSID:

# Intune → custom OMA-URI setting
OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Authentication/DisableCredentialProviders
Data type: String
Value:     {60b78e88-ead8-445c-9cf4-d98f5fdbb5a9}
#          ^ the CLSID of the Windows password credential provider

How to read the result

That GUID is the password provider's identifier; listing it in DisableCredentialProviders hides the password field on the sign-in screen for the scoped users. After it applies, those users see the PIN / Authenticator options but no password box. Confirm on a test device before widening scope — and keep this scoped to standard users only (see the admin caveat below).

05The offline fallback — Windows Hello for Business PIN

The step that stops passwordless from locking people out.

Here's the gap that sinks naïve rollouts: passwordless via Authenticator/Web Sign-In needs to reach Entra. Offline, or when the device can't reach Azure, there's no way in — and you've just removed the password. The fix is Windows Hello for Business (WHfB) with a TPM-backed PIN as the local, offline-capable credential. A dedicated Intune policy configures it:

# WHfB PIN fallback — Intune enrollment / Settings catalog
- Configure Windows Hello for Business: Enabled
- Biometrics: not required   ← PIN-only works on devices with no camera/reader
- PIN policy: enforce minimum length, complexity, expiration
- Result: a "keypad" PIN option appears at the Windows sign-in screen

06The end-user experience

Fewer steps, and no secret to phish.

The payoff, side by side — the passwordless flow is both shorter and safer:

Step	Traditional MFA	Passwordless
Sign in	Username + password	Username only
Verify	Get an OTP via text / email / app	Number-matched push on Authenticator
Authenticate	Type the one-time passcode	Approve the notification
Result	Signed in	Signed in — no secret ever typed

Number matching is what makes the push phishing-resistant: the user must type a number shown on the sign-in screen into the app, so a blind "approve" on an attacker-triggered prompt fails. The Windows sign-in ends up offering the PIN keypad, the Authenticator option, and — for scoped standard users — no password field at all.

Anonymized from real deployment work; organisation, account, device, and personal identifiers have been removed. The credential-provider CLSID shown is Microsoft's public, well-known password-provider GUID.