Device intelligence and fraud decisions across the user lifecycle

At a glance

What this is: This is a fraud operations guide on using device intelligence to make earlier identity decisions across the user lifecycle.

Why it matters: It matters because IAM, fraud, and identity teams need proportionate controls that combine device, behavioural, identity, and payment signals without blocking legitimate users.

By the numbers:

• In 2025, 44% of fraudsters used developer tools to simulate device behavior.
• Synthetic identity fraud in the US rose 300% in a single year.

👉 Read SumSub's guide to device intelligence for fraud decisions

Context

Device intelligence is the practice of using signals from a device to judge whether a session, account action, or transaction looks legitimate. The governance gap is that attackers can change common identifiers quickly, but they cannot fully hide device-level patterns, which makes device data a valuable control point for fraud teams.

This article is really about decision quality across the user lifecycle, from signup to refunds and investigations. It treats device intelligence as one signal in a broader identity model, not as a standalone answer, which is the right starting point for fraud and identity programmes that need to reduce friction without losing control.

Key questions

Q: How should fraud teams use device intelligence in signup and login decisions?

A: Use device intelligence as one part of a layered decision model. At signup and login, combine device signals with identity, behavioural, and payment data, then choose between approve, monitor, step up, review, or block. The goal is to catch coordinated abuse early without treating every anomaly as a hard failure.

Q: Why do device signals matter when fraudsters can rotate other identifiers quickly?

A: Device signals matter because email addresses, IPs, phone numbers, and payment details can change quickly, but device behaviour is harder to fake consistently across a full journey. That makes device intelligence a useful context signal for distinguishing a genuine user from a coordinated abuse pattern.

Q: What do fraud teams get wrong about device data?

A: The biggest mistake is treating device data as a standalone truth source. Device signals can be spoofed, noisy, or misleading unless they are interpreted alongside identity and behavioural evidence. Teams also overblock when they do not separate suspicious patterns from legitimate reuse, shared devices, or unusual travel.

Q: How can teams reduce false positives without missing fraud?

A: Set different thresholds for different lifecycle stages and transaction types. A low-risk login, a new account, and a payout request should not trigger the same response. Good programmes use graduated controls, so only aligned evidence triggers the strongest friction.

Technical breakdown

Device fingerprinting vs device intelligence

Device fingerprinting tries to recognise a device by collecting attributes such as browser configuration, OS traits, and other stable signals. Device intelligence is broader: it interprets those signals in context and combines them with identity, behavioural, and payment data to support a decision. That distinction matters because a fingerprint alone can be noisy or spoofed, while intelligence is about pattern recognition across time and events. In fraud operations, the value is not just identifying a device, but understanding whether the same device behaviour fits a known risk pattern such as account creation abuse or payout fraud.

Practical implication: use device signals as one input to a decision engine, not as a single block-or-allow gate.

How device signals support the fraud lifecycle

Device data becomes useful at different points in the fraud lifecycle. At signup it can expose fake accounts and multi-accounting. During login it can support account takeover detection. At payment and payout stages it helps identify abuse patterns that a static identity check would miss. The key technical idea is correlation across lifecycle stages. A device that looks benign at registration may become suspicious when linked to repeated failed logins, abnormal velocity, or mismatched payment behaviour later. That is why the article frames device intelligence as a lifecycle control rather than a single-step verification method.

Practical implication: map device signals to each lifecycle stage and define what evidence should trigger review, step-up, or block.

Combining device, behavioural, and payment data

Device intelligence is strongest when it is fused with identity, behavioural, and payment signals. Device data answers whether the environment looks consistent. Behavioural data adds how the user interacts. Payment data shows whether the financial trail fits the rest of the session. Together they improve confidence and reduce false positives. This is a common fraud pattern: no single signal is decisive, but a composite view can distinguish a legitimate user from a coordinated abuse attempt. The article’s emphasis on proportionate friction reflects this. Good fraud controls do not treat every anomaly as a block condition; they escalate only when multiple signals align.

Practical implication: define scoring and escalation rules that require multiple signals before you apply the harshest controls.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Device intelligence is now a governance layer, not just a detection layer. The article shows that fraud teams are using device data earlier in the lifecycle because identifiers that used to anchor decisions are easy to rotate. That shifts the control problem from after-the-fact investigation to pre-transaction decisioning. For identity programmes, the practical conclusion is that device context must sit inside access and transaction governance, not beside it.

