How a signature is produced
If a signature is ever challenged, the burden falls on the party asserting it. This page describes what MedSign records at each step, so that record can be described concretely rather than in generalities.
Integrity and attribution are different things
A cryptographic seal proves a document has not changed since it was sealed. That is integrity, and it is largely uncontested in practice — very few disputes turn on whether a PDF was altered.
What gets litigated is attribution: whether the signature was the act of that specific person. A seal says nothing about who clicked. MedSign is designed so attribution rests on evidence that is actually recorded — how the link was delivered, what the signer had to prove, what they saw, what they agreed to, and precisely when.
We never state or imply that the cryptographic seal proves who signed. Anyone who tells you otherwise is describing the wrong control.
What gets recorded, step by step
- 1
Envelope creation
- An immutable copy of the source PDF is taken, with its SHA-256 hash.
- Field positions and page geometry are snapshotted onto the envelope. Editing the template afterwards cannot change a document someone is mid-way through signing.
- Recipients and their email addresses — and, for elevated assurance, phone numbers — are supplied by the sender.
- 2
Delivery
- A 32-byte token from a cryptographic random source is generated and base64url-encoded into the signing URL.
- Only a SHA-256 hash of that token is stored. The token itself exists solely in the emailed link.
- The token is time-limited, scoped to one recipient’s view of one envelope, and invalidated when the link is resent.
- 3
Identity assurance
- Email tier: possession of the mailbox the link was sent to. This establishes control of a mailbox — not identity independently.
- SMS one-time passcode tier: a six-digit code, valid ten minutes, limited attempts, sent to a number the sender supplied at envelope creation. Recipients cannot supply their own number; one who could would have defeated the control.
- The code is never stored in plaintext and never logged. Only the last four digits of the number are retained on the signing record.
- 4
Consent to electronic records
- The disclosure is shown before any field is fillable.
- The checkbox is never pre-checked, and consent is never inferred from continuing.
- The timestamp and the exact disclosure version are stored on the recipient record; every version is retained indefinitely and reproducible.
- Declining, and requesting a paper copy, are both offered.
- 5
Signing
- Each field completion is recorded as its own event.
- Finalizing records the timestamp, IP address, and user agent.
- The drawn or typed signature is an appearance — a visual artifact. The legal signature is the affirmative act, evidenced by the audit record.
- 6
Assembly and sealing
- Values are merged at their stored coordinates and any existing form fields are flattened, so nothing remains editable.
- A certificate of completion is appended, carrying the full event history, each recipient’s consent and assurance record, and the pre-seal hash.
- The whole document is then sealed. No byte is written afterwards — anything written after sealing would invalidate the signature.
- The envelope reaches "completed" only after a successful seal. There is no path that finishes an envelope with an unsealed document.
Controls behind the product
Tenant isolation
Every table carries an organization ID and every query is scoped by it. The database enforces the same separation independently through row-level security, and the application connects as an unprivileged role that cannot bypass those policies.
Append-only audit trail
Updates and deletes on the event log are rejected by database trigger and by revoked grants. Each entry hashes together with the one before it, so a removed, inserted, or altered row breaks the chain at that point and everywhere after.
Key custody
The document-signing key lives in a key management service. The application asks for a signature; it never reads the key. A separate, isolated service performs the sealing and holds no tenant data.
Document handling
Documents are stored under tenant-scoped keys and served only through short-lived signed URLs issued after an authorization check. Storage keys are never exposed to the browser. Credentialing packets carry sensitive personal data, and are treated as sensitive at rest.
Stated plainly, because overstating it is worse than the limitation
- MedSign establishes control of an email account, and — where SMS verification was applied — control of a specific phone number supplied by the sender. It does not perform government-ID identity proofing.
- MedSign does not provide notarization.
- MedSign does not produce a qualified electronic signature under eIDAS.
- MedSign has not been validated for 21 CFR Part 11.
- MedSign is not a patient-facing product. It does not handle protected health information as part of a patient care workflow and does not integrate with an EHR.
What we do claim: signatures collected through MedSign are intended to be legally binding under the federal ESIGN Act and state adoptions of UETA, supported by a tamper-evident audit trail and a cryptographic seal. Nothing on this page is legal advice.
Going through a security review?
We maintain a written process declaration describing exactly how a signature is produced and how tampering is detected. Ask for it and we will send it over.