New account fraud exposes the limits of behavioral context alone

At a glance

What this is: This is an analysis of how new account fraud evades registration controls and which behavioral signals help identify it.

Why it matters: It matters because IAM, fraud, and identity teams must decide which registration signals are reliable enough to inform account risk decisions across human, NHI, and automated journeys.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Transmit Security's analysis of new account fraud detection

Context

New account fraud is the abuse of registration flows to create accounts for malicious use, often by mixing real, synthetic, and stolen identity data. In practice, defenders are trying to evaluate behaviour before they have enough history to trust it, which makes the first session one of the hardest points in the identity lifecycle to secure.

That creates a governance problem for IAM and fraud teams at the same time. Registration data may be sparse, device signals may be noisy, and human-like bots can imitate normal activity closely enough that static rules miss them, which is why behavioural scoring and model governance matter as much as front-end verification.

Key questions

Q: How should teams reduce new account fraud without blocking legitimate users?

A: Use layered scoring across behavioural signals, device reputation, browser fingerprinting, and geolocation rather than relying on any single registration attribute. Legitimate users and fraud actors can both look unusual in isolation, so the goal is to identify combinations that meaningfully raise risk while preserving a review path for borderline cases.

Q: Why do registration flows create such a difficult identity decision point?

A: Because teams must decide whether a user is legitimate before they have much behavioural history to compare against. That means the first session carries outsized trust value, and fraudsters exploit that by shaping the evidence they present during enrolment. The result is a governance problem, not just a detection problem.

Q: What do security teams get wrong about bot and emulator detection?

A: They often treat bot indicators as if they were stable, binary proof of fraud. In reality, attackers can slow down, vary input methods, randomise browser attributes, and use emulators to look less automated. Detection works better when teams score patterns over time and across multiple signals.

Q: How do you know if a fraud model is still working in production?

A: Look for stable false-positive rates, predictable alert volumes, and preserved precision or recall against the outcomes your team actually wants. If registration behaviour changes, the model may be drifting even when its output volume looks healthy, so daily monitoring and retraining signals matter.

Technical breakdown

Behavioural signals in registration risk scoring

Registration models look for differences between legitimate and malicious account creation by analysing typing speed, field dwell time, mouse movement, copy-paste behaviour, and navigation patterns. These signals are useful because they reveal whether the user is hesitating, correcting, or moving through forms in a way that matches a natural person. But behavioural data is not inherently trustworthy. A fraudster can slow down to look human, a bot can emulate common patterns, and high-volume campaigns can learn the application flow well enough to move faster than genuine users. The technical challenge is not just detecting anomalies, but deciding which anomalies still have predictive value when adversaries adapt.

Practical implication: treat behavioural features as one input to risk scoring, not as a standalone fraud decision.

Device, browser, and geolocation fingerprinting

Identity fraud controls often combine device type, operating system, browser attributes, location, and network patterns to build a registration fingerprint. Sudden shifts in those properties can indicate automation, emulator use, or coordinated abuse. Private browsing complicates this by randomising browser attributes and weakening fingerprint consistency, while emulators allow fraudsters to scale from clean-looking devices. The architecture works best when these attributes are evaluated as a distribution, not as isolated flags. A single unusual property may be benign, but repeated combinations across many registrations can indicate a campaign rather than an individual outlier.

Practical implication: correlate device, browser, and location signals before taking blocking action.

Model training, thresholds, and monitoring for fraud detection

Machine-learning fraud models depend on preprocessing, labelled data where available, and careful threshold selection. If raw data is incomplete or biased, the model can learn the wrong patterns and underperform in production. Supervised models can be measured with true and false positives and negatives, while unsupervised models rely more heavily on uniqueness and similarity measures. After deployment, the model must be monitored for drift, false-positive pressure, and changes in attacker behaviour. In other words, detection quality is a lifecycle problem, not a one-time training exercise.

Practical implication: establish model monitoring and retraining rules before attackers force the tuning cycle for you.

Threat narrative

Attacker objective: The attacker wants to create trusted-looking accounts that can be used to scale fraud, bypass controls, or support later abuse.

1. Entry occurs when fraudsters start account opening with fake, synthetic, or mixed identity data, often supported by bots, emulators, or human-assisted automation.
2. Escalation occurs when they adapt the registration flow with realistic typing, private browsing, or device changes that reduce the value of simple behavioural rules.
3. Impact occurs when the malicious account is created and can be used for abuse, scaling, or downstream fraud activity before defenders can distinguish it from a legitimate enrolment.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• JetBrains GitHub plugin token exposure — CVE-2024-37051 in JetBrains IntelliJ GitHub plugin exposed GitHub access tokens.

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

