Who should own synthetic identity risk in an organisation?

Why This Matters for Security Teams

synthetic identity risk is not just an IAM problem or a fraud problem. It starts at onboarding, but it often shows up later in access abuse, account farming, payment abuse, or bust-out behaviour. That means ownership has to span the full lifecycle, not sit inside a single control tower. The most common failure is a narrow operating model that treats identity proofing, access, and behavioural monitoring as separate workstreams.

NHI Management Group’s Ultimate Guide to NHIs notes that only 20% of organisations have formal offboarding and key revocation processes, which is a useful warning sign for identity governance more broadly. The same structural weakness appears in synthetic identity programs when no team owns the join-up between onboarding signals, authentication events, and downstream financial or operational abuse. The NIST Cybersecurity Framework 2.0 reinforces that identity risk should be managed as an enterprise function, not a siloed technical task.

In practice, many security teams encounter synthetic identity abuse only after a bad actor has already moved from registration into monetisation, rather than through intentional cross-functional detection.

How It Works in Practice

The right ownership model is usually federated. IAM should own identity proofing, credential lifecycle, and access policy. Fraud or financial crime teams should own transaction patterns, velocity checks, and account takeover signals. Risk should set policy thresholds, escalation criteria, and loss tolerance. Operations should own manual review, customer friction, and remediation workflows. The key is a single operating model with shared metrics, not a single team carrying the entire burden.

Current guidance suggests synthetic identity detection works best when organisations connect signals across the lifecycle. For example, suspicious onboarding attributes should be correlated with device reputation, shared contact data, repeated payment instruments, and unusual access behaviour. That is where identity governance and fraud controls meet. The 52 NHI Breaches Analysis is useful here because it shows how missed identity controls often become incident chains rather than isolated events. Even though the subject matter differs, the operating lesson is the same: the strongest controls emerge when signals are shared quickly across teams.

• Define one accountable executive owner for the program, then assign execution to IAM, fraud, risk, and operations.
• Build shared playbooks for onboarding review, step-up verification, lockout, and case escalation.
• Use policy-as-code where possible so risky patterns trigger consistent decisions at runtime.
• Track shared KPIs such as false positives, loss prevented, review latency, and downstream abuse rates.

This model works best when event telemetry is already unified; it tends to break down in heavily fragmented environments where onboarding, fraud, and access data sit in separate systems with no reliable correlation layer.

Common Variations and Edge Cases

Tighter ownership often increases coordination overhead, requiring organisations to balance faster risk decisions against slower internal workflows. That tradeoff becomes more visible when synthetic identity controls are embedded in customer-facing journeys, where friction can damage conversion or trust. Best practice is evolving, but there is no universal standard for this yet.

In regulated sectors, risk ownership may sit with second-line risk while IAM and fraud remain first-line operators. In smaller organisations, one senior leader may own the program while the actual controls live in shared service teams. In mature environments, the better pattern is a cross-functional council with clear decision rights. The Top 10 NHI Issues is a reminder that identity failures often come from weak visibility, weak lifecycle control, and excessive privilege all at once, which is why no single team can see the full blast radius alone.

For organisations building broader identity governance, the practical question is not who “owns” synthetic identity risk in name only, but who can actually stop it across proofing, access, and abuse response. The answer is usually a shared model with one accountable sponsor and distributed operational responsibility, aligned to frameworks like the NIST Cybersecurity Framework 2.0.

Related resources from NHI Mgmt Group

• Who should own identity governance in high-risk payment environments?
• When does secret exposure become a broader identity risk?
• Why do authentication and identity proofing need to be linked more closely in high-risk environments?
• Who should own identity verification when it sits inside authentication workflows?