Account takeovers are becoming a trust problem, not just fraud

At a glance

What this is: This is Sumsub’s podcast discussion on how account takeover has shifted from obvious credential theft to trust hijacking, where normal-looking accounts are abused by fraudsters.

Why it matters: It matters because IAM, fraud, and financial crime teams all rely on signals that can be manipulated after takeover, so the control problem spans identity, verification, and transaction monitoring.

👉 Read Sumsub’s podcast discussion on account takeover and trust hijacking

Context

Account takeover is a fraud pattern where a real account is used by someone other than the legitimate holder. The core problem is not just initial access, but the way attackers blend into normal behaviour and stay inside trusted workflows long enough to move money or change account details. For identity and fraud teams, that makes takeover a governance problem as much as a detection problem.

In this episode, Sumsub frames the issue through financial crime and risk operations at Monavate. The discussion shows why KYC alone is not enough once an account has already passed onboarding, and why change detection across device, IP, contact details, and transaction behaviour has become central to defence. For teams building controls, the lesson is that trust must be continuously re-evaluated after login.

Key questions

Q: What breaks when account takeover controls focus only on login security?

A: Controls break after authentication, when a fraudster inherits an already trusted account and starts changing device, IP, contact details, and transaction patterns. Login checks may still pass, but the account is no longer being used by the legitimate holder. The real failure is treating successful authentication as proof of ongoing trust.

Q: Why do dormant accounts create extra account takeover risk?

A: Dormant accounts often regain trust when they wake up, even though the context around them may have changed. That makes sudden reactivation attractive to fraudsters because the account already carries history, limits, and reputation. Organisations should re-qualify trust before high-value activity rather than assuming past good standing still applies.

Q: What do security and fraud teams get wrong about behavioural change?

A: They often treat small changes as isolated events instead of a chain that signals takeover. A new device, a different IP, an updated email, and unusual transaction values may each look tolerable on their own, but together they show trust drift. Teams need correlation across signals, not just threshold alerts.

Q: Who is accountable when account takeover succeeds despite verification controls?

A: Accountability sits across identity, fraud, and operations, because takeover usually exploits a gap between onboarding, monitoring, and transaction decisioning. If a business relies on one team to verify the customer and another to catch abuse later, the attacker can move through the handoff. Governance should assign ownership across the full account lifecycle.

Technical breakdown

How account takeover evades normal verification patterns

Account takeover often succeeds because the attacker does not need to break the entire identity stack. They only need to inherit an already trusted account and then make changes slowly enough to stay below alert thresholds. Common signals include IP changes, device ID changes, address updates, email changes, and transaction behaviour that still fits some existing account profile. Fraud teams therefore have to look for a shift in the relationship between identity attributes, not just a failed login. The important technical point is that post-authentication behaviour becomes the real trust signal when credentials are already compromised.

Practical implication: monitor for compound attribute drift, not just authentication failure, because takeover often appears as a series of small, legitimate-looking changes.

Why dormant accounts and low-friction controls are attractive targets

Dormant accounts are useful to fraudsters because reactivation can look like legitimate return activity rather than compromise. Once an account has a history of good standing, many systems grant it more operational trust than a newly created account, which lowers friction for the attacker. That creates a governance blind spot: controls built for onboarding and first-use verification often weaken when the same account becomes inactive and then suddenly active again. The result is not a break in identity proofing at the start, but a failure to re-qualify trust when the context changes.

Practical implication: treat reactivated accounts as a distinct risk state and apply stronger re-verification before value movement or profile changes.

How relationship-based fraud turns into account takeover

The episode also points to the human side of takeover. Phishing, spam, romance scams, and other trust-building tactics are often used to collect just enough information to cross the account boundary. That means account takeover is frequently the endpoint of a broader social engineering chain, not a standalone technical exploit. For practitioners, the technical lesson is that behavioural telemetry needs to be paired with intelligence on suspicious contact patterns, because the attacker’s entry path may begin outside the account long before the takeover becomes visible inside it.

Practical implication: combine fraud telemetry with social engineering indicators so you can correlate trust-building activity with later account changes.

Threat narrative

Attacker objective: The attacker wants to convert a trusted account into a fraud channel that can move money, bypass controls, and delay detection until losses are already material.

1. Entry occurs when the fraudster uses phishing, spam, romance scams, or other social engineering to obtain enough details or access to reach a trusted account.
2. Escalation follows as the attacker changes device, IP, email, address, or spending behaviour in ways that remain subtle enough to avoid immediate detection.
3. Impact lands when the attacker uses the trusted account to move funds or carry out high-value transactions before the business or customer realises the account has been hijacked.

Breaches seen in the wild