NHI Mgmt Group analysis

New account fraud is an identity trust problem, not just a bot problem. The article shows that registration abuse succeeds because defenders are trying to infer legitimacy before they have enough behavioural history. That is an IAM decision problem as much as a fraud problem, because the first enrolment event often sets the trust baseline for the account lifecycle. Teams should treat registration confidence as a governed identity outcome, not a purely technical detection score.

Behavioural fingerprinting has a finite shelf life: once fraud actors learn the registration flow, the same signals that separate humans from automation can be imitated or reversed. Slow typing can be faked, fast navigation can be rationalised, and private browsing can be used to randomise fingerprints. The practical implication is that teams must assume signal adaptation and design for layered evidence, not one dominant indicator.

Model governance is the real control surface. The article makes clear that preprocessing, thresholds, daily checks, and retraining quality determine whether the model remains useful as attacker behaviour changes. That aligns with NIST CSF detection and response discipline, but the deeper lesson is operational: fraud detection fails when organisations treat model tuning as a one-off implementation instead of an ongoing identity control.

New account fraud exposes a lifecycle gap between verification and trust assignment. Registration often grants more trust than the evidence collected at enrolment can justify. That gap matters across human identity programmes, but it becomes sharper when organisations reuse the same registration logic for bots, assisted fraud, and account automation without revisiting what “known user” actually means.

Named concept: registration-context debt. The article describes a condition where the system knows too little about the user at the moment trust is assigned, yet the account is already usable. That debt accumulates when teams over-rely on first-session signals without lifecycle follow-up, and practitioners should treat it as a structural weakness in account opening governance.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% having no or low visibility and 47% having only partial visibility, according to The State of Non-Human Identity Security.
• The same research found that lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, which shows how often trust fails after issuance rather than at first access.
• For a broader governance frame, see NHI Lifecycle Management Guide for how visibility, rotation, and offboarding fit together across the identity lifecycle.

What this signals

Registration-context debt: the longer a programme relies on first-session signals alone, the more trust it assigns before evidence exists. For teams managing identity risk, the practical issue is not whether behavioural scoring works in a lab, but whether it can survive real attacker adaptation and still support safe account opening.

With 1 in 4 organisations already investing in dedicated NHI security capabilities and another 60% planning to do so within twelve months, according to The State of Non-Human Identity Security, identity governance is moving from verification-only thinking toward lifecycle control. That shift matters because account-opening controls increasingly need to align with downstream access and review processes.

Fraud teams should watch for the same pattern IAM teams see in machine identity programmes: weak early trust assignments create remediation debt later. The lesson is to connect enrolment scoring, identity review, and response playbooks so the account lifecycle does not become a blind spot after the first login.

For practitioners

• Weight enrolment signals by confidence, not presence Use behavioural, device, browser, and location features together, and suppress single-signal blocking unless the combination crosses a documented risk threshold.
• Separate human verification from trust assignment Require a second-stage control for high-risk registrations so the account is not fully trusted just because the form was completed successfully.
• Tune model thresholds to operational capacity Set alert and block thresholds against the team’s ability to review false positives, then revisit them as registration volumes and fraud patterns change.
• Monitor drift in registration patterns daily Track shifts in typing speed, device mix, emulator prevalence, and geolocation clusters so attacker adaptation is visible before the model degrades.

Key takeaways

• New account fraud exploits the fact that defenders often know too little at the moment trust is assigned.
• Behavioural and device signals help, but they remain vulnerable to attacker adaptation, so layered scoring is essential.
• Model governance, monitoring, and retraining are operational controls, not housekeeping tasks, because fraud patterns change quickly.

Key terms

• New Account Fraud: New account fraud is the creation of accounts for malicious purposes using stolen, synthetic, or mixed identity data. It targets the point where a business knows the least about a user, making enrolment controls and early behavioural evidence especially important for risk decisions.
• Behavioural Fingerprinting: Behavioural fingerprinting is the practice of inferring risk from how a user interacts with a registration flow, including typing, timing, and navigation patterns. In identity programmes, it is most useful when combined with device and network signals rather than treated as a standalone proof of legitimacy.
• Model Drift: Model drift is the gradual loss of predictive accuracy when attacker behaviour, user behaviour, or environmental conditions change. In fraud detection, drift matters because a model that once separated normal from malicious registration can become unreliable even if the underlying code has not changed.

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 NHI governance in your organisation, it is worth exploring.

This post draws on content published by Transmit Security: new account fraud detection and machine-learning based prevention. Read the original.