What Is a Verifiable E-Signature? The 2026 Definition Most Platforms Don't Meet

TL;DR — the seven criteria

A truly verifiable e-signature meets all of the following. A signature missing any one of them is, at best, legally valid but not technically verifiable.

#CriterionWhat it means1Cryptographic binding to document contentThe signature mathematically binds to the document's bytes; any alteration breaks the signature2Cryptographic binding to a verifiable signer identityThe signature traces back to a key controlled by an identified entity, typically via a certificate chain to a recognised trust authority3Tamper evidenceModifications to the document after signing are detectable, not merely prohibited by policy4Independent verifiabilityA third party can verify the signature without access to the signing platform's internal systems5Long-term verifiabilityThe signature remains verifiable years after the signing event, including after the signing certificate's natural expiry6Revocation channelThe signer or issuer can revoke the signature, and verifiers can check current status7Recipient-accessible verification UXA non-technical recipient can confirm the signature's validity without specialist tools

The first six are technical. The seventh is what made verifiable e-signatures actually usable in the real world — and is the criterion most platforms still fail.

What ESIGN and UETA actually require

Before the verifiable criteria above, it's worth stating clearly what the legal frameworks require, because the gap between the legal threshold and the verifiable threshold is the entire subject of this article.

The US legal framework consists of two complementary laws.

The ESIGN Act, enacted in 2000, is the federal statute. It applies to interstate and foreign commerce and provides that electronic signatures and records have the same legal effect as their paper equivalents, provided four conditions are met. Our full breakdown is in ESIGN Act vs UETA; the short form:

Intent to sign. The signer must intend to be bound by the signature. Clickwrap buttons clearly labelled "I Agree" or "Click to Sign" generally suffice.

Consent to do business electronically. Particularly for consumer transactions, the consumer must affirmatively consent to receive and sign documents electronically — and demonstrate they can access the electronic records.

Association of signature with the record. The signature must be attached to or logically associated with the document being signed, with a record of how the signature was created.

Record retention. The signed record must be retained in a form that accurately reproduces the original and remains accessible to all parties for the required retention period.

UETA, adopted by 47 states plus DC, the US Virgin Islands, and Puerto Rico (with New York and Illinois operating under their own functionally-equivalent state laws), provides the state-level framework with essentially the same four pillars. The two laws coexist: ESIGN applies federally, UETA applies intrastate, and a signature meeting either is generally enforceable.

The EU framework under eIDAS 2.0 is structurally different but reaches a comparable bottom threshold. eIDAS distinguishes three tiers:

Simple Electronic Signature (SES). Any data in electronic form attached to or logically associated with other data that's used by the signatory to sign. A typed name qualifies.

Advanced Electronic Signature (AdES). SES plus: uniquely linked to the signatory; capable of identifying the signatory; created under the signatory's sole control; linked to the signed data such that subsequent change is detectable.

Qualified Electronic Signature (QES). AdES plus: created using a qualified signature creation device (QSCD) and based on a qualified certificate from a Qualified Trust Service Provider (QTSP). QES is the only electronic signature that is automatically equivalent to a handwritten signature across all EU member states.

The legal upshot in both jurisdictions: the minimum requirement for a legally valid e-signature is procedural (intent, consent, attribution, retention), not cryptographic. A typed name with appropriate consent and audit trail can be a perfectly valid e-signature.

For more on the practical EU-specific implications including the EUDI Wallet rollout, see our eIDAS explained overview.

Why "legally valid" ≠ "verifiable"

This is the core tension the rest of the article unpacks.

A signature is legally valid when it satisfies the procedural requirements of the relevant law. A signature is verifiable when an independent party, examining the signed document, can confirm with high confidence that the signature is authentic, the signer is identified, and the document has not been altered.

The two overlap but are not the same. A typed name on a clickwrap is legally valid but not verifiable: a recipient cannot, from the document alone, confirm that the named person actually clicked the button (rather than someone who knew their email password) or that the document they have is the document the named person actually saw and consented to. The audit trail held by the signing platform may resolve this — but only if the platform is still in business, still accessible, still trusted, and willing to attest to what happened. None of these are guarantees over a decadal horizon.

The distinction has practical consequences:

In disputes. A signature that's only verifiable through the signing platform creates a dependency on the platform's continued cooperation and existence. If the platform is acquired, sunset, or compromised, the signature's verifiability degrades.

