Trackr.Live The landing site for Trackr Services
§ AC

Microsoft’s passwordless-by-default shift: what Entra admins and home users need to know

By AutoCypher ·

The password box is going away. Not as a policy you opt into, not as a checkbox buried in authentication methods — as the default behavior for every Microsoft-managed Entra tenant, rolling in now and fully deployed by the end of June 2026. If a user has a passkey registered, the first-factor sign-in prompts for the passkey instead of the password. The password prompt simply doesn’t render for that user. That’s the change worth planning around, and most shops haven’t written the helpdesk comms yet.

This is the natural endpoint of a pivot Microsoft has been pushing for over a year under the name system-preferred authentication. The idea is mechanical and mostly sensible: the platform offers the strongest method the user has registered rather than letting them fall back to whatever’s most convenient. What’s new as of May 2026 is that the “Microsoft managed” default state — the one every user is in unless an admin says otherwise — now applies system-preferred logic to the first factor, not just the second. Up to now it steered the MFA step. Now it steers the whole sign-in.

The credential ranking, and why CBA moving matters

System-preferred authentication picks the method by a documented ranking. In the Microsoft-managed state the order is: Temporary Access Pass, passkey (FIDO2), certificate-based auth, Authenticator push notifications, external MFA, TOTP, telephony, QR code, and password dead last.

The one that changed recently is CBA. It moved from the bottom of the list to position three on March 18, 2026, after the earlier issues that kept it parked at the end were resolved. If you run a CAC/PIV shop or anything else leaning on certificate-based auth, that reordering is the difference between CBA being the offered method and being the thing nobody ever reaches. Worth a look at your sign-in logs after the cutover to confirm the offered-method distribution matches what you expect — SignInLogs with the authenticationDetails field expanded, assuming your retention covers the window (and assuming the field actually populated, which it does not always do cleanly on guest/B2B sign-ins).

The ranking maps straight onto IA-2 and IA-5. Phishing-resistant MFA at the top, passwords at the bottom by design, is IA-2(1)/(2) and the phishing-resistant enhancement made into platform default rather than a control you have to assert and assess separately. That’s genuinely useful for an ATO package — but only if your authenticator-management lifecycle under IA-5 actually keeps up, which is where the provisioning surface gets messy.

Passkey types and the policy cap nobody reads until it bites

Two flavors of passkey, and the distinction drives your policy decisions. Device-bound passkeys keep the private key on one device and never let it leave — Microsoft Authenticator, FIDO2 security keys, and Entra passkey on Windows all fall here. Synced passkeys get an encrypted key replicated through a cloud provider like iCloud Keychain or Google Password Manager. Synced passkeys and passkey profiles hit GA in March 2026.

Here’s the catch that decides privileged-vs-general policy: synced passkeys do not support attestation. Attestation is enforced at the passkey-profile level, and when you turn it on, only device-bound passkeys are allowed. So for your admins, your break-glass accounts, anyone touching a privileged role — attestation on, device-bound only, synced excluded. For general users where you care more about adoption than provenance, synced is fine and frankly will get more people off passwords faster.

The Passkey (FIDO2) policy has a 20-KB size limit, and this used to be a shared budget across all auth methods. In May 2026 Microsoft gave passkeys a dedicated 20-KB allocation and raised the max passkey profiles per tenant from 3 to 10. If you tried to do granular AAGUID allow-listing before and ran into the size ceiling, that constraint just got a lot looser.

One documentation gotcha: the older “how to enable passkey” Learn page still says you can have up to three profiles. That page is lagging. The What’s New changelog is the current source; trust the changelog over the how-to page on this one.

Entra passkey on Windows is the piece moving from preview to GA between April and roughly mid-June 2026. It lets a user register a device-bound FIDO2 passkey stored in the local Windows Hello container, and it does not require the device to be Entra joined or registered. One PC can hold passkeys for multiple Entra accounts. It needs admin opt-in — you add the Windows Hello AAGUIDs to a passkey profile allow list. For BYOD-adjacent scenarios and contractors on unmanaged machines, that’s a real unlock, but treat the AAGUID allow list as a control surface, not a formality.

Break-glass accounts are not exempt. Read that again

