Encryption, explained without the acronym soup

Every vendor security page says the same sentence: 256-bit AES encryption at rest, TLS 1.3 in transit. Ours does too. It is true and it is nearly meaningless without knowing what those two things defend against, because they defend against quite narrow threats.

In transit: protecting the journey

TLS protects data moving between your browser and our servers. Without it, anyone positioned along the network path — a compromised router, someone on the same café wifi, an ISP — could read the contents.

TLS 1.3 removed the older cipher suites that made previous versions vulnerable, and it provides forward secrecy: session keys are ephemeral, so an attacker who records encrypted traffic today and later obtains our private key still cannot decrypt it.

What it does not protect against: anything at either endpoint. If a signer’s laptop has malware, TLS is irrelevant — the document is decrypted and on screen by definition.

At rest: protecting the storage

Encryption at rest means data on disk is stored as ciphertext. The threat model is physical and infrastructural: a stolen drive, an improperly decommissioned server, a misconfigured storage bucket, a backup that ends up somewhere it should not.

It is genuinely important and it is frequently oversold. Encryption at rest does not protect against a compromised application, because a running application must be able to decrypt the data to function. If an attacker gains application-level access, they inherit its ability to read.

Key management is the real question

Strong encryption with poorly managed keys is decoration. The questions that actually distinguish implementations:

• Where are keys stored, and is it separate from the encrypted data?
• Who can access them, and is that access logged and reviewed?
• How often are they rotated, and can rotation happen without downtime?
• Is there a hardware security module, or are keys in application config?
• What is the recovery path if a key is lost, and who can trigger it?

We use envelope encryption. Each document is encrypted with its own unique data key; that key is itself encrypted by a master key held in a hardware security module. The HSM never releases the master key — it performs decryption operations internally. Access is logged, and no individual employee can extract it.

Why not end-to-end encryption?

A fair question, and one we get regularly. End-to-end would mean we could never read document contents at all. It would also make most of the product impossible.

We render pages for display in a browser. We detect signature lines for Smart Fields. We generate searchable completed documents and produce a hash of the final file. Every one of those requires the plaintext at some point during processing.

A product that stored only opaque blobs would be a file locker, not a signing platform. We think the honest position is to say clearly what we can technically access and constrain it tightly, rather than imply a guarantee the architecture does not provide.

Backups are where encryption quietly fails

Production databases get attention. Backups frequently do not. A common real-world failure is a well-encrypted primary store and a backup written to storage with weaker controls, or restored into a staging environment where access is looser and the data is now plaintext to a much larger group.

Our backups are encrypted with the same key hierarchy as production and are never restored into non-production environments with real data. Test environments use synthetic data generated to match production shape without containing any customer content. This is unglamorous and it closes one of the most common paths to a breach that had nothing to do with the production system.

What "zero knowledge" would actually require

Since we get asked: a genuinely zero-knowledge signing platform would need keys generated and held exclusively on client devices, with the server storing only ciphertext it can never open.

The consequences are severe and worth stating. Losing your key means losing every document permanently, with no recovery path. Sharing a document with a new signer requires a key exchange. Server-side search becomes impossible. Audit trail generation and document hashing would have to happen client-side, where they are considerably easier to tamper with — which undermines the exact property signing platforms exist to provide.

There are products where that trade is correct. A platform whose core value is a trustworthy third-party record of what was signed is probably not one of them.

What we actually access

Automated systems process document contents to provide the service. Human access to customer document contents requires an explicit break-glass procedure, is limited to a small on-call group, generates an immutable audit record, and triggers a notification. In the ordinary course of operating the platform, no employee reads your documents.

That is a policy and access-control guarantee rather than a mathematical one. We would rather describe it accurately than dress it up as something stronger.