Trust & evidence
Electronic Signature Process & Evidence
How Hereby captures an electronic signature, certifies it, and lets anyone check it afterward — written so a reviewer can compare the process against the resulting certificate, line by line.
Every statement below is meant to correspond to something you can see on an actual signed certificate. Section numbers (§) are cross-referenced throughout; a sample certificate appears at the end.
§1What Hereby is
Hereby is an electronic-signature and evidence service designed to support transactions governed by the U.S. ESIGN Act and applicable state electronic-transactions laws. Every completed signing produces a Certificate of Electronic Signature that records the signer information submitted, the phone-possession verification performed, the version of the terms presented for acceptance and the result of the client-to-server hash comparison, and a tamper-evident fingerprint of the final document.
The service rests on three deliberate principles, each reflected on the certificate:
- Verified signing. The signer confirms control of a mobile number through a one-time passcode delivered by SMS, and the verified (masked) number is recorded on the certificate. Each record describes precisely what was verified — a proportionate, widely-used method for commercial agreements (§3).
- Independent certification. Hereby attests, through its own certification process, that the phone-possession challenge, disclosure integrity, and cryptographic sealing were carried out. This is Hereby’s own mark of process — a certification, separate and distinct from a notarial act.
- Data minimization. The completed, certified document — including its certificate page — is delivered to the organization that sent it, which retains it. Hereby does not retain the completed PDF or the field values entered by the signer during the signing session. It may retain limited transaction metadata and values supplied by the sending organization, as described in §7.
§2Legal basis
ESIGN and applicable state electronic-transactions laws generally provide that a signature or record may not be denied legal effect solely because it is electronic. Enforceability still depends on applicable law, consent, intent, attribution, record availability, and transaction-specific requirements. The certificate records evidence relevant to several of these considerations:
| Consideration | Evidence on the certificate |
|---|---|
| Intent to sign | The applied signature (drawn or typed) plus the affirmed acceptance statement |
| Consent to transact electronically | “Electronic signature consent — Agreed (ESIGN / UETA)” |
| Association with the record | Signature and record hash bound in the same certified PDF |
| Retention / reproducibility | The completed PDF contains the agreement text and certificate page in a retainable, reproducible form; SHA-256 hashes help detect later changes |
§3Signer verification (SMS one-time passcode)
The signer confirms possession of a specific mobile number by receiving and entering a one-time passcode. The certificate records the verified number in masked form (e.g., +1 (•••) •••-5554) and states the method and its limits verbatim:
“Possession of mobile number … confirmed by one-time passcode at signing. No government-issued ID was collected or verified.”
This states what was and was not established. Possession of a phone number is not, on its own, proof of legal identity, and the certificate does not represent it as government-ID proofing.
§4Disclosure integrity — evidence of what the signer was shown
This is the point most often weak in electronic signing, and the one most likely to be tested in a dispute: which words was the signer shown?
- Each version of the agreement text has a stable version identifier and a canonical SHA-256 hash of its exact text.
- When the signer’s browser displays the terms, it independently hashes the text it rendered and sends that hash with the submission.
- The server compares the browser-reported hash to the canonical hash on file. A match reads “Verified: the text rendered in the signer’s browser hashed identically to the canonical disclosure on file.” Any missing client hash, version mismatch, or different hash says exactly that, and does not say “Verified.”
- The certificate prints the version identifier and matching text hash together, and reproduces the full agreement text on the record.
A “Verified” result confirms that the client-reported hash matched the canonical hash on file. It does not, by itself, prove that a human read or understood the terms.
§5Assent capture — recorded as observed, never fabricated
The interface records the interaction as it happens and reports only what was observed: when the terms were opened; that they were displayed to the end — distinguishing between the signer scrolling to the end of a long agreement and the full text fitting on screen with no scrolling required; and when the acceptance box was agreed. The Agree control stays disabled until the full text has been displayed. The terms-opened, displayed-to-end, and acceptance interaction timestamps are reported by the client and recorded as received; the signing-completion time (§6) is separately recorded by Hereby’s server. Hereby never invents or auto-completes an interaction event.
§6The Certificate of Electronic Signature — field by field
Every completed record carries a certificate page. Each line states one fact:
| Field | What it records |
|---|---|
| Electronic signer | Name · title · business submitted for the person who signed |
| Electronic signature consent | ESIGN/UETA consent, recorded |
| Agreement assent | The acceptance statement was affirmed; full terms reproduced on the record |
| Terms assent interaction | The opened / displayed-to-end / agreed timestamps and what was observed (§5) |
| Phone-possession verification | SMS one-time passcode result, masked number, and its stated limits (§3) |
| Signed (server time) | Hereby server time recorded when signing was completed |
| Signer IP address | The network IP address observed by Hereby at signing |
| Device / browser | The browser/OS reported by the signer’s software |
| Reference | The unique transaction reference |
| Agreement version | The version identifier of the terms signed |
| Agreement text (SHA-256) | The canonical fingerprint of the exact terms reproduced above (§4) |
| Terms as displayed | The disclosure-integrity result — “Verified” only on a real hash match |
| Record hash (SHA-256) | Fingerprint of the submitted data; any change to the data changes it |
The certificate is internally consistent: the version identifier, the text hash, the “Terms as displayed” result, and the reproduced agreement text all refer to the same thing. No line asserts something another line contradicts.
§7Data custody and privacy
Hereby follows a data-minimization model — keep the evidence, not the paperwork. Two things should be distinguished:
- The certificate page embedded in the delivered PDF is a self-contained record: it reproduces the agreement terms and the signing facts, and is delivered to the sending organization, which holds the executed document.
- Hereby’s server-side evidence record is deliberately limited. It may retain: transaction metadata and the field values supplied by the sending organization; the phone-possession result (masked number and method); the disclosure version identifier; server timestamps, including the signing-completion time; and cryptographic fingerprints (the record and document hashes). It does not retain the completed PDF or the field values the signer entered during the signing session.
- Roles mirror the standard e-signature model: the customer is the data controller and holds the executed agreement; Hereby is the processor of the signing event.
This design reduces the amount of completed-document content Hereby retains and limits exposure if retained systems are compromised. It does not eliminate all privacy or security risks during transmission and processing.
§8Tamper-evidence and independent verification
Two independent integrity mechanisms are applied to every signed document. The document fingerprint (§8.2) is the primary file-matching check used by Hereby. The embedded cryptographic seal (§8.1) is a second, in-file mechanism.
8.1Cryptographic seal (PAdES-compatible)
The final PDF is digitally sealed using a PAdES-compatible PDF signature and carries an RFC-3161 timestamp from an independent third-party Time Stamp Authority, providing independently verifiable evidence of the signing time. Opening the PDF in a reader such as Adobe Acrobat shows a signature in the Signatures panel. What a reviewer sees depends on the reader’s version, trust settings, and network access, but typically:
- ✓The reader reports whether the document has been modified since the signature was applied — the integrity check the seal provides.
- ✓The signature carries an RFC-3161 timestamp from an independent third-party Time Stamp Authority, giving independently verifiable evidence of signing time rather than relying on the signer’s own computer clock.
- !A certificate-trust warning may appear if the reader cannot build a trusted chain to Hereby’s signing certificate. That warning is not, by itself, proof that the signed bytes were modified. Using a certificate whose trust chain is recognized by the reader, such as an appropriate AATL-backed certificate, would ordinarily remove that issuer-trust warning.
A certificate-trust warning reflects how a reader evaluates the issuer — a separate question from whether the signed bytes changed. The primary file-matching check is §8.2.
8.2Document fingerprint (SHA-256)
At the moment of signing, Hereby records the SHA-256 hash of the exact delivered PDF. Anyone can later confirm that a file matches the exact PDF Hereby recorded at signing by re-hashing it and comparing.
The public verifier
Anyone — a counterparty, an auditor, or a court — can check a document at herebysign.com/verify, with no account. Drop the PDF onto the page; the file is hashed in your own browser, so only the 64-character fingerprint is sent to Hereby and the document itself is never uploaded. Hereby reports whether that fingerprint matches the file it recorded at signing, and if so shows the signing facts. Every certificate prints the verification address, so a signed document carries its own instructions for being checked. Verification is available while the corresponding evidence record remains within Hereby’s retention period and the verification service is operational (§9).
The fingerprint rejects any change
The fingerprint is exact. An unaltered, originally-delivered file matches; after even a trivial modification — highlighting text and undoing it, then re-saving the file — the modified copy no longer matches (saving rewrites the file’s internal structure, changing the fingerprint). There is no such thing as a “harmless” edit.
8.3Certificate legal notice
Hereby’s signing certificate carries an embedded legal notice (visible in Acrobat under Signature Properties → Show Signer’s Certificate → Legal Notice) stating, in the certificate itself, that this is a private certification seal, that signer verification is by SMS one-time passcode rather than government ID, and where to independently check a document.
§9Important caveats
- Only the originally-delivered file matches. A re-issued or reconstructed copy is not byte-identical — even if it reproduces the same information more clearly — and will show “no match.” Use the exact PDF delivered at signing.
- The seal is a private seal. A certificate-trust warning in a PDF reader is expected (§8.1) — it reflects a privately-issued certificate, not tampering. The primary file-matching check is the SHA-256 fingerprint / public verifier (§8.2).
- Verification is possession-of-phone, not government ID (§3).
- What Hereby retains is the evidence record, not the completed document (§7).
- Verification depends on retention and availability. A file can be checked only while the corresponding evidence record remains within Hereby’s retention period and the verification service is operational. Retention periods are set per the applicable agreement and Hereby’s data-retention practices.
Ex.A sample signed certificate
A representative completed signing. Its delivered PDF matches the file Hereby recorded at signing and carries the seal, independently verifiable timestamp, and legal notice described above.
- Signer
- Frankie Vito · Owner · Vito’s Pizza
- Phone-possession verification
- SMS one-time passcode · +1 (•••) •••-5554
- Terms as displayed
- Verified — client-reported hash matched the canonical disclosure on file
- Signed (Hereby server time)
- Jul 26, 2026 at 12:10 AM ET
- Network IP observed
- 98.28.99.168
- Document hash (SHA-256)
- 15ac73ed50acabe6e6b540a4712c0da498b1e46653eb4b803da044817f4adf70
Every statement on this page is meant to be checkable against a signed certificate. Confirm that a file matches the exact PDF Hereby recorded at signing at herebysign.com/verify.