Arkose Device ID and the limits of device trust in fraud defense

At a glance

What this is: Arkose Labs argues that device identification can improve fraud detection across customer journeys, but device trust alone cannot keep pace with AI-assisted account takeover, session hijacking, and fraudulent payments.

Why it matters: IAM, CIAM, and fraud teams need to treat device signals as one input in a broader trust model, because stronger device correlation does not replace step-up controls, session governance, or risk-based verification.

By the numbers:

• More than 70% of enterprises consider identity-based attacks their top security concern.
• 40% of identity-based attacks are AI-powered.
• 88% of security professionals report a rise in AI-powered bot attacks.

Context

Device trust in fraud defence means using signals from hardware, browser state, and session telemetry to decide whether a login, registration, or payment looks legitimate. The problem is that those signals are increasingly easy to spoof or replay when attackers use automation and AI-assisted tactics.

Arkose Labs is framing Device ID as a way to improve visibility and reduce friction, but the deeper governance issue is that device recognition is not the same as identity assurance. Fraud teams still need controls that work when a device is known, a session is hijacked, or a legitimate-looking request is actually malicious.

The article's core claim is not that device identification is unnecessary. It is that device trust should be treated as a risk signal inside a broader identity decisioning model, not as a substitute for step-up verification or session governance.

Key questions

Q: What breaks when trust signals are treated as proof of identity?

A: Trust signals are useful for prioritisation and risk scoring, but they are not a substitute for cryptographic proof. If teams treat reputation, verified-brand cues, or relationship history as identity assurance, they create a path for social engineering and impersonation. Strong programmes separate trust decisions from authentication decisions and keep the proof layer enforceable.

Q: Why do AI-powered bots make device-based fraud controls less reliable?

A: AI-powered bots can mimic human pacing, reuse browser characteristics, and adapt their behavior to the control being tested. That means the same device fingerprint may be compatible with both legitimate use and malicious automation. Teams need layered risk decisions because device recognition alone cannot distinguish intent.

Q: What are the signs that device trust is failing in login and payment flows?

A: Common signs include high repeat usage from supposedly trusted devices, unusual session reuse, account sharing across locations, and fraud that persists even after device-based suppression rules. When these patterns rise, the device signal is no longer separating good traffic from bad traffic with enough precision.

Q: How should fraud teams balance device signals with step-up verification?

A: Fraud teams should use device signals to reduce friction only when other context supports the transaction. If the device is known but the session, payment behavior, or login pattern is unusual, step-up verification should take precedence. That keeps convenience from overriding risk.

How it works in practice

Why device fingerprinting does not equal identity assurance

Device identification combines attributes such as browser configuration, hardware signals, and session telemetry to generate a reusable identifier. That helps correlate activity across sessions, but it does not prove that the person or bot behind the request is authorized. Attackers can borrow, spoof, or replay many of the signals used for trust decisions, especially when the control logic treats a device as inherently reliable. The technical mistake is conflating continuity with authenticity. A persistent identifier can tell you that the same endpoint returned, but not whether the actor using it is legitimate.

Practical implication: treat device signals as one factor in risk scoring, not as a standalone trust decision.

How AI-powered bots undermine login and payment signals

AI-assisted bots reduce the value of static heuristics because they can adapt behavior, rotate infrastructure, and mimic expected interaction patterns. In login and payment flows, that means a device can look consistent while the intent behind the session is fraudulent. This shifts the defensive problem from spotting obvious anomalies to separating legitimate continuity from adversarial imitation. When the attacker controls repetition, timing, and request shape, conventional trust markers become much less durable. The right technical lens is session-level decisioning with layered verification, not a single device verdict.

Practical implication: add escalation paths that trigger when risk is low-noise but behavior is still inconsistent.

Why session hijacking still matters even when the device is known