Mandatory MFA enforcement is the other half of this story, and it has no opt-out. Phase 1 started October 2024 for the Azure portal, Entra admin center, and Intune admin center — any CRUD operation. The Microsoft 365 admin center followed in February 2025. Phase 2 began October 1, 2025 and covers Azure CLI, Azure PowerShell, the Azure mobile app, IaC tooling, and REST API endpoints, again on any Create/Update/Delete. Reads are exempt. CUD is not. If you’re genuinely blocked, Phase 2 is postponable per tenant to July 1, 2026 via aka.ms/postponePhase2MFA — but that’s a stay of execution, not a pardon.

The part that catches people: your emergency-access accounts are not exempt either. The old playbook of a couple of cloud-only break-glass accounts with long random passwords and nothing else is dead. Move them to a phishing-resistant passwordless method — Passkey (FIDO2) is the recommendation, or CBA if that fits your PKI — and keep at least two of them. Exclude them only from Conditional Access policies that block or restrict sign-in. Report-only policies don’t need the exclusion, and you don’t protect the account by excluding it from everything; the phishing-resistant credential is what protects it. That’s AC-2 account management talking directly to IA-5.

Phase 2 also breaks automation that signs in as a user. Any service account authenticating as a human — the unattended script that’s been running as svc-reporting@ since 2021 because someone needed it working by Friday — gets blocked on CUD operations. Move those to managed identities or service principals. If you can’t before the deadline, postpone, but put the migration on the board because July 1, 2026 arrives whether the work is done or not.

TAP — Temporary Access Pass — is the workhorse for both onboarding and recovery. It’s a time-limited passcode, single- or multi-use, that bootstraps passwordless methods and rescues a user who’s lost their only strong method. Pair it with an authentication-methods registration campaign that nudges users to set up Authenticator or a passkey during sign-in. The campaign is the cheapest way to get registration coverage up before the first-factor change lands and people start asking where the password went.

Gate sensitive apps with Conditional Access authentication strengths rather than trusting the tenant default. Three are built in — Multifactor, Passwordless MFA, Phishing-resistant MFA — and custom strengths are available. Requiring Phishing-resistant MFA on your crown-jewel apps is a cleaner control story than hoping system-preferred logic does the right thing globally.

Expect the first week after the first-factor rollout to be noisy on the helpdesk. “The password box disappeared” tickets, users who registered a passkey on a phone they left at home, kiosk and shared-device edge cases where the device-bound model doesn’t fit the usage pattern. Carve out the shared/kiosk scenarios deliberately before the cutover rather than reacting to the ticket flood.

Home users: the wind-down already bit

New personal Microsoft accounts — Outlook.com, Xbox, Microsoft 365 Personal — default to passwordless creation. Announced May 1, 2025 on the first World Password Day, the flow lets you stand up an account without ever choosing a password, using a passkey, biometric, or PIN with a one-time code as the interim factor. Existing personal accounts keep their passwords but get steered hard toward passkeys.

The change that actually hurt people, though, wasn’t account creation. It was Authenticator’s password manager going away. The timeline, roughly: June 2025, Authenticator stopped accepting new or imported passwords. July 2025, autofill stopped and stored payment info was deleted outright. Mid-August 2025, saved passwords and addresses became inaccessible inside the app. The passwords survive in your Microsoft account and in Edge; the payment cards are gone for good. Anyone who’d been using Authenticator as their primary password vault had to export to a third-party manager or move to Edge before mid-August or lose access to their own credentials.

For a home user the real risk now is recovery. Passwordless is great until you lose the one device that holds your only passkey and have nothing else enrolled. The fix is boring and non-negotiable: register a second method. A second passkey on a second device, or a recovery path you’ve actually tested. Don’t be the person with a single device-bound passkey and no fallback.

On the “governance convergence” framing

A widely-circulated op-ed reads all of this as part of a larger convergence — identity, data protection, and cloud-resource governance collapsing onto one policy plane, with Entra Agent ID and sensitivity labels extending to govern security groups. Treat that as direction-of-travel commentary. The Entra Agent ID GA date and the sensitivity-labels-govern-security-groups claim could not be confirmed against Microsoft primary sources, so if you’re citing them, cite them as that op-ed’s framing, not as Microsoft fact. The passwordless mechanics in this post are documented. The convergence thesis is a reasonable read of the trajectory, not a shipped feature set.

The concrete action items don’t depend on the thesis being right. Get break-glass onto phishing-resistant credentials, kill the service accounts authenticating as users, decide synced-vs-device-bound per privilege tier, and write the helpdesk comms before the password box vanishes in June.

Sources