You verify a new user by combining identity proofing, behavioural checks, and risk signals instead of relying on one data point. Look for document consistency, device and network anomalies, velocity of signup attempts, and signs of automated interaction. Step up to stronger verification when the profile, history, or evidence looks inconsistent.
How to verify a new user is really human
A reliable check is not a single test, it is a layered assessment that combines document proofing, behavioural signals, and environmental signals. Human applicants usually leave a messy but coherent trail: consistent identity attributes, ordinary device behaviour, and natural interaction timing. Synthetic identities tend to break coherence somewhere, especially when speed, repetition, or automation pressure the onboarding flow.
The strongest verification approach is to compare what the person claims with what the session and evidence actually show. That means checking whether the identity evidence aligns across name, address, contact data, device history, and interaction pattern, then escalating when the profile is thin, contradictory, or unusually fresh.
For identity proofing and onboarding controls, see Identity Proofing and KYC Guide, which covers document checks, liveness checks, and synthetic identity patterns. When you need a broader fraud lens across onboarding and account creation, Identity Fraud Prevention Guide is the better navigation point.
What to check when the evidence looks inconsistent
Start with document consistency, because forged or assembled identities often fail basic cross-field alignment. Look for mismatches in names, addresses, dates of birth, or document metadata, and treat repeated retries as a signal rather than a nuisance. Device and network context matter too: disposable email domains, proxy patterns, virtualized environments, and repeated signups from the same technical footprint often indicate synthetic activity rather than a genuine first-time user.
Behavioural checks should complement, not replace, proofing. Fast form completion, copy-paste-heavy input, perfectly uniform typing, or impossible navigation speed can indicate automation. A synthetic identity may also be “quiet” until later, so early-life monitoring matters: the account can look clean at registration and still be low-trust because the surrounding signals are weak.
When you need a broader control model for identity lifecycle and governance, Human vs Non-Human Identity helps distinguish who should be proving what, and Identity Security Programme Guide helps place proofing into a wider operating model.
When to step up verification instead of approving the account
Step-up verification is the right response when the profile is incomplete, the evidence is inconsistent, or the interaction pattern looks engineered. Good step-up design increases assurance without blocking genuine users unnecessarily, so use stronger checks only when the risk score, document quality, or device behaviour justifies it. If the user repeatedly fails lower-friction checks, treat that as an accumulation of weak trust signals, not a one-off inconvenience.
The practical decision point is whether the current evidence would still look believable if it were reviewed by a fraud analyst later. If the answer is no, escalate to stronger identity proofing, manual review, or additional corroboration before granting access. At scale, the most common mistake is overreliance on one strong-looking signal, such as a government ID image or a single phone check, while ignoring the broader pattern of automation and account farming.
For a wider view of how these signals sit inside online fraud patterns, Top 10 Online Fraud Attacks is useful context, especially where synthetic identity is one part of a larger fraud chain.
Risk and Threat Considerations
Synthetic identities matter because they can pass shallow onboarding checks and then age into stronger-looking profiles over time. The risk is not only account creation fraud, but also downstream abuse such as credit loss, mule activity, policy evasion, and harder-to-detect account takeover paths.
Failure mechanism: The attacker or fraudster combines real and fabricated attributes, then exploits weak proofing, low-friction onboarding, or limited device scrutiny to create a profile that appears credible enough for approval.
Impact: Organisations may issue trust, limits, or access to an identity that is not anchored to a real, accountable person, which increases fraud exposure and weakens later detection and recovery.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-63, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Covers identity proofing and assurance for new-user verification. |
| Recommendation — Apply identity proofing and assurance levels before granting a new account. | ||
| NIST SP 800-53 Rev 5 | IA-12 — Identity Proofing | Directly governs proofing a new identity before activation. |
| IA-5 — Authenticator Management | Supports lifecycle control over evidence, authenticators, and escalation steps. | |
| Recommendation — Require identity proofing evidence before account creation or activation. Manage authenticators and step-up methods according to trust level. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Applies where synthetic identities rely on weak signup or login authentication. |
| Recommendation — Harden authentication paths so weak or automated signups cannot bypass checks. | ||
| CIS Controls v8 | CIS-5 — Account Management | Covers controlling account creation, review, and removal for suspicious identities. |
| Recommendation — Restrict account creation and review suspicious registrations promptly. | ||
Practitioner Guidance
What to prioritise: Build verification around evidence convergence, not a single approval gate. The most useful judgment is whether document, device, network, and behaviour signals all support the same identity story.
Decision rule: If the identity evidence is inconsistent, the session is automated, or the signup pattern is unusually fast or repetitive, step up verification before account approval rather than trying to detect abuse after activation.
What to verify: Keep reviewable evidence of why a user was accepted or escalated, including the signal mix that influenced the decision. That makes later fraud investigation and tuning far more defensible than a simple pass/fail record.
Practitioner takeaway: The goal is not to prove “humanness” from one signal, but to establish enough coherent evidence that a synthetic identity cannot cheaply mimic the onboarding story.