Rolling Out Passwordless Sign-In with Entra ID

Passwords are the weakest link in almost every identity compromise: they get phished, sprayed, reused, and dumped. Passwordless authentication in Entra ID removes the thing attackers are actually after by replacing the password with a phishing-resistant credential bound to a device or a key. This post walks through planning and rolling that out through the Authentication methods policy — which, since the legacy MFA and SSPR policies were retired, is now the single place this all lives.

Key Takeaways

• Passwordless authentication in Entra ID replaces the password with phishing-resistant methods: FIDO2 security keys, passkeys in Microsoft Authenticator, and Windows Hello for Business.
• All authentication methods are now managed in the Authentication methods policy; management in the legacy MFA and SSPR policies was retired on 30 September 2025.
• A Temporary Access Pass gives new or recovering users a time-limited way to register a passwordless method without ever touching a password.
• Roll out by group in waves, starting with a pilot, rather than enabling a method for all users at once.
• Passwordless is strongest when paired with Conditional Access that actually requires phishing-resistant authentication for sensitive access.

Environment

• Entra ID tenant (passwordless methods work on the standard tiers; Conditional Access enforcement needs P1 or higher).
• Microsoft Authenticator for passkeys and phone sign-in, and/or FIDO2 security keys for the highest-assurance users.
• Windows 11 devices for Windows Hello for Business and device-bound passkeys.
• The Authentication Policy Administrator role to manage the Authentication methods policy.

The Problem

Multifactor authentication helped, but it did not solve phishing. A user with a password plus an approve/deny push can still be walked through an adversary-in-the-middle proxy that captures the password and the resulting token, or worn down by MFA fatigue until they approve a prompt they should not. The credential the attacker wants — the password — is still there, still phishable, still the root of the problem.

Passwordless methods change the shape of the attack. A FIDO2 key or a passkey is bound to the legitimate site or relying party and to the user's device; there is no shared secret to type into a fake page. That is why Microsoft, and frankly everyone else, has been pushing hard toward phishing-resistant, passwordless sign-in. The mechanics of getting there are where the work is, and most of that work now runs through one policy.

The Solution

Step 1 — Confirm you are on the Authentication methods policy

Historically, methods were configured in three places: the legacy per-method MFA policy, the SSPR policy, and the newer Authentication methods policy. That split is over. As of 30 September 2025, authentication methods can no longer be managed in the legacy MFA and SSPR policies, and the Authentication methods policy is the single source of truth. If you have not run the migration, do that first — the wizard in the Entra admin center audits your old settings and consolidates them, and the move is reversible.

One caveat to know going in: security questions are not managed in the Authentication methods policy and remain in the legacy SSPR settings. Everything else — Authenticator, FIDO2, voice, SMS, email OTP — is configured under Protection → Authentication methods.

Step 2 — Enable the passwordless methods you intend to use

Under Protection → Authentication methods → Policies, enable the methods that fit your population. The three worth planning around:

• FIDO2 security key / passkey — the strongest, unphishable option. Best for administrators, highly privileged users, and anyone in a regulated role. Hardware keys cost money and create a recovery process when lost, so scope them deliberately.
• Passkeys in Microsoft Authenticator — phishing-resistant and device-bound, with no extra hardware to buy. A good default for the broad workforce that already has the app.
• Windows Hello for Business — biometric or PIN sign-in bound to the device's TPM, already present on managed Windows 11 hardware.

Each method targets specific groups rather than all users. That group targeting is what makes a staged rollout possible instead of a tenant-wide flip.

Step 3 — Issue Temporary Access Passes for onboarding

There is a chicken-and-egg problem with passwordless: to register a passkey, a user normally needs to authenticate first, and if the goal is to never give them a password, what do they authenticate with? The answer is a Temporary Access Pass (TAP) — a time-limited passcode an administrator generates so the user can sign in once and register their real passwordless method. Enable TAP as a method, then issue one per user during onboarding or recovery.

Note that registering a passkey requires the user to have completed multifactor authentication within the last few minutes, which the TAP satisfies. This is the mechanism that lets you onboard a brand-new hire to a passwordless credential without ever minting a password for them to lose.

