Security at SealProof

Last updated September 24, 2026

SealProof is built so that we can't read your documents, and so that anyone can check a signed document without trusting us. This page explains how, what we don't do yet, and how to reach us about security.

Want the details? The math behind SealProof shows every construction, the numbers, and how to check each claim yourself.

Your documents are end-to-end encrypted

• Documents, titles, field contents and signatures are encrypted in your browser (AES-256-GCM, Web Crypto) before they're uploaded. Our servers store only ciphertext.
• Each envelope has its own random key. It's locked to your account key (X25519 sealed boxes, libsodium). Your account key is protected by your passphrase (Argon2id) and a recovery key that only you hold.
• Signers get the key in the part of their link after “#”, which browsers never send to servers. Because we email and text links for you, the key passes through our server's memory when links are built (at sending, when it's the next signer's turn, at completion and on reassigning), and the full link passes through our email or SMS provider. The key is never stored or logged. With an access code, the key isn't in that signer's link at all, though it still passes through our server's memory. Senders can also require a one-time code by email, or a photo ID check.
• Sharing with teammates and saving to a signer's portal work the same way: the key is locked to their account key in the browser.

Every signature is sealed, timestamped and anchored

• When everyone has signed, the final PDF, including its Certificate of Completion, is hashed and sealed with our signing key, which lives in AWS KMS and can't be exported.
• Each seal gets an RFC 3161 timestamp from an independent timestamp authority.
• Seals are published in the SealProof Anchor, a public append-only Merkle log (RFC 9162 style) that's periodically committed to Bitcoin through OpenTimestamps.
• Anyone can verify a document without an account at sealproof.io/verify, which uses keys and anchor roots we publish, or offline with the open verification tools, without trusting us.

The audit trail can't be quietly edited

Every event on an envelope (sent, viewed, signed, reassigned, shared) is appended to a hash-chained audit trail. The database refuses updates and deletes to it, and changing any past event would break the chain, which the app and the Certificate of Completion check.

Accounts and infrastructure

• Sign-in by one-time email link or single sign-on (SAML). Each account is limited to a small number of signed-in devices, which you can see and sign out.
• Data is stored in Postgres with row-level security, behind an authenticated gateway. Traffic is encrypted in transit (TLS).
• Emails we send carry a verification code, so recipients can check a SealProof email is genuine.

What we don't have yet

We're a young company and we'd rather be plain about it. SealProof doesn't yet hold SOC 2 or ISO 27001 certification and hasn't had a third-party penetration test. We run automated scanning (OWASP ZAP) and follow the practices above. A completed security questionnaire (CSA CAIQ-Lite) is available on request.

Report a vulnerability

Please email security@sealproof.io with the details and steps to reproduce. We'll acknowledge it within 3 business days and keep you updated. We won't take legal action against good-faith research that avoids privacy violations, data destruction and service disruption, and that gives us a reasonable time to fix the issue before disclosure. Our security.txt has the same details.