Microsoft Entra Is Going Passwordless. Here's the Identity Verification Gap You Have to Close.
Finn Jensen | Founder, FastPasscorp
Passkeys are the right destination. But a passkey is something a user has — and the moment they don't have it, there's nothing to "reset." They have to be verified another way, at the help desk or in self-service. That verification is now the weakest link in your identity chain, it's the workflow attackers actually target, and Microsoft's Entra timeline is about to push far more people through it. This post explains what's changing, where passkeys fall short today, and how to make identity verification strong enough to carry the load.
- Microsoft Entra makes passkeys the default sign-in method on September 1, 2026, and retires Microsoft-provided SMS and voice authentication on February 1, 2027 — no opt-out.
- A passkey is a device-bound credential. When a user loses, breaks, or can't reach their device, it cannot be reset — the only path back is to re-verify the person and issue a new credential or a Temporary Access Pass (TAP).
- That re-verification runs through the help desk or self-service — the exact workflow behind recent breaches at MGM, Clorox, and Marks & Spencer.
- Passkeys don't cover everything. On-premises Active Directory, SAP, Oracle, mainframe, legacy apps, and many frontline workers still depend on passwords and manual verification — and will for years.
- FastPass secures identity verification at the help desk and in self-service — before an agent issues a TAP, re-enrolls a passkey in Entra, or resets a password that isn't going away.
We agree on the destination: passwordless is the right goal
Let's be clear up front, because this is not a "passkeys are bad" argument. Passkeys are one of the best things to happen to enterprise security in twenty years. They're phishing-resistant, they can't be reused across sites, and they can't be lifted from a breach database. Microsoft moving Entra ID to passkey-by-default is the right call, and organizations should keep going.
The problem isn't the destination. It's the assumption that arriving there makes identity verification someone else's problem. It doesn't. Passwordless doesn't remove the need to verify who someone is — it relocates that need to a smaller number of higher-stakes moments. And most organizations haven't hardened those moments.
A passkey is something you have — and sometimes you don't have it
A password is something you know: a shared secret that can be transmitted and reset over a channel. A passkey is something you have: a private key bound to a device that, by design, never leaves it. That non-exportability is exactly what makes it strong — and exactly what makes the word "reset" meaningless. When the device is gone, there is nothing to re-issue. The only way back in is to prove who the human is through another channel and bind a new credential.
So the question that decides your security is no longer "how strong is the login?" It's "how do you verify someone when they can't log in?" Here's what that looks like on an ordinary Tuesday:
- The graze. A fingerprint reader won't read a plastered finger, and the phone that could approve the sign-in is on the kitchen table at home. Nothing is lost or stolen — the user simply can't authenticate, and has to be verified another way.
- The stolen phone. A sales director's phone is lifted in an airport in another country. The passkey lived on that phone. They have a meeting in three hours and no way to prove, to a voice on a helpline, that they are who they say they are.
- The new joiner. A first-day hire can't register a passkey until they're signed in, and can't sign in until they've registered a passkey. Someone has to verify them before the first credential is ever issued.
- The executive on a new laptop. Twenty minutes before a board call, on a new device the old passkey never migrated to. They call the help desk, give their name and title, and make clear they're senior and in a hurry — the exact call an attacker rehearses.
In every one of these, the credential is missing, so the credential can't help. Identity verification is the only control left.
What Microsoft is changing — and when (opens in new tab)
Microsoft has put this on a fixed, public calendar for tens of thousands of Entra tenants:
A forced transition of this size means one thing operationally: more people than usual will be unable to authenticate at once — more recovery calls, more Temporary Access Passes issued at pace, more staff unfamiliar with the new method. It's a period of elevated help-desk load and elevated risk, on a schedule attackers can read as easily as you can.
When users simply can't use a passkey
Beyond lost and broken devices, whole categories of users can't present a passkey at all — permanently, not temporarily:
- Frontline and deskless workers who don't carry a work phone.
- Shared terminals and kiosks — a warehouse floor, a hospital ward, a retail point of sale — where the passkey lives on a personal device that isn't present or isn't allowed.
- Secure and regulated environments — manufacturing lines, trading floors, clean rooms, call centers — where personal phones are locked away at the start of every shift.
- Biometric edge cases — an injured finger, gloves, a cracked screen, a broken reader.
- Contractors, temps, and third parties who need short-lived access and aren't in the standard device fleet.
For all of these, the sign-in problem is solved only after a person is verified by other means. The passkey never enters the picture.
The infrastructure that isn't going passwordless — and won't for years
Here is the part the passkey headlines miss entirely. Even a "fully passwordless" enterprise still runs a high-volume password-reset and verification operation, because the passkey only reaches the systems your identity provider fronts:
- On-premises Active Directory.AD was built on Kerberos and NTLM — password-centric protocols that don't natively speak FIDO2. Passkeys reach on-prem AD only through a hybrid Entra-Kerberos bridge, and Microsoft explicitly leaves several sign-in scenarios unsupported. Organizations running cloud-disconnected AD get none of it, and Microsoft's February deadline doesn't touch on-prem AD at all.
- Business-critical and legacy applications.SAP, Oracle, mainframe, legacy thick-client apps, OT and industrial systems, and non-federated SaaS. Some can be fronted by SSO — but many still authenticate with their own passwords, and those passwords still get forgotten, locked, and reset.
- Service and technical accounts. A large share of what a help desk unlocks isn't a person at all — and no passkey will ever cover it.
The dangerous moment: recovery, TAP, and re-enrollment
Every situation above funnels into one moment: prove you're really you so we can get you back in. Whether it's a help desk agent or a self-service flow, that moment is where the assurance of your entire identity program is actually set — and it's where attackers go.
They don't attack the passkey; a passkey isn't worth attacking. They trigger recovery: research a target on LinkedIn, call the help desk, recite the "verification" answers that are already public, and if the first agent refuses, call back and try another. This is the pattern behind the costliest breaches of the last three years. As the industry now puts it, attackers aren't hacking in — they're logging in.
A Temporary Access Pass makes this sharper, not safer. A TAP is a time-limited passcode that bootstraps or restores passwordless access — which means an unverified TAP hands the attacker the passwordless account itself. If your help desk can issue a TAP on the strength of a name and an employee ID, you haven't closed the door. You've built a faster one for the attacker.
What secure identity verification actually looks like
The fix is not to slow down passkeys. It's to treat verification-when-the-credential-is-absent as a first-class control, engineered with the same rigor as authentication. In practice that means:
- Stop using data an attacker can buy. Date of birth, employee ID, and a manager's name are not verification. Use dynamic, contextual signals drawn from live systems the real user interacts with and an outsider can't research.
- Make it system-enforced, not agent discretion. It should be easier for an agent to say "the system won't let me" than to be talked into an override — especially by a caller claiming to be a senior executive in a hurry.
- Match the check to the privilege. A CEO and a summer intern should not clear the same bar.
- Cover self-service too.Self-service reset and enrollment are only as safe as the verification behind them.
- Log every decision. The difference between a contained incident and an unprovable one is whether you can reconstruct what happened.
How FastPass closes the gap
FastPass secures the exact moment passwordless leaves exposed: verifying a user when they can't authenticate, at the help desk and in self-service.
FastPass Identity Verification Manager
Verifies a user with strong, dynamic, system-enforced checks before an agent — or a self-service flow — resets a credential, issues a Temporary Access Pass, or re-enrolls a passkey in Microsoft Entra. Consistent, role-aware, and fully logged.
Explore IVM →FastPass Self-Service Password Reset
Covers everything that isn't going passwordless — on-premises Active Directory, applications, and legacy systems — so users resolve routine lockouts securely without a call, and the help desk isn't buried by the transition.
Explore SSPR →The result: your move to Microsoft Entra passkeys is protected on the side that matters most — recovery and enrollment — and the passwords that remain across your estate are handled with the same verified rigor. Passwordless becomes a security upgrade end to end, not a stronger front door with an open side entrance.
Ask your most experienced help-desk agent: if someone calls right now claiming to be an executive locked out before a meeting, and recites their employee ID, manager's name, and date of birth — what stops you resetting their access or issuing a TAP? If the answer is "my judgment," the gap is operational, and it's exploitable today.
See exactly where your verification gap is — and what it takes to close it before September 1.
Frequently Asked Questions
What happens if a user loses their passkey in Microsoft Entra?
A passkey can't be "reset," because the private key never left the device. The user must be re-verified through another channel, after which the help desk (or a self-service flow) issues a Temporary Access Pass or re-enrolls a new passkey. Identity verification — not the credential — is the control at that moment.
