Security & the trust layer

The hard part of electronic signing isn’t drawing a squiggle on a PDF — it’s preserving checkable evidence of which document version was served, how inbox control was verified and what happened afterwards. That evidence is designed to support authenticity, attribution and enforceability; it does not guarantee human identity, signature genuineness or any legal result. This page describes exactly what DrakonSign does, in plain language.

The hash-chained audit trail

Every envelope carries an append-only event log: created, sent, verification started, verification code sent, inbox code verified, protected PDF accessed, signed, completed, downloaded. Each event records a UTC timestamp and the actor. Events caused by someone using a browser — starting verification, requesting protected PDF bytes, entering their code, signing — also record the IP address and user agent of that request. Events the platform raises for itself, such as completing an envelope once the last signature lands or expiring a link, have no network request behind them and so carry no IP or browser: recording one would be inventing it. Every event is linked to the previous one by a SHA-256 hash — each event’s hash is computed over its own content plus the hash of the event before it. Alter, remove or reorder any record and every hash after it stops matching. The chain’s head is anchored on the document record, so even truncating the tail is detectable.

Verification isn’t something you take on trust: the dashboard’s Verify integrity button (and the /audit/verify API) recompute the entire chain from scratch, live. They distinguish an internal chain break, an invalid stored external anchor, a valid external anchor, and an intact chain with no anchor recorded. Before completion no anchor is expected; after completion, a failed anchoring attempt is appended as an immutable fail-open degradation. A valid timestamp covers the completion prefix independently: damage in a later download/event suffix is still a chain failure, but does not falsely invalidate the earlier RFC 3161 statement.

Completion artifacts

The moment the final signature lands, DrakonSign renders the signed PDF, generates the certificate of completion as a separate PDF — its own file with its own fingerprint, not an appendix bound into the signed document — computes both files’ SHA-256 fingerprints, and seals those fingerprints into the completion event on the audit chain. Completion artifacts are published once and never rewritten in place, so a fingerprinted file cannot be silently swapped. If a downloaded copy is ever questioned, its hash either matches the sealed record or it doesn’t.

Cryptographic document seal (PAdES)

When signing completes and both the signing key and RFC 3161 timestamp authority are available, the signed PDF receives a self-issued PAdES B-T seal. Standard PDF readers can verify byte integrity, but show the self-issued certificate as an untrusted issuer unless its root is trusted separately. If the timestamp authority is unavailable, DrakonSign records PAdES B-B — but only when the signature itself validates. Three other outcomes are recorded exactly as measured rather than hidden: a timestamp is present but unverified; there is a signature that did not verify; or the seal state is unknown because the produced file could not be read back. If the signing key is absent, the completion artifact remains unsealed. Each degradation is recorded, and the completion certificate and the envelope’s recorded seal state are authoritative for what actually happened. PAdES B-LT and B-LTA long-term validation material is not shipped.

The level recorded is measured, not assumed. After sealing, DrakonSign re-opens the file it just produced and validates it offline: the signature’s integrity over the bytes it covers, that the signing certificate is the one this deployment is configured with, and then the embedded timestamp’s own signature, its chain to a configured authority root, and its imprint over that signature. Only a timestamp that passes all three is reported as B-T, and only then does anything claim the file existed by the attested time. A timestamp that is merely present is recorded as embedded but unverified, and a file that cannot be read back at all is recorded as unknown — never as the level the sealing attempt intended. A baseline level is a claim about a signature that verified, so a file whose signature does not validate is recorded as unverified too, even when no timestamp was expected: the absence of a timestamp says nothing about the signature. Where the seal did not validate, the certificate of completion says the seal proves nothing until an independent validation succeeds, rather than repeating an assurance the measurement does not support.

External chain anchoring

A matching hash chain makes later record mutation detectable, but does not by itself establish who operated the system. On completion, DrakonSign asks an independent RFC 3161 authority to timestamp the exact COMPLETED event hash. If the authority answers, its token is stored alongside the trail and validates the hash-chain prefix through that completion checkpoint. Downloads and other events appended later are recomputed as part of the internal chain, but are not covered by the earlier timestamp. This anchoring is fail-open: if no authority is configured or it does not answer, completion continues and the missing anchor is recorded as a degradation. “Verify integrity” recomputes the entire chain and, when present, reports both the validated completion prefix and the number of later events outside that timestamp. Its displayed anchor time comes only from a valid TSA token, never the database row’s operator-controlled creation time. Re-anchor is available only when the anchor is missing, including after content erasure: an existing invalid token is retained and refused, while missing trusted-root configuration is reported separately. A damaged completion prefix is refused before any authority call.

