Security
What we protect, and how
Sensitive fields are encrypted one by one, sign-in needs no password, and every signed document carries the proof of what happened to it. This page lists what that means in practice.
How it works
Five protections, built into the product
What protects your documents and your accounts, and where each protection sits.
Sensitive fields, encrypted one by one
Signatures, form values, names and email addresses, the audit trail, link tokens, webhook secrets and payloads, and messages are each encrypted with AES-256-GCM before they reach the database. The keys sit on a keyring: a new key takes over encryption while older ones still decrypt, so a key can be rotated without re-encrypting everything at once.
An audit trail that shows any change
Every event is chained to the one before it by its hash, and the chain is anchored by an RFC 3161 external timestamp. The finished PDF is sealed: change one byte afterwards and it no longer matches its seal.
Sign in without a password
Sign-in uses a one-time code sent by email, so there is no password to reuse or to leak. Single sign-on admits only people whose provider has confirmed their email address, and the provider's tokens are not stored.
A second factor your organisation can require
Add two-factor authentication or a passkey to an account. An organisation can make a second factor mandatory for every member.
Webhooks and API tokens that hold up
Every webhook is signed with HMAC-SHA256 so your endpoint can check it came from us, and a webhook URL must resolve to a public address. API tokens are stored only as a hash, and error reports are scrubbed of personal data before they leave the application.
Sovereign plan
Control that stays with you
On the Sovereign plan, the choices that matter most to a regulator are yours to make. Each one is configured with your team before you go live.
- Bring your own keys: customer-held keys, or signing in your HSM or KMS
- Choose where your data is hosted, in your own region
- Verify each signer's identity with an ID document and a liveness check
FAQ
Security questions
What exactly is encrypted?
Sensitive fields are encrypted individually with AES-256-GCM: signatures, form values, names and email addresses, the audit trail, link tokens, webhook secrets and payloads, and messages. Underneath that, stored files and the database are encrypted at rest by the storage provider.
Who holds the encryption keys?
On our managed service, we do, on a keyring that lets us rotate them: the newest key encrypts and older keys can still decrypt. On the Sovereign plan you can bring your own keys and sign in your own HSM or KMS; we set this up with your team.
How is sign-in protected?
There is no password. You sign in with a one-time code sent to your email, or through single sign-on, which only admits people whose email address the provider has confirmed. An account can add two-factor authentication or a passkey, and an organisation can require a second factor for every member.
How does a signed document prove it was not changed?
The finished PDF is sealed, so any change afterwards breaks the seal. Its audit trail is hash-chained, each event linked to the one before, and anchored by an RFC 3161 external timestamp. Anyone holding the file can check it without asking us.
Where is our data hosted?
On our managed infrastructure by default, with files and the database encrypted at rest. On the Sovereign plan you choose where it is hosted, including in your own region or on your own servers.