Plain-English security page

Security & evidence

What we already do — and what we’re transparent about not doing yet. We’d rather earn your trust honestly than hide behind compliance theatre.

At a glance

Four things every signed document gets, automatically

TLS 1.2+ everywhere

Every byte travels over TLS 1.2 or 1.3 with a modern cipher policy and HSTS preload. The public certificate is issued and auto-renewed by Let’s Encrypt.

Bcrypt-hashed passwords

Passwords are hashed with bcryptwith unique per-user salts. Even our own engineers can’t read your password — only verify a fresh attempt against the hash.

Append-only audit trail

Every meaningful action is logged with actor, timestamp and IP: DOCUMENT_VIEWED DOCUMENT_SIGNED COMPLETED.

Tamper-aware PDF output

Every signed PDF carries a cryptographic SHA-256 hash of the original file plus a public verify URL on the last page — anyone holding the PDF can independently confirm it matches what was signed.

Evidence chain

What we capture for every signature

If a contract is ever disputed, this is the dossier you’d hand to your lawyer. None of it is bolted on as an “enterprise add-on” — it’s the default ceremony for every signer.

  • Verified email delivery

    Each signer receives a unique link tied to their email address; the link itself is the proof of receipt.

  • IP address

    Captured at every state transition (viewed, signed, declined) so location-of-action can be cross-checked.

  • User-agent string

    Browser and device string captured alongside each event in the audit log.

  • Latitude / Longitude (6 decimals)

    Browser geolocation with reported accuracy (in metres). Always with explicit user consent.

  • Geocoded address

    Best-effort reverse geocoding of the lat/long into a human-readable address, stamped on the PDF.

  • Identity selfie

    Live camera capture during the ceremony, with an optional negative-rendered version stamped on the signed PDF next to the signature.

  • Optional government ID + AI face-match

    When ANTHROPIC_API_KEY is configured, signers can upload a government-issued photo ID and we run an AI face match between the ID photo and the live selfie.

  • Server timestamp

    Authoritative UTC timestamp from our server is recorded for every state transition — never trusted from the client.

  • SHA-256 hash of the original document

    Computed at upload and stored alongside the document; the hash never changes after signing, so any byte-level tampering is detectable.

  • Status-transition audit log

    Every transition is appended: PENDING VIEWED SIGNED COMPLETED.

  • QR code on every page of the final PDF

    A QR code with the public verification URL is printed on every page — anyone holding the printed PDF can scan it and see the live record.

  • Per-request reference code

    Each signing request gets an 8-character shortId (e.g. K3X7P2QM) printed in every email subject so signers can quote it on the phone or in support tickets.

Account security

How owners log in

Senders pick the auth path that suits their security policy. Recipients sign via a unique email link and don’t need an account at all.

Password + bcrypt

Per-user salt, slow hashing — the only way back is a fresh attempt.

Google OAuth

Sign in with Google via NextAuth — no password to leak in the first place.

Two-factor (TOTP)

Optional time-based one-time password (Google Authenticator, 1Password, Authy) on top of password login.

Email verification on sign-up

Every new account confirms the email address before it can send envelopes.

Reference codes in email subject

Every signing email includes the 8-character shortId in [BRACKETS] so signers can quote it without forwarding the link.

Session signed cookies

NextAuth-issued, httpOnly, Secure, SameSite cookies — signed with NEXTAUTH_SECRET, not stored anywhere readable.

Honest gaps · roadmap

What we’re not doing yet

A trust differentiator for us is telling you what we don’t do, in plain language, before a procurement questionnaire forces it out. Each item below is on the public roadmap — none of it is hidden behind “contact sales”.

  • PAdES cryptographic PDF seal Roadmap

    Today the signed PDF stamps a signature image plus our SHA-256 hash and verify URL. PAdES (PDF Advanced Electronic Signatures) adds a real certificate-based seal embedded inside the PDF object structure. On the roadmap.

  • Long-Term Validation (LTV) Roadmap

    LTV embeds the validation chain (CRL/OCSP responses) inside the PDF so a signature can be verified decades later even if the issuing CA goes away. On the roadmap, after PAdES.

  • True end-to-end encryption Roadmap

    Today: encryption in transit (TLS 1.2+) and at rest. We can technically read your documents to render and stamp them. End-to-end encryption — where only the signer holds the keys — is on the Privacy Plus roadmap.

  • SOC 2 Type II / ISO 27001 Roadmap

    We follow the underlying control practices but have not (yet) gone through a SOC 2 Type II audit or ISO 27001 certification. Both are on the roadmap. Until then, we won't claim them.

  • Aadhaar eSign / DSC tokens / national ID schemes Roadmap

    Government-grade identity proofing via Aadhaar eSign (India), DSC USB tokens, Singpass (Singapore), Smart-ID / Mobiil-ID (Estonia) is on the roadmap — they're worth doing properly or not at all.

Reporting a vulnerability

Found something? Tell us first.

Email support@esignature.llc with reproduction steps. We aim to acknowledge within 72 hours. Please don’t disclose the issue publicly until we’ve had a chance to patch it — we’ll credit you in the release notes once it’s fixed, if you’d like.