βοΈπͺπ»CP - Security - Passwordless Sign-in
Deploying Windows Hello removes the need for a password. This removes the password itself, because a credential nobody can type is a credential nobody can be talked into typing.
What this policy is about πͺβ
Rolling out Windows Hello gets you a device-bound credential. It does not get you a passwordless estate, because the password field is still sitting there on the lock screen, and everything that made the password dangerous still works: it can be phished, reused, shoulder-surfed, or handed over the phone to somebody claiming to be from IT.
This policy takes the field away. On an Entra joined device the password credential provider disappears, and the sign-in screen offers Hello, a security key, or a passkey. Nothing else.
The second half of the policy makes that survivable. Web sign-in lights up the credential provider that accepts a Temporary Access Pass, which is how a brand new user signs in to a brand new laptop when they have no Hello credential yet and, by design, no password to fall back on.
The password still exists in Entra ID and still works elsewhere. This changes what the Windows sign-in screen offers, not what the account can do. That is a meaningful reduction in day-to-day exposure, not an account-level control, and it is worth being precise about when a customer asks whether they are "passwordless now".
Why this matters π΅οΈβ
Most credential theft ends at a password prompt. Somebody phishes one, somebody reuses one, somebody rings the helpdesk with a convincing story and a bit of urgency. Every one of those attacks needs a human who knows a password and can be persuaded to use it somewhere.
Users who have not typed their password in three months are dramatically worse at being socially engineered out of it, and that is not a joke about memory: it is the actual mechanism. The attack surface shrinks because the muscle memory is gone. When a caller asks for it, the honest answer becomes "I genuinely do not know it," which is the best possible outcome from a phishing attempt. π
Web sign-in matters for a smaller but sharper reason. Without it, the onboarding story for a passwordless tenant falls apart at the first laptop: the user cannot use Hello because they have not enrolled it, and cannot use a password because you just hid the field. A Temporary Access Pass plus web sign-in closes that loop, and it doubles as the recovery path when somebody loses their laptop and their key on the same day.
π οΈ Configurationβ
Where: Intune admin center β Devices β Configuration β Create β Windows β Settings catalog β Authentication.
| Setting | Value |
|---|---|
| Enable Passwordless Experience | Enabled |
| Enable Web Sign In | Enabled |
| Assignment, include | π‘οΈπͺπ»βοΈGroup - Windows Devices |
| Assignment, exclude | π‘οΈπͺπ»βοΈGroup - Autopilot Devices - Kiosk, π‘οΈπͺπ»βοΈGroup - Autopilot Devices - Shared, π‘οΈπͺπ»βοΈGroup - Autopilot Devices - IoT |
Deploy Windows Hello first, and confirm it landed. This is the one ordering mistake that turns a good policy into an outage. If the password provider is hidden on a device where nobody has provisioned a Hello credential and no Temporary Access Pass has been issued, that device has no way in. Roll this out behind Windows Hello for Business, to a pilot ring, and check enrolment status before widening.
Web sign-in is what makes Temporary Access Pass usable at the lock screen. Enable the TAP method in Entra ID as well, under Authentication methods; the Windows setting and the tenant method are two halves of the same capability and neither works alone.
Kiosk and shared devices are excluded. They sign in through their own mechanisms, and hiding credential providers on a device with a local kiosk account solves nothing while creating an interesting afternoon.
Caveats β οΈβ
The recovery path has to exist before you need it. In a passwordless tenant, "I cannot get into my laptop" is answered with a Temporary Access Pass, not a password reset. Make sure the helpdesk can issue one, knows where the button is, and understands the default lifetime. A control like this is only as good as the runbook underneath it.
Windows 11 22H2 or later, Entra joined. Hybrid joined devices behave differently and older builds ignore the setting. On a mixed estate you will see it apply cleanly on some machines and do nothing on others, which reads like a bug and is a version boundary.
It is a sign-in screen change, not an account hardening change. The password remains valid for anything that accepts one. If the goal is a genuinely unusable password, that is a separate conversation about phishing-resistant authentication strengths in Conditional Access, and eventually about deleting the password credential altogether.
Some legacy scenarios still want a password field. A local account for break-fix, a device that drops off the network for a long period, an application that prompts for Windows credentials in its own dialog. Test the customer's actual line-of-business software rather than assuming, particularly anything that does its own authentication prompt.
Clean-revert, with a caveat about credentials. Unassign the profile and the password provider comes back at the next policy refresh. What does not roll back is the Hello enrolment that users completed in the meantime, which is fine and is the point.
π₯ Assignment scopeβ
Baseline for 1:1 Windows devices in tenants where Windows Hello is deployed and confirmed working, including Cloud PCs. Kiosk, shared and IoT builds are excluded structurally.
This is a policy to stage rather than switch on fleet-wide. Pilot ring first, verify Hello enrolment and TAP issuance actually work end to end, then widen. The failure mode is not subtle: a user locked out of a laptop with no way in is a phone call, not a ticket.
Worth verifying at tenant takeover: whether Temporary Access Pass is enabled as an authentication method at all. Plenty of tenants have never turned it on, and it is the prerequisite that makes the rest of this safe.
π Relatedβ
- π§±πͺπ»ES - Windows Hello for Business: the credential that has to be in place before this policy is safe.
- ππ§βπΌAMP - Authentication Methods: where Temporary Access Pass, FIDO2 and passkeys are enabled tenant-side.
- ππ§βπΌAS - Authentication Strengths: how to require those methods rather than merely offer them.
The safest password is the one the user has forgotten. This is how you get there without stranding anybody on day one. πͺ