Your e-signature proves someone opened an email

Every e-signature platform can prove a document was delivered, opened and sealed, and none of them can prove who clicked. The law always put the weight on attribution, and a mailbox link was never able to carry it. This is what actually proves who signed, and what survives when the platform does not.

The green checkmark that nobody questions

Picture a compliance analyst at a mid-size broker-dealer on a Tuesday morning. A client has called to complain about a transfer he says he never authorised. The analyst does what the procedure says: pull the envelope, pull the certificate of completion, check the audit trail.

Everything is green. The document went to the client's email address, the one on file for six years. It was opened at 14:07. The signer clicked through four pages, drew a signature that looks like the one on every other document in the file, and clicked Finish at 14:09. The certificate records an IP address, a browser fingerprint, a timezone, and a chain of SHA-256 hashes proving the document was not altered after signing. There is a tamper-evident seal. There is a unique envelope ID.

The analyst writes back to the client: our records show you signed this on the 14th at 2:09pm from your usual IP range. The matter is closed, because the paperwork is immaculate.

Six weeks later it turns out that the client's mailbox had been accessible to someone else since March. Every single fact on that certificate of completion is true. The document really was delivered to that address. It really was opened at 14:07. The hashes really do match. And the certificate proves, with genuine cryptographic rigour, something that was never in dispute: that a document was delivered to a mailbox and that somebody with access to that mailbox clicked a link.

It does not prove who that somebody was. It was never able to.

This is not an attack on e-signature platforms. It is an observation about what they were built to do, which they do extremely well, and what they were never built to do, which almost everyone assumes they do anyway. The gap between those two things is where the disputes live.

What does an e-signature actually prove?

Let us be precise about the mechanism, because precision is the whole point of this article.

The flow, step by step

The dominant e-signature flow has five steps and each one is worth reading slowly.

One. A sender uploads a document and types in a recipient's email address. That address is the only identifier in the system. There is no lookup against a government register, no check that the address belongs to the named person, no verification that the person named in the document and the person who owns the mailbox are the same human. The sender asserts it, and the platform accepts the assertion.

Two. The platform sends an email containing a link. That link usually carries a long random token, which is the actual credential. Anyone holding that token can reach the document. The security property here is that the token is unguessable, which is true and useful, and that it arrived in a particular mailbox, which is the part that will fail us later.

Three. The recipient clicks. The platform records the timestamp, the source IP address, the user agent string, and often geolocation derived from the IP. In many configurations it will ask the signer to consent to doing business electronically, which is a legal requirement under the US ESIGN Act, not a security control.

Four. The signer types a name, draws with a mouse or finger, or picks a stylised font rendering of their name. This is the part everyone thinks of as "the signature". Technically it is an image or a string. It carries no cryptographic relationship to the signer. Two people typing the same name produce identical artifacts.

Five. The platform computes a hash of the completed document, signs that hash with the platform's own key, and issues a certificate of completion listing every event with timestamps. This is genuine cryptography and it is genuinely valuable. It means nobody can alter the document afterwards without detection.

What the certificate of completion actually contains

Read one sometime. It is an honest document, and its honesty is the point. It says, in effect: this platform received this document, sent it to this address, observed these events at these times, and here is a hash proving the content has not changed since.

Every claim in that list is a claim about the platform's own observations. The platform is attesting to what it saw. It is a very good witness. What it cannot testify to is the identity of the person on the other end of the connection, because it never had any way to establish that. It saw a session, not a face.

The analogy worth holding onto: a courier company can prove it delivered a package to a specific letterbox at a specific minute, and can prove the package was not opened in transit. That is real evidence and it is worth having. It is not evidence about who took the package out of the letterbox.

Why is a mailbox link legally sufficient?

Here is where the naive critique goes wrong, and where being fair to the industry matters.

In the United States, the Electronic Signatures in Global and National Commerce Act of 2000 (ESIGN) and the Uniform Electronic Transactions Act (UETA), adopted in most states, establish that a signature cannot be denied legal effect merely because it is electronic. They define an electronic signature broadly, as an electronic sound, symbol, or process attached to or logically associated with a record and executed or adopted by a person with the intent to sign.

That definition is deliberately technology neutral, and that was a good decision. It let commerce move online without waiting for a national identity infrastructure that the United States still does not have.

