Device management plays a critical role in identity management by ensuring that the devices your customers use to access services are trusted and secure. It involves verifying the identity of devices and enforcing policies that link devices to authorized users. By managing devices in this way, organizations can maintain a secure environment where only authenticated and compliant devices can connect to sensitive resources, reducing the risk of unauthorized access or data breaches.
Keeping track of user devices offers multiple benefits, particularly in enhancing security, user experience, and operational efficiency, including:
Secure authentication: By keeping track of devices, organizations can ensure that only authorized devices access sensitive systems. In MFA, a device can work as a "something you have" authentication factor.
Seamless user experience: By linking users to their devices, organizations can offer seamless and secure identity experiences, allowing known devices to perform certain activities without additional authentication, reducing friction and promoting user trust.
Streamlined operations: Restricting the number of devices per user, such as allowing only a single mobile device per user, enhances security and brings clarity into your app operations.
Risk mitigation: If a device is lost or stolen, or is suspected to be compromised, the ability to remotely suspend devices minimizes the risk of account takeover.
In Mosaic, a Device entity is a logical endpoint that represents a specific physical device a user authenticates from, such as a mobile app installation on a smartphone or tablet, or a browser instance on desktop or mobile. A device in Mosaic doesn’t always map one-to-one to a physical device. For example, different browsers used on the same laptop are represented as separate device entities.
Each device is identified by a device_id. This identifier can be generated by the Orchestration SDK or can be provided by Mosaic Fraud Prevention or another provider during registration. If no external identifier is supplied, the SDK-generated ID is used as the fallback device_id.
Mosaic supports two device types:
- Mobile: smartphones and tablets running native apps
- Web: browsers such as Chrome or Safari accessing your web domain
Device identities are tightly connected to user identities and are scoped per user and application. The same physical device used by two different users, or to access two different apps, produces separate Device entities. For example, Mosaic maintains separate device identities for an Android smartphone accessing Acme app and Acme Pro app. If the user utilizes several browsers to access your web service, each browser is also treated as a separate device identity.
The device profile (Admin Portal > B2C Identity > Users > user > Devices > device) extends the user profile and provides general information about the device associated with the user, including device type, status, last login attempt, etc. For details on viewing devices, see Manage devices.
In the device lifecycle, there are several statuses a device might have. After a device is registered and associated with a user, it appears in the user profile with an Active status. A device can be Suspended by an admin when it should no longer be trusted, for example, if lost or stolen. Suspending a device also suspends its linked device cryptographic keys and locks device-bound authenticators (mobile biometrics and PIN) that were registered on that device. Suspended devices can be restored to Active by reactivating them.
Devices that are no longer needed can be permanently deleted. Deletion removes the Device entity from the user profile; you can optionally also delete linked device-bound authenticators at the same time. For details, see Manage devices.
Crypto-binding establishes a strong, cryptographically verifiable connection between a device and its Device entity.
When a device is registered through the Register or Update Device journey step, crypto-binding takes place automatically. It is handled implicitly by Mosaic client SDKs (Web, Android, or iOS).
During crypto-binding, a cryptographic key pair is generated by the device. The public key is exported and sent to Mosaic while the private key never leaves the device and is stored in a dedicated non-extractable way, depending on the platform.
The resulting device cryptographic key serves as a cryptographic authenticator linked to the Device entity. The device_key_id (device cryptographic key identifier) identifies this authenticator and remains consistent even when the underlying cryptographic keys rotate. It is available in the device profile in the Admin Portal in the Device keys view.
The Device entity and the device cryptographic key are separate concepts: a device can exist without a device cryptographic key, and device cryptographic keys remain supported independently for backward compatibility.
Mosaic establishes relationships between devices, authenticators, and authentication events to provide visibility into how and where users authenticate.
Every authenticator record includes a registering_device field that stores the device_id of the device present during authenticator registration and cannot be changed once set. For device-bound authenticators (mobile biometrics and PIN), this relationship enables coordinated lifecycle management—suspending a device also locks its linked device-bound authenticators, and reactivating restores them. For non-device-bound authenticators, the field provides additional visibility into the registration context, even though the user can use these authenticators from other devices.
All authentication flows (backend APIs and journey steps) accept an optional device_id. When provided, Mosaic records the device_id and device ownership (user-owned or non-user-owned) alongside the authentication event in the user activity log. Authentication outcome is not affected by device-user mismatch—the device context is purely informational and enriches observability. When device ID is provided during the journey, it remains available in the journey context.
Each authenticator maintains a last_used_devices list—a rolling list of the last 5 devices from which the authenticator was successfully used. This list may include devices not owned by the authenticating user, with each entry recording the device_id, device ownership, and a timestamp. Since PIN and mobile biometric authenticators are cryptographically bound to a single device, their last_used_devices list will always contain exactly one entry. For other authenticator types, this list can surface signals such as an authenticator being used from an unexpected device.
Each device entity tracks authentication activity with two timestamp fields: last_auth_attempt (updated on every authentication attempt where device_id and user_id are provided) and last_authenticated (updated on every successful authentication). If the device_id is not provided, does not exist, or belongs to another user, the device entity is not updated — this prevents cross-user side effects.
Devices can be viewed in the Admin Portal and managed using identity journeys, via client-side SDKs, or via APIs. See Manage devices for details.
Mosaic's Fraud Prevention takes various device telemetry into account when assessing risk: device cryptographic keys, device fingerprints, and IDs provided by device manufacturers. (Learn more)