Why do synthetic identities cause such large losses?

Why This Matters for Security Teams

Synthetic identities are expensive because they turn trust itself into the attack path. A fake or blended identity can pass onboarding checks, build history, and become embedded in billing, credit, or access workflows before the loss event occurs. That makes detection harder than with immediate fraud. For identity teams, the issue is not just a bad record; it is the compounding effect of time, legitimacy, and operational access.

This pattern is closely related to NHI risk management because long-lived credentials and weak lifecycle controls let an identity remain credible far longer than intended. NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs, which shows how often identity sprawl hides abuse until impact is already material. The same visibility gap often appears in synthetic fraud environments, where records, tokens, and accounts are trusted simply because they have existed for a while. Current guidance from the NIST Cybersecurity Framework 2.0 emphasises ongoing risk management rather than one-time verification. In practice, many security teams encounter the loss only after the synthetic identity has already accumulated sufficient trust to trigger a large bust-out event.

How It Works in Practice

Synthetic identities create large losses because they exploit the gap between initial verification and later exploitation. The identity may be assembled from real and fake attributes, then used slowly so it looks normal. As activity grows, so does confidence from fraud controls, support teams, or downstream systems. When the attacker finally monetises the identity, the exposure is no longer a single transaction. It is the full value of the trust the identity has accumulated.

Practitioners should think in terms of identity lifecycle controls, not just intake checks. The practical question is whether the organisation can continuously validate that an identity still makes sense given its behaviour, history, and access. That means stronger monitoring on account age, device reuse, contact changes, payment patterns, and link analysis across related entities. It also means detecting when a low-risk profile is gradually being shaped into a high-limit or high-trust profile. The JetBrains GitHub plugin token exposure case is a useful reminder that credentials and trust artifacts can persist long enough to be reused in ways defenders did not expect.

• Require step-up checks when an identity starts to cross value thresholds or behaviour shifts sharply.
• Use graph-based detection to identify shared infrastructure, funding sources, devices, or recovery paths.
• Treat velocity, age, and consistency as controls, not just fraud signals.
• Reassess trust continuously after onboarding, because initial approval is not proof of long-term legitimacy.

This approach aligns with the NIST Cybersecurity Framework 2.0 emphasis on continuous governance, but it breaks down when identity and transaction data are siloed across channels, because correlated abuse then looks like unrelated normal activity.

Common Variations and Edge Cases

Tighter identity controls often increase friction for legitimate customers, so organisations must balance fraud reduction against onboarding conversion and support burden. That tradeoff is especially important where thin-file users, shared households, gig workers, or newcomers have limited historical data. There is no universal standard for how much evidence is enough; current guidance suggests using risk-based scoring rather than a single approval rule.

Some synthetic identities are designed for small, repeated losses instead of a single bust-out event. Others are used to obtain credit, drain rewards, abuse refund logic, or establish mule infrastructure. In regulated environments, recovery and reimbursement obligations can increase the effective loss beyond the initial amount. Defenders should also watch for “seasoned” identities that only become risky after months of benign activity, because traditional rules often focus on the first 30 days and miss long-horizon abuse. NHI Mgmt Group’s broader guidance on long-lived secrets and poor offboarding in the Ultimate Guide to NHIs maps well to this problem: once trust is granted, it is rarely removed quickly enough.

Best practice is evolving toward continuous revalidation, shared signal fusion, and faster removal of trust when behaviour changes. Where those capabilities are weak, synthetic identities tend to cause the largest losses in systems that allow limits, credit, or privileged actions to accumulate over time.

Related resources from NHI Mgmt Group

• Why can a single SaaS app create such a large blast radius?
• What do teams get wrong about synthetic identities in marketplace environments?
• When do non-human identities pose the greatest risk to organizations?
• Why do non-human identities create more risk than many human accounts?