In the European Union, Regulation 910/2014, known as eIDAS, does something more structured. It creates three tiers. A simple electronic signature is roughly the US concept. An advanced electronic signature must be uniquely linked to the signatory, capable of identifying them, created using data the signatory can use under their sole control, and linked to the data such that later changes are detectable. A qualified electronic signature is an advanced signature made with a qualified device and backed by a qualified certificate from a trust service provider, and it carries the legal equivalence of a handwritten signature across the Union.

Notice something important. The eIDAS advanced tier describes, almost word for word, the properties that a mailbox link does not have. The Europeans wrote down the gap in 2014. The tiers exist precisely because someone recognised that "an email arrived and was clicked" is a different assurance level from "this identified person, using a key only they control, signed this exact data".

The attribution clause everyone skips

Now the part that matters most, and that gets quoted least.

UETA and ESIGN do not say an electronic signature is valid full stop. They say it is valid, and separately they address attribution. Under UETA, an electronic signature is attributable to a person if it was the act of that person, and that may be shown in any manner, including by showing the efficacy of the security procedures used.

Read that again. The statute makes validity easy and puts the weight on attribution, which is a question of fact to be proven by evidence. The law never promised that clicking a link proves who clicked. It said: if you want to attribute this act to this person, show your work.

For twenty-five years, showing your work has meant producing the certificate of completion, and it has usually been enough, for a completely rational reason: disputes are rare relative to volume, contesting a document is expensive, and the audit trail combined with circumstantial evidence such as the person subsequently performing the contract is generally persuasive. The system works because most people do not lie about signing things, and because the ones who do usually lack the resources to litigate.

The system does not work as well when the person contesting the signature is telling the truth.

So where does the mailbox actually break?

Three ways, and the third one is new.

The stolen mailbox

Adversary in the middle phishing kits made session theft ordinary. A victim authenticates against the real identity provider through a reverse proxy, and the attacker keeps the resulting session token. The account is not "hacked" in a way anyone will notice: the password still works, the multi-factor prompt was answered by the legitimate user, and no alerts fire. The attacker simply has a valid session, sometimes for weeks. We wrote about the mechanism in detail in the post on session theft.

An attacker in that position does not need to forge anything. They wait for an envelope, or they trigger one. They click the link that arrives, and everything downstream is authentic. The IP address may even be plausible if they proxy through a matching region.

The shared and delegated inbox

This one is banal and probably more common. Assistants hold delegated access to executive mailboxes. Shared addresses such as [email protected] are open to entire teams. Families share addresses. Owners give the bookkeeper the login.

None of these people are attackers. Most of the time the delegation is exactly what the principal wanted. But the artifact produced is indistinguishable from one the principal produced personally, which means that when a dispute arises about whether the principal personally reviewed and intended to be bound by a particular clause, the record cannot answer the question. The certificate of completion will say the envelope was signed. It cannot say by whom.

In regulated contexts this is not a hypothetical. In October 2025 the Financial Industry Regulatory Authority published a disciplinary settlement concerning individuals at a firm who signed client documents themselves rather than obtaining genuine client signatures, involving hundreds of documents over a period of years, with financial sanctions attached. FINRA publishes its disciplinary actions in a public database, and forged or improperly obtained signatures are a recurring category there. We are describing the shape of the case rather than the details because the underlying documents are the authoritative source and readers in the industry should read them directly.

In December 2025, mortgage industry press reported litigation by a wholesale lender against a broker alleging forged electronic signatures alongside fabricated income documents across a set of loans. The useful takeaway is structural rather than anecdotal: when the artifact is a click, forging it takes access, not skill.

The agent that reads your email now

This is the part that changes the calculus, and it is why this article exists in 2026 rather than 2016.

A growing number of people have given an assistant agent access to their mailbox. It triages, drafts, schedules, and increasingly acts. Browser-operating agents work inside the user's authenticated sessions, which is the entire point of them. We covered the implications in the post on agentic browsers.

Ask yourself what happens when an envelope arrives in a mailbox an agent is operating. The link is in the inbox. The agent can open it. The agent can click through the pages. The agent can type a name into a field. Nothing in the flow was designed to distinguish an agent from a person, because nothing in the flow was ever designed to identify the person in the first place.

The industry is aware of this. Platform security leadership has publicly described adding verification steps and risk analysis to counter document fraud, which is a reasonable response and also an admission that the base flow does not settle identity.

Do the add-ons fix it?

Every major platform sells authentication add-ons for higher value envelopes. They are genuinely better than nothing. It is worth being exact about what each one moves and what it leaves in place.

