Upload: TLS in transit
The browser uploads the document over TLS 1.2/1.3. The connection itself is protected by hybrid encryption — the exact envelope pattern: a symmetric session key negotiated under asymmetric cryptography.
When you upload a contract to an e-signature platform, where does it get encrypted, with what, and by whose keys? This guide walks through the practical encryption architecture behind e-signature platforms — transport security, envelope encryption at rest, key custody, and the questions to ask before you trust a vendor with sensitive documents.
A document passes through distinct states, and each state needs a different protection mechanism.
The browser uploads the document over TLS 1.2/1.3. The connection itself is protected by hybrid encryption — the exact envelope pattern: a symmetric session key negotiated under asymmetric cryptography.
The document is written to encrypted storage. Serious platforms use envelope encryption: each document (or object) is encrypted with a unique data key (DEK), and the DEK is wrapped by a customer or platform master key (KEK). A breach of storage yields only ciphertext and wrapped keys.
Signing events are recorded in an audit log, itself encrypted and often write-once. The signed document is sealed with a cryptographic seal and timestamp so its final state can be proven later.
When recipients download, access is re-checked and the document is served over TLS again. Copies in browsers and email threads are outside the platform's protection — a point most buyers miss.
The term "envelope encryption" shows up in vendor security docs, but it applies at specific layers. Knowing which layer you are looking at changes what you should ask.
Envelope encryption is only as strong as the key management around it. Three models dominate, and each changes your risk profile.
The platform generates and holds the master keys in its own HSM. Simplest to operate; your security depends on the vendor's key-handling controls and their breach response.
You bring your own key (AWS KMS, Azure Key Vault, GCP KMS, or an on-prem HSM). The platform encrypts with your key; you can revoke or rotate it. Stronger control, more operational work for you.
Your organization controls the entire key hierarchy and the platform never sees plaintext keys. The strongest posture for regulated industries, but requires real crypto operations capability on your side.
Encryption answers "who can read it?" — but buyers often assume it answers more. Three gaps matter for compliance.
After a recipient downloads or screenshots a document, platform encryption no longer applies. DLP, watermarking, and access policy are separate controls; ask about them explicitly.
Encryption alone does not prove who signed or that content is unaltered. That is the signature's job — a legally binding signature needs a certificate chain and trusted timestamp, not just encryption.
How a vendor handles key-compromise disclosure, key rotation schedules, and region restrictions on keys varies widely. Ask for the key lifecycle policy in writing.
Look for three things in the trust center: (1) TLS 1.2+ enforced everywhere, (2) at-rest encryption using envelope encryption with per-object DEKs, (3) key custody options (vendor-managed vs BYOK). If the security whitepaper does not mention envelope encryption or key hierarchy, ask why.
eSign.AI encrypts documents in transit with TLS 1.2+ and at rest with envelope encryption under managed keys, seals completed documents with cryptographic tamper-evidence and trusted timestamps, and packages the certificate chain for long-term validation — so the document is protected at every stage of its journey, and provably authentic years later.
