# Account Recovery

Keyless helps organizations securely recover accounts and enroll new devices when users lose access to their originally enrolled device. These flows leverage the Keyless Mobile SDK.

Keyless offers two services that can be used as part of a device/account recovery experience.

* [Enroll a new device](#enroll-a-new-device-via-client-state)
* [Managing multiple enrolled devices](#managing-multiple-enrolled-devices)

{% embed url="<https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FMICv0gJkqz9AwvsR8uSs%2Fuploads%2FPP44aF47EnVJbkdW5rfM%2FDemo%20Oct%202025%20-%20Account%20Recovery.mp4?alt=media&token=5bc81852-9a54-4c94-ae9d-ef39d2128a74>" %}

### Enroll on a new device <a href="#enroll-a-new-device-via-client-state" id="enroll-a-new-device-via-client-state"></a>

For customers who have already established trusted alternative second factors such as passwords, SMS One-Time Passwords (OTPs), or email magic links. Keyless' face matching is typically used in combination with the existing factors to enroll the new device.

**How it Works**

1. The user downloads the app on a new device, enters their username and authenticates via a first factor (e.g., password, SMS OTP, email magic link).
2. Customers invoke the Keyless Mobile SDK, retrieve the KeylessID associated with the user and the client state generated during enrollment and send this to the SDK to enable secure account recovery.
3. This triggers the recovery flow via the Mobile SDK, which captures a selfie and authenticates that the originally enrolled user is genuinely present, without revealling or processing the biometric data outside of the users' device.
4. If successful, the new device is bound to the user’s identity, enabling ongoing authentication for login, step-up, or payment use cases.
5. Optional: Users can review and [delete previously bound devices](#managing-multiple-enrolled-devices).

{% embed url="<https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FMICv0gJkqz9AwvsR8uSs%2Fuploads%2FtLnUz0wVDqek1EwDf02z%2Fimage-20241217-161156.png?alt=media&token=99d1db6a-839f-492b-bb8c-ee83c1326a45>" %}

**Find out more →** [Account Recovery (Mobile SDK)](https://docs.keyless.io/consumer/mobile-sdk-use-cases/guide-account-recovery)

**Find out more →** [Retrieve and delete devices via API](https://docs.keyless.io/consumer/server-api/devices)

### Managing multiple enrolled devices <a href="#managing-multiple-enrolled-devices" id="managing-multiple-enrolled-devices"></a>

Customers can use our API to retrieve and delete devices bound to their users' identities. This allows users to have multiple devices, reducing both costs and security risks associated with device loss.

Leverage our GET and DELETE apis to create a “device management” experience, allowing users to:

* View and manage their bound devices
* Delete any device listed
* Add a new device when needed

**Find out more →** [GET and DELETE user devices](https://docs.keyless.io/consumer/server-api/devices)

**Find out more →** [Add user device](https://docs.keyless.io/consumer/mobile-sdk-use-cases/guide-account-recovery)

### Keyless Client Devices

Finally, of relevance to the account recovery flow, are the Keyless Client Devices and Client States which are subset of these entities. Keyless Client Devices represent the user profiles that contain the necessary non-pii data which allow a user to authenticate on a new device or channel (Mobile or Web apps).

Within this category Keyless allows customers to generate a **Client State** during enrollment which is the for these device types prior to them being activated or bound for on-going two factor authentication. Once that binding takes place a new **"SDK" Device** is generated. Each of these devices is given a DeviceID and can be one of the following Device Types:

1. **Backup** - this is the **Client State** typically stored by the Keyless customer in preparation for a user to then authenticate on a new camera enabled physical device. Generated either via IDV Bridge or Live Enrollment, and then leveraged during an account recovery flow at a later date
2. **Temporary** - identical to the above however recommended where the customer doesn’t need to store the client state beyond the flow they are executing such as where the enrolment is immediately followed-up by the activation or binding process.
3. **SDK** - this device type is applied where a user profile has now been activated via a mobile or Web app to support ongoing authentication via a Mobile SDK. It contains additional keys and meta data to support both physical device and facial authentication in privacy-preserving manner.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.keyless.io/account-recovery.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.