Passwordless is one of those features that sounds like a single toggle but is actually three separate layers stacked on top of each other, and getting the order wrong is exactly how people lock themselves out of their own tenant. This was a from-scratch passwordless rollout on a solo-admin Microsoft 365 Business Premium tenant — the goal being genuinely simple: type an email address, and go straight to Windows Hello or a passkey, with no password prompt anywhere in the flow.
The three layers
Before touching any settings, it’s worth being explicit about what’s actually being configured, since “passwordless” isn’t one setting:
- Authentication methods policy — controls which credential types even exist and can be registered (passkey, Windows Hello for Business, password, etc.)
- System-preferred authentication — controls which registered credential gets offered first at sign-in. This is the specific thing that makes the password prompt disappear.
- Conditional Access + Authentication Strengths — the actual enforcement layer, controlling what’s required to get in. This is what makes password sign-in genuinely impossible, not just deprioritised.
Layers 1 and 2 alone get you the UX described above. Layer 3 is optional extra hardening for anyone who wants password sign-in to fail outright, not just be hidden.
The platform shift that made this easier
As of the May–June 2026 rollout, Entra ID’s system-preferred authentication now applies to first-factor sign-in, not just the MFA step as before. The ranking, most-preferred first, is:
Temporary Access Pass > Passkey (FIDO2) > Certificate-based authentication
> Microsoft Authenticator > External MFA > TOTP > Telephony > QR code > Password
For any user with a passkey registered, the password prompt no longer appears at all — they’re presented with their phishing-resistant credential immediately. That rollout reached all Microsoft-managed tenants by the end of June 2026, so the main remaining work is registering the right credentials and confirming the policy is set to “Microsoft managed” rather than “Enabled” (which instead requires manually ordering every method by hand).
One dated but relevant platform note: as of 6 July 2026, Conditional Access policies scoped to the Register security information user action now also apply to Windows Hello for Business provisioning. Any existing Conditional Access aimed at that action needs checking before registering anything new, or the registration step can fail silently with no clear error pointing back to the policy.
Step 0 — Break-glass account, before anything else
This is the step that actually matters most for a one-admin tenant, and the one it’s easiest to skip and regret. If a PC’s Windows Hello breaks, a phone with Authenticator is lost or wiped, and there’s no registered backup, a solo admin can lock themselves out of their own tenant with nobody able to let them back in.
Entra admin center → Identity → Users → All users → New user → Create new user
- Named something identifiable but not an obvious admin target (e.g.
brk-glass-admin@yourtenant.onmicrosoft.com), deliberately using the default.onmicrosoft.comdomain rather than the custom domain, so it doesn’t depend on DNS or custom-domain health during an actual emergency - Assigned the Global Administrator role
- Given a long, random password (20+ characters), with no forced change at next sign-in
- Deliberately not given any MFA/passwordless method — this account relies purely on the password as the emergency path
- Credentials written down physically and stored securely — not in a password manager tied to the same identity ecosystem, and not in a note synced to a device that could be the very thing that’s lost
This account then gets explicitly excluded from every Conditional Access policy built later, so it’s never subject to passwordless-only enforcement. A recurring calendar reminder every 6–12 months to actually sign in with it once is worth setting up too — an untested break-glass account is just a hope, not a plan.
Step 1 — Authentication methods policy
Entra admin center → Protection → Authentication methods → Policies
Passkey (FIDO2):
Enable: Yes
Target: All users
Allow self-service: Yes
Enforce attestation: No # enterprise device-trust feature, unnecessary for solo/personal use
Allowed key types: Platform (Windows Hello) + Cross-platform (physical keys, phone passkeys)
Restrict specific keys: Unrestricted
Windows Hello for Business: confirmed enabled, targeted to All users. Since the Windows 11 device was already Entra-joined and Intune-enrolled under Business Premium, this was very likely already provisioning automatically — this step was mostly confirmation rather than a fresh change.
Method state → Microsoft managed: where exposed in the tenant, setting the overall method state to Microsoft managed rather than manually Enabled is what activates system-preferred ranking at first factor specifically. Some tenants don’t yet expose this as an explicit toggle (Microsoft was still rolling the UI out tenant-by-tenant at time of writing) — in that case the underlying first-factor behaviour may already be active regardless, verified empirically in Step 3.
Password itself stays enabled as a method type — there’s currently no way to fully delete it from the authentication methods policy the way SMS or voice call can be disabled. That’s fine: system-preferred ranking handles the everyday UX, and Conditional Access (Step 4) handles genuine enforcement if wanted. Password remains registered on the break-glass account by design.
Temporary Access Pass (TAP) was also enabled for future use, even though not strictly required to bootstrap this particular tenant (there was already a password-based account to start from). TAP sits above even passkeys in the system-preferred ranking — it exists specifically as a “prove who you are without a password” method for scenarios like re-registering a wiped device.
Step 2 — Registering three independent credentials
myaccount.microsoft.com/security-info
Windows Hello for Business — confirmed present under Settings → Accounts → Sign-in options on the Windows 11 device, already tied to the work account courtesy of the existing Intune enrollment. This credential is device-bound; it only ever works on that specific PC, which is fine since it’s the everyday method.
Passkey via Microsoft Authenticator — added via Add sign-in method → Passkey in Microsoft Authenticator, confirmed from the Authenticator app on the phone already used for MFA. Worth noting explicitly: Microsoft Authenticator passkeys are bound to that specific phone, not synced across devices the way Apple’s or Google’s passkey implementations work — which is actually the point here, since it means this credential is genuinely independent of the PC’s Windows Hello rather than a copy of the same trust.
Physical FIDO2 security key — added as a third, deliberately device-independent credential via Add sign-in method → Security key, set up as a USB device with its own PIN. Stored physically separate from daily-use devices, alongside the break-glass credentials, specifically so it’s a genuine fallback rather than a third copy of “stuff sitting on the desk.”
The end state: three independent passwordless credentials — Windows Hello on the PC, an Authenticator passkey on the phone, and a physical key in a drawer.
Step 3 — Verifying the password prompt is actually gone
Tested from a fully signed-out session and separately from an InPrivate window against myaccount.microsoft.com:
- Enter email address only
- Prompted directly for Windows Hello or the passkey — no password field appears anywhere in the flow
Where this didn’t immediately work as expected, the usual causes were the method state not yet being set to Microsoft managed, policy propagation delay (changes to authentication methods can take up to 30–60 minutes to apply tenant-wide), or a browser profile with cached sign-in/autofill behaviour masking the real flow.
Step 4 — Conditional Access enforcement (optional, but implemented)
Layer 3 — the piece that makes password sign-in genuinely impossible rather than just hidden by default.
Entra admin center → Protection → Conditional Access → Policies → New policy
Name: Require phishing-resistant auth - all apps
Users: Include All users
Exclude <break-glass account> # non-negotiable
Target resources: All cloud apps
Conditions: default
Grant: Require authentication strength → Passwordless MFA
Enable policy: Report-only (initially)
Run in report-only mode for a few days, checking Conditional Access → Insights and reporting to confirm the policy would have allowed genuine sign-ins and wouldn’t have unexpectedly blocked anything, before switching Enable policy to On.
One thing worth double-checking given the July 2026 platform change mentioned earlier: if a separate Conditional Access policy is ever built specifically targeting the “Register security information” action, it needs its own report-only testing pass first — otherwise there’s a real risk of blocking the ability to register new credentials on a future device, which is a particularly awkward way to lock yourself out.
Step 5 — Self-service password reset, before September 2026
From 7 September 2026, Entra ID’s SSPR only accepts identity-verification methods that have been explicitly registered — not just contact information sitting passively in the directory profile (a phone number field, for instance, that was never formally registered as an SSPR method).
Entra admin center → Protection → Password reset → Authentication methods
Confirmed which methods SSPR actually requires (e.g. 2 of: mobile app notification, mobile app code, email, phone), then cross-checked against myaccount.microsoft.com/security-info to make sure those specific methods were explicitly registered there, not just present as directory attributes. This matters more once passwordless is live, not less — a working recovery path becomes the thing standing between “locked out” and “fine” if every other credential fails simultaneously.
Ongoing maintenance
- Break-glass account sign-in tested every 6–12 months
- Physical FIDO2 key stored separately from daily-use devices
- SSPR methods explicitly registered ahead of the September 2026 change
- Any future Conditional Access touching the “Register security information” action gets a report-only pass first
- Periodic revisits to the Authentication methods policy, since Microsoft has continued expanding passkey profile limits and management options through 2026
Result
Sign-in is now genuinely two steps — an email address, then Windows Hello or a passkey — with no password field appearing anywhere in the normal flow, backed by three independent passwordless credentials and a tested break-glass path that never touches passwordless enforcement. The Conditional Access layer means this isn’t just a nicer UI hiding the same old password underneath — password sign-in is actually blocked for every account except the one deliberately excluded to prevent a total lockout.