• Cisco Active Directory credentials breach — Kraken ransomware group leaked Cisco Active Directory credentials.
• Emerald Whale breach — exposed Git config files led to 15K secrets stolen and 10K repo compromises.

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

NHI Mgmt Group analysis

Account takeover is no longer just credential abuse. It is trust hijacking after authentication. The critical control failure is not the login screen, but the assumption that a verified account remains trustworthy throughout the session, relationship, and transaction lifecycle. Once fraudsters can change device, IP, contact details, and spending patterns without triggering escalation, the identity programme has lost sight of the real trust boundary. Practitioners need to recognise that post-authentication trust now sits at the centre of fraud governance.

The operating model fails when onboarding and monitoring are treated as separate controls. The article shows a common governance split: one team proves the customer at entry, another tries to catch misuse later, and the gap between them becomes the attacker’s workspace. That gap is especially visible in financial services, where trusted accounts can be dormant for months before sudden activation. The implication is that lifecycle state and behavioural monitoring must be managed as one continuous control surface.

Account takeover reveals a named concept we should sharpen: trust drift. Trust drift is the gradual separation between what the account was verified to be and what its behaviour now indicates. The episode shows that drift can be invisible to rigid rules because each individual change may look harmless. The practical conclusion is that identity and fraud teams should model change over time, not just current-state checks.

Human trust manipulation is now part of the identity attack chain. The fraudster often starts outside the account with social engineering, then uses the resulting trust to cross into operational access. That collapses the boundary between customer education, financial crime, and identity security. Practitioners should stop treating these as separate problem domains when the attacker moves through all three.

Continuous re-validation matters more than historical account reputation. The discussion makes clear that long-standing good standing can become a liability when it lowers scrutiny after an account goes quiet and then returns with unusual activity. The governance lesson is simple: account history should inform risk, but it must never override fresh behavioural evidence. Teams that rely too heavily on reputation will miss the moment trust flips into abuse.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• For teams dealing with account takeover, the next step is to map account trust drift against lifecycle controls in the NHI Lifecycle Management Guide.

What this signals

Trust drift: account takeover programmes now need to model how trust decays after onboarding, not just how it is established. In practice, that means watching for device, IP, contact, and transaction changes as a single behavioural story rather than separate events. Teams that integrate fraud telemetry with lifecycle-aware identity monitoring will see takeover earlier, before money leaves the account.

The scale of the problem is reinforced by adjacent identity hygiene failures. When leaked secrets take an average of 27 days to remediate, according to The State of Secrets in AppSec, attackers have a long window to convert stolen access into fraud or account misuse. That is why account trust, secret exposure, and incident response should be treated as linked control domains, not siloed workstreams.

Practitioners should also align detection logic with the OWASP Non-Human Identity Top 10 and the Ultimate Guide to NHIs when machine or service credentials sit behind customer-facing workflows. The governance question is no longer whether an account is valid at login, but whether its behaviour still matches the trust profile the business is relying on.

For practitioners

• Correlate identity drift with transaction risk Link changes in device ID, IP address, email, delivery address, and merchant behaviour to a shared investigation queue so analysts can see takeover patterns as one event, not separate low-signal alerts.
• Re-verify dormant and reactivated accounts Treat accounts that have been inactive for months and then suddenly become active as higher-risk sessions, especially before balance transfers, payout changes, or new payee setup.
• Join fraud and identity telemetry Feed social engineering indicators, suspicious email domains, phone changes, and unusual login context into the same monitoring model so account recovery, step-up checks, and behavioural scoring inform each other.
• Review controls that over-trust historical good standing Test whether long-lived customer reputation suppresses alerts, relaxes limits, or bypasses verification in ways that let a takeover move money before manual review occurs.

Key takeaways

• Account takeover succeeds when trusted accounts remain trusted after the user is gone.
• Behavioural drift across device, IP, contact details, and transactions is the clearest practical signal of compromise.
• Teams need continuous trust re-validation across onboarding, monitoring, and recovery, not just stronger login checks.

Key terms

• Account takeover: Account takeover is when an attacker gains control of a legitimate account and uses it as if they were the real holder. In identity and fraud programmes, the challenge is not just access entry but the abuse that follows after trust has already been established.
• Trust drift: Trust drift is the gradual gap between what an account was originally verified to be and what its later behaviour shows. It matters because small, isolated changes can hide a larger compromise when teams fail to correlate them across the account lifecycle.
• Behavioural fraud signal: A behavioural fraud signal is a pattern in how an account acts that suggests misuse, even when authentication appears valid. Examples include device changes, IP shifts, unusual transaction values, or profile edits that do not fit the historical customer pattern.

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

This post draws on content published by Sumsub: Account Takeover: When Trust Gets Hijacked | "What The Fraud?" Podcast. Read the original.