What proofing establishes
A record that already exists
Imagine a health clinic that has treated Alex for years. It keeps Alex's patient record, appointment history, and test results. The clinic now offers an online portal, and Alex wants an account there to read results at home instead of waiting for a phone call.
Creating the portal account is easy. The harder question is which patient record it should open. Alex can type a name, a date of birth, and a home address, but so could a relative, a former partner, or someone holding a stolen list of patient details. If the portal connects the account to a record because the typed details match, it has trusted exactly the information an impersonator is most likely to know.
In Establishing an identity, identity proofing appeared as a way to establish confidence that someone is the person they claim to be. For the clinic, the claim is specific: the person creating this account is the patient described by this record. Proofing is how the clinic decides whether to believe it.
The work usually breaks into three questions. Which person is being claimed? Is the evidence for that claim genuine? And does the evidence belong to the person presenting it?
Which person?
Before checking any evidence, the clinic needs to know whose identity is in question. Names are a poor way to tell people apart. Two patients can share a name and a birthday, and the same person can appear under a previous surname on one record and a new one on another.
Resolution narrows a claim down to one individual within a particular context. The clinic might collect a name, date of birth, and postal address, then look for exactly one matching patient. If nothing matches, or two records match equally well, it cannot continue as though it had found Alex.
Resolution needs enough information to be unambiguous, and no more. The clinic has no reason to ask for an employer or a national identification number if its own records can distinguish patients without them. Each extra attribute is something else to store, protect, and eventually delete.
How the portal responds also matters. A message such as "No patient with that date of birth" tells anyone testing stolen details which parts were right. A single, general response for every unsuccessful attempt keeps the sign-up form from becoming a way to check who is a patient.
Is the evidence genuine?
Once the claim points to one person, the clinic can look at evidence supporting it. Identity evidence is anything offered to show that the claimed identity is real: a driver's license, a passport, an insurance record, or the clinic's own history with the patient.
Validation asks whether that evidence is genuine, accurate, and current. For a physical document, that can mean checking its security features, confirming it has not expired, and looking for signs of alteration. Some evidence can be checked with its issuer or another authoritative source, which confirms that a document number exists and matches the details presented. The clinic can also compare the submitted details with its own records.
Evidence varies in strength. A government-issued document with a photo and anti-forgery features says more than a utility bill, which in turn says more than a typed address. Sources also vary in what they can speak to. An insurer can confirm that a policy exists for a name and birth date, but it knows nothing about who is sitting at the keyboard.
Validation alone is not enough. A synthetic identity combines real and invented details, such as a real identification number with a made-up name, and can be built up over time until it passes checks against several databases. Evidence that validates perfectly can also belong to someone other than the applicant. A genuine, unexpired driver's license can be lost or stolen.
Does the evidence belong to this person?
Verification connects the validated evidence to the person actually going through the process. It answers the question validation cannot: is the applicant the person the evidence describes?
At the clinic's front desk, this is familiar. A receptionist compares the photo on Alex's license with the person standing at the counter. Remotely, the same comparison is harder. A portal might ask Alex to photograph the license and record a short selfie video, then compare the two faces. Because a photo of a photo or a generated video could fool a simple comparison, remote systems also look for signs that a live person is present, a check often called liveness or presentation attack detection.
Face comparison is not the only approach. The clinic could mail a one-time code to the postal address already in Alex's record, confirming that the applicant can receive mail there. A clinician who knows Alex could vouch for the request. Alex could simply visit in person. Each method connects the applicant to the evidence in a different way and fails in a different way: mail can be intercepted, and a well-meaning staff member can be deceived.
The next lesson, Proofing methods, looks closely at document checks, remote face comparison, and address confirmation, including the attacks each is designed to resist and the ways each can fail honest people.
How much confidence is enough?
None of these steps produces certainty. Each check adds confidence and costs time, money, and personal information. How much a service should ask for depends on what goes wrong if it accepts the wrong person.
A portal that only shows appointment reminders might accept a lighter process than one that releases lab results or allows prescription changes. Services with similar risks often follow published proofing guidelines that group requirements into levels, so that "we verified this person" means something consistent from one service to the next. Whatever the level, the service should be able to explain what was checked and why that was enough.
The outcome is not always a clear yes or no. Alex's license might carry a surname that changed after the patient record was created. A camera might produce images too dark to compare. Some people have no government photo identification at all. Treating every inconclusive result as fraud locks out legitimate patients, while quietly accepting it defeats the purpose. A well-designed process offers another route, such as a different kind of evidence, review by trained staff, or an in-person visit, and records that the alternate route was used.
Failures also carry information. Many attempts from one source that each match a different patient, or the same document presented for several accounts, suggest someone working through stolen data. The service should slow or stop that pattern without revealing which details were correct.
After proofing succeeds
When the clinic is satisfied, it links the portal account to Alex's patient record and records the result: which evidence was used, which checks were performed, when they happened, and the level of confidence reached. That record supports later decisions, such as an audit or a request that needs stronger assurance than the original process provided. It does not need to include a copy of Alex's license. Keeping document images or detailed biometric data just in case creates a store of exactly the information identity thieves want.
Proofing describes a moment. It establishes that the person creating the account was Alex, on that day, to a particular level of confidence. On the next visit, the portal should not ask for a license again. During enrollment, Alex sets up a way to return, such as a password, a passkey, or a security key, and later sign-ins rely on that instead.
The connection between the proofed identity and those credentials is as important as the proofing itself. If anyone can replace Alex's credentials by giving a birth date over the phone, careful proofing at sign-up protects very little. Recovery that replaces credentials may need to repeat some of the original proofing. Enrollment, replacement, and recovery follows that part of the lifecycle in more detail.