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 and user experience, but identity-based attacks and AI-powered bots are eroding the trust signals traditional security depends on.

Why it matters: IAM and fraud teams need to treat device trust as one signal in a broader identity control set, because spoofable identifiers and AI-driven abuse can undermine both security decisions and customer journeys.

By the numbers:

• 70% of enterprises consider identity-based attacks, ed attacks, including fake account creation and account takeovers, their top security concern.
• 40% of these attacks are AI-powered, reflecting the growing sophistication of modern threats.
• 88% of security professionals report a rise in AI-powered bot attacks, where bots can mimic trusted devices and identities to evade detection.
• 775 million stolen credentials are available for sale, e for sale, giving fraudsters a direct path into systems that should be secure.

👉 Read Arkose Labs' article on Arkose Device ID and AI-powered fraud

Context

Identity-based fraud succeeds when security teams trust signals that can be copied, replayed, or correlated too loosely to a real subject. Device identifiers, browser traits, and session behaviour can help separate legitimate users from bots, but they do not become trustworthy just because they are persistent.

For IAM, fraud prevention, and account security programmes, the problem is not only attack volume but signal quality. If device reputation, user context, and transaction risk are not evaluated together, attackers can move from registration to login to payment with very little resistance.

Key questions

Q: How should security teams use device identification without over-trusting it?

A: Use device identification as a correlation signal, not as proof of legitimacy. It works best when combined with credential history, session behaviour, account risk, and transaction context. If the same device can be spoofed or replayed, then a trusted-device decision should always require supporting evidence before access or payment is approved.

Q: Why do AI-powered bots make identity-based fraud harder to stop?

A: AI-powered bots can adapt to challenge responses, mimic trusted device traits, and automate repeated attempts at scale. That reduces the value of fixed thresholds and static device rules. Defenders need layered controls that detect repeated patterns early and can escalate scrutiny before the attacker reaches recovery or payment steps.

Q: What breaks when device trust is treated as a standalone control?

A: Standalone device trust breaks when attackers reuse credentials, spoof browser signals, or simulate normal session behaviour long enough to pass a simple reputation check. The control can look effective while missing takeover, account sharing, or fraudulent payment activity. Device identity only works when it is governed as one part of a broader identity decision.

Q: Who should own device risk decisions in an IAM programme?

A: Device risk decisions should be shared across fraud, IAM, and customer identity teams because the control affects authentication, account security, and transaction authorisation at once. If those teams work separately, the organisation usually creates inconsistent friction and blind spots that attackers can exploit across the customer journey.

How it works in practice

Persistent device identifiers and spoofable trust signals

A device identifier ties a session to a repeatable device profile using browser configuration, hardware attributes, and telemetry. That helps organisations distinguish returning devices from unfamiliar ones, but it is still a derived signal rather than proof of legitimate intent. In fraud environments, attackers can manipulate the surrounding environment, reuse credentials, or automate sessions in ways that make a single signal look trustworthy when it is not. The technical value is correlation, not certainty. Device identity is strongest when it is joined to account history, behavioural patterns, and risk scoring rather than treated as a standalone trust anchor.

Practical implication: use device identity as one input to policy decisions, not as a replacement for account, session, or payment verification.

AI-powered bots and account takeover pathways

AI-assisted fraud reduces the cost of reconnaissance, automation, and adaptation. Bots can cycle through login attempts, mimic device traits, and adjust behaviour based on challenge responses, which makes static thresholding less effective than it once was. Account takeover usually begins with a credential or session advantage, then expands through weak step-up controls or overly permissive recovery paths. Device identification helps expose repetition and reuse, but the deeper control problem is that the attacker can look like a legitimate returning user long enough to cross the trust boundary. The real risk is not just fraud volume, but the speed at which attack infrastructure can evolve.

Practical implication: detect repeated device and session patterns early, before the attacker reaches account recovery or payment authorisation.

Versioning, continuity, and the lifecycle of device trust

Arkose Labs notes that its device ID uses versioning to preserve continuity when identifier logic changes. That matters because device trust systems fail when a change in telemetry rules severs the link between historical and current risk. If the identifier cannot be mapped over time, defenders lose fraud lineage and attackers gain a fresh start. This is an identity lifecycle problem as much as a detection problem: trust signals need governance across their creation, change, and retirement. Without that lifecycle view, teams end up over-weighting either stale reputation or newly reset identifiers.

Practical implication: govern device identifiers as lifecycle assets, with clear rules for continuity, change management, and retirement.

NHI Mgmt Group analysis

Device identity is not a trust boundary, it is a correlation layer. The article treats persistent device identifiers as a way to separate legitimate users from fraudulent traffic, but that signal only has value when it is combined with account, session, and behavioural context. In identity security terms, the device becomes evidence, not proof. Practitioners should therefore stop treating device reputation as a decisive control and start treating it as one input in a broader identity decisioning model.