Completion is not the only outcome that gets one. A decline, a void and an expiry are each timestamped over their own terminal event — declines especially, because a disputed “this was refused on the 3rd” should not rest on our records alone. Each checkpoint states which event type it covers and how many events sit inside its prefix, and each is validated on its own: a checkpoint that does not validate covers nothing, and a token over one event never passes as a checkpoint over another. A completed envelope also carries an earlier signatures checkpoint, taken over the final signature event before the certificate of completion is generated — which is what lets that certificate quote a real authority, a real attested time and a real validation result instead of a promise. The certificate cannot contain the completion timestamp, because the completion event commits the certificate’s own fingerprint and the token does not exist until the certificate does; the certificate says so and names where the later token is published rather than implying coverage it does not have. A token is only ever accepted after it has been validated against the exact event hash it was asked for and the configured authority roots — a response that does not check out is refused and retried, never stored as evidence. Every checkpoint that a third-party outage prevented is recorded as a durable obligation and can be created later over the same unchanged prefix, at a later attested time, without any existing record being rewritten.

The evidence bundle

A certificate you can read is not the same as evidence you can check. Once an envelope’s completion checkpoint has been obtained, DrakonSign publishes a write-once evidence bundle: a file carrying a machine-readable manifest with every audit record the hash chain covers, every RFC 3161 token in raw form, the artifact fingerprints, the consent wording each signer accepted, and the step-by-step procedure to check all of it — together with the original PDF, the signed PDF and the completion certificate themselves, so the fingerprints it asks you to check are of files you are holding. The sender can download it; so can each signer who completed, through the receipt link in their completion email.

Three tiers, and we do not blur them. The hash chain and the timestamp tokens are checkable without trusting us — but only if you validate those tokens against timestamp authority roots you obtained from somewhere other than the bundle. Certificates travel inside it for convenience, and the bundle says in those words that they are not trust anchors: anyone able to rewrite the file could have replaced them and re-issued the tokens together. Check them against our published trust-anchor fingerprints, or against public PKI policy for the named authority. Second, the manifest carries a signature by our own sealing key over every field in it, so alteration by anyone else is detected — including the fields no hash chain covers. That authenticates the issuer; it is not evidence against the issuer, and we do not present it as such. Third, everything else — the title, the recipient list, the seal state — is our statement, and the verifier labels it that way rather than leaving you to guess.

What it does not claim is to cover itself. No container can, and it says so. Publication is write-once but additive: if a timestamp we owed arrives after a bundle has been issued, we never rewrite the copy you already hold — a new edition is published naming the previous one’s fingerprint. Every edition stays retrievable, so a copy you were given remains obtainable after a newer one exists. That link between editions is issuer-authenticated only: our publication signature covers it, so nobody else can alter it, and no timestamp authority attests it. It cannot be otherwise — an edition cannot contain the record of its own publication, any more than the certificate can contain its own hash. We do record each publication on the envelope’s audit trail; that is our operational record, readable from the live trail, and the bundle says plainly that it is not something the file itself establishes. Bundles are destroyed with the rest of an envelope’s content when erasure is requested.

Certificate trust, stated plainly

The seal currently uses Drakon’s own, self-issued document-sealing certificate. That is what gives you the integrity guarantee above — any verifier can still check that the bytes have not changed — but it is not a certificate any reader trusts out of the box. Adobe Acrobat and similar readers will show the signature as “valid, but from an issuer that is not trusted” unless the reader has been given the Drakon root.

Getting into Adobe’s Approved Trust List, or issuing qualified signatures (QES) through a Qualified Trust Service Provider, is not a setting we can switch on. Both normally require the private key to live in an HSM or the certificate authority’s own cloud-signing service, which changes how sealing works inside the product, not just which secret it reads. We would rather say that than imply a swap is imminent. If your use case needs a reader to show a green tick without any local trust configuration, tell us before you buy.

Signer verification

Signers receive a personal, expiring link. Before the protected PDF can be served, they must confirm control of their email inbox with a 6-digit one-time code (10-minute expiry, strict attempt and re-send limits, HMAC-protected at rest). Only then does a short-lived signing session open — carried in a header, never in a URL. Consent is captured explicitly, with the exact consent text versioned into the record.

Legal design

DrakonSign is designed around the UK eIDAS regulation and the Electronic Communications Act 2000, under which electronic signatures are admissible in evidence. The audit chain, signer verification and fingerprinted completion artifacts exist to produce an evidential record designed to support enforceability — which signer record acted, which document version was served, how inbox control was verified, and whether the record changed afterwards. It does not prove human identity, signature genuineness or a person’s physical location.

What that is not: a guarantee that any particular document is enforceable. That depends on the document’s own formalities — some instruments require a witness, a deed, or a wet signature — and on the law that governs it. Nothing on this page is legal advice, and we do not promise a court will accept any given signature. The system is designed to preserve independently checkable evidence; operational availability and recovery are described without guarantees on this page and on the status page.

