Overview#
A detective logs in from the same agency-issued laptop every day. Making them prove their identity with a second factor on every single login adds friction without meaningfully improving security. But the moment that laptop shows up in an unexpected city at 2 a.m., the platform should treat it very differently. Device Management and Trusted Devices handles exactly this distinction: building a stable fingerprint for each device, assigning a trust score based on behavioural signals, and adjusting the MFA challenge accordingly.
All devices start untrusted. Trust is earned over time through consistent, recognisable patterns and explicit user verification. It can be revoked instantly by the user or by a security administrator responding to an incident.
Open Standards#
- FIDO2 / W3C Web Authentication (WebAuthn) Level 3: Passkey and hardware-token MFA challenges issued during device trust evaluation fully implement the W3C WebAuthn credential registration and assertion protocol, including AAGUID, attestation type, sign-count, and transport metadata.
- RFC 7519, JSON Web Tokens (JWT): Every authenticated session is carried in a signed JWT; the platform embeds a
dfp(device fingerprint) claim in each token so that the middleware can bind the session to the originating device and reject tokens presented from a different device context. - RFC 8176, Authentication Method Reference (AMR) values: Step-up authentication decisions inspect the
amrJWT claim for recognised values (mfa,totp,fido,webauthn,hwk,swk,otp) to determine whether a current token already satisfies the elevated-assurance requirement before re-challenging the user. - RFC 6238, Time-Based One-Time Password (TOTP): TOTP is one of the supported second factors triggered when device trust is absent or degraded; the AMR value
mfa_totp/totpis recorded in the issued JWT upon successful completion. - ArcSight Common Event Format (CEF): All device registrations, trust changes, and revocations are exported from the append-only audit log in CEF format for ingestion by SIEM platforms such as Splunk, Microsoft Sentinel, and IBM QRadar.
- GraphQL (June 2018 specification): The device management API surface, queries for device lists and mutations for trust revocation, is exposed as a typed GraphQL schema, giving client applications a consistent, permission-gated interface.
- W3C HTTP Client Hints (UA-CH): The device fingerprinting engine derives its stable identifier from the
User-AgentandAccept-Languagerequest headers, aligning with the W3C Client Hints framework for passive environment signals that do not contain personally identifiable information.
Last Reviewed: 2026-02-05 Last Updated: 2026-04-14
Key Features#
Device Fingerprinting and Registration#
The fingerprinting engine generates unique, stable identifiers by analysing browser characteristics, hardware attributes, and client environment signals. IP addresses are deliberately excluded from the fingerprint, so VPN changes and network roaming do not trigger unnecessary re-verification.
- Multi-Factor Fingerprinting: Combines user agent, screen resolution, timezone, language preferences, and HTTP client hints
- Privacy-First Design: No personally identifiable information collected; fingerprints rely solely on browser and hardware characteristics
- 99.7% Device Uniqueness: Accuracy across diverse device populations while keeping false positive registration rates low
Device Trust Scoring#
The trust scoring system evaluates device reliability based on usage patterns, authentication history, and geographic consistency. High-trust devices face fewer challenges; low-trust devices or anomalous signals trigger additional verification.
- Time-Based Trust Degradation: Trust expires after 30 days of inactivity (configurable per organisational policy)
- Behavioural Trust Signals: Login frequency, geographic stability, and consistent access patterns all contribute to the score
- Admin Override: Security administrators can force immediate trust revocation for lost, stolen, or compromised devices
Adaptive MFA Integration#
The MFA system adjusts authentication requirements dynamically based on device trust, login context, and real-time risk signals. Supports TOTP, FIDO2 passkeys, SMS, email, biometric, and hardware tokens. Users can opt into device trust periods of 7 to 90 days.
- Risk-Based Authentication: Real-time risk scoring determines whether an MFA challenge is required
- Context-Aware Policies: Location, network, time-of-day, and device trust all influence the decision
- Step-Up Authentication: Sensitive operations trigger additional challenges regardless of device trust level
Device Management Dashboard#
Users have complete visibility and control over every device registered to their account: active sessions, trust scores, last-seen timestamps, IP addresses, and remote revocation.
- Real-Time Device List: Instant updates when new devices are registered or existing devices change status
- Forensic Timeline: Full reconstruction of device access patterns available for incident investigation
Audit Logging#
All device registrations, trust changes, authentications, and removals are written to an append-only audit log in PostgreSQL, integrated with SIEM platforms for security event correlation.
Use Cases#
- Law enforcement agencies reducing MFA friction for officers on recognised agency hardware while maintaining strict controls for off-network or unknown devices
- Government IT administrators enforcing re-verification after device inactivity periods aligned to security policy
- Enterprise deployments detecting credential-stuffing attempts through anomalous fingerprint patterns
- Security operations teams remotely revoking device trust during active incidents without waiting for password resets
Integration#
- FIDO2 and TOTP MFA providers for step-up authentication challenges
- SIEM platforms (Splunk, QRadar, Microsoft Sentinel) for device event correlation
- JWT authentication with auto-refresh for session continuity on trusted devices
- Organisational RBAC policies for controlling which roles can approve or revoke device trust