Access code. The sender gives the signer a code out of band. That proves the signer received a code from the sender. If the sender emails the code, which happens constantly, it proves nothing.

Email OTP. A second code is sent to the same mailbox that received the link. If the mailbox is the compromised element, sending a second thing to it does not help. This is the security equivalent of checking whether the fox is a fox by asking the fox.

SMS OTP. A code goes to a phone number. This is a genuine improvement because it requires the attacker to control a second channel. It is also the channel with the best documented failure mode in the industry. FBI Internet Crime Complaint Center reporting has tracked SIM swap complaints and losses for years, and while 2025 figures were lower than the 2022 peak, the per-incident consequences remain severe because SMS sits in front of high value actions.

Knowledge based authentication. The signer answers questions derived from credit header data. The premise is that only the real person knows the answers. After two decades of breaches that premise is hard to defend, and it fails in both directions: attackers with a bought dossier pass, and legitimate signers who moved recently fail.

ID document upload with selfie. Now we are getting somewhere, because this actually tries to establish identity. The limitation is that it is a one-time proofing event bound to a session, not a key. It proves that at 14:08 a document and a face were presented. It creates nothing the signer holds afterwards, so the next envelope starts from scratch, and the capture pipeline is itself under pressure from injection attacks that feed synthetic video straight into the camera stream. Vendor research reports such attempts in the millions annually; methodology varies, the direction does not.

Here is the summary in one place.

Notice the pattern down the rows. Every method except the last authenticates a channel or a moment. The last authenticates a key, and the key stays with the human across envelopes, platforms and years.

What would actually prove who signed?

The requirement is easy to state and has been understood for a long time, which is why eIDAS wrote it into the advanced tier in 2014: the signature must be created with data the signatory can use under their sole control, uniquely linked to them, and bound to the content so that any change is detectable.

Modern platform authenticators give us the pieces. A passkey is a key pair where the private key lives in the device's secure hardware and never leaves it. Using it requires a local gesture, a face or a fingerprint or a device PIN. The WebAuthn specification defines how a relying party asks that key to sign a challenge and how the resulting assertion is verified.

The move that turns this from a login mechanism into a signing mechanism is small and it is the crux of the whole thing: instead of sending a random challenge, you send a challenge derived from the document.

// The signer's browser asks the enrolled device to sign the DOCUMENT,
// not an anonymous login challenge.

const documentHash = sha256(pdfBytes);           // 32 bytes, the exact file

const payload = {
  doc_hash:   toHex(documentHash),
  envelope:   "ENV-2026-0914-7731",
  signer:     "[email protected]",
  role:       "Authorised signatory, Northwind Ltd",
  terms_hash: toHex(sha256(disclosureText)),     // what they were shown
  signed_at:  "2026-09-08T14:09:22Z"
};

const challenge = sha256(canonicalJson(payload)); // deterministic bytes

const assertion = await navigator.credentials.get({
  publicKey: { challenge, allowCredentials: [enrolledCredential],
               userVerification: "required" }   // face or fingerprint, locally
});

Walk through what each field buys you, because this is the part worth understanding properly rather than skimming.

The doc_hash binds the signature to one exact sequence of bytes. Change a single character in the PDF and the hash changes and the signature no longer verifies. This is the property that makes it a signature on the document rather than a signature near the document.

The terms_hash is the underrated one. It commits to what the signer was actually shown on screen. In a later dispute about whether a disclosure was displayed, this field answers the question, because the disclosure text hashes to that value or it does not. Most disputes about signatures are really disputes about what the signer saw.

The signer and role fields bind the act to a claimed identity and capacity, so the record says not merely that a human signed, but that this human signed in this capacity.

And userVerification: "required" means the device demanded a local biometric or PIN gesture before it would use the key. The face check happens on the device. No biometric leaves it, and none is stored by anyone. Manav's own approach follows this rule strictly: the face never leaves the device, and only a one-way key remains, which is why there is no biometric database to breach.

Verification, later, by anyone:

# Anyone holding the receipt and the PDF can check it. No platform required.

payload  = receipt["payload"]
assert payload["doc_hash"] == sha256(open("contract.pdf","rb").read()).hex()

challenge = sha256(canonical_json(payload))
assert webauthn_verify(
    assertion   = receipt["assertion"],
    challenge   = challenge,
    public_key  = receipt["signer_public_key"]   # from the enrollment record
)

