How should organisations verify that a new user is real?

Why This Matters for Security Teams

Verifying that a new user is real is no longer just a fraud-screening exercise. It is an access-control decision that determines whether a person, synthetic identity, or fraud ring can enter systems that hold customer data, finance workflows, or privileged workflows. Current guidance increasingly treats this as a layered assurance problem, combining document checks, liveness detection, and risk-based review rather than relying on a single signal.

That matters because identity proofing failure creates a durable weak point: once a fake user is onboarded, downstream controls often assume the account belongs to a legitimate person. NIST SP 800-207 Zero Trust Architecture makes the broader point that trust should be continuously evaluated, not granted once at enrollment, and that mindset is equally relevant at onboarding. NHI Mgmt Group’s Ultimate Guide to NHIs shows how identity sprawl and weak credential control amplify risk after the initial trust decision is made.

In practice, many security teams discover identity proofing gaps only after an account has already been used for fraud, mule activity, or privilege abuse, rather than through intentional enrollment testing.

How It Works in Practice

Real-world verification should match the risk of the use case. For low-risk digital onboarding, organisations may accept standard document capture plus automated checks. For higher-risk access, the control should confirm three things at the same time: the document appears authentic, the applicant is physically present, and the interaction is live rather than replayed. That is the core defence against stolen photos, deepfake video, mask attacks, and synthetic identities.

Best practice is evolving toward risk-based orchestration. A stronger flow often includes:

• Document validation against known templates and tamper indicators
• Face or biometric comparison with active liveness detection
• Challenge-response steps to defeat recorded or generated media
• Device, network, and behavioural risk scoring during the session
• Escalation to human review when confidence is low or the account is high value

The control should also align with the access that follows onboarding. If the new user will receive admin rights, payment authority, or regulated data access, the identity proofing threshold should be higher than for a routine self-service account. NIST SP 800-207 Zero Trust Architecture supports this kind of context-aware trust decision, while the Ultimate Guide to NHIs is a useful reminder that identity weakness is rarely isolated; it becomes more dangerous once credentials, sessions, and privileges are issued.

Organisations should document the assurance level they are targeting, the evidence collected, how exceptions are handled, and how false positives are reviewed. These controls tend to break down in high-volume remote onboarding environments because latency, inconsistent camera quality, and rushed exception handling erode the signal quality that genuine presence verification depends on.

Common Variations and Edge Cases

Tighter identity proofing often increases onboarding friction, requiring organisations to balance fraud resistance against customer abandonment and support overhead. That tradeoff is real, especially where legitimate users may have poor connectivity, limited identity documents, or accessibility needs.

There is no universal standard for this yet, so the right approach depends on the threat model. For consumer fintech, telecom, and high-value account creation, stronger liveness and human review are usually justified. For internal workforce onboarding, organisations may rely more heavily on trusted identity sources, HR checks, and conditional access, but should still apply heightened review when the account will receive privileged access.

Common failure modes include over-reliance on a single biometric score, accepting video selfies without real liveness, and treating identity proofing as complete once the account is created. Guidance from NIST SP 800-207 Zero Trust Architecture and NHI Mgmt Group’s Ultimate Guide to NHIs both point to the same operational lesson: trust should be narrow, evidence-based, and revisited when risk changes.

For organisations handling sensitive data or regulated workflows, the practical question is not whether a person appears genuine once, but whether the assurance level remains appropriate for the access being granted over time.

Related resources from NHI Mgmt Group

• Why is it crucial to adopt new authentication methods in MCP usage?
• Should organisations replace stored credentials with secretless authentication?
• Why do workload identities create new risk when used across clouds and APIs?
• Should organisations prioritise key exchange or certificate signatures first?