The question every signature has to answer
Behind every signed document is one question a dispute will eventually ask: how do you know the right person signed it? An emailed link proves someone with access to that inbox signed — which is usually enough, but not always. The whole field of signer identity verification exists to raise that confidence on the documents where "someone with the link" isn't a strong enough answer. The trick isn't to verify everyone to the hilt; it's to match the rigor to the stakes, so routine documents stay frictionless and high-value ones carry real proof of who.
This is a plain tour of the identity-verification methods available in e-signing, what each one actually proves, and how to choose between them. It builds on the broader question of what makes a signature legally binding — identity is the "who" in the intent-consent-integrity test.
The default: an emailed signing link
The baseline method is the one most documents use: you send a signature request to an email address, and signing requires access to that inbox. This is a real identity signal — control of a specific mailbox is something most people don't share — and for the large majority of business documents between known parties, it's proportionate. The audit trail records the email, IP, device, and timestamp, tying the signature to a specific person and session.
What it doesn't do is defend against a shared or compromised inbox, or prove the signer is who they claim when you've never dealt with them before. When that gap matters, you layer a second factor on top.
Access code: a shared secret you set
The simplest step up is an access code — a password you set on the envelope and deliver to the signer through a different channel than the email. They can't open the document without it. The security comes from the separation: an attacker would need both the inbox and the code you texted or spoke separately.
Access codes are ideal when you have an out-of-band way to reach the signer that you trust — a phone number you'll call, an account portal, an in-person handoff. The catch is operational: you have to deliver the code securely and the signer has to not lose it. Don't email the code in the same thread as the link, which defeats the entire point.
One-time passcode: email or SMS
The most common second factor is a one-time passcode (OTP) — a short code generated per signing session, valid briefly, delivered by email or, more powerfully, by SMS:
- Email OTP sends the code to the signing email itself. It mainly defends against a forwarded link, confirming the signer is in that inbox right now — a modest but useful step up from a bare link.
- SMS OTP sends the code to the signer's phone number. This is the stronger and more popular choice because it ties the signature to a separate thing the signer controls — a device, a phone line — not just the inbox the request arrived in. As we note in signing on your phone, this is especially natural on mobile, where the same device receives both the document and the code.
OTP is the workhorse for elevated-stakes documents: a large contract, a first-time counterparty, anything carrying real liability. It's low-friction for the signer (a quick code entry) and meaningfully raises the bar for impersonation.
Knowledge-based authentication (KBA)
The heaviest common method is knowledge-based authentication — the signer answers a few questions generated from public and credit-record data that only they should be able to answer ("which of these streets have you lived on?"). KBA verifies identity against records the signer never gave you, so it's the closest a remote flow gets to checking a real-world identity rather than just possession of an inbox or phone.
KBA carries more friction and sometimes a per-use cost, so reserve it for documents where identity assurance is the explicit requirement — certain financial transactions, some regulated workflows, anything where a statute or counterparty demands a stronger identity tier. For most business signing it's overkill; for the few documents that need it, nothing lighter will do.
Matching the method to the stakes
The whole point is proportionality. A useful ladder:
- Routine document, known party — emailed link. Don't add friction that doesn't buy you anything.
- Elevated value or a first-time signer — add SMS OTP. Cheap insurance, barely noticeable to the signer.
- Out-of-band channel you trust — access code, delivered separately.
- Regulatory or high-assurance identity requirement — KBA, or notarization if the document genuinely needs a notary rather than a signature.
Over-verifying has a real cost: every extra step is a chance for a signer to stall or abandon. Under-verifying has a worse one: a signature you can't stand behind when it's challenged. The skill is reading which document is which.
Where verification fits the bigger picture
Identity verification is one leg of a defensible signature, not the whole thing. It establishes who; the audit trail records when and how; the SHA-256 seal and trusted timestamp prove nothing changed since. A strong identity check on a document with no tamper-evident record is half a system, and so is a beautiful audit trail on a signature anyone could have placed. For documents that matter, you want both — the right identity tier and the sealed evidence behind it. And whichever method you choose, build it into a reusable template so the requirement applies automatically every time, rather than relying on someone to remember to switch it on.
The takeaway
Signer identity verification answers the "who" that every dispute eventually raises. The menu runs from an emailed link (proves inbox control) to an access code (a separately delivered secret), to email or SMS one-time passcodes (the popular workhorse, tying the signature to a phone the signer controls), to KBA (record-based identity checks for the highest-assurance documents). Match the method to the stakes — frictionless for routine paper, OTP for elevated-value or first-time signers, KBA where a rule demands it — and pair whatever you choose with a sealed, audited record so the signature proves both who and that nothing changed.
This article is general guidance, not legal advice. For identity-assurance requirements specific to your industry or jurisdiction, consult qualified counsel or a compliance specialist.