TL;DR: Device identification can reduce login friction by recognising trusted returning devices and applying adaptive checks only when risk signals justify them, according to Arkose Labs. The governance issue is not whether device ID improves user journeys, but whether identity teams can keep adaptive controls aligned with fraud pressure without weakening assurance.
NHIMG editorial — based on content published by Arkose Labs: Device ID Reducing Friction, Boosting Engagement: The Power of Device ID
By the numbers:
- Nearly 1 in 6 online shoppers abandon purchases after just one negative interaction.
- Device ID solutions provide over 35 additional real-time device signals for precision risk insights.
Questions worth separating out
Q: How should security teams use device ID without overtrusting familiar devices?
A: Security teams should treat device ID as a probabilistic risk signal, not as proof that a session is safe.
Q: Why does device identification matter for customer identity programmes?
A: Device identification matters because it lets teams balance conversion and assurance instead of forcing every user through the same authentication path.
Q: What breaks when device-based trust is treated as a yes-or-no decision?
A: What breaks is policy precision.
Practitioner guidance
- Separate device trust from identity assurance Use device recognition as one input into adaptive access, and keep account state, session history, and behavioural risk in the decision path.
- Tune friction thresholds to business risk Define when a known device can skip step-up checks and when it must be challenged, then test the policy against abandonment and fraud metrics.
- Correlate devices across accounts Look for repeated device patterns across registrations, logins, and recovery flows so one abused device does not remain invisible inside separate user records.
What's in the full article
Arkose Labs' full article covers the operational detail this post intentionally leaves for the source:
- A closer breakdown of how device ID uses hardware and software signals to create persistent identifiers.
- Examples of over 35 real-time device signals used to support risk-based decision-making.
- Implementation detail on how device ID integrates with existing user flows and risk engines.
- The vendor's own framing of how to apply friction surgically for high-risk devices.
👉 Read Arkose Labs' article on device ID and frictionless access journeys →
Device ID and customer friction: what IAM teams should watch?
Explore further
Device identification is not an identity proof, it is an assurance signal. The article frames device ID as a way to recognise trusted returning devices, but that is only safe if teams treat the signal as probabilistic rather than authoritative. In IAM terms, the device becomes one factor in a broader risk decision, not a replacement for account state, session context, or user behaviour. Practitioners should use device ID to refine access decisions, not to declare the device trusted in every context.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, showing how limited identity visibility still is across many environments.
A question worth separating out:
Q: Who should own device risk policy in an organisation?
A: Device risk policy should be jointly owned by IAM, fraud, and product or customer experience leaders. IAM defines the access rules, fraud teams monitor abuse patterns, and product teams measure user impact. Without shared ownership, the control tends to drift toward either excessive friction or weak assurance.
👉 Read our full editorial: Device ID changes the balance between friction and fraud risk