Accountability should sit with the product, fraud, and IAM owners who define the proofing threshold and approve the trust model. If verification results are used to create accounts or grant access, then the failure is not just a fraud event. It is an identity governance failure that should be reviewed like any other access-control breakdown.
Why This Matters for Security Teams
Fake-user onboarding is not just a bad verification outcome. It is a trust boundary failure that can cascade into account takeover, fraud loss, and downstream access abuse if the identity proofing result is used to create an account or unlock privileges. Current guidance suggests treating the proofing decision as part of the access-control chain, not as a separate compliance check. That means product, fraud, and IAM owners all have accountability for the trust model they approve.
For security teams, the key mistake is assuming identity verification ends when a vendor returns a pass or fail. In reality, the business decides how much confidence is enough, what data sources are accepted, and what happens when verification is ambiguous. That is why this issue belongs alongside control design in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where identification, authentication, and account lifecycle controls intersect. NHIMG’s research on Ultimate Guide to NHIs also shows how weak lifecycle governance turns identity decisions into long-lived exposure.
In practice, many security teams encounter fraudulent onboarding only after an account has already been activated and used for abuse, rather than through intentional proofing governance.
How It Works in Practice
Accountability should be mapped to the people who define the trust decision, not just the team that operates the verification tool. Product owns the customer experience and the acceptance criteria. Fraud owns the risk signals, step-up thresholds, and exception handling. IAM owns the account creation, provisioning, and downstream access rules. When a fake user gets through, the root cause is often an unclear decision chain or a control gap between proofing and provisioning.
A practical operating model usually includes:
- Defined proofing thresholds for low-risk, medium-risk, and high-risk onboarding flows.
- Explicit approval of what evidence is acceptable, including document checks, device signals, or liveness checks.
- Immediate quarantine or limited access when verification confidence is below threshold.
- Audit logs that preserve the proofing result, the approver, and the account action taken.
- Post-event review that traces whether the failure was in data quality, policy design, vendor performance, or internal exception handling.
Where identity verification is used to create a durable account, the failure should be handled like an access-control incident, not a customer-support issue. That aligns with the broader governance lessons in 52 NHI Breaches Analysis, where identity misuse becomes damaging once it is trusted by systems. For onboarding policy, the external trust model also needs to reflect identity assurance expectations such as eIDAS 2.0 where regulated assurance levels matter. These controls tend to break down in high-volume consumer onboarding and partner onboarding flows because exception handling gets automated faster than governance gets updated.
Common Variations and Edge Cases
Tighter proofing often increases friction, operational cost, and abandonment, so organisations have to balance fraud reduction against conversion and support burden. There is no universal standard for this yet, and current guidance suggests risk-based calibration rather than a single proofing threshold for every user type.
The accountability question shifts in a few common scenarios. If a third-party identity provider makes the verification call, internal owners still remain accountable for selecting the provider, setting acceptance criteria, and defining fallback controls. If the account is temporary or low-privilege, some teams accept lighter proofing, but that should be a documented policy choice, not an informal exception. If verification is used for regulated onboarding, such as financial or identity-sensitive workflows, the review standard is higher and should be tied to legal, fraud, and IAM sign-off.
One useful rule is simple: the team that decides what “verified enough” means owns the risk when that decision fails. NHIMG’s Top 10 NHI Issues underscores how weak governance persists when ownership is split across silos. The right response is not to blame the tool alone, but to document who approved the trust model, who can override it, and who must review failures when fake identities slip through.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Identity proofing failures affect who gets access and under what assurance. |
| NIST SP 800-63 | Digital identity assurance governs how much trust an onboarding result deserves. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | Weak identity lifecycle governance lets fraudulent identities persist after onboarding. |
| CSA MAESTRO | MAESTRO addresses governance and trust decisions across automated identity flows. | |
| NIST AI RMF | AI RMF applies when automated checks or decisioning influence onboarding trust. |
Tie onboarding proofing outcomes to access gating and review any exception that grants account creation.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
