# 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


Note
This step replaces the **Known Device Status (deprecated)** step. Existing journeys remain fully supported and can continue to operate without changes.

## Description

This step determines whether a user performs actions in the app from a known or unknown device. 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.

The step checks if the device is registered to the user by checking device ID and issuing a challenge to the client to sign using the private key stored on the device. This process is handled implicitly by the client SDK and no user interaction is required. The step branches based on the result:

- **Yes**: the device is registered to this user. The journey proceeds on the success path.
- **No**: the device is not associated with this user, suspended, or an error occurred (e.g., device not found, invalid user ID). You can design the journey to register the device for a verified user, prompt additional verification, or reject access.


Note
The device can be recognized as known even if you haven't registered it using the [Register or Update Device](/guides/orchestration/journeys/register_device) journey step. Other Mosaic services, such as Fraud Prevention, can also perform device binding and registration as part of integration.

The step outputs the `deviceInfo` object and make it accessible via to the journey context. For details, see [Devices](/guides/orchestration/concepts/devices).

## 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 step output, including the `device_key_id` (device cryptographic key identifier) and the `device` object which can be used in subsequent journey steps. |
| **Error output variable** | Name of the variable that stores any errors returned by the step. |


Journey event data
This step can be configured to record step input and output data, or a custom payload, which is then surfaced in journey events in Journey Analytics for diagnostic purposes. For details, see [Additional data reporting](/guides/orchestration/getting-started/event_reporting).

## 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 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 the device status.

- If the device is known (**Yes** branch), the journey completes successfully ([Complete Journey](/guides/orchestration/journeys/complete_journey) step).
- If the device is unknown (**No** branch), 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.