Users make mistakes. They’ll forget the credentials they used to register for a service, the email or username they may have used, or even the name of the actual service they registered for in the first place. They’ll use other people’s emails thinking they own them, lock themselves out putting in the same exact password that failed repeatedly, and outsmart themselves by using bad information (such as a fake birthday) during registration and then promptly forget it.
Users also make well-intentioned decisions. They might need to log into a service from a place thousands of miles away from where they normally do in order to change plans. They might try to perform what would otherwise be a valid operation during a time that they simply have never been logged on over years of steady use. They might need to force an old device, now in the hands of an abuser, to be logged out of the service – and do so rapidly.
Users entrust us with their data. For a given CIAM service, compromise of an account created by a user may disclose PII, allow for adverse financial transactions to occur on behalf of the user, use the service in a manner that the user may find objectionable or otherwise is against terms of service, and so on. It behooves us as stewards of a user’s data to ensure compromise does not occur, but at the same time ensure that if the user does what humans do and makes a mistake that they are able to recover gracefully.
With all of that in mind, there comes a point where the actions of a well-intentioned but clumsy user may look not unlike a threat actor who has compromised a user’s account. It becomes extremely difficult to determine the reality of the situation without having significant context. A prudently designed system might restrict or otherwise lock users who demonstrate suspicious activity – likewise, a user who suspects their account may be compromised (because they can’t log in suddenly, for instance) may wish to take some actions to prove the account is theirs and kick out anyone else who may be using the account.
A well-designed service should offer a set of mechanisms by which a user may attempt to regain logical access. Today, these account recovery flows are often highly automated, requiring specific information or actions from the user and minimal intervention from support staff for the service. This becomes a blessing and a curse, as a savvy attacker may be able to lock out a user and then leverage the account to perform nefarious deeds.
We are then faced with a monstrous task. How then should we model account recovery so that it rebuffs attackers? It turns out that recently some interesting answers were shared on this very topic. During the summer of 2025, Sid Rao and Gabriela Sonkeri gave a talk at Black Hat titled Lost & Found: The Hidden Risks of Account Recovery in a Passwordless Future that offers an auditing framework for account recovery called the ARTHA framework.
The repository that contains the ARTHA framework can be found at https://github.com/Nokia-Bell-Labs/Account-Recovery-Threat-Heuristic-Auditing-Framework . The auditing process is across 9 separate test cases, which test the following:
- Account creation
- Account state specific tests (how can we recover from different paths in an account recovery flow?)
- How recovery works with multiple recovery methods in play
- Session termination
- The usage of MFA in the flow
- Interchangeability of authentication factors / recovery channels
On top of the framework, the slides from the presentation (https://i.blackhat.com/BH-USA-25/Presentations/US-25-Rao-Lost-and-Found-The-Hidden-Risks-Of-Account-Recovery-In-a-Passwordless-Future.pdf) are also rich with content and should be given a read over. For instance, from the session termination perspective a major design flaw is that sessions are allowed to remain in-place after an account recovery action has been performed. The slides give a fantastic diagram for this, as we can see below.
The team also gives a solid list of best practices that should be considered. The team goes into far more detail through the slide deck (which, again, is fantastic) but their slide on the ideal recovery flow is particularly salient here.
Given the increasingly automated and human-detached processes that make up account recovery, we as practitioners need to understand the choices we are making as part of that process to extract the enterprise from assisting directly with account recovery. This means we need to build trust from the start, communicate meaningfully with the user about account state, and ensure that recovery actions are meaningful through session termination and communication back to the user.
Disclaimer: The views expressed in the content are solely those of the author and do not necessarily reflect the views of the IDPro organization.
Author
Rusty Deaton has been in Identity and Access Management for over a decade. He began in technology as a technical support engineer for a Broker-Dealer and has since worked across many industries, carrying forward a passion for doing right by people. When not solving problems, he loves to tinker with electronics and read. He currently works as Federal Principal Architect for Radiant Logic.ghts on identity security through his blog at iam.ninja and engages with the IAM community on LinkedIn. When he’s not deep in security design, you’ll find him playing pickleball, writing about personal finance, stargazing, or playing tabletop board games.
