ESIGN, UETA and eIDAS — what each one actually asks for
Three frameworks, two continents, and a short list of things your system must record if you want the signature to hold up.
Nothing here is legal advice, and validity depends on your jurisdiction, the document type and how the transaction was carried out. What follows is what these frameworks ask of the software, which is the part you can actually check.
The three, in one table
| ESIGN (US federal) | UETA (US state) | eIDAS (EU) |
|---|
|---|---|---|---|
| Scope | Interstate and foreign commerce | Adopted by most US states | EU member states |
|---|---|---|---|
| Consent | Explicit consumer consent to transact electronically, with disclosures | Agreement of the parties | Not framed the same way |
| Tiers | None | None | Simple, Advanced (AdES), Qualified (QES) |
| What software must do | Record consent, attribute the signature, keep an accurate retainable record | Record intent and attribution | Meet the technical conditions of the tier claimed |
What "attribution" means for your software
Both US frameworks turn on attribution: showing that the signature is the act of the person it names. No statute tells you how. In practice a system attributes a signature through the record it keeps:
- The invitation went to a specific address, and only that link could sign.
- The link was a credential — not guessable, not reusable by someone else, replaced rather than duplicated on resend.
- Any additional identity check that was applied, and its result.
- What the signer was shown before they acted.
- A timestamp for each step, in a trail that cannot be edited afterwards.
If a vendor cannot show you those, attribution rests on their word.
Consent is a record, not a checkbox
ESIGN's consumer consent provisions are the part most often satisfied loosely. The requirement is not merely that a box was ticked; it is that disclosures were made and the consumer's consent was obtained and can be evidenced. A system that records consent as its own event, at the moment it happened, with what was shown, is doing this properly. A system that infers consent from the fact that someone signed is not.
The eIDAS tiers, briefly
Simple electronic signature is the broad category — data in electronic form used to sign. Most e-signature products produce this.
Advanced (AdES) adds conditions: uniquely linked to the signatory, capable of identifying them, created using means under their sole control, and linked to the data such that later changes are detectable. The last condition is where sealing and hashing matter.
Qualified (QES) is AdES created by a qualified signature creation device with a qualified certificate from a trust service provider on the EU trusted list. It is the only tier with legal effect equivalent to a handwritten signature across the EU. It requires a qualified TSP; no software produces it on its own.
Be sceptical of any product claiming QES without naming its qualified trust service provider.
A practical checklist
- Does the system record consent as a distinct, timestamped event?
- Can it show what the signer was shown, not just what they clicked?
- Is the completed document sealed so that later changes are detectable?
- Does the record survive without the vendor?
- If a tier is claimed, is the mechanism named — or only the tier?
Last reviewed 2026-09-18. Pactlyra produces a detailed evidence record for every completed document. Electronic signature validity depends on your jurisdiction, the document type, and how the transaction is carried out; nothing here is legal advice.