What a breach at an e-signature company exposes

What an e-signature service holds

An e-signature service holds more than your documents. A breach reaches whatever the attacker can read, so it helps to think in layers.

Layer	What it contains	Readable by a service that holds the keys	At Attest
Accounts	Email addresses, sign-in details, settings	Yes	Account emails, when and how each account signed in, and each passkey's label naming its device type and browser. There are no passwords: you sign in with a link emailed to you or with a passkey. Attest emails you whenever a passkey is added to your account or your key is reset
People	Names and email addresses of senders and signers, including people who only signed	Yes	Yes
Agreement details	Titles, file names, notes to signers, timestamps, where fields sit	Yes	Yes
Documents and entries	The contracts, and what signers filled in	Yes: encryption at rest is decrypted by the service whenever its software needs the file	No: stored only as ciphertext Attest can't read
Keys	The keys that decrypt documents or make signatures	The service's own	Attest never sees a signer's private key, passkey secret or recovery phrase
Biometrics	Faces, fingerprints, ID photos	Only if the service collects them, for example for ID checks with a selfie, which some services offer	Never sent to Attest: a passkey checks your face or fingerprint on your device

The first three layers exist at every signing service, Attest included: to deliver a document and prove it was signed, a service has to know who it goes to and when each step happened. The fourth layer is where services differ most. Can your e-signature company read your contracts? explains why most can, and the 21-service comparison quotes what each says.

What two real incidents exposed

Dropbox Sign, 2024. On April 24, 2024, Dropbox became aware of unauthorized access to the Dropbox Sign production environment. Dropbox said a third party had gained access to "a Dropbox Sign automated system configuration tool" and "compromised a service account that was part of Sign's back-end". For users, the exposed data included email addresses, usernames, phone numbers, hashed passwords, general account settings and "certain authentication information such as API keys, OAuth tokens, and multi-factor authentication". And: "For those who received or signed a document through Dropbox Sign, but never created an account, email addresses and names were also exposed." Dropbox reported "no evidence of unauthorized access to the contents of customers' accounts (i.e. their documents or agreements), or their payment information", and it disclosed the incident on May 1, 2024, in a blog post and a Form 8-K filed with the SEC.

DocuSign, 2017. DocuSign's alert of May 15, 2017 said that "a malicious third party had gained temporary access to a separate, non-core communication system used for service-related announcements that contained a list of email addresses", that "only email addresses were accessed", and that "No content or any customer documents sent through Docusign's eSignature system was accessed". The same alert described phishing emails that "spoofed" the DocuSign brand with malicious Word attachments, and listed fake subject lines that began with "Completed" and ended with "Document Ready for Signature".

Two lessons follow. People who only signed a document can have their names and email addresses exposed, even when they never created an account. And a list of email addresses is enough to aim convincing fake signing requests at a service's users, which how to tell a real signing request from phishing helps you spot.

If Attest's servers were breached

What would be exposed. The information around your agreements: account and signer email addresses, each document's title, file name, size and type, your note to the signers, the signers' names, where fields are placed and when each step happened, plus when and how each account signed in and each passkey's device-and-browser label (such as "iPhone · Safari"). Also the signature evidence: each signer's passkey public key and the WebAuthn data of each signature, which a public certificate shows anyway, since anyone needs them to re-check a signature.

What would stay unreadable.

• Your documents and everything signers entered. Each document is encrypted in the sender's browser with AES-256-GCM under its own random key, and that key is locked separately to each party's public key. What signers fill in is encrypted in their browsers with the same document key. Attest stores your document only as ciphertext it can't read.
• The keys that open them. Each person's private key is created in their browser and stored only encrypted, under a key derived from their passkey or their recovery phrase. Attest never sees a private key, a passkey's secret or a recovery phrase, so the stored copies are ciphertext too.
• Faces and fingerprints. Attest never receives them. The WebAuthn standard behind passkeys says biometric data "is not revealed to the WebAuthn Relying Party", so "a security breach at a Relying Party cannot expose biometric data for an attacker to use for forging logins at other Relying Parties".
• Passwords. There are none to steal.
• The wallet keys that anchor records. They are held only by a separate signing service that can sign nothing but anchors, key directory roots and capped network-fee top-ups. The app holds no wallet keys.

What a breach couldn't quietly change. Each signature is the signer's own passkey signature over a statement naming the document's fingerprint and their entries, and the completed agreement is anchored on the Horizen public blockchain. Change one byte of the document, of any signer's entries or of the signed pages, and verification fails. The open-source verifier inside every signed copy checks each signer's passkey signature, the original document, the pages you see and Attest's anchored record on Horizen, and it pins its trust root: the chain, Attest's registry and the keys it checks against are built in, never read from the file being checked.

Future documents. Before your browser locks a document key to someone, it checks their public key against Attest's public key directory, whose roots are published on Horizen and can never be replaced, and refuses a key that isn't the published one. Each person's browser also checks their own entry in every published root, so a key slipped in for them is found.

What end-to-end encryption doesn't cover

End-to-end encryption protects the contents stored on a service. It doesn't hide:

• The information around the document, listed above. Use neutral titles and file names, and keep terms out of notes to signers.
• The signing emails. They carry the document's title and the sender's email address, and pass through ordinary email providers.
• A public certificate. If the sender leaves it public, anyone with its link sees the title, the file name and each signer's name and signing time, among other details, never the document. A private certificate is visible only to the parties.
• Anchor activity. Each account's anchors are sent from its own wallet address, so their number and timing are public, never their content.
• Copies people have downloaded. A signed copy on someone's laptop or in their email is as safe as that laptop or that inbox.

What to do after a breach notice from your e-signature provider

1. Read what was accessed. Accounts, people, agreement details and document contents are different layers, and the notice should say which ones.
2. Expect targeted phishing. Attackers who hold a list of a service's users can send fake requests in its name. The US Cybersecurity and Infrastructure Security Agency advises: "if you think it could be real, don't click on any link or call any number in the message. Look up another way to contact the company or person directly".
3. Replace what the notice names. Change passwords and rotate API keys or tokens if they were exposed, and turn on stronger sign-in where you can.
4. Check your signed documents. With Attest, drop a signed copy on attest.datahubz.com/verify, or on the verifier attached inside it, and confirm it still checks out.
5. Tell the people you sign with, if their names and email addresses were part of what was exposed, so they know to expect fake requests.