People verification redefines human identity checks for the AI era

At a glance

What this is: People verification is a cryptographic method for two humans to verify each other directly, using hardware-bound keys instead of call-centre or helpdesk mediation.

Why it matters: It matters because IAM teams now have to protect human verification flows against AI-generated impersonation, while also preserving trustworthy escalation, support, and identity confirmation paths.

By the numbers:

• The Arup Hong Kong incident in early 2024 made the new pattern public: a finance employee transferred $25.6 million after a video conference in which every other participant was an AI-generated deepfake.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read Scramble ID's full explanation of people verification and human-to-human trust

Context

People verification is a human identity control, not a generic authentication wrapper. It verifies that two people can cryptographically confirm each other’s identity in the moment, using hardware-bound keys and a single-use artifact instead of human recognition or a helpdesk-mediated callback.

That matters because AI-generated voice, video, and behavioural imitation have weakened the trust signals many organisations still rely on for support escalation, vendor confirmation, and sensitive approval flows. For teams already thinking in phishing-resistant terms, this sits alongside broader identity hardening patterns covered in the Ultimate Guide to NHIs and the NIST zero trust model.

Key questions

Q: How should security teams handle human verification when voice and video can be faked?

A: Treat voice and video as untrusted indicators, not proof. For high-risk human verification, use cryptographic confirmation tied to a device-bound private key and a single-use session artifact. Keep the human conversation for context, but move the trust decision to a deterministic signature check that synthetic media cannot reproduce.

Q: When is a callback no longer a safe way to confirm identity?

A: A callback is no longer safe when the decision depends on recognising a voice, face, or familiar behaviour that AI can imitate. If the request could cause payment movement, access changes, or support authorisation, move to a cryptographic verification step instead of relying on human memory or familiarity.

Q: What should identity teams do with provenance when sharing user attributes?

A: Identity teams should preserve provenance all the way through the workflow. Verified and self-asserted fields should remain distinct, because they support different trust decisions. If a process cannot consume provenance explicitly, it should not pretend that all disclosed attributes carry the same assurance level.

Q: Who should use people verification instead of password resets or helpdesk callbacks?

A: Use it for cases where impersonation risk is high and the decision has real business impact, such as executive approvals, payment changes, or sensitive support requests. It is most useful when the organisation needs to confirm a real person in the moment without handing that burden to a helpdesk agent.

Technical breakdown

Cryptographic human verification versus recognition-based checks

People verification replaces probabilistic human judgment with deterministic cryptography. The verifier is not asked to decide whether a face or voice seems right. Instead, the system checks whether the presenter can produce a valid signature from a hardware-bound private key that never leaves the device. That design makes the result independent of deepfake quality, social engineering polish, or call-centre scripting. The shared artifact, whether QR, type code, or SMS link, only carries a short-lived verification context, not the identity proof itself.

Practical implication: move sensitive human confirmation flows away from recognition-based checks and toward device-bound cryptographic verification.

Single-use artifacts, binding, and replay resistance

The Dynamic Identifier is the session control point. It is server-issued, single-use, and time-bound, so the artifact cannot be reused after first consumption or after expiry. The QR, type code, and SMS deep link are simply delivery formats for the same underlying session binding. Because the result is tied to a specific environment and a bound connection, intercepting the artifact is not enough to redirect or replay the verification outcome. That is what makes the flow operationally fast without becoming reusable in the way passwords or OTPs often are.

Practical implication: treat the artifact as disposable session context and design controls around one-time use, expiry, and bound delivery channels.

Attribute provenance and selective disclosure

People verification does not force a fixed identity disclosure. The presenter chooses a Work, Personal, or Custom profile and sees exactly which attributes will be shared before continuing. The verifier sees provenance marks that distinguish verified sources from self-asserted ones. That separation matters because trust decisions are often made on partial evidence, not full identity records. The design gives the verifier context without pretending that every field has the same assurance level, which is a more honest model than overloading a single identity assertion with too much meaning.

Practical implication: separate verified attributes from self-asserted attributes in downstream workflows, rather than treating every shared field as equally authoritative.

Threat narrative

Attacker objective: The attacker aims to impersonate a trusted human well enough to trigger support actions, sensitive approvals, or fraudulent transfers.

