ESIGN & UETA compliance for developers

ESIGN vs UETA, in two sentences

ESIGN (the federal Electronic Signatures in Global and National Commerce Act, 15 U.S.C. §7001, 2000) makes electronic signatures and records legally effective across US interstate commerce. UETA (the Uniform Electronic Transactions Act, 1999) is the near-identical state-level law adopted by 49 states; where a state has adopted UETA, it generally governs, with ESIGN as the federal backstop.

Both say the same core thing: a signature, contract, or record may not be denied legal effect solely because it is electronic. Neither dictates a technology — they set outcomes your process must achieve. Here is that process as code requirements.

The five code requirements, mapped to statute

1. Intent to sign — §7001(a)

The signer must take a deliberate action that manifests intent to sign (typing a name, drawing a signature, clicking a clearly labeled “Sign” button). In code: capture the specific action and its timestamp; never treat a page view or a pre-checked box as a signature.

2. Consent to do business electronically — §7001(c)

For consumer transactions, ESIGN requires affirmative consent to use electronic records, plus disclosures: the right to a paper copy, how to withdraw consent, the hardware/software needed to access records. In code: gate signing behind an explicit consent step and store the exact disclosure text and version the signer agreed to.

3. Association with the record — attribution, §7001(a) & UETA §9

The signature must be logically bound to the exact document that was signed. In code: hash the final document bytes (e.g. SHA-256) and store the hash with the signature event, so you can later prove the signed bytes were not altered.

4. Retention & reproducibility — §7001(d)

The record must be retained and capable of accurate reproduction for later reference by everyone entitled to it. In code: store the signed artifact in a durable, tamper-evident form (a PAdES/PKCS#7-sealed PDF is ideal) and keep it for the life of the agreement plus any statute-of-limitations tail.

5. Attribution & audit trail — §7001(a), UETA §9

You must be able to show who signed and how you know. In code: record signer identity signals (authenticated email/OTP, IP address, user agent, timestamps for view/consent/sign) in an audit record bound to the document hash.

Sample consent-screen copy (copy-paste)

A minimal, defensible consent gate for a consumer e-sign flow. Adapt the specifics; the point is that it is affirmative (an unchecked box the signer must tick) and that it names paper-copy rights, withdrawal, and system requirements.

☐ I agree to sign electronically.

By checking this box I consent to use electronic records and
signatures for this transaction under the ESIGN Act and applicable
state UETA law. I understand that:

  • I may request a paper copy of any record at no charge by
    emailing records@example.com.
  • I may withdraw my consent before signing by closing this
    window; withdrawal does not affect records already signed.
  • To access and retain these records I need a current web
    browser and a PDF reader, and an email account to receive them.

[ Continue to sign ]   ← disabled until the box is checked

A JSON audit-record schema (copy-paste)

This is the citable artifact: a compact, court-friendly audit record that captures the five requirements for one signer on one document. Emit one per signer, bind it to the document hash, and seal it with the final PDF.

{
  "envelope_id": "env_9f2c1a",
  "document": {
    "filename": "services-agreement.pdf",
    "sha256": "b1946ac92492d2347c6235b4d2611184...",   // hash of the exact signed bytes (req. 3)
    "version_signed": 2
  },
  "signer": {
    "name": "Jordan Rivera",
    "email": "jordan@example.com",
    "identity_method": "email_otp",                       // how identity was verified (req. 5)
    "authenticated_at": "2026-07-23T14:01:40Z"
  },
  "intent": {                                             // deliberate signing action (req. 1)
    "action": "click_sign_button",
    "signed_at": "2026-07-23T14:02:11Z"
  },
  "consent": {                                            // e-records consent + disclosure (req. 2)
    "granted": true,
    "disclosure_version": "esign-consent-v3",
    "disclosure_sha256": "5f0c1e...",
    "granted_at": "2026-07-23T14:01:58Z"
  },
  "attribution": {                                        // who/where/when (req. 5)
    "ip": "203.0.113.7",
    "user_agent": "Mozilla/5.0 ...",
    "viewed_at": "2026-07-23T14:00:12Z"
  },
  "retention": {                                          // reproducible, sealed record (req. 4)
    "sealed_pdf": "s3://vault/env_9f2c1a/sealed.pdf",
    "seal": "PAdES-PKCS7",
    "retain_until": "2033-07-23"
  }
}

Bind this record to the sealed PDF (embed it, or store it under the same document hash). That single object answers the questions a dispute actually asks: was it the right document, did they mean to sign, did they consent, and can you prove who and when?

What ESIGN does not cover

ESIGN carves out categories where electronic signatures may not be sufficient. Don’t use a generic e-sign flow for:

• Wills, codicils, and testamentary trusts.
• Certain family-law matters (e.g. adoption, divorce).
• Specific court documents and official court orders/notices.
• Some statutorily required notices — utility shut-off, insurance cancellation, foreclosure, eviction, product recalls, and the like — where the law may require paper.

These exceptions live in the statute (§7003). When your product touches one, route it to the appropriate legal process rather than assuming e-sign applies.

When US law isn’t enough: eIDAS, AES, and QES

ESIGN/UETA govern the United States. If your signers are in the EU/EEA, the relevant framework is eIDAS, which tiers signatures as SES (simple), AES (advanced — uniquely linked to and under the sole control of the signer), and QES (qualified — AES backed by a qualified certificate from a Qualified Trust Service Provider, with legal effect equivalent to a handwritten signature EU-wide).

You cannot self-issue a QES. If a transaction demands qualified or advanced signatures, integrate a QTSP — a US-law self-hosted flow, however well built, does not produce them. For most US commercial and consumer agreements, though, a sound ESIGN/UETA implementation is exactly right.

The developer checklist

• ☐ Deliberate signing action captured with a timestamp (intent).
• ☐ Affirmative, unchecked-by-default consent gate; store the disclosure text + version.
• ☐ Paper-copy right, withdrawal method, and system requirements disclosed.
• ☐ SHA-256 (or stronger) hash of the exact signed bytes stored with the signature.
• ☐ Signer identity signal recorded (authenticated email/OTP, SSO, etc.).
• ☐ IP, user agent, and view/consent/sign timestamps in an audit record.
• ☐ Signed artifact sealed (PAdES/PKCS#7) and retained per your retention policy.
• ☐ Excluded document types (§7003) routed away from generic e-sign.
• ☐ EU signers → evaluate whether AES/QES via a QTSP is required.

A worked example. Lifted Sign implements this checklist as a self-hostable server: an explicit ESIGN/UETA consent gate, a document hash bound to each signature, and a PAdES/PKCS#7-sealed Certificate of Completion capturing identities, timestamps, IPs, and consent. It’s one open example among several — Documenso, DocuSeal, and OpenSign also emit completion certificates — so you can read exactly how a compliant flow is built rather than trust a black box.