How to use this reference
Review an owned application’s recovery completion criteria across registered credentials, sessions and recovery channels. Make security interfaces explain what each revocation changes and what remains authorized; use clear credential provenance and action-specific notifications. Treat these as design-review questions, not evidence of a deployed fix.
Before reading
- Passkey registration and relying-party credential records
- Session invalidation and account-recovery concepts
Context and limits
- The simulated scenario presupposes earlier account access sufficient to register a credential; one service additionally required an email challenge. This is not a cryptographic break of passkeys or evidence of unauthenticated access.
- The paper reports that no participant completed all required remediation unaided. This demonstrates usability failures in controlled test accounts, not population-wide compromise rates or current service exposure.
- The small, single-city sample used researcher-provided devices and accounts; researcher assistance limits generalization of success rates.
- The authors explicitly label proposed interface improvements speculative and needing validation. Password reset, credential removal and session termination have distinct effects.
- This is a conference proceedings research paper, not a vendor patch advisory; no fixed-version claim is made.
Sources and provenance
- “Maybe there’s only one passkey?”: Challenges Investigating and Remediating Adversarial Passkeys USENIX Association · reviewed 2026-10-03
- Publisher-hosted proceedings paper USENIX Association · reviewed 2026-10-03
Record reviewed 2026-10-03. Snapshot d5550c789111. Open the complete JSON contract.