Session hijacking breaks the assumption that a trusted device and an authenticated user remain aligned for the life of the session. If an attacker steals or reuses a session, the device may still appear familiar while the actor is no longer legitimate. That is why session governance, token binding, and anomaly detection matter even in environments with strong device recognition. The device did not fail in isolation. The trust model failed because it treated the device as proof of session legitimacy rather than as one signal among several.

Practical implication: pair device identity with session controls that detect abuse after authentication.

NHI Mgmt Group analysis

Device trust is a fraud signal, not an identity control: Device IDs can improve correlation across sessions, but they do not establish who is behind the interaction. Once teams start treating device continuity as proof of legitimacy, they collapse the distinction between recognition and authorization. The practitioner conclusion is simple: device intelligence belongs inside decisioning, not above it.

AI-powered fraud is eroding static trust assumptions: The article's numbers point to a shift in attacker economics, where automation can imitate enough of the customer journey to defeat simple heuristics. That is not a device problem alone. It is a control-design problem in which static trust markers are losing value faster than teams can tune them.

Session governance remains the missing layer in many fraud stacks: Even accurate device identification cannot stop abuse once a session is hijacked or a known device is repurposed for malicious actions. This is where CIAM, fraud, and identity governance meet: the programme must decide when continuity is acceptable and when the session must be challenged, not simply recognized. Practitioners need controls that survive post-login compromise.

Persistent device identifiers create a useful, but bounded, identity graph: The named concept here is the identity trust gap, the space between recognizing a device and proving a legitimate actor. That gap will widen whenever organisations use device signals to suppress friction without matching them to risk-based step-up, token protection, and session monitoring. The practitioner conclusion is to design for bounded trust, not device certainty.

What this signals

Identity trust gap: The useful mental model here is not device fingerprinting versus fraud, but recognition versus assurance. A device can be familiar and still be unsafe, so programmes need a policy layer that decides when continuity is enough and when challenge is mandatory.

The control question for CIAM teams is whether device intelligence is reducing friction only for legitimate users or also reducing resistance for attackers. If the same signal is suppressing both bot noise and fraud friction, the trust model is probably overextended.

For practitioners

• Separate device recognition from authentication decisions Use device identifiers to enrich risk scoring, but keep login approval tied to explicit authentication and contextual policy checks.
• Add step-up triggers for trusted-device abuse Require additional verification when a familiar device shows improbable session behavior, payment risk, or account-sharing patterns.
• Monitor session continuity after device trust is established Track token reuse, location shifts, and rapid context changes so a trusted device does not mask hijacked session activity.
• Correlate device reputation with fraud workflows Feed known-bad device history into fraud rules for registration, login, and payments so the same actor is not repeatedly relearned as trusted.

Key takeaways

• Device identification can improve fraud decisions, but it does not prove that the actor using the device is legitimate.
• The article's evidence points to a growing mix of identity-based attacks, AI-powered automation, and bot activity that weakens static trust signals.
• Teams need to pair device intelligence with authentication, session monitoring, and risk-based challenge paths or they will keep confusing recognition with assurance.

Key terms

• Device Trust: Device trust is the confidence that a requesting endpoint is known, managed, and in a compliant state. It matters because identity alone does not prove safety. In zero trust programmes, device trust becomes one of the inputs used to decide whether access should be granted or sustained.
• Device Fingerprinting Accuracy: Device fingerprinting accuracy is the rate at which a system correctly recognises a returning device as the same device on later visits. In practice, it measures how reliably identification persists over time, especially when browser, hardware, and network signals are reused or change slightly.
• Session Hijacking: Session hijacking is the takeover of an authenticated session after the original login has completed. The attacker does not need to know the password if they can use the active session token, which is why session monitoring and revocation are essential controls in SaaS identity governance.
• Risk-Based Authentication: An access model that changes verification requirements based on the estimated risk of the request. It combines identity assurance, device posture, application sensitivity, and contextual signals to decide whether to allow, block, or step up verification before access is granted.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.