# And the receipt envelope itself, signed by the issuer:
ed25519_verify(receipt["signature"], receipt["payload_bytes"], published_key)

The important word in that comment is anyone. Not the platform. Not a vendor with an API. A court expert, an auditor, an opposing counsel, a regulator, five years from now, holding nothing but the file and the published key.

What survives the platform disappearing?

This is the column nobody puts in the comparison charts, and it is the one that should decide procurement for long-lived documents.

Ask a simple question about any signing method: if the platform that produced this evidence no longer exists in fifteen years, or has migrated its systems three times, or is itself the party in dispute, what remains verifiable?

A mortgage runs thirty years. A pension election outlives the employer. A shareholder agreement gets litigated when the founders fall out, which is exactly when everyone's records become interested records.

Two honest observations about that table.

First, eIDAS qualified signatures already deliver most of what this article argues for, inside the European Union, and have done for years. Anyone in the EU handling high value documents should be looking hard at the qualified tier rather than at anything novel. The gap this article describes is far more acute in jurisdictions with no equivalent at consumer scale, which includes the United States.

Second, the device bound approach has its own archival dependency: the enrollment record binding the public key to the human must survive too. That is a real operational requirement, not a detail to wave away, and we say more about it in the limits section.

What does this look like in a real envelope flow?

Concretely, and without changing how the document gets prepared or routed.

The sender builds the envelope as usual. At the completion step, instead of, or in addition to, capturing a drawn name, the platform hands the document hash to a signing widget. The signer, who enrolled once, gets a prompt on their enrolled device. For a routine document, that is a face or fingerprint gesture on the phone in their hand, about eight seconds.

For a high value envelope, the flow can require a companion device pairing where the desktop displays a rotating pattern that the phone claims, and the phone performs a liveness check before releasing the signature. This matters for a reason worth stating plainly: it separates the screen that renders the document from the device that holds the key, which is the same structural lesson we drew from the analysis of the Bybit signing incident, where the display and the signer shared one compromised machine.

The receipt then travels with the document. It goes into the certificate of completion, into the deal file, into the loan package, and into the signer's own wallet of receipts, which is the part that matters for the human: their evidence is not held hostage by a vendor relationship they did not choose and cannot control.

You can see the underlying signing primitive at the developer docs, and the companion device flow in the signing lab.

Honest limits

This section is not a formality. If you take nothing else from this article, take these five caveats, because a control sold without its limits is a liability.

Cryptographic strength is not legal weight. Admissibility and evidential weight are functions of statute, procedural rules, and precedent, not of key length. A stronger signature does not automatically win a case, and in some jurisdictions an unfamiliar format may require expert testimony that a familiar certificate of completion would not. This article is a technical explanation and it is emphatically not legal advice. Ask your counsel how attribution evidence is actually weighed in your jurisdiction and your document types.

Enrollment is the whole ballgame. A device bound signature proves that the key enrolled to Priya Raman signed this document. If the enrollment was sloppy, if nobody ever confirmed that this key belongs to that human, then you have moved the problem rather than solved it. Enrollment deserves the identity proofing rigour that people currently apply to the signature itself.

A compromised device defeats it. If malware controls the phone and can drive the biometric prompt, the signature is produced by the attacker. Nothing here creates an uncompromisable device. What it does is remove the entire category of remote attacks that need only mailbox access, which is the overwhelming majority.

Coercion and rubber stamping are untouched. A signature binds intent to an act. It cannot tell you whether the intent was informed, considered, or free. Someone standing over a signer's shoulder produces a perfectly valid signature.

It is a two-sided adoption problem. The signer must be enrolled before the envelope arrives, which is easy for employees, repeat counterparties and account holders, and hard for one-off consumers. Apply it where the same counterparties sign repeatedly and values are high, and leave low value one-off envelopes as they are. Manav has not shipped native integrations with the major platforms, so today this is an API integration rather than a checkbox.

What to do this week

Concrete, in order, none of it requiring a procurement cycle to start.

