Guide

How to sign an NDA without uploading the PDF

An NDA is the canonical example of a document that shouldn't live on a third-party server. Its whole purpose is to control who knows the contents of a thing. Then we routinely upload it to a SaaS to put a signature on it. This guide shows how to sign an NDA locally, in your browser, with cryptographic evidence designed around ESIGN/UETA and eIDAS Article 26 — without ever transmitting the PDF. Admissibility in any specific dispute is jurisdiction- and fact-specific; if the stakes warrant it, run the artefact past counsel.

Why this matters for NDAs specifically

The standard e-signature flow has the same hole every time: to attach a signature, you give the signature provider a copy of the document. For most agreements that's an acceptable trade. For NDAs — especially M&A NDAs, mutual NDAs covering trade secrets, IP-assignment NDAs, security-research disclosure NDAs — it's a small but real leak. Your counterparty doesn't know there's a third copy on a vendor's S3 bucket. Their lawyer didn't sign off on it being there. The document's purpose is “limit who has this,” and the workflow contradicts that purpose.

FreeSign is built to remove the contradiction: only the parties to the NDA ever hold the PDF. The signature provider (us) sees a 32-byte hash, the email used for OTP, and a cryptographic signature over a canonical payload. That's it.

What you'll end up with

• A signed PDF, sealed with a PAdES-B-T CMS PKCS#7 signature under a per-user X.509 certificate (Subject CN = your typed legal name; subjectAltName = your verified email).
• An RFC 3161 timestamp from DigiCert's AATL-listed TSA, embedded in the signature.
• An OpenTimestamps proof for the signed-region hash (calendar attestation is immediate; public block-header confirmation typically lands in 1-2 hours).
• An evidence JSON containing the canonical signed payload, the request fingerprint and the public key — embedded inside the signed PDF, in each signature's CMS, so the PDF is self-contained.

Any third party can verify the signature with openssl, pyHanko, Adobe Reader, and the ots CLI — no call back to FreeSign required.

Step-by-step

1. Prepare the NDA PDF locally

Use whatever you'd normally use — Word/Pages export, your firm's DMS, a tool that flattens a fillable form to a static PDF. Save the file on the device you're signing from. FreeSign works on any PDF Adobe Reader can open.

2. Open FreeSign and drop the PDF

Go to free-sign.com on a browser with WebCrypto (any current Chrome, Firefox, Safari, Edge). Drag the NDA into the dropzone, or click to choose it. The browser computes the SHA-256 locally and shows it onscreen. No bytes have left your machine. The dropzone now shows the first page of the PDF as a preview — that preview is rendered by pdfjs-dist in your browser, not by us.

3. Enter your email + legal name, accept consent

Email is used only to receive a 6-digit OTP code and to bind the signer's identity into the per-user certificate's subjectAltName. We store the email as an envelope-scoped HMAC, not as plain text. Full legal name goes into the certificate's Subject CN — this is what Adobe Reader shows under “Signed by.”

4. Enter the OTP code

Check your inbox. Enter the 6-digit code in the modal. The browser generates a ceremony keypair (non-extractable WebCrypto), signs a canonical-JSON payload binding the document hash + your consent + the OTP challenge id, and posts it to the Worker. The Worker issues your per-user X.509 leaf cert from the FreeSign CA (HSM-backed, FIPS 140-2 Level 3), submits the signed-region hash to the OpenTimestamps calendar pool, fetches an RFC 3161 timestamp from DigiCert, and assembles the CMS seal. The seal is sent back to your browser; the browser appends it as an incremental update to the PDF.

5. Download the signed PDF

Click Download signed PDF. That one file is the complete evidence package: the evidence JSON is embedded inside it — in the signature's CMS, where the certificate chain and timestamp also live — and re-checkable any time with the verifier or openssl cms. You can optionally also click Download timestamp proof for a standalone copy of the .ots file. The signed PDF alone is enough for any standard PAdES verifier.

Sending the signed NDA to the counterparty

This is where FreeSign deliberately stops short of being a workflow product. We don't route the PDF for you, because we don't have it. Email it. Send it through Signal. Drop it in Drive. Burn it to a USB stick if the threat model demands it. The counterparty receives a normal PDF with an embedded signature; nothing about the file requires them to know FreeSign exists.

If the counterparty needs to countersign

They drop the signed PDF into free-sign.com, repeat the ceremony. Their signature appends a second incremental revision on top of yours. Both signatures stay verifiable in the same file — Adobe Reader's Signature Panel will list both, openssl/pyHanko can extract both. No coordination through us required.

Handing the file to a verifier (e.g. opposing counsel)

The verifier needs only the signed PDF — the evidence JSON is embedded inside it, in each signature's CMS. With that one file plus public tools, they can independently check that:

1. The PDF's own SHA-256 is its final_pdf_sha256 (shasum -a 256 signed.pdf).
2. The consent payload is what was signed (canonical-JSON hash equals evidence.payload_hash).
3. The signer's identity is bound to the signature (cert's Subject CN + subjectAltName are your name + email).
4. The signature has an independent timestamp proof (verify the .ots proof with ots verify; after upgrade it resolves to public block headers).
5. The signed PDF is sealed by the same browser key that agreed to consent (verify the final-payload signature in evidence.final_signature_base64url).

The FAQ → verification section has the exact shell commands for each step.

What the legal team needs to know

FreeSign is designed to provide the evidence usually needed for the ESIGN Act (15 U.S.C. §7001) and UETA in the US, and Article 26-style evidence under eIDAS in the EU: signer attribution, consent, association with the record, retention, ceremony-control evidence, and tamper detection via CMS hash + OpenTimestamps. The signature is not a QES (Qualified Electronic Signature) under eIDAS Article 25(2) — that requires a QTSP-issued cert on a QSCD, which is on the roadmap but not in the free product. FAQ → signature classification goes deeper.

FAQ for the NDA flow

Can the counterparty's e-signature platform (e.g. DocuSign) ingest a FreeSign-signed PDF?

Yes — it's a normal PAdES-B-T PDF with a CMS signature. They can countersign through their workflow if they want; both signatures stay verifiable independently.

What if my company requires audit trails in a specific format?

The evidence JSON embedded in the signed PDF carries the request fingerprint (IP, UA, Cloudflare colo/ASN, country); the full audit hash chain is available via GET /api/receipts/{envelope_id}. If your audit format needs more or different fields, the data is all there; map it in your own tooling.

Adobe Reader shows yellow ⚠️ next to the signature. Will that confuse the counterparty?

Maybe. The FAQ Adobe explainer is written specifically to forward to counterparty counsel: it reproduces the exact warning and explains that it is about Adobe's commercial trust list (AATL), not document integrity.