Security

In one paragraph

Every document signed through Sealpost comes back as a PDF with a digital seal, a record of events, and a chain of hashes that lets anyone check that the document and its record have not changed since the last signature. The seal’s private key lives in a hardware security module at AWS and never leaves it. Documents are stored under a retention lock that the service cannot shorten. Each customer’s data is encrypted with its own key and separated at the database level. We log what happened, never what a document says.

The seal

When the last person signs, the finished PDF is sealed with a PAdES digital signature (PAdES is the PDF profile of the EU’s advanced-signature standard; Acrobat and every major PDF reader understand it).

• Where the key is. The signing key is an asymmetric key in AWS Key Management Service. Only the document’s hash is sent to KMS; the key cannot be exported, copied or read by anyone, including us. Every use is written to an audit trail we keep.
• Whose certificate. At launch the seal certificate is issued by Sealpost’s own certificate authority, with a published revocation list. That proves the seal came from Sealpost; a reader that has not been told to trust our authority shows the seal as “valid, unknown issuer”. A certificate from a publicly trusted document-signing authority, which readers accept without configuration, follows later.
• When. Each seal carries a timestamp from a public RFC 3161 timestamp authority, so the time of sealing is attested by a third party, not by our clock.
• Long-term validation. The seal embeds the certificate chain, revocation data and timestamps it needs to be verified years later even if our authority or the timestamp service is gone (PAdES B-LTA).

What the seal proves: that this exact PDF left Sealpost at this time and has not been changed since. What it does not prove: who the signers were. That is the job of the record of events.

The record of events and the hash chain

Every action in a document’s life is an event: sent, link opened, disclosure accepted, field signed, finished, declined, sealed, and so on (25 types). Each event stores the time (set by our server, not the caller), the signer’s IP address and approximate location, the browser, and what happened.

Events are hash-chained. Each event’s record includes the SHA-256 hash of the previous event, so an event cannot be inserted, removed or edited without breaking every hash after it. The database refuses updates and deletes on the event table, and a job re-verifies every chain nightly. The chain’s root is the SHA-256 of the original PDF; the final event records the hash of the sealed PDF.

You get the record two ways: as a certificate page appended to the PDF, and as JSON from GET /v1/envelopes/{id}/audit, which returns the events and the result of verifying the chain, so your own system can check it.

Storage

• Retention lock. Finished documents are written to Amazon S3 with Object Lock in governance mode for the retention period the account set (7 years by default, 1 to 10). While the lock holds, the service cannot delete or overwrite the object. Governance mode lets a separately permissioned AWS administrator lift a lock outside the service; we would do that only if the law required it.
• Versioning. Every stored object is versioned. Replication of sealed documents to a second AWS region is planned and not yet in place.
• A key per customer. Every document is encrypted with its own data key. Those data keys are protected by a key that belongs to one account alone. The account keys are kept in a shared key store and protected in turn by one AWS KMS key that all accounts in the service share. Each encrypted document is bound to its account and to itself, so one account’s key cannot open another account’s documents, and a document cannot be passed off as another. When an account closes, the customer can still export its documents for the 30 days the terms give; after that, the customer’s access ends. Sealed documents stay stored under their retention lock for the period that was set, and until the account’s key is destroyed they can still be decrypted, which is what lets us honour a legal hold or a court order. Once nothing of the account is under a retention lock or a legal hold, its key is destroyed. Our key backups expire within 35 days after that; from then on, no copy still held in our storage can be read. Copies you or your signers already downloaded are yours and are not affected.
• Uploads. Documents can also go straight to a private staging area over a short-lived pre-signed URL. The service then checks the exact bytes, stores them encrypted, and removes the staged copy.

Tenancy

Every row in the database carries the account it belongs to, and PostgreSQL row-level security policies enforce that boundary inside the database, not only in application code. A request running as account A cannot read account B’s rows even if the application has a bug. A test suite that tries exactly that, with one account’s key against another account’s resources, across the API, the signing page and the dashboard, runs on every change before it merges.