1. Pull three certificates of completion from your highest value envelopes and read them line by line, writing down in one sentence what each line proves. This changes minds faster than any argument.
2. Inventory envelope categories by value and reversibility. A thirty year mortgage and a room booking form do not deserve the same assurance, yet most organisations apply one setting to everything.
3. Find your shared and delegated mailboxes that receive envelopes. Ask whether any document signed from those addresses would be attributable to a named individual in a dispute. If the answer is no, decide whether that is acceptable for that document class.
4. Stop counting email OTP as a real control. Either move to a genuinely separate factor, or accept the risk explicitly and in writing.
5. Ask your platform what identity options they support and specifically whether any of them produce evidence that verifies without querying the platform. It is a fair question and the answer tells you a lot.
6. If you operate in the EU, price the qualified tier for your top document category. It may already be the right answer and it is well supported.
7. Write the attribution paragraph before you need it. Draft the explanation you would give a regulator or a court about how you attribute a signature to a person. If drafting it makes you uncomfortable, you have found the gap.
8. Pilot device bound signing on one internal high value category such as payment authorisations or executive approvals, where the signers are enrolled employees and adoption friction is near zero.

The uncomfortable summary

The e-signature industry sold legal validity, and delivered it. Validity was the easy half. The statutes always put the weight on attribution, and attribution is a question of evidence about a human being, which a delivery channel cannot answer.

For twenty-five years that gap was tolerable, because forging a click required access that was hard to get and disputes were rare. Mailbox access is no longer hard to get, and the number of entities holding it who are not the named human, including agents acting helpfully on their owner's behalf, is rising.

The fix is not a better audit trail. A better audit trail is a more detailed account of the same unanswered question. The fix is to make the signature something only the named human can produce, and to make the resulting evidence something anyone can check without asking the platform that produced it.

Frequently asked questions

Is a DocuSign signature legally binding if someone else clicked the link? The signature is legally valid as an electronic signature, but validity and attribution are separate questions. Under UETA and the ESIGN Act the act must be attributable to the person, shown by any evidence including the security procedures used. If a third party had mailbox access, the certificate of completion cannot establish who signed, and attribution becomes a contested question of fact.

What does a certificate of completion actually prove? It proves what the platform observed: that a document was sent to an address, opened at a time, from an IP, and that the content has not changed since sealing. Those are real cryptographic and log-based facts. It does not prove the identity of the person operating the session, because the platform never established that identity.

Is email OTP enough for e-signature authentication? Not when the mailbox itself is the risk. Sending a one time code to the same address that received the signing link adds a step for a legitimate signer and adds nothing against an attacker who already controls that mailbox. SMS moves the code to a separate channel, which is genuinely better, though SIM swap remains a documented weakness.

What makes an electronic signature attributable under ESIGN and UETA? Attribution requires evidence that the signature was the act of the named person, provable in any manner, including the efficacy of the security procedure used. That is a factual standard, not a technical one. Stronger procedures produce stronger attribution evidence, which is why the authentication method matters when a document is likely to be contested.

How is this different from an eIDAS qualified signature? It is not different in intent. The eIDAS advanced and qualified tiers were written in 2014 to require exactly these properties: sole control of the signing data, unique linkage to the signatory, and tamper evidence. Inside the European Union the qualified tier is a well supported answer. The gap is largest in jurisdictions with no equivalent at consumer scale.

Can an AI agent sign a document on my behalf? Technically an agent with access to your mailbox can already complete a standard envelope, because nothing in that flow distinguishes an agent from a person. Whether that is authorised is a separate question. A device bound signature makes the distinction explicit, since the agent cannot produce a signature from a key held in your device's secure hardware behind a local biometric gesture.

What happens to my signed documents if the e-signature vendor shuts down? With a platform-held audit trail your evidence depends on that vendor continuing to exist, retain records and respond. With a device bound receipt, verification needs only the document, the receipt and a published key, so any party can check it independently. That matters for documents that outlive vendor relationships, such as mortgages and shareholder agreements.

Sources

1. Electronic Signatures in Global and National Commerce Act (ESIGN), Public Law 106-229, govinfo.gov.
2. Uniform Electronic Transactions Act (UETA), Uniform Law Commission, uniformlaws.org.
3. Regulation (EU) No 910/2014 (eIDAS), signature tiers and definitions, EUR-Lex.
4. Regulation (EU) 2024/1183, European Digital Identity Framework, EUR-Lex.
5. FINRA disciplinary actions database, for settlements involving forged or improperly obtained signatures, finra.org.
6. FBI Internet Crime Complaint Center, annual Internet Crime Reports, including SIM swap complaints and losses, ic3.gov.
7. Web Authentication (WebAuthn) Level 3, W3C, w3.org.
8. ETSI standards for PAdES and advanced electronic signature formats, etsi.org.

A certificate of completion is an excellent witness to everything except the one fact in dispute.