Security and trust

Our security starts from one idea: the document proves itself. A signed PDF carries its own evidence, so its truth does not depend on our servers, our database or our staff.

If someone broke into our systems

No online service is immune to a breach. Here is what an attacker could and could not do, by design.

An attacker who controls...	Could	Could not
Our servers: the API, the database and the document storage	Read standard envelopes and the personal data in them. Delete or replace our stored copies. Stop or misroute envelopes. Send email in our name.	Forge a signature on any document already signed (the signing keys were thrown away). Change a signed document without the verifier noticing. Change the copies that signers already received.
Our servers and the key that vouches for email-code sign-ins	Create new documents signed in the name of any email address that confirms with a one-time email code, for as long as the key is valid.	Sign as someone who confirms with Google, Microsoft, Apple or their organization's own sign-in: those keys are not ours. Date a forgery before the key's period of use, once trusted timestamps are in place. Escape the public log of every email-code sign-in, once that log is in place.
The code our servers send to signers' browsers	Show future signers one document and have them sign another, or read the documents they open, while the attack lasts.	Change documents signed before it. Sign without the signer confirming who they are with Google, Microsoft, Apple or their email. Produce a document that breaks the verifier's rules.
A signer's Google, Microsoft or Apple account	Sign as that person, like any service that relies on that account.	Sign as anyone else.
Our release pipeline, which builds and publishes the apps and the verifier	Publish apps or verifier builds with harmful code.	Go unnoticed by anyone who rebuilds them from the public source code and compares. This detects such an attack; it does not prevent it.
A partner: an identity-check provider, a qualified trust service or a notary	Affect the evidence that partner adds to a document.	Affect signatures that did not use that partner.

That is why every party receives the signed PDF by email when signing is complete: the evidence exists outside our storage from the first day.

The code that runs when you sign

When you sign in a browser, you trust the code the service sends to it. That is true of every hosted signing service. We keep that code small and our own, and we are making changes to it detectable.

No third-party code. No analytics, chat widgets, tag managers, fonts or libraries from other sites on the signing pages, the web app or this site.
A strict Content Security Policy on every page we serve: the browser runs only our own files.
Signatures made in the signer's browser, with a key used once and discarded; the server only receives the signer's addition.
Every upload checked again by our server with the same engine, before it is accepted.
Integrity hashes on the verifier's code files, so a changed file is refused.
A separate web address for signing, serving only fixed, versioned files, with no account sessions. Coming
Signed release lists of every file the signing page serves, published so anyone can compare, and an outside monitor that checks them every few minutes. Coming
Reproducible builds of the signing engine, so anyone can rebuild it and get the same bytes. Coming

Your data

Your documents are yours. We do not sell them or use them to train AI models.
Region. Data is stored in the United States at launch. An EU region follows, and you choose the region when you sign up. Support can tell you more about where your data is hosted.
Encryption. In transit with TLS; at rest with Azure's encryption, plus a key per organization for documents, so deleting an organization's key makes its documents unreadable everywhere, backups included.
Isolation between customers in the database itself (row-level security), not only in our code.
No standing access for our staff. Access to production is granted for a task, logged, and expires. Support, human or AI, sees account details and diagnostics, never document contents.
Private envelopes encrypted in the sender's browser, which we cannot read. Coming

Identity

A signer is named by the email address that Google, Microsoft or Apple has verified, never by a name they typed. The proof of identity is tied to one signature and one document, so it cannot be reused elsewhere. The verifier accepts only the providers' own published keys, and only for sign-ins made for Sovrasign.

Google, Microsoft and Apple are trusted third parties here: if a signer's account is taken over, the attacker can sign as them. Signing by just clicking a link is never offered: a one-time email code is the minimum, and the document records which method each signer used.

Testing

Automated tests that attack the format: forged identities, changed pages, added layers, rewritten history and hostile files, run on every change to the engine.
Cross-checks of our signatures with an independent PDF signature validator (pyHanko).
A penetration test before the public launch. Coming
A way to report vulnerabilities from the private beta, and a bug bounty later. Coming
SOC 2 Type I, then Type II, as the service grows. Coming

Other limits

Long-term validation. Signatures do not yet carry the extra material that keeps them checkable by third-party PDF readers for decades after certificates expire. Our own verifier keeps the providers' old keys. Coming
Time. Until trusted timestamps arrive, a signature carries the signer's device time, which the verifier checks is not earlier than the sign-in. Coming
Other PDF readers. Adobe Reader and others apply their own rules and may show our signatures differently. Sovrasign Verify applies stricter rules.

Report a vulnerability

Write to security@sovrasign.com. A published disclosure policy, with safe-harbor terms, comes with the private beta. Coming

Acknowledgments

We thank the people who report vulnerabilities to us under our responsible disclosure policy. With their permission, we name them here once the problem is fixed. No one is listed yet.