# Known Device Status

div
div
Client SDK
div
Mobile approve
div
SSO
div
Sub-journey
> Checks if the device is registered to the current user


## Description

This step ensures that the device attempting to access the application is registered to a specific user. It allows the device to act as a user-identifying factor, which enhances the security of the flow. This step could be used as part of a two-factor authentication approach, leveraging something the user has (their device) and something the user knows (such as a password). It can also be used to elevate trust for known devices, and reduce user friction accordingly.

This step checks if the device is cryptographically bound to the end-user. The validation process involves issuing a challenge to the client to sign using the cryptographic key generated as part of device registration (via the [Register Device](/guides/orchestration/journeys/register_device) step). This process is handled implicitly by the client SDK and no user interaction is required.

If the device is known for this user, the journey proceeds to the `Success` branch. If the device is unknown, you can design the journey to proceed with registering the device for a verified user or implement any other necessary actions.

The output variable is a `key_id` generated during device registration is used here to verify if the device is recognized as trusted. This ID allows you to manage the device, including updating its details (see [Update device key](/openapi/user/device-key.openapi/other/updatedevicekey)) or removing it from the user’s account if it’s compromised (see [Delete device key](/openapi/user/device-key.openapi/other/deletedevicekeys)), ensuring that only known devices can access the application.

## Configuration

div
| Field | Description |
|  --- | --- |
| **User auth state** | Indicates if the user has authenticated in this journey. If the user is authenticated (default), the user context is provided implicitly by the journey. If not, a user identifier must be configured. |
| **Identifiers** | Only configured if the journey doesn't authenticate the user before invoking this step. Can be an external user ID, email, phone number, username, or a [custom identifier](/guides/user/manage_user_schema), if configured for B2C users in your tenant. |
| **Output variable** | Variable used to store the device `key_id` generated during the device registration process, inherited by the which can be used in subsequent journey steps. |


## Example

Consider a login journey that authenticates the user and then checks if the device is known. A [Login Form](/guides/orchestration/journeys/login_form) step collects a user credentials, and a [Password Authentication](/guides/orchestration/journeys/authenticate_password) step validates them. Once the user is authenticated, the **Known Device Status** step checks if the current device is registered to this user.

If the device is known, the journey completes successfully ([Complete Journey](/guides/orchestration/journeys/complete_journey) step). If the device is unknown, the journey proceeds to a stronger verification method, such as an OTP challenge, before granting access.

figure
a
img
figcaption

    Click to open the image in a dedicated tab.