In transfer. When a signed document moves between parties — a contract assigned to a third party, a credential presented to a new verifier, a mortgage loan sold in a secondary market — the new holder has no inherent way to verify the signature without going back to the original signing platform.

In long horizons. A signature meant to remain enforceable for decades (mortgages, deeds, wills where they're permitted, long-term contracts) needs to remain verifiable when the original signing platform may no longer exist.

In an AI-fraud context. When the document itself can be fabricated convincingly by AI, a signature that depends on the audit trail of one platform — rather than on the document's intrinsic cryptographic properties — provides no defence against documents that simply weren't signed there to begin with.

The verifiable e-signature standard solves these problems structurally rather than procedurally.

The seven criteria, in depth

1. Cryptographic binding to document content

A verifiable signature must be mathematically tied to the bytes of the document being signed. The standard approach: compute a cryptographic hash (typically SHA-256, producing a 256-bit fingerprint that changes if any byte of the document changes), then sign the hash with the signer's private key.

This produces three properties simultaneously: the signature is unique to this specific document (the hash differs for any other document), any modification to the document invalidates the signature (the recomputed hash won't match), and the signature can be verified by anyone with the signer's public key (without access to the original signer or any platform).

A signature that's not bound to document content — a typed name in an email, a clickwrap on a contract, an image-based "signature" pasted into a PDF — fails this criterion. The signature exists but isn't mathematically tied to what was signed. We cover the technical distinction in more depth in electronic signature vs digital signature.

2. Cryptographic binding to a verifiable signer identity

The signature must trace back to a private key whose corresponding public key is associated with an identified entity. The standard mechanism is a digital certificate issued by a Certificate Authority (CA) — a trusted third party that has verified the entity's identity before issuing the certificate. The certificate binds the public key to the identity; the signature uses the matching private key; verification consists of validating the signature against the certificate.

There are two main trust models:

Web PKI (the same model that secures HTTPS) uses commercially-operated CAs and well-known root certificates installed in operating systems and browsers. PDFs signed under this model use certificates from CAs participating in the Adobe Approved Trust List (AATL) for broad PDF reader recognition.

eIDAS / national trust lists, where qualified certificates are issued by Qualified Trust Service Providers (QTSPs) listed in EU Member State trust lists, and verifying parties trust the published lists rather than a private root.

A signature whose certificate doesn't trace to a recognised trust authority — or where no certificate exists at all — fails this criterion. The signature might be cryptographically valid in isolation, but the verifier has no basis to associate it with a specific identity.

3. Tamper evidence

Modifications to the signed document after signing must be detectable. This is closely related to criterion 1 — content-binding via hashing inherently provides tamper evidence — but extends beyond it. Tamper evidence requires that:

The signature covers the full meaningful content of the document, not just a portion of it.

Modifications anywhere in that content invalidate the signature.

The signature itself cannot be easily transplanted onto a different document without breaking the verification.

Different signature formats provide different scopes of tamper evidence. For PDFs, the ETSI PAdES standard (ETSI EN 319 142-1) specifies signature embedding in a ByteRange that covers the entire PDF except for the signature object itself, providing whole-document tamper evidence. The depth on this is in our QR code signature validation guide.

For other document types, the equivalent standards are CAdES (general data signing, ETSI EN 319 122-1), XAdES (XML, ETSI EN 319 132-1), and JAdES (JSON, ETSI EN 119 182-1). Wallet-bound credentials under W3C Verifiable Credentials Data Model 2.0 use VC-JOSE-COSE for signature embedding.

4. Independent verifiability

A verifiable signature must be checkable by a third party who has no relationship with the signing platform. This is the criterion most "e-signature" platforms fail in a structural way: the signature is only verifiable through their own audit trail interface.

Independent verifiability requires that the signed document carries everything a verifier needs:

The signature itself.

The signer's certificate (or a reliable reference to it).

Sufficient information to validate the certificate against a trusted root.

The data that was signed (the document content, or a hash of it).

A signed PDF with an embedded PAdES signature satisfies this — Adobe Acrobat, open-source PDF readers with trust list support, or command-line tools like openssl can validate the signature against the certificate, without any dependency on the platform that produced the signature.

A "signed" document where the signature is merely a typed name with an audit trail held in a vendor's database fails this criterion entirely. Without access to the vendor's system, no verification is possible.

5. Long-term verifiability

Signing certificates expire — typically 1 to 3 years after issuance. Cryptographic algorithms eventually weaken. Trust authorities can be deprecated or change roots. A naive signature implementation that just embeds a signature and certificate may become unverifiable after a few years, even though nothing about the document or the signing event has changed.

The solution is long-term validation (LTV) or long-term archival (LTA) signature profiles. PAdES specifies PAdES-LTV (and the more rigorous PAdES B-LTA), which:

Embed the full certificate chain at signing time, including intermediate certificates.

Embed certificate revocation information (OCSP responses or CRLs) captured at signing time.

Add cryptographic timestamps from a Qualified Trust Service Provider (TSA), proving the signature existed at a specific moment.

Refresh those timestamps periodically (every few years), creating a chain that extends the verifiability horizon indefinitely.

A signature without LTV is a signature whose verifiability degrades over time. For documents meant to be enforceable for decades — deeds, mortgages, professional certifications, academic credentials — LTV is not optional.

6. Revocation channel

The signer (or the issuer, for credential-style signatures) must be able to revoke the signature, and verifiers must have a way to check current revocation status. This matters whenever a signature represents an ongoing claim — a professional licence still in good standing, an offer of employment still valid, a digital certificate still trusted — rather than a one-time event.

The standard mechanisms:

Certificate Revocation Lists (CRLs) — published lists of revoked certificates, downloadable and cacheable.

Online Certificate Status Protocol (OCSP) — real-time lookup of an individual certificate's revocation status.

OCSP stapling — embedding OCSP responses into the signed document at signing time to reduce verifier-side dependencies.

W3C Bitstring Status List — the W3C VC-native mechanism for revocation of verifiable credentials, privacy-preserving and space-efficient.

A signature with no revocation channel is permanently valid by default, which is the right behaviour for some uses (a signed historical document) but the wrong behaviour for credential-style signatures (a current employment letter, a current insurance certificate, a current professional licence). The right design exposes revocation as part of the verification flow.

7. Recipient-accessible verification UX

This is the criterion most discussions of digital signatures historically ignored, and the one whose absence has held back verifiable e-signatures for two decades. A signature that requires the recipient to install specialised software, configure trust roots, run command-line tools, or interpret a certificate chain may be cryptographically verifiable but is not practically verifiable for the people who actually receive most documents — HR managers, tenant screeners, lenders, underwriters, regulators, customers.

The 2026 answer is QR-based verification: the signed document includes a QR code resolving to a hosted verification page on the issuer's domain, where the cryptographic checks are performed server-side and the result is rendered for a non-technical recipient. The recipient opens their phone camera, scans, and gets an answer in seconds. The cryptography is real; the experience is human.

The full architecture is covered in our scan-to-verify documents pillar guide. The point for this article is that a signature platform missing this criterion may produce signatures that are technically verifiable to specialists but aren't verifiable in any meaningful sense to the recipients who matter.

Where most platforms fall short

The 2026 e-signature market is dominated by platforms that produce signatures meeting some of the seven criteria but not all. The common patterns:

Click-to-sign with audit-trail-only verification. The signature is a typed name plus a record of the signing event held in the platform's database. This is legally valid under ESIGN/UETA. It fails criteria 1, 2, 3, 4, 5, and 7. The only verification available is "log in to the platform and trust what the audit trail says."

PDF "signature image" embedding. The signature is a graphical image (a drawn signature, a logo, a typed name in a stylised font) pasted into the PDF, possibly with metadata. No cryptographic binding to content or identity. Legally valid; fails criteria 1, 2, 3, 4, 5, and 7.

PDF cryptographic signatures with self-signed or non-trusted certificates. The signature is technically cryptographic but uses a certificate that doesn't trace to any recognised trust authority. The PDF viewer often shows a warning: "Signed and all signatures are valid, but the signer's identity is unknown." Meets criterion 1 (content binding) and partially 3 (tamper evidence within the file). Fails criterion 2 (identity binding to a trust authority) and consequently 4 (independent verifiability against a recognised root).

PDF signatures with AATL-trusted certificates but no LTV. Cryptographically sound at signing time, but degrades after the certificate expires. Meets criteria 1, 2, 3, 4. Fails 5 (long-term verifiability), and typically 7 (still requires opening in a capable PDF reader).

Full PAdES-LTV with QR-based hosted proof page. Meets all seven criteria. This is the 2026 baseline for documents that matter.

The realisation that follows: the gap isn't between cryptography and no cryptography. It's between legally sufficient and operationally trustworthy. Most platforms aren't lying when they say their signatures are valid under ESIGN/UETA — they are. They are also producing signatures that depend entirely on their own platforms for ongoing verifiability, which is a different problem.

The three-tier model, applied

The cleanest mental model for thinking about where a given signature sits comes from eIDAS, which we can apply globally even outside the EU:

Tier 1 — Simple (SES). Procedural compliance with intent/consent/attribution/retention. Legally valid; cryptographically minimal. Examples: typed name with clickwrap, email signature.

Tier 2 — Advanced (AdES). Cryptographic content binding, identity binding to a certificate, tamper evidence, independently verifiable. Examples: PAdES-signed PDF with a recognised commercial CA certificate, W3C Verifiable Credential signed with VC-JOSE-COSE.

Tier 3 — Qualified (QES). Advanced plus a qualified certificate from a Qualified Trust Service Provider plus a qualified signature creation device. Cross-border legal equivalence to handwritten signature across the EU. Examples: QES signatures issued by QTSPs listed on EU Member State trust lists.

The "verifiable e-signature" of this article's title sits at Tier 2 or above. Tier 1 signatures are valid; they aren't verifiable in the technical sense the seven criteria require.

Where you need each tier depends on the use case. For internal company contracts, Tier 1 is often sufficient. For HR documents that will be presented downstream to lenders and landlords, Tier 2 is appropriate. For high-value international transactions where the signature's legal weight matters across borders, Tier 3.

For a deeper look at how all this maps to specific document types, see our scan-to-verify documents pillar guide; for credential-specific signatures, QR code certificate verification.

The audit trail vs. the signature itself — a critical distinction

A common source of confusion deserves a section of its own. Most e-signature platforms market their "audit trail" as the evidence supporting their signatures, and audit trails are real and useful. They are not, however, a substitute for cryptographic verifiability.

An audit trail records what happened during the signing process: when the document was sent, when it was opened, what IP address the signer accessed it from, what authentication they completed, when they clicked sign. This is evidence about the signing event, held by the signing platform.

A cryptographic signature, by contrast, is evidence intrinsic to the signed document. The document carries within itself the proof that it was signed by the holder of a specific private key, against specific content, at a specific time.

The difference matters in three ways:

Trust dependency. The audit trail's reliability depends on the platform's continued existence and trustworthiness. The cryptographic signature's reliability depends on mathematics.

Transferability. An audit trail belongs to the platform; the signed document belongs to the parties. When a document moves between platforms, the audit trail stays behind.

Tamper resistance. An audit trail can in principle be altered by the platform that holds it (or by an attacker who compromises the platform). A cryptographic signature can be altered only by breaking the cryptography, which is currently infeasible.

For low-stakes, short-horizon decisions, an audit trail may be sufficient. For high-stakes, long-horizon, or downstream-circulation use cases, the audit trail is a supplement to verifiable signatures, not a replacement.

Not every document needs to meet the verifiable threshold. A pragmatic decision framework:

Verifiable is required when:

The document will be presented to parties who don't have access to the signing platform (e.g., HR letters presented to lenders, certificates presented to regulators).

The document needs to retain verifiability beyond the realistic life of the signing platform.

The document is in a category where AI fraud is now common (income documents, identity documents, credentials).

Cross-border legal equivalence matters (especially for EU jurisdictions).

The document is subject to formal compliance frameworks that mandate it (SOC 2, ISO 27001, sector-specific frameworks — see our CISO's guide to document trust).

Verifiable is nice-to-have when:

The document is internal, short-lived, and never leaves the original parties.

The transaction is bilateral and both parties have a continuing relationship.

The cost of verification failure is bounded.

Verifiable is not the right framing when:

The document type is legally excluded from electronic signing entirely (wills, certain family law matters, court orders) — paper or notarisation is required regardless.

The "signature" is really a notification or acknowledgement rather than a binding commitment.

For organisations evaluating their current signing infrastructure, the practical test is the seven criteria: does what you produce today meet all of them? If not, the document categories that should move first are the ones that get circulated downstream — HR letters, financial documents, credentials, contracts that get assigned or referenced years later.

Is a typed name in an email a valid e-signature?

Under ESIGN and UETA, yes — if intent to sign, consent to electronic transaction, association of signature with the record, and proper retention are demonstrated. Courts have upheld email signatures repeatedly (notably Cloud Corp. v. Hasbro in 2002). It is not, however, a verifiable signature in the technical sense — it fails most of the seven criteria.

Is a DocuSign or Adobe Sign signature verifiable?

Depends on the configuration. Both platforms can produce signatures at multiple tiers — from clickwrap-style Tier 1 signatures up through PAdES-compliant Tier 2 signatures with AATL-trusted certificates. The specific signature on a specific document determines verifiability; the platform brand alone doesn't.

Can a signature be cryptographic and still not be verifiable?

Yes. A self-signed cryptographic signature, or one using a certificate that doesn't trace to any recognised trust authority, is cryptographically valid in isolation but fails the identity-binding criterion. A PDF reader will show "Signed, identity unknown."

What's the relationship between a verifiable e-signature and a digital signature?

"Digital signature" usually refers specifically to the cryptographic technique (asymmetric cryptography, hashing, certificate-based identity). A verifiable e-signature uses digital signature technology as part of meeting the seven criteria — but adds independent verifiability, long-term verifiability, revocation, and recipient-accessible UX as additional requirements. See electronic signature vs digital signature for the deeper terminology.

Do I need a verifiable e-signature for internal company contracts?

Generally no — internal bilateral contracts where both parties have ongoing access to the signing platform can rely on Tier 1 signatures with adequate audit trails. The verifiable threshold becomes necessary when documents circulate beyond the original parties.

Is blockchain signing a verifiable e-signature?

Blockchain anchoring solves a different problem (proving a hash existed at a point in time without trusting any single party). It's a useful complement to cryptographic signing in some cases, but not a substitute for the seven criteria — particularly criterion 7 (recipient-accessible UX), which blockchain alone does not provide.

What happens to verifiability when the signing certificate expires?

Without long-term validation, verification depends on the verifier's ability to trust an expired certificate or to retroactively check what the certificate's status was at signing time. With PAdES-LTV or equivalent, the necessary validation material (revocation status, timestamps from a TSA) is embedded in the document at signing time and the signature remains verifiable indefinitely.

Does GDPR affect what counts as a verifiable signature?

GDPR doesn't define signature validity — eIDAS does. But GDPR affects how signing platforms handle the personal data involved in signature creation, particularly authentication data, audit trails, and identity verification artefacts. Verifiable signatures and GDPR compliance are independent dimensions; a platform can score well on both.

Can a verifiable e-signature be revoked after the fact?

Yes, via the revocation channel (criterion 6). Revocation doesn't unsign the document — it doesn't change what happened at signing time — but it signals to verifiers that the signature should no longer be relied upon. For credential-style signatures (employment letters, professional licences, certificates of insurance), revocation is essential.

Is the "verifiable e-signature" definition in this article the same as a "qualified electronic signature" under eIDAS?

Closely related but not identical. A QES under eIDAS is a specific legal designation with formal qualification requirements (qualified certificate from a QTSP, qualified signature creation device). The verifiable e-signature definition in this article is broader and applies globally — a PAdES-LTV signature with an AATL-trusted certificate from a commercial CA would qualify as verifiable under our seven criteria without necessarily being a QES under eIDAS. QES is verifiable; verifiable isn't always QES.

How do I tell if my current platform produces verifiable signatures?

Three quick tests. First, open a signed document from your platform in Adobe Acrobat (or a PDF reader with trust list support) — does it show a verified signature with a known signer identity? If it shows "signature is valid, identity unknown" or no signature at all, you're at Tier 1. Second, take the signed document and try to verify it on a machine that has never used your platform — does verification still work? If not, you fail criterion 4 (independent verifiability). Third, does your platform expose a verification URL or QR code that someone with no account can use to confirm authenticity? If not, you fail criterion 7.

VerifyDoc.ai produces e-signatures that meet all seven verifiable criteria, with QR-based recipient verification built into every document. For the cryptographic mechanics, see our QR code signature validation guide; for what this looks like for recipients, our hosted proof page guide.