Passkey-only MFA without any credential creates permanent account lockout

This document recounts a security design flaw in Discourse where an account registers a passkey as its sole multi-factor authentication method while failing to provide any actual passkey credential on any connected device. When users arrive at the sign-in page for such accounts, the frontend instructs them to use their passkey to prove identity, yet the backends contain no way to retrieve or replay that credential. As a result, the account becomes permanently inaccessible despite appearing correctly configured elsewhere in the system.

The core accounting mismatch

The fundamental problem is that the account lookup process records "passkey" as a valid factor for mandatory MFA, but nowhere in the client storage—whether in iOS Passwords, iCloud Keychain, Google Password Manager, or within the application's local credential cache—is there an actual passkey string. The user reported that neither of those services contains a passkey; each only holds a standard password entry. This means the registration endpoint succeeded in marking the account as passkey-protected, but subsequent provisioning failed silently, leaving no secret for the platform to verify later.

Email verification does not resolve the deadlock

Even though completing the initial email verification step succeeds—the user receives confirmation that their email is associated with the account—the subsequent authentication phase breaks down. Once the verification passes, the interface prompts for a second factor, and the only offered option is the unlinked passkey. Because no backend credential exists to satisfy that request, selecting "Try another method" produces a frozen UI (on the iOS native app) or simply stops at the passkey choice on web. The session eventually times out, returning the user to the sign-in page where they repeat the cycle with no success. In the worst case, the account remains locked for an indeterminate amount of time, in this instance spanning roughly seven days before the user gave up.

Community queries and potential remediation paths

Has anyone else encountered a similar discrepancy where a primary MFA method exists in the registry but nothing matches on any device? Staff responded that recovery options are closed—not only is resetting, removing, or unlinking the passkey impossible, but even attempting to register a different method is rejected by the challenge system. Several community members asked whether admins could generate a fallback passkey or inspect the registered factors to identify why credentials were never stored. They noted that creating a backup passkey through the administrator console—or manually triggering a secondary enrollment flow—remains undocumented, suggesting this represents a gap between the registration intent and the provisioning implementation. Until either the registration process validates that a credential will actually be stored, or an admin-assisted workaround is exposed, affected users lose access to their accounts without the possibility of self-service recovery.