Passkeys Are Becoming the Default Login, but Recovery Gap Remains Open

Microsoft’s enterprise identity service changed its default login path in September 2026. Entra ID now defaults to passkeys and moves new enrollments away from SMS and voice-based authentication, according to Cyber Security Intelligence. The change does not delete passwords. It reorders the defaults. A service that spent two decades treating the password as the first factor is now treating a discoverable public-key credential as the primary one. The date matters because it is a vendor action, not a vendor promise. Defaults also reach customers who never read a security advisory.

CSO Online read the move less as an extinction event and more as a compression event. In a piece headlined “Microsoft nudges enterprise security closer to its passwordless future. But ‘123456’ will survive”, the publication reported that Microsoft’s backing will spur adoption of passwordless technology but that most enterprises will continue to keep passwords in some portion of their estate. That framing is more precise than the marketing. Passkeys reduce the attack surface for remote credential phishing. They do not eliminate the recovery infrastructure, the service accounts, the legacy line-of-business apps, or the helpdesk reset queue where the password still lives.

The FIDO Alliance, the industry body behind the WebAuthn and CTAP standards, is now focused on the region where the next wave of adoption is expected. On April 30, 2026, the alliance announced the agenda for Authenticate APAC 2026, a Singapore conference it said would bring together leaders to advance “secure, simple and trusted technologies,” according to a Business Wire release. The agenda signals where the actual work is: deployment logistics, recovery paths, enterprise policy, and cross-platform passkey portability, not the core cryptographic design. The protocol layer has been stable for years. The operational layer is where the failures are accumulating.

Vendor mandates arrived in the enterprise supply chain in June. On June 1, 2026, Yubico announced a partnership with OpenAI to support a passkey mandate for users in OpenAI’s Trusted Access for Cyber program, the company said in a release aggregated by Yahoo Finance. The announcement matters because it attaches hardware-backed passkeys to a serious access incentive for researchers and engineers who work with an AI lab’s infrastructure. A mandate tied to access makes passkeys an operational requirement, not a security suggestion. It also pushes the hardware question forward: synced passkeys on phones are convenient, but device-bound keys on a YubiKey remove a category of export risk.

The rollout itself began in earnest in 2022, when Apple, Google, and Microsoft publicly committed to FIDO-compatible passkeys, and has moved at vendor speed since. The WebAuthn API, the part of the stack a browser implements, standardizes how a cryptographic key pair is created and used during login. CTAP handles roaming authenticators such as security keys. Passkeys add two consumer-facing properties: credentials sync across a user’s devices through the platform cloud account, and the private key never leaves the device or its synchronized enclave. That architecture removes the shared secret an attacker can phish. It also shifts the trust boundary from the website to the platform account, a shift that creates the exact recovery problem the Cornell study examined.

The distance between the promise and the user’s inbox is still wide. Apple-focused outlet 9to5Mac published a piece on July 10, 2026, under a headline that functions as a status report. Security writer Arin Waichulis framed the gap between the 2022 credential rollout and the 2026 reality in a single sentence. The piece ran in the site’s Security Bite column, a format built for concise security observations. The headline, reproduced below, is a better summary than most analyst decks.

Passkeys were supposed to have killed the password by now...Arin Waichulis, security writer, 9to5Mac

Consumer products are moving in the same direction with the same hesitations. WhatsApp introduced multi-passkey support and more complex two-factor authentication on August 25, 2026, as Cyber Defense Magazine reported. Multi-passkey means an account can hold more than one credential, which is the first step toward treating a passkey as a revocable, enumerable object instead of a secret. But adding a passkey is only half of the identity problem. The other half is removing one when the person who registered it should no longer have access.

Consumer friction is still measurable. Android Authority published an account in May of trying to ditch passwords and finding the alternatives more complicated, not less, partly because Google’s passwordless features still lean on verification emails and platform-specific flows. That friction matters because a transition that feels complicated to a technical user will stall for everyone else. Passkeys add a credential; they do not always remove the password, the backup code, the SMS fallback, and the notification prompt that already surround it.