Device data only works when it is interpreted as part of identity context. A device signal by itself can suggest risk, but the real value comes from combining it with behavioural, identity, and payment evidence. That is the right model for fraud operations because attackers can mimic one signal at a time, but they struggle to make all signals align consistently. Practitioners should treat inconsistency across signals as the signal, not any single attribute in isolation.

Friction should be precision-controlled, not universally increased. The article’s strongest operational message is that teams need to apply step-up, review, or block at the right point in the user journey. Broad friction creates avoidable abandonment, while no friction creates abuse. The governance challenge is therefore proportionate control design, where risk thresholds are explicit and tied to lifecycle stage and transaction value.

Device intelligence exposes a named concept: contextual signal fusion. Device signals are most useful when they are fused with identity and payment context to create a decision that is stronger than any one input. That is a programme design choice, not a point product feature. The implication for fraud and IAM leaders is to manage the decision layer as a governed capability, with clear rules for when the system escalates human review.

From our research:

• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which is why identity signals become unreliable when governance is fragmented, according to Ultimate Guide to NHIs.
• For a broader control model, see NHI Lifecycle Management Guide, which ties lifecycle governance to provisioning, rotation, and offboarding.

What this signals

Contextual signal fusion is becoming the practical pattern for fraud and identity teams because single-signal decisions are too easy to evade. With 79% of organisations having experienced secrets leaks and 77% of those incidents causing tangible damage, according to our research on NHIs, governance has to focus on the quality of the decision layer as much as the quality of the signal.

The next maturity step is to tie device intelligence to governance outcomes rather than detection volume. Teams should watch for cases where step-up requests, manual reviews, and blocks are being triggered by one noisy signal instead of a consistent pattern across device, identity, behaviour, and payment context.

For practitioners

• Map device signals to lifecycle stages Define which device indicators matter at signup, login, account recovery, payment, payout, refund, and investigation. Different stages need different thresholds because the same pattern can mean onboarding risk in one context and legitimate reuse in another.
• Combine signals before making hard decisions Require alignment between device, identity, behavioural, and payment evidence before blocking a user. Use a risk score or decision tree that makes it possible to monitor or step up first, especially where legitimate users may share devices or networks.
• Calibrate friction to the abuse pattern Use step-up or manual review for ambiguous cases, and reserve block actions for clear multi-signal abuse. This avoids overfitting to device anomalies that may be explained by legitimate user behaviour, travel, browser changes, or shared devices.
• Document the common failure modes Train fraud and identity teams to recognise the six recurring errors the guide calls out, including overtrusting device data and applying one-size-fits-all thresholds. Pair that guidance with review of 52 NHI Breaches Analysis where lifecycle control failures caused broader identity exposure.

Key takeaways

• Device intelligence is most useful when it improves fraud decisions across the full user lifecycle, not when it is treated as a single authentication signal.
• The evidence in the article points to a shift toward contextual decisioning, where device data gains value only when paired with identity, behavioural, and payment signals.
• Fraud teams should tune controls to the lifecycle stage and abuse pattern, so friction is precise enough to stop abuse without blocking legitimate users.

Key terms

• Device Intelligence: Device intelligence is the practice of interpreting signals from a device to assess whether a session or transaction is likely legitimate. It goes beyond fingerprinting by combining device context with behavioural, identity, and payment evidence to support a risk decision.
• Device Fingerprinting: Device fingerprinting is a method for identifying a device from attributes such as browser settings, operating system traits, and other configuration details. It is useful for recognition, but it is weaker than contextual analysis when attackers can spoof or change attributes quickly.
• Contextual Signal Fusion: Contextual signal fusion is the process of combining multiple weak signals into a stronger decision input. In fraud and identity governance, it means interpreting device, behavioural, identity, and payment data together so that risk decisions reflect the full user journey rather than one noisy indicator.

Deepen your knowledge

Device intelligence, lifecycle-based fraud decisions, and contextual signal fusion are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a similar decision model across identity programmes, it is worth exploring.

This post draws on content published by SumSub: Device Intelligence guide for fraud teams. Read the original.