Each device is enrolled with its own cryptographic identity — a unique key pair, a registered record, and an assigned App ID. Sessions are bound to the physical device, not just a token or cookie.
Five steps from first contact to fully enrolled device. The process establishes a hardware-anchored identity that persists across sessions.
Challenge Request
Device requests an enrollment challenge from the server
Attestation
Device proves its integrity via platform attestation (Play Integrity / App Attest)
Key Exchange
Device generates an ECDSA key pair and registers the public key with the server
Device Record
Server creates a persistent device record with hardware fingerprint and metadata
App ID Assigned
A unique App ID is issued, binding this device to the client application
Challenge Request
Device requests an enrollment challenge from the server
Attestation
Device proves its integrity via platform attestation (Play Integrity / App Attest)
Key Exchange
Device generates an ECDSA key pair and registers the public key with the server
Device Record
Server creates a persistent device record with hardware fingerprint and metadata
App ID Assigned
A unique App ID is issued, binding this device to the client application
Every device transitions through defined states. State changes take effect immediately — no cache delay, no grace period.
Device is enrolled and authenticated. All requests from this device are processed through the full trust pipeline.
Device is temporarily disabled. Existing sessions are invalidated, but the device record is preserved for reactivation.
Device is permanently removed from the trust chain. The public key is invalidated and all associated sessions are terminated.
User initiated logout. Refresh tokens are revoked, but the device enrollment remains intact for future authentication.
Key binding status, device limits, app versions, and ban history — all in one panel.
Device identity is resolved on every request through a three-layer cache system. The resolver ensures that device lookups are fast in the common case and always accurate — even under load. Cache invalidation propagates immediately on state changes.
When a device is revoked or suspended, the blacklist is updated immediately. The next request from that device is rejected — there is no window where a revoked device can continue operating. The blacklist check runs before cache resolution, ensuring that stale cache entries cannot bypass revocation.
Users operate across multiple devices. The trust layer manages each device independently while maintaining a unified view of the user's device fleet.
Configurable per-client maximum device count. When the limit is reached, new enrollments require removing an existing device or admin approval.
Automatic replacement policy for exceeded limits. The oldest inactive device can be automatically de-enrolled when a new device is registered.
Each device maintains its own independent session. Revoking one device does not affect sessions on other enrolled devices.
Users and administrators can remotely terminate sessions on any enrolled device. The revocation takes effect on the next request from that device.