DrakonSign produces a simple electronic signature. It is not an advanced electronic signature (AES) and not a qualified electronic signature (QES), and the sealing certificate is self-issued rather than one of the reader-trusted authorities in Adobe’s AATL. Deeds, HM Land Registry transfers, wills and lasting powers of attorney are excluded outright, and regulated or high-value documents need independent advice first — which documents suit DrakonSign sets out the whole list in plain English. Meeting your document’s formalities remains yours to do.

Witness and Approver are routing labels, not legal roles. A recipient marked Witness or Approver is routed and described that way on the certificate of completion, and goes through exactly the same ceremony as a Signer: the same inbox one-time code, the same consent wording, the same fields. There is no statutory witnessing, no record that a witness was physically present when somebody else signed, and no role-specific consent text. CC is the only role that behaves differently — CC recipients do not sign and are not emailed.

Infrastructure

Where it runs: the application and the database run in London (UK), on Fly.io’s lhr region. The document store — your uploads, the completed signed PDFs and the certificates of completion — is a separate Tigris bucket configured as single-region London (UK), and it is the authoritative copy of that content. Two providers, both holding live data in London; the backups below are the deliberate exception.
Backups, stated accurately: encrypted full backups of the database and the document store are taken nightly and held in a separate, globally distributed Tigris bucket for 30 days — a different bucket, and a different credential, from the live document store above. That bucket is not geographically pinned, so we will not tell you your data never leaves the UK or the EU: the live service is in London, the backups are not. Erasing a document removes its database record immediately; file removal is verified and any cleanup-pending residue is retried. It is excluded from every future backup; the copies already written age out with ordinary 30-day rotation.
Encryption: TLS in transit; encryption at rest for the live document bucket, for the database, and for the backup bucket.
Timestamping: RFC 3161 tokens come from DigiCert’s public timestamp authority — an authority independent of us, which is the entire point of anchoring there rather than signing our own clock.
Hardened responses: every page is served with X-Frame-Options: DENY, frame-ancestors 'none', nosniff and a no-referrer policy — signing pages cannot be framed for clickjacking, and signing links never leak via referrer headers.
No trackers: no analytics, advertising or tracking cookies, and no third-party scripts or fonts, on any page — including our own API documentation, which serves its assets from this origin rather than a CDN. Signing pages set no cookies at all; the dashboard sets two strictly-necessary cookies on the sign-in journey — the session cookie ds_session, and ds_mfa, a ten-minute ticket set only if you use two-step sign-in. Signing a document makes requests to us and no one else.
Account sign-in: the dashboard signs in by emailed one-time link, with optional two-step sign-in using an authenticator app (TOTP, RFC 6238) and one-time recovery codes. It is off by default and you turn it on yourself; we do not support passkeys/WebAuthn or SMS codes, and there is no organisation-wide “require it” policy. Every dashboard session is a listed device you can end individually. Sessions end after 14 days, or after 7 days without use, whichever comes first. We email you on every new sign-in, every change to your sign-in settings, and a sign-in link that was used but abandoned without the second step — meaning its ten-minute ticket ran out or its attempts did. If you start a fresh sign-in before finishing the first, that supersedes the abandoned one and stays deliberately silent, so asking for a second link never mails you a warning about your own first one. If you lose both your authenticator and your recovery codes, recovery is a manual support process with out-of-band checks by a human — an emailed link would mean the second step never raised the bar. Two-step sign-in is for the sending account and is a separate thing from the signer’s own inbox verification during a ceremony.
Credentials: API keys and database credential columns store only hashes. A pending durable invitation, reminder or completion-email provider request necessarily retains its raw working link until terminal redaction or envelope erasure; provider-crossed uncertainty can retain it longer and blocks erasure pending controlled support reconciliation. One-time codes are HMAC-keyed for verification, while a pending provider request temporarily retains the plaintext code it must submit before the same redaction rules apply. Their usable expiry stays anchored to the first provider attempt, so a delayed response cannot resurrect an old challenge or supersede a newer accepted code. Recovery never submits an expired or too-close retry; it redacts the unusable request so the signer can request a fresh code.

Roadmap, honestly

Shipped and described above: the hash chain and fingerprinted completion artifacts; a self-issued PAdES B-T document seal when the signing key and timestamp authority are available; recorded PAdES B-B degradation when the authority is unavailable and the signature validates; the measured unverified and unknown states when it does not; and a recorded unsealed outcome when signing material is absent. Independent chain anchoring is likewise conditional on the RFC 3161 authority answering. Not shipped, and each a real piece of engineering rather than a configuration change: a sealing certificate trusted by readers out of the box (Adobe AATL), PAdES long-term validation (B-LT / B-LTA) so signatures stay verifiable after certificates expire, qualified signatures (QES) through a Qualified Trust Service Provider, stronger signer identity (SMS or document verification) and per-organisation branding. Every claim on this page describes the shipped product; everything in this paragraph’s second half does not exist yet.

Questions, or want to report a vulnerability? Email support@drakonsystems.com — security reports are read first.