Why do synthetic identities make trust and safety programmes harder to run?

Why This Matters for Security Teams

Synthetic identities are hard for trust and safety programmes because they are not obviously false at onboarding. They blend real, stolen, and fabricated attributes, then build a credible history over time. That makes them resilient against static checks such as document verification alone, and it shifts the problem from initial acceptance to ongoing assurance, fraud monitoring, and recovery control.

This is where identity governance meets operational security. Teams that rely on a one-time pass or a single risk score often miss the gradual accumulation of trust signals that synthetic identities are designed to exploit. The result is account opening abuse, laundering, bonus exploitation, and downstream transaction fraud that looks legitimate until the damage is already distributed across products and channels. NIST’s Cybersecurity Framework 2.0 is useful here because it frames trust as a managed lifecycle, not a point-in-time event.

NHIMG research on JetBrains GitHub plugin token exposure shows how quickly trusted access paths can be abused once credentials or identity signals are compromised. In practice, many security teams encounter synthetic identities only after transaction abuse, chargebacks, or mule activity has already turned the account into a reliable fraud primitive.

How It Works in Practice

Synthetic identity programmes succeed by exploiting gaps between verification controls and real-world behaviour. A candidate may pass KYC-style checks, register with a clean email and phone number, then slowly establish credibility through low-risk actions before escalating to higher-value abuse. The challenge is not just proving that an identity exists, but proving that it remains the same accountable actor across sessions, devices, recovery events, and payment methods.

Operationally, stronger programmes combine document and device checks with behavioural analytics, velocity rules, graph analysis, and step-up verification. The aim is to detect when an identity’s attributes are internally consistent but externally suspicious, such as repeated use of similar device fingerprints, clustered addresses, or improbable recovery patterns. NIST guidance on digital identity and fraud-resilient assurance remains relevant, but current guidance suggests there is no universal standard for synthetic identity detection yet, so teams need layered controls rather than a single gate.

• Verify identity attributes at enrolment, then re-check them at high-risk lifecycle events.
• Score relationships across accounts, payment instruments, devices, and recovery channels.
• Use transaction thresholds and delayed trust elevation for newer identities.
• Monitor for shared infrastructure patterns that suggest a coordinated fraud ring.

NHIMG’s Code Formatting Tools Credential Leaks research is a reminder that trusted systems can be compromised through ordinary workflows, not just overt attacks. These controls tend to break down when onboarding is optimised for speed across high-volume mobile channels because fraud signals are diluted and recovery flows are often weaker than issuance flows.

Common Variations and Edge Cases

Tighter verification often increases friction and abandonment, requiring organisations to balance fraud reduction against customer conversion and inclusion. That tradeoff is especially sharp in thin-file populations, minors, newcomers, and gig or marketplace users where there is limited documentary history but genuine demand for service.

Best practice is evolving for these edge cases. Some programmes use staged trust, where low-risk functionality is available early but sensitive actions require stronger evidence later. Others lean on consortium signals, network intelligence, and repeated behavioral confirmation rather than rejecting users who cannot present traditional credentials. The right answer depends on the business model, regulatory exposure, and tolerance for false positives.

There is also an important intersection with NHI governance. Synthetic identities often coexist with automated signup abuse, bot-driven account farming, and compromised recovery infrastructure, which means trust and safety teams should coordinate with identity, fraud, and application security teams. This is where JetBrains Marketplace AI Plugin Campaign is a useful analogue: once a system can masquerade as trusted, the control problem becomes continuous validation rather than initial approval alone.

Related resources from NHI Mgmt Group

• Why do synthetic identities make AML programmes less effective?
• Why do non-human identities make access certification harder than human identities?
• Why do non-human identities make privileged access governance harder?
• Why do non-human identities make Zero Standing Privilege harder to achieve?