Access to the service

• API keys are prefixed sk_live_ or sk_test_, scoped, and shown in full only once. Rotation keeps the old key alive for 24 hours.
• Signing links are single-use tokens that expire after 30 days or when the document is finished or withdrawn.
• Optional signer authentication: PIN, SMS code or email code, with attempt limits and lockout; the method used is printed on the certificate.
• Dashboard logins use a password and a time-based one-time code, with remembered devices.
• Webhooks are signed with an HMAC header; two secrets can be active during rotation.
• The signing page runs on its own hostname with a strict content security policy and no dashboard cookie.

What we log, and never log

Logged: request id, account id, method, path, status code, timing, the caller’s IP, and the event records described above. API requests are kept in a 90-day request log you can read in the dashboard.

Never logged: document content, field values, signer names or emails in application logs, signing-link tokens, API keys, or request and response bodies. The API request log keeps metadata only: method, path, status, timing and request id. Error reports have personal data scrubbed before they leave the service. Signing emails carry the document’s title, never its content; a HIPAA-mode account can mask the title too.

Infrastructure

The service runs in its own AWS account owned by DigiMar, separate from any other DigiMar system: containers on ECS Fargate, PostgreSQL on RDS with Multi-AZ failover and point-in-time recovery, CloudFront with a web application firewall in front, secrets in AWS Secrets Manager, CloudTrail on with log validation. Backups: continuous database recovery plus a nightly dump to a second account, with a restore drill. Encryption in transit is TLS 1.2 or higher everywhere, including between internal services.

Testing and review

• Penetration test: scheduled. A third-party test of the signing page and the API, or a structured self-review, is the SG-11 gate before the first live document. Results, with fixes applied, are summarised on this page when done.
• Legal review. Our terms, privacy notice and e-signature disclosure were written and reviewed in-house against the ESIGN Act, UETA, the US state privacy laws and HIPAA, not by outside counsel. We say so because it is true.
• Code review. Every change is reviewed by two independent reviewers before merge, and the test suite, including the cross-account test, runs on every change.
• Dependencies are pinned and scanned on every change; secrets are scanned on every push.
• No certifications yet. We do not hold SOC 2 or ISO 27001. We will say so here until we do. Our controls are described on this page so you can judge them directly.

HIPAA

Sealpost is built to the HIPAA Security Rule standard for every account: encryption at rest and in transit, access logging, no PHI in logs, single-use expiring links, defined deletion procedures. For accounts that handle protected health information we sign a business associate agreement and switch the account to HIPAA mode, which adds field-level encryption, masked email subjects and a 7-year minimum retention. Our AWS account is covered by AWS’s business associate addendum. Ask at security@sealpost.app for the agreement.

Subprocessors

The privacy notice section 6 has the same list with locations and the notice we give before adding one.

Reporting a vulnerability

Email security@sealpost.app. Include what you found, how to reproduce it, and which account or test key you used. We reply within two business days, say when a fix will ship, and credit you here if you want. We do not pay a bounty at this stage.

If you are testing in good faith, keep it to test-mode keys and accounts you created, do not read or change anyone else’s data, do not run denial-of-service or social-engineering tests, do not keep or publish any data you reach, and stop and tell us the moment you reach another account’s data. Research that follows these rules is authorised access as far as we are concerned, including under the Computer Fraud and Abuse Act and Florida’s computer-crimes law, and we will not take legal action over it. This does not cover testing against our providers’ systems, which have their own rules.

Incidents and status

Incidents are posted on the status page, with a post-mortem for anything that affected customers. Until the status page exists, this line stands in: no incidents to report; status page coming. If we learn of a breach involving your data we email affected customers within 72 hours of confirming it, and affected individuals within 30 days of determining it (Florida’s statutory period), or sooner where another law sets a shorter one.

Last reviewed: Oct 21, 2026. Questions: security@sealpost.app.