The recovery problem

In August, researchers at Cornell University documented a specific failure in the account recovery path. Tech Times reported that the study found a person who briefly accesses a victim’s unlocked computer, and who knows the victim’s password, can register a rogue passkey on the victim’s Google, PayPal, or LinkedIn account in minutes. The critical detail is what happens next. As Tech Times summarized it, the rogue passkey survives the password reset the victim would normally use to lock the abuser out. The passkey becomes a credential that persists past the recovery procedure.

The distinction here is not subtle. WebAuthn was designed to stop remote credential phishing, the attack where a person is tricked into entering a password into a fake login page. A passkey is origin-bound, which means the browser will only release it to the domain that created it. That property is why it defeats phishing. It is not designed to defeat an attacker with brief local access to an unlocked device and a known password. The Cornell study does not claim attackers are using this technique at scale. It claims the capability exists and that recovery workflows have not caught up. The verb matters. An attacker could register a rogue passkey; whether attackers did, and how often, is not answered by the study.

Enterprise decision guides published this year have begun to split the question in exactly that way. A Security Boulevard framework from August argued that device-bound hardware keys beat synced passkeys in some enterprise contexts and lose in others, depending on user risk, device context, compliance needs, and total cost. The framework identified three failure patterns in passkey rollouts, each tied to recovery and lifecycle management rather than cryptography. That is the systemic version of the Cornell finding: the technical primitive is sound, but the rollout, the inventory, and the recovery path decide whether an authentication system is actually safer.

Regulators are pulling the same thread. On September 1, 2026, Help Net Security published guidance on NIS2 credential compliance, describing stronger access controls, MFA, credential management, and audit logs as prerequisites before the 2026 audit. The NIS2 angle turns identity from a user convenience into an auditor’s checklist item. When compliance requires an inventory of authentication methods, silent passkeys become a problem. An auditor cannot flag a credential the organization does not know exists. For enterprises, the immediate task is less about adding passkeys and more about making the authentication estate legible.

There is no public telemetry on how often rogue passkeys are registered across Google, PayPal, or LinkedIn. None of the providers named in the Cornell study has published a passkey inventory or abuse report specific to this pathway. That absence is itself a finding. Passwords leave residue in password managers and breach dumps; passkeys live inside platform keychains and are harder for a user to audit. A victim can scroll through a password manager and see saved passwords. The same user often has no equivalent dashboard that shows every passkey bound to an account, when it was added, and from which device. The recovery interface assumed passwords were the only thing a user might need to revoke.

A technical fix is straightforward. Relying parties could show enrolled passkeys in security settings, with creation dates and device labels, and could require a second factor before adding a new passkey after a password reset. Some providers already do pieces of this. The Cornell study suggests the pieces are not yet assembled into a default recovery guarantee. For abuse survivors specifically, the gap is not a matter of convenience. It is a matter of whether changing a password, the one action a victim has been told to take for twenty years, still means the abuser is locked out. When a rogue passkey survives the reset, that advice stops being true without the victim knowing it.

9to5Mac’s headline mostly asks a consumer question. The security answer is that passwords and passkeys now coexist inside the same identity stack, and the password’s continued existence is not always a flaw. The password is the recovery anchor. If an attacker can obtain the password and add a passkey, the passkey becomes a persistence mechanism layered on top of that anchor. Microsoft has moved Entra ID defaults, OpenAI has attached hardware passkeys to a compliance program, and WhatsApp now supports multiple passkeys. Each of those moves changes the front door. None of them, on its own, changes the recovery path.

The next checkpoint will be the FIDO Alliance’s Authenticate APAC conference and the rollout metrics that follow the Microsoft default switch. The measurable question is not how many accounts have passkeys. It is how many accounts can enumerate them, revoke them, and detect one that was added without authorization. The same pressure is coming from NIS2 and from enterprise procurement teams that want device-bound keys for privileged users and synced keys for everyone else. A single headline number will not answer whether the account recovery gap closes. An inventory of credentials, one that a victim can read, a helpdesk can revoke, and an auditor can review, will.