AI-powered fraud collapses the value of static trust signals. Once attackers can adapt device traits, session timing, and interaction patterns in real time, any control that assumes stable human-like behaviour becomes easier to bypass. That is why this issue belongs in the same governance conversation as NHI and automated identity abuse: the problem is not just who holds the credential, but how quickly an attacker can reshape the signal environment around it. Practitioners need fraud controls that assume the attacker will learn from the challenge path.

Identity lifecycle governance must extend to device reputation systems. The article’s versioning point exposes a common failure mode: when signal logic changes without continuity, historical risk context is lost and malicious actors inherit a clean slate. That is the same class of governance problem seen in unmanaged credentials and stale entitlements. Ephemeral trust debt: security teams accumulate exposure whenever they allow trust signals to expire, reset, or drift without preserving lineage. Practitioners should manage device signals as governed assets, not disposable telemetry.

The strongest defence is policy choreography, not a single anti-bot control. Device ID can improve precision, but it does not replace step-up authentication, risk-based challenge design, or payment scrutiny. The article shows why fraud teams need layered decisioning that can adapt to trusted, unknown, and suspicious devices without making every interaction equally hard. Practitioners should tune controls to the risk of the action, not the convenience of the channel.

Fraud defence is now an identity governance problem as much as a detection problem. When identity-based attacks are driving enterprise concern, security leaders must align fraud controls with IAM, customer identity, and lifecycle governance rather than leaving them in separate silos. That is where device identity becomes most useful and most dangerous: it can reduce friction, but only if the organisation understands exactly what it can and cannot prove. Practitioners should reassess whether their current trust model is still defensible under AI-assisted abuse.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• The pattern is already visible in the 52 NHI breaches Report, which shows how identity trust gaps become breach paths when credentials, access, and oversight drift out of sync.

What this signals

Ephemeral trust debt: device reputation, like any identity signal, becomes a liability when teams cannot preserve lineage across changes in rules, telemetry, or access state. Programmes that separate fraud operations from IAM governance will keep re-losing context every time a signal is recalibrated.

Arkose Labs' survey numbers point to a wider control issue: once identity-based attacks become the top concern, security teams need to decide which signals deserve enforcement authority and which should remain advisory. That decision belongs in policy design, not in the fraud queue alone.

If you are already mapping NHI and machine identity controls, the governance lesson here is familiar. Identity systems that can be copied, replayed, or reset need lifecycle thinking, and that is why device trust should be reviewed alongside the broader access model rather than as a one-off detection layer.

For practitioners

• Treat device identity as a decision signal, not a trust verdict. Combine device identifiers with account age, credential history, session patterning, and transaction context before allowing access or payment completion. Do not let a known device bypass other checks unless the risk model has been explicitly tested against credential replay and bot automation.
• Harden recovery and step-up paths against AI-assisted abuse. Review password reset, account recovery, and challenge bypass logic for paths that reward a fraudster who has already mimicked a trusted device. Add friction at the point where takeover becomes monetisation, especially in login and payment flows.
• Preserve lineage across device reputation changes. Version your device trust logic so historical fraud patterns remain visible after updates, and retain a mapping between old and new identifiers. Without continuity, you create clean breaks that attackers can exploit to reset their risk profile.
• Align fraud telemetry with IAM governance. Bring fraud, IAM, and customer identity teams into the same policy review process so device signals, authentication controls, and transaction rules are tuned together. The goal is consistent governance across registration, login, and payment decisions.

Key takeaways

• Device identification can improve fraud precision, but it does not turn a spoofable signal into a trust boundary.
• Arkose Labs' own data shows identity-based attacks and AI-powered bot activity are already mainstream concerns, not edge cases.
• The practical response is layered governance across device, account, session, and payment decisions, with lifecycle control over reputation data.

Key terms

• Device identity: Device identity is the practice of assigning a repeatable signal to a device so systems can recognise returning traffic and compare it against prior behaviour. In security programmes, it is useful for correlation and fraud detection, but it is not proof of legitimate intent on its own.
• Account takeover: Account takeover is the unauthorised capture of a legitimate user account, usually after an attacker gains access through stolen credentials, session abuse, or recovery-path weakness. It is an identity problem because the attacker succeeds by appearing to be the valid user long enough to pass controls.
• Signal lineage: Signal lineage is the ability to preserve the history of an identity-related signal across changes in logic, versioning, or telemetry. Without lineage, defenders lose continuity and attackers can benefit from what looks like a fresh, low-risk state even when the underlying behaviour has not changed.
• Risk-based authentication: Risk-based authentication is a control model that adjusts authentication strength based on context such as device, location, behaviour, and transaction sensitivity. It is most effective when the risk inputs are validated, continuously updated, and combined rather than treated as a single trust source.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 governance in your organisation, it is worth exploring.

This post draws on content published by Arkose Labs: Strengthening Security and Elevating User Experiences with Arkose Device ID. Read the original.