Identity Proofing

Identity Proofing establishes that a claimed identity belongs to the person claiming it, before any credential is issued against it: evidence is collected, validated against the source that issued it, and verified as belonging to the applicant — classically a passport, increasingly a digital credential from a wallet. Every control layered on top inherits that one decision, because a phishing-resistant credential bound to the wrong human is a strong credential for an impostor, and nothing about the sessions that follow looks anomalous. Two problems dominate the discipline. Synthetic media is cheap, so the question is not only whether a document is forged but whether the camera saw a person. And the same decision recurs whenever a credential is recovered rather than issued, usually on far weaker evidence than enrolment demanded.

Deciding How Much Assurance

The question is not whether an identity was verified but how much confidence the process earned, measured against what the resulting account will be able to do. Identity Assurance Level (IAL) is that answer, and it describes a process rather than a product. NIST SP 800-63 Revision 4, final since August 2025, keeps it separate from authenticator strength (AAL) and federation assurance (FAL) so that a strong credential is never mistaken for a well-proofed identity, and its proofing volume grades both the setting — remote or on site, attended by a human or not — and the evidence, the highest grade being cryptographically protected evidence whose issuer enrolled the subject in person. European deployments decide the same thing in another vocabulary: ETSI TS 119 461 v2.1.1 grades the proofing component of a trust service Baseline or Extended and assumes it is often a subcontracted specialist, which is where the audit boundary falls, while BSI TR-03147 assesses procedures against the eIDAS levels normal, substantial, and high but carries no BSI certification, so a conformance claim describes an assessment.

What matters more than mapping those vocabularies onto each other is that somebody owns the sentence: "IAL2, remote unattended" is defensible for a self-service consumer account and weak for an identity that will hold administrative entitlements. The answer then has to be recorded, because every later consumer — an access request workflow, a step-up decision, a partner accepting your assertion — either uses it or silently invents one. That is what makes proofing governable rather than a purchase: the level ages as evidence expires and as an account gains entitlements it was never proofed for, so re-proofing belongs on a schedule.

What a Liveness Claim Covers

Remote proofing puts most of the assurance on a biometric check, and "liveness" is sold as one property when it is two. Presentation attack detection concerns what is held up to a camera — a photograph, a screen replay, a mask — and ISO/IEC 30107-3, the standard for testing it, is scoped explicitly to attacks at the capture device. An injection attack is everything that scope excludes: a synthetic or replayed stream inserted behind the sensor, with nothing presented to a camera at all. A certificate naming 30107-3 can be entirely truthful and still say nothing about deepfakes. Evidence for the second discipline has to be requested separately — CEN/TS 18099 is the only published specification dedicated to it, its international equivalent ISO/IEC 25456 is still a working draft, and the FIDO Alliance Face Verification programme tests both disciplines together with demographic bias. NIST requires both as well, including controls that raise confidence the media came from a genuine sensor. So the useful procurement question is not whether a product is certified but which discipline was tested, under which specification, and by which laboratory.

The answer depends on where capture happens, because injected media enters between sensor and matcher: virtual cameras, emulators, hooked platform APIs, an intercepted stream. A native application using platform attestation can say something about the device and the origin of its frames; a browser calling getUserMedia cannot tell a physical camera from a virtual one, which makes web-only capture structurally weaker however good the matcher behind it. That trade-off costs completion rates, is invisible in any accuracy figure, and does not stay settled, since attack tooling is packaged and resold. The capture path needs a named owner, and proofing outcomes need watching as a live fraud signal rather than trust in a control that passed a test once.

The Two Places It Is Weakest

An organization can spend a year reaching IAL2 at onboarding and then let a phone call re-establish the same identity in twenty seconds. Every recovery path — a multi-factor authentication reset, a lost passkey, a changed phone number, an account locked before a deadline — asks the question proofing answers, with weaker evidence and against someone measured on call handling time, and service desk social engineering assisted by cloned voices succeeds without touching a technical control. FIDO2 and passkeys treat recovery as the weakest authenticator on an account; it is also the weakest proofing on one, and that is where the real assurance level is set. Recovery should therefore demand what issuance demanded — a wallet credential, a document and biometric check, a second enrolled authenticator rather than facts an attacker can buy — with reverification conditions documented and the people who decide trained, reviewed, and left no discretion to be helpful. Approval can also leave the conversation entirely for a device the user already holds via Client-Initiated Backchannel Authentication (CIBA). And since a recovery is a proofing event, it belongs in the log and in Identity Threat Detection and Response (ITDR): a cluster of resets in one department is an identity signal, not a service desk metric.

Hiring is the other weak point. Workforce proofing is usually implicit — it happens when someone collects a laptop from a building — and remote hiring drops that step without replacing it, which is how AI-assisted personas and deepfake interviews reach as far as employment. State-sponsored operatives obtain remote positions this way on stolen and fabricated identities, a pattern documented in government advisories and in the accounts organizations have published of discovering the hire only after onboarding it. A background check validates attributes of a claimed identity and says nothing about whether the person in the interview is their subject. Only proofing binds the two, so the joiner process needs an explicit proofing step whose result reaches the identity record over the same SCIM path as everything else, before entitlements are granted. Contractors and other third-party identities arrive with someone else's process at a level you cannot see, so record the level you verified yourself — and treat a rehire like a joiner, because a dormant record with a familiar name is the cheapest identity an attacker can acquire.

Reusing a Proofing Result

Good proofing is expensive, so the strongest lever is to do it once and reuse the result. Verifiable Credentials express that reuse — issued by an accredited party after a full process, presented cryptographically to any number of relying parties, disclosing only the attribute needed instead of the document behind it — and the W3C Digital Credentials API makes presenting one an ordinary web capability, with eIDAS 2.0 supplying accredited issuers in Europe and decentralized identifiers and self-sovereign identity infrastructure handling keys and revocation. Reuse relocates the assurance question rather than removing it: the level achieved is the issuer's, and accepting a presentation means accepting their process plus the wallet's binding of the credential to its holder. Whose proofing an identity rests on is therefore worth recording too.

Where There Is No Person

Applied to non-human identities, the word needs care. A workload has no document and no face, so the equivalent is attesting provenance — that an instance came from a known build and runs where it claims to — which belongs to Workload and Machine / Non-Human Identity Management, while accountability for an autonomous agent belongs to the AI Agent Registry and Lifecycle. The two subjects meet in one place: a check an agent can satisfy on its user's behalf is not a liveness check, which puts proofing and reverification among the few actions that cannot be delegated to an agent.

Deployment Considerations

Proofing happens in every identity programme; the only question is whether it happens deliberately. Name a target level per population and entitlement tier, record the level and its evidence where later decisions can use it, and ask suppliers which liveness discipline was tested, under which specification, by which laboratory. Own the capture path instead of inheriting it. Then hold recovery and hiring to the same standard as onboarding, where the work is procedural — evidence requirements, scripts, referee training, an audit trail of who decided what. Where a wallet ecosystem exists, accepting a credential from somebody else's high-assurance process beats repeating a mediocre one, provided you know whose process it was.