1. Entry occurs when an attacker relies on AI-generated voice, video, or relationship-building to impersonate a trusted person in a high-friction human verification flow.
2. Credential access is blocked because the verification step requires a hardware-bound private key and a valid cryptographic signature, not a convincing persona.
3. Impact is avoided when the single-use artifact expires or is consumed, because the attacker cannot replay the session or complete the verification ceremony without the bound device.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Human verification based on recognition has collapsed as an identity assumption. The control model that says a familiar voice, face, or callback proves identity was designed for a world where impersonation was expensive and noisy. That assumption fails when AI can cheaply reproduce the same signals at scale, with enough fidelity to pass as routine. The implication is that human verification now needs cryptographic evidence, not better human intuition.

People verification creates a useful boundary between identity proofing and identity confirmation. Proofing remains the enrollment problem, while people verification exercises the binding between an already-proofed person and a device-bound credential. That separation is valuable because it prevents organisations from asking support teams to carry a proofing burden they were never designed to hold. Practitioners should preserve that distinction in policy, workflow, and audit language.

Human identity governance must now assume adversarial synthetic interaction. The rise of convincing AI-generated calls and video means support paths, vendor callbacks, and executive confirmations are no longer low-risk human processes. This is not just a fraud problem. It is a governance problem for every workflow that still relies on informal recognition as an access signal. Teams need to rethink which human interactions deserve cryptographic verification.

Provenance is becoming as important as assertion. A verified attribute and a self-asserted attribute can sit side by side in the same interaction, but they should never drive the same decision. That distinction becomes more valuable as organisations combine people verification with customer service, B2B trust, and internal escalation. The practical conclusion is that provenance-aware identity design should be treated as a baseline control, not a nice-to-have.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• The lifecycle gap is broader than credentials alone, so read Ultimate Guide to NHIs for the governance baseline and 52 NHI Breaches Analysis for incident patterns.

What this signals

People verification will likely become one piece of a larger trust stack, not a replacement for identity proofing, MFA, or human escalation controls. The operational question for programmes is where a cryptographic human confirmation step belongs and where it would add friction without reducing risk.

Human-recognition debt: organisations that still depend on voice familiarity, visual recognition, or helpdesk intuition are carrying a trust model that synthetic media can now exploit. The right response is to identify the workflows where that debt is most dangerous and redesign those flows first.

For identity teams, the most immediate signal is not whether people verification is adopted everywhere, but whether high-risk support and finance workflows stop depending on informal human judgment. That is where the control has the clearest measurable impact, especially when paired with provenance-aware attribute handling and phishing-resistant identity patterns.

For practitioners

• Replace recognition-based callbacks for high-risk requests Use cryptographic human verification for payment changes, access reset requests, vendor onboarding, and executive approvals where a voice or face could otherwise be spoofed. Keep the callback path as a fallback only when the authenticated channel is unavailable.
• Separate proofing from confirmation in policy Write support and IAM procedures so enrollment, proofing, and moment-of-confirmation are distinct steps with different assurance requirements. That prevents service desks from improvising proofing decisions during live incidents.
• Treat shared attributes as provenance-scoped Require downstream systems to preserve whether an attribute was verified or self-asserted, especially for directory updates, delegated admin requests, and vendor trust workflows. Do not collapse both into one generic trusted profile.
• Use short-lived, single-use verification artifacts Make the verification context disposable, time-bound, and bound to a single session so intercepted artifacts cannot be replayed later. Align expiry, binding, and audit logging to the same event record.

Key takeaways

• People verification matters because it replaces fallible human recognition with a cryptographic proof that AI cannot imitate.
• The biggest risk it addresses is impersonation in support, finance, and executive workflows where one convincing conversation can trigger real damage.
• Identity teams should separate proofing, confirmation, and provenance so human trust decisions do not depend on memory, familiarity, or synthetic media.

Key terms

• People Verification: A human identity confirmation method in which two people verify each other through cryptographic proof rather than recognition, callback, or third-party mediation. The design uses device-bound keys and a single-use artifact so the result is deterministic and resistant to deepfake impersonation.
• Dynamic Identifier: A short-lived, single-use session token that carries verification context for a people verification ceremony. It binds the interaction to one attempt, one moment, and one result, which makes replay and reuse materially harder than with static codes or reusable shared secrets.
• Attribute Provenance: The source quality attached to a disclosed identity attribute, such as verified source or self-asserted. Provenance matters because identity decisions are only as strong as the evidence behind each field, and not all disclosed data should be treated as equally trustworthy.
• Hardware-bound private key: A cryptographic key generated and stored inside protected device hardware such as a secure enclave, TPM, or strongbox. It cannot be copied out by ordinary software, which makes it a stronger root of trust than knowledge-based or media-based identity signals.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Scramble ID: What Is People Verification? Read the original.