What is identity verification in an e-signature request?

What each method really tests

Every method is a proxy for identity rather than identity itself. A link tests who can read a mailbox. A code sent to that same mailbox tests the same thing at a more useful moment, namely during signing rather than whenever the invitation arrived. A code sent to a phone tests control of a different channel, which is what makes it worth more than a second email step. Questions drawn from credit files test recall of records that may also be available to somebody else. A document check tests a physical credential against a live image, which is why it is the only one that reaches beyond the digital trail.

Matching the method to the risk

The useful question is not which method is strongest but what a challenge would look like for this document. A recurring order confirmation with a long trading history behind it needs almost nothing. A guarantee signed by somebody the business has never met needs as much as it can get. Between those, a second channel is usually the sensible default, because it defeats the single most common scenario, which is somebody else reading an inbox. Applying the strongest method everywhere trains people to abandon signing halfway through, which has its own cost.

Where the evidence ends up

A method is only worth what the record says about it afterwards. The completed evidence should name which check was applied to each signer, when it succeeded, and from which address, so a reader can weigh the signature without asking the vendor how the product works. A process that verifies rigorously and records nothing has bought reassurance rather than evidence. The reverse also happens: detailed logs of a process that only ever sent a link, presented as though identity had been established.

The shared inbox problem

Nothing degrades identity evidence faster than sending to accounts@ or admin@. Whatever method is layered on top, the record can only ever say that somebody with access to a shared mailbox acted, and a business with five staff on that mailbox has five candidates. The fix is procedural rather than technical: collect the individual's own address before sending, even when the invoice contact is a role account. Where the counterparty insists, a second channel such as a phone code at least narrows the field to one device.

Failure handling matters as much as the check

Two failure modes deserve thought. Lockouts, where an honest signer mistypes a code several times, need a documented path back that does not involve emailing the code to somebody else. And silent failures, where a code never arrives because of spam filtering, need a resend that rotates the link rather than reusing the old one. A verification design that only considers the happy path produces support calls at exactly the moment the customer is trying to give you money.

The three methods available here

Email link only, which authenticates the recipient automatically when they open their personal link. An access code of at least four characters, hashed with a salted key derivation and compared in constant time, which the sender shares out of band and the interface never reveals. And an emailed one time code of six digits that expires after ten minutes, redeemable once, with at most five codes issued to a recipient in any ten minute window. Five failed attempts lock that recipient for fifteen minutes. Text messages, knowledge based questions and document checks are not offered. The method is chosen per recipient rather than per envelope, so a document going to a long standing customer and to a stranger can treat the two differently on the same request. That choice is made when the envelope is prepared and cannot be changed after sending, which is a reason to think about it at the point of drafting rather than at the point of clicking send. Reviewing the pattern occasionally is worthwhile too, since teams tend to drift toward the lowest friction option for everything once the first urgent document goes out without a code.

Questions people ask