Security & data handling
How NoSign protects data, ensures provability, and erases everything afterwards.
NoSign’s security model is built around one prime directive: if everything else fails, the signature must still be legally sound and provable.
Hard delete gated on delivery
NoSign will not delete any signing request data until your platform returns 2xx from the webhook. This is a hard gate, not a best-effort behavior:
- Delivery failures trigger exponential-backoff retries.
- Exhausted retries move the delivery to a dead-letter path, visible in the admin dashboard for manual retry.
- The signing request remains intact — with full document and personal data — until delivery succeeds and your platform confirms receipt.
This ensures you always have the opportunity to receive the sealed PDF and audit bundle before any data is erased.
Retention scheduler
A daily scheduler runs as a safety net. It finds signing requests in completed state that have exceeded their configured retention window and have not yet been explicitly deleted by your platform. The scheduler triggers the same single delete code path as an explicit DELETE API call.
This prevents data from accumulating indefinitely if your platform fails to call DELETE, without introducing a second delete mechanism.
Audit tombstone
After hard deletion, a PII-scrubbed audit tombstone is retained. The tombstone records:
- That a signing request with the given ID existed.
- Its completion timestamp.
- Its deletion timestamp.
The tombstone contains no personal data (no names, emails, IPs), no document content, and no audit event details. It exists solely to prove that the request was handled and deleted — not to reconstruct what was signed.
Byte-faithful HMAC webhook
The sealed PDF delivered in the webhook is the exact byte sequence that was sealed and timestamped. NoSign signs the raw request body with HMAC-SHA256, sending the signature in the X-NoSign-Signature header.
This means:
- The bytes you verify with HMAC are exactly the bytes NoSign sealed.
- If HMAC verification passes, you have a cryptographic guarantee the payload was not modified in transit.
- The document hash embedded in the PDF seal matches the document hash in the audit bundle.
This chain of hashes — from the original document through each stamping step to the final seal — is what makes the signature legally provable end to end.
Signer identity verification
Signer identity is established through email verification (OTP and magic link) before any document access. A signer who does not verify their email address cannot view the PDF or complete the ceremony.
IP addresses are recorded in the audit trail as HMAC hashes — not in plaintext — providing attribution without storing raw PII beyond what is necessary.
Admin boundary isolation
The admin dashboard runs behind a separate authentication boundary with 2FA required and no public registration. Admin sessions cannot be initiated from a signer link, and signer sessions cannot access admin functionality.
Local-only storage
All documents and personal data are stored in local private storage on the server running NoSign. There is no S3, no CDN, no cloud object store. Data does not leave your infrastructure except via the signed webhook to your callback_url.