Step 4 — Drive registration with a campaign and pilot group

Do not enable a method for everyone and hope they register. Start with a pilot group — IT and a friendly business unit — confirm the experience on your actual device fleet, and document the recovery path before widening. For the broad rollout, the registration campaign feature nudges users to set up Authenticator during sign-in, which steadily moves the population onto a stronger method without a hard cutover.

The relationship to your existing identity hardening matters here. If you have already deployed FIDO2 keys, the hybrid sign-in quirks I wrote about in FIDO2 sign-in fails on hybrid joined devices are exactly the kind of edge case a pilot surfaces before it becomes a helpdesk queue. The same goes for key writeback, which I covered in FIDO2 key writeback to AD.

Step 5 — Require phishing-resistant authentication where it counts

Enabling passwordless methods makes them available; it does not make anyone use them, and it does not stop the old password from still working. To get the security benefit, pair the rollout with Conditional Access. Entra ID supports an authentication strength control that can require phishing-resistant MFA for a given set of users or applications:

Conditional Access policy
  Users:        Administrators (pilot: IT group)
  Cloud apps:   All cloud apps  (or the Microsoft admin portals)
  Grant:        Require authentication strength
                -> Phishing-resistant MFA
  Enable:       Report-only  ->  On (after pilot validation)

Start with administrators, who are the highest-value targets and the smallest group to support, then expand. Build this on top of the baseline policies from essential Conditional Access policies for Microsoft 365, and always exclude your break-glass accounts so a strength requirement cannot lock out emergency access.

Frequently Asked Questions

Can I still manage methods in the legacy MFA and SSPR policies?

No. As of 30 September 2025, authentication methods can no longer be managed in the legacy MFA and SSPR policies. The Authentication methods policy is the single place to configure them. The one exception is security questions, which remain in the legacy SSPR settings.

What is a Temporary Access Pass used for?

A Temporary Access Pass is a time-limited passcode an administrator issues so a user can sign in and register a passwordless method without using a password. It solves the onboarding and recovery bootstrap problem and is the cleanest way to get a new hire straight onto a passkey.

Do passwordless methods need an Entra ID P1 or P2 license?

The passwordless methods themselves work on the standard tiers. You need Entra ID P1 or higher only for the Conditional Access policies that enforce phishing-resistant authentication. In practice you want both: the methods to sign in with, and Conditional Access to require them.

Are passkeys in Microsoft Authenticator phishing-resistant?

Yes. Passkeys are bound to the relying party and to the device, so there is no shared secret to capture on a fake page. Combined with the device biometric or PIN, a passkey in Authenticator serves as a phishing-resistant multifactor credential.

How do I stop users from falling back to their password?

Enabling passwordless does not disable the password on its own. You restrict password use with Conditional Access authentication strength requirements, and over time by reducing where password-based sign-in is accepted. The rollout and the enforcement are two separate steps, and you need both.

Conclusion

Passwordless sign-in is one of the few security changes that improves the user experience and the security posture at the same time — no password to remember, and no password to phish. The methods are mature, the Authentication methods policy consolidates the configuration into one place, and Temporary Access Passes solve the awkward bootstrap problem cleanly.

The work is in the rollout discipline, not the technology. Pilot on your real devices, document recovery before you scale, drive registration with a campaign, and enforce phishing-resistant authentication through Conditional Access so the old password stops being a usable path. Do it in that order and passwordless goes from an aspiration to the normal way people sign in.

Related Posts

• FIDO2 Sign-In Fails on Hybrid Joined Devices — The UPN Suffix Trap — a real edge case a passwordless pilot will surface.
• FIDO2 Key Writeback to AD — What msDS-KeyCredentialLink Actually Does — the hybrid plumbing behind FIDO2 sign-in.
• Essential Conditional Access Policies for Microsoft 365 — where you enforce phishing-resistant authentication.

Editorial note: posts on this blog are drafted with AI assistance and then reviewed, edited, and tested against a real environment before publishing. Commands, output, and screenshots come from systems I actually ran the work on.