Which e-signatures still verify if the vendor is gone?

What "still verifies" has to mean

A vendor can shut down, end a product, or simply end your access when a subscription lapses. (What vendors' terms say about keeping your documents is covered in what happens if your e-signature company shuts down.) This page compares something else: once you hold the signed file, what does it take to check it? Three tests decide it:

1. The file carries the evidence. The signed document and the proof of who signed it, how and when, inside the file you keep.
2. Anyone can run the check. With public tools, not the vendor's database, validator or support team.
3. It still passes in ten years, without anyone renewing a certificate or issuing the file again.

A fourth question is what the check proves: that a platform sealed the file, or that each person signed it.

Five ways vendors make a signed document checkable

As each vendor publishes it, read on October 11, 2026:

• A vendor certificate seal, checked in a PDF reader. The most common approach, and it needs no vendor service at check time. The seal is the platform's: Documenso's documentation says its signature "is applied at the platform level, not by individual signers". Its value depends on the certificate (a self-signed one shows a warning) and, over the years, on long-term validation data in the file.
• A national validator. In Brazil, ICP-Brasil seals can be checked on the government validator run by ITI, with limits each vendor describes.
• The vendor's own records or validator. A database lookup, a vendor-hosted checker, or evidence files kept by the vendor or its archiver.
• Accredited timestamps and conservation certificates. Qualified timestamps in the EU and NOM-151 conservation certificates in Mexico, issued by accredited providers.
• Public blockchain anchors. A document's fingerprint written to a public ledger anyone can read: Zoho Sign (Bitcoin, on Enterprise), Cincel (Bitcoin, with its Certificado Smart), Mifiel (the Liquid sidechain, for promissory notes) and Attest (Horizen, on every plan).

The 21 compared

We compared 21 e-signature services in October 2026, Attest and 20 others, from each vendor's own pages (what each says about encryption is a separate comparison). Here is how each one's signed documents are checked:

Service	What you check a signed document with	What the check still needs, or its documented limits
DocuSign	A PKI tamper seal on the downloaded PDF, and the certificate of completion	A PDF reader; DocuSign's pages don't say whether the standard seal is on Adobe's trust list
Adobe Acrobat Sign	A certified PDF with a blue banner in Acrobat Reader (Adobe Approved Trust List)	Adobe Acrobat or Acrobat Reader
Dropbox Sign	A digital tamper-proof seal; an audit trail ID to "look up a record in our database"	To prove no tampering, Dropbox Sign "can provide you with the two unique document records"
PandaDoc	An Entrust certificate, checked in Adobe Acrobat	A PDF reader
SignNow	An airSlate certificate, checked in Adobe Reader	A PDF reader
Zoho Sign	A GlobalSign certificate (US); Bitcoin anchoring on Enterprise	A PDF reader; long-term validation on paid plans
Documenso	A platform-level PDF signature	A green check in Adobe if its certificate's CA is on Adobe's trust list; a warning if self-signed
DocuSeal	A PDF signature, trusted on cloud plans	Self-signed on the free self-hosted edition, which Acrobat flags
OpenSign	A P12 certificate seal	A PDF reader; the default certificate's trust status isn't stated
Clicksign	Clicksign's ICP-Brasil seal, on ITI's validator or Clicksign's own	On "Assinatura Inválida" at ITI, an updated file from Clicksign; on Clicksign's validator, a certificate renewal for documents over 12 months old
ZapSign	ZapSign's A1 ICP-Brasil seal, on ITI's validator or in Adobe	Its help pages disagree on long-term validation
D4Sign	D4Sign's verifier; certificate signatures on ITI's validator	Its help center says signatures without a certificate are commonly not validated by ITI
Autentique	Its own "processo de verificação auditável" (auditable verification process) for signatures without a certificate	Certificate signatures on ITI's validator; no external check described for its default signatures without a certificate
Youtrust	A PDF signature from a qualified trust service provider, checked in a PDF reader (a green tick for EU or Adobe trusted-list certificates); a per-signer audit trail; every signature time-stamped	Audit trails are for account users: "external signers and approvers do not have access"
Signaturit	A qualified seal and an official timestamp on the document and audit trail	A 2021 help article: validity "won't last forever, as certificates must be updated", re-download advised; its pricing page now cites a qualified preservation service
Skribble	PAdES-LTV long-term signatures; AES and QES through its trust service providers	Independent EU and Swiss validators, which Skribble points to
Mifiel	An XML file with a NOM-151 conservation certificate	Mifiel's open-source verifier, which checks "exclusivamente" Mifiel documents
Cincel	A NOM-151 file and a public blockchain anchor; anyone can read the ASN.1 file in a public decoder and check the anchor by the document's hash	Requires its Certificado Smart
Certicámara	PAdES, CAdES and XAdES signatures with accredited certificates	Standard PDF and signature readers
ecert	Certificate signatures, with a published validator, revocation lists and trust lists	Its published validation material
Attest	The original document, each signer's passkey signature and the full evidence, inside the PDF, anchored on Horizen	Nothing from Attest: the open-source verifier inside the file and any public blockchain node

Several of these are strong. Qualified seals and timestamps on EU trusted lists, ICP-Brasil seals and NOM-151 certificates carry legal weight in their jurisdictions, and Skribble, Certicámara and ecert point to validation anyone can run. If a law or a counterparty requires a qualified signature, an ICP-Brasil signature or a NOM-151 certificate, choose a provider that issues it. Several approaches need nothing from the vendor at check time: a certificate seal checked in a PDF reader, and the blockchain anchors of Zoho Sign, Cincel and Mifiel among them. What Attest adds is the combination: a check that needs nothing from the vendor, each signer's own signature on every document by default, and a verifier carried inside every signed copy.

How an Attest signed copy verifies with Attest gone

Every party downloads the same sealed PDF: the signed pages, with a "Signed with Attest" stamp on each signature and a seal line at the foot of every page, a certificate of completion, the audit trail up to completion and a "Verify it yourself, without us" page, with the full evidence, the original document and a standalone verifier attached inside.

Open the verifier in any browser and drop the PDF on it. It checks the original document inside the signed copy against what every signer signed, each signer's passkey signature and entries, Attest's anchored record of the agreement on the Horizen public blockchain, and that nothing was added to the PDF after it was sealed. It also re-makes every page you see from what was signed and compares the result with the copy byte for byte, so pages drawn with anything else fail. It pins its trust root (the chain, Attest's registry and the keys it checks against are built into the verifier, never read from the file being checked), reads only a public blockchain node, any node of that chain, and works offline apart from its on-chain checks: the anchor, and that the verifier attached to the copy is a build Attest published.

Nothing in it depends on a certificate that expires. Each signature is made with a passkey, a cryptographic key only the signer controls, unlocked with Face ID, Touch ID, Windows Hello or the device PIN, and the evidence uses only open standards, such as WebAuthn, SHA-256 and Merkle trees. Each cryptographic check can also be run with standard tools, such as any SHA-256 tool, any WebAuthn library and any Ethereum JSON-RPC node. The verifier itself is open source under the MIT license, on GitHub at DataHubz/attest-verifier, with reproducible builds and each release published with its SHA-256.

Attest has tested this on a real agreement: signed on attest.datahubz.com and anchored on Horizen, it was verified with Attest blocked, by the verifier inside its signed copy, reading only a public blockchain node, and changing the pages made it fail. The film, "We blocked Attest. The agreement still verified.", is on the signing page.

How to test any vendor before you rely on it

1. Complete a test document and download it. Open the PDF's attachments: is the evidence inside, or only signed pages?
2. Check it the way a stranger would, with no account: in a PDF reader, on a public validator, or with a verifier you can download.
3. Ask what the check needs in ten years: long-term validation data, a certificate renewal, or a fresh download from the vendor.
4. Ask what it proves: that the vendor sealed the file, or that each signer signed it.
5. Keep the files exactly as downloaded, in two places you control.

Your first 2 documents on Attest are free, in total, so you can run this test on Attest too, with a real agreement.