Isaac Maw
Technical Content Creator
Published July 27, 2026
Updated July 27, 2026
5 min
ESIGN vs. eIDAS: Understanding Digital Signature Compliance
Isaac Maw
Technical Content Creator
Summary: ESIGN and eIDAS both govern when an electronic signature is legally binding, but they take different approaches: ESIGN asks whether there was intent and consent, while eIDAS asks which of three technical assurance tiers (SES, AES, QES) was used. We’ll compare the two frameworks, walk through what compliance means for developers, and show how the same signing workflow can satisfy both.
For developers building software workflows that comply with industry requirements, such as the financial and insurance industries, it’s important to understand not only industry-specific regulations like PCI DSS or GLBA, but also laws that govern things like accessibility, personal data, and digital signatures.
What Is the ESIGN Act?
The ESIGN Act (Electronic Signatures in Global and National Commerce Act) is a U.S. federal law that gives electronic signatures and records the same legal standing as their paper counterparts in interstate and international commerce. It applies to virtually any electronic transaction conducted in the United States and its territories, protecting both businesses and consumers who choose to sign or receive records electronically.
Complying with the ESIGN Act
Meeting ESIGN Act requirements means ensuring every electronic signature satisfies three core conditions:
- Intent to sign and consent. All parties must demonstrate clear intent to sign the record and must affirmatively agree to conduct business electronically. Consent needs to be captured as part of the signing process.
- Signer authentication and attribution. Can the signature be reliably tied to the person who signed it? Organizations must be able to produce supporting evidence, such as signer identity details, timestamp, geolocation, IP address, and the authentication method used, to demonstrate that the signature belongs to the claimed signer.
- Record retention and consumer disclosure. Consumers must be clearly informed of their right to request a paper copy of the transaction and must affirmatively consent to receiving records electronically instead. The electronic record itself must be accurately reproducible and remain accessible to all parties for later reference. This is also where ESIGN intersects with long-term archival requirements — see how PDF/A works alongside digital signatures to keep signed records both valid and readable years later.
What ESIGN Act Compliance Means for Developers
If you’re building a digital signature workflow that needs to comply with the ESIGN act (for example, you’re operating in US markets or with other compliance standards that are based on the ESIGN act), here’s the TL;DR:
- The act states that electronic signatures are considered legally equivalent to wet signatures. This includes ordinary electronic signatures, such as a symbol drawing with a pen tool.
- However, this type of electronic signature doesn’t include any verifiable electronic information, so there is no real way to verify that the signature is authentic or that the document was not altered after it was signed.
- Digital signatures solve this by combining the signature with a digital certificate containing the signer's public key into a PDF document.
- Because the signature is hashed using the signer’s private key during the signature, it can be verified by using the signer’s public key to obtain the hash, proving that the data was not altered.
- The Apryse Digital Signature SDK gets you up and running with secure digital signatures faster. For the full technical picture when it comes to certificate management, production trust chains (AATL/EUTL), and long-term validation, see our developer's guide to compliant PDF signing, and for a deeper look at ESIGN specifically, this breakdown of the ESIGN Act and what it means for your signing workflow
What Is eIDAS? Types of Digital Signatures
In the EU, not all electronic signatures are considered equivalent to handwritten signatures. eIDAS facilitates secure cross-border transactions by establishing a framework for digital identity and authentication, and it defines three types or tiers of digital signatures:
Tier | Requirements | Typical Use Cases |
|---|---|---|
SES | Any data logically associated with the signatory's intent to sign. E.g., a typed name | Low-risk agreements, informal internal approvals |
AES | Uniquely linked to the signatory, created so the signatory retains control, and tamper-evident | Standard business contracts, NDAs, most loan and account agreements |
QES | AES plus a qualified signature creation device and a qualified certificate | Real estate deeds, notarized documents, high-risk or high-value transactions |
- Simple Electronic Signature (SES): An electronic signature is defined as "data in electronic form which is attached to or logically associated with other data in electronic form and which is used by the signatory to sign" (eIDAS Article 3) . Thus, something as simple as writing your name under an e-mail might constitute an electronic signature.
- Advanced Electronic Signature (AES): An advanced electronic signature (eIDAS Article 3) is an electronic signature which is additionally:
- uniquely linked to and capable of identifying the signatory;
- created in a way that allows the signatory to retain control;
- linked to the document in a way that any subsequent change of the data is detectable.
- Apryse Digital Signature SDK provides these features using PKI (public-key infrastructure).
- Qualified Electronic Signature (QES): A qualified electronic signature (eIDAS Article 3) is an advanced electronic signature which is additionally:
- created by a qualified signature creation device;
- and is based on a qualified certificate for electronic signatures.
For QES, signature creation devices come in many forms to protect the electronic signature creation data of the signatory, such as smartcards, SIM cards or USB sticks. "Remote signature creation devices" can also be used where the device is not in the physical possession of the signatory, but managed by a provider.
For a deeper dive specifically on eIDAS and how the Apryse SDK supports each tier, see our full eIDAS compliance guide.
What eIDAS compliance means for developers
Here’s the TL;DR if you’re building an eIDAS-compliant digital signature workflow:
- QES is required for highly regulated, high-risk transactions such as real estate deeds, public contracts, long-term lease agreements, and notarized documents.
- AES is standard for the majority of signings, such as standard business contracts, NDAs, employee onboarding, and supplier agreements.
- Apryse SDK lets you build AES out of the box.
- You can build a QES workflow with Apryse if you provide the qualified creation device and use qualified certificates issued by an accredited qualified trust service provider (QTSP).
Can a Digitally Signed Document Still Be Edited?
Some software tools don’t allow users to alter digitally signed documents, but it’s certainly possible. However, a digital signature guarantees that any change made after signing is recorded and detectable.
The Apryse SDK allows you to control what can be done to the signed file without invalidating the signature. For example, it may be necessary to get multiple digital signatures on the same file – for example, a contract – where all parties need to sign the document, but no changes should be possible to the content of the contract. Alternatively, it may be desirable to be able to add annotations to a signed document without invalidating it.
If any of the changes were not permitted, for example, a change to a clause in a contract, then the digital signature will become invalid, and this will be recognizable.
ESIGN vs. eIDAS: Key Regulatory Differences
| ESIGN (U.S.) | eIDAS (EU) |
|---|---|---|
Legal structure | Federal law, works alongside state-level UETA adoption | Single regulation, applies uniformly across all EU member states |
Format mandate | None - any reasonably reliable method can qualify | Tiered - SES, AES, or QES, each with its own technical bar |
Core legal test | Was there intent to sign and consent to do business electronically? | Which tier's technical and identity assurance was met? |
Default legal weight | Court weighs the totality of evidence (audit trail, consent, authentication) | Only QES carries an automatic presumption of validity in every member state |
Here are the key differences between eIDAS and ESIGN for developers to be aware of when implementing signature capabilities in software:
ESIGN is a U.S. federal law that applies to transactions in interstate and foreign commerce, and it works alongside UETA (the Uniform Electronic Transactions Act), which most U.S. states have separately adopted. ESIGN doesn't mandate a specific signature format or vendor, only that a signature can't be denied legal effect solely because it's electronic. Even a customer’s name written in plain text can constitute a signature under ESIGN in the right context. However, a digital certificate provides cryptographic evidence of the signer and any changes to the document, making secure digital signatures much more reliable in the event of a dispute.
eIDAS, by contrast, is a single EU regulation, meaning it applies directly and uniformly across all member states without needing separate national legislation. The tiered structure of eIDAS means that legal weight and cross-border enforceability of a signature depends on which tier it satisfies. This is the single biggest structural difference between the two frameworks: ESIGN asks "was there intent and consent?" while eIDAS asks "which tier of technical and identity assurance was used?"
For developers, this means that complying with the eIDAS AES definition provides a broad base of support for different types of secure transactions. Basic, unsecured e-signatures can lead to disputes and issues, while the high-level QES may be needed for some use cases, but overkill for others.
Legal Enforceability: When Are Digital Signatures Binding?
Under ESIGN, a signature is legally binding as long as the three core conditions are met:
- demonstrated intent and consent
- reliable authentication and attribution
- proper record retention with consumer disclosure where applicable
There's no separate certification step or government-approved technology required. For most document types, a court evaluates the totality of the evidence (audit trail, consent language, authentication method) to determine enforceability.
Under eIDAS, enforceability is tier-dependent:
- An SES is not denied legal effect merely because it's electronic, but if challenged in court, the burden is on the relying party to prove its validity. There's no automatic legal presumption in its favor.
- An AES strengthens that position through cryptographic linkage to the signer and the document.
- A QES carries an automatic legal presumption of equivalence to a handwritten signature across all EU member states, and it's the only tier that must be recognized as such by every member state's courts without additional proof.
In practice, this means EU regulators and courts effectively push higher-value or higher-risk transactions toward AES or QES, since a challenge to an SES-signed contract puts the evidentiary burden back on the business.
Security Considerations (PKI, Authentication, Audit Trails)
Both ESIGN and eIDAS use similar technical building blocks, even though they arrive at them differently:
- Public-key infrastructure (PKI). Digital certificates and asymmetric encryption are the backbone of both AES/QES under eIDAS and of any ESIGN-compliant digital signature that needs to prove document integrity. Our developer's guide to compliant PDF signing covers production certificate management in detail, including trust lists like AATL and EUTL.
- Signer authentication. ESIGN leaves the authentication method largely up to the business as long as it's reasonably reliable and documented. eIDAS is more prescriptive as the tier rises, as explained above.
- Audit trails. Both rely heavily on the audit trail to prove compliance after the fact. A defensible audit trail typically captures signer identity and authentication method, IP address and geolocation, exact timestamp of consent and of signing, the specific version of the document presented and signed, and a tamper-evident hash chain showing the document was unmodified post-signature. Apryse SDK generates this metadata automatically as part of the signing workflow, so it's available if a signature is ever challenged.
- Long-term validation (LTV). Certificates expire and revocation checks (CRL/OCSP) may become unavailable over time. Embedding LTV information at signing time ensures a signature can still be verified years later, which matters for both eIDAS's stronger tiers and for any ESIGN-governed record with a long retention requirement.
Financial Industry Example: Lending and Loan Agreement Workflows
In the U.S., a personal loan or mortgage signed electronically must satisfy ESIGN's consumer disclosure requirements (the borrower must affirmatively consent to receiving loan documents electronically and confirm they can access them), on top of standard truth-in-lending disclosures. An AES compliant digital signature helps organizations prove who signed what, providing a robust audit trail.
With AES, the borrower's identity is verified (often via a bank's existing KYC data or a third-party ID verification provider), the signature is cryptographically bound to the specific version of the loan agreement, and any later edits invalidate it. For larger, higher-risk lending, a QES may be required.
Financial Industry Example: Banking Account Opening
Account opening workflows illustrate how identity verification requirements scale with regulatory tier and risk.
Under ESIGN, opening a bank account online generally requires authentication strong enough to satisfy the bank Know Your Customer (KYC) and Bank Secrecy Act obligations. A secure digital signature workflow helps satisfy these compliance requirements and ESIGN.
Under eIDAS, many EU banks build account opening around an AES, since the identity verification already required for KYC/AML compliance naturally satisfies AES requirements.
Beyond Financial Services: Digital Signature Compliance Across Industries
While lending and banking are common proving grounds for signature compliance, the same principles extend well beyond financial services:
- Healthcare: Patient consent forms, telehealth intake, and HIPAA-related authorizations in the U.S. typically rely on ESIGN-compliant e-signatures paired with strong authentication; in the EU, patient consent for certain treatments may need to meet AES standards depending on national health law.
- Real estate: Property purchase agreements and leases are commonly ESIGN-compliant in the U.S., though many states still require wet-ink or notarized signatures for deeds. In the EU, property transactions frequently require QES and, in many member states, mandatory notarization regardless of signature type. This kind of embedded, industry-specific signing flow, including real estate, mortgage, and insurance use cases, is covered in more depth in this guide to building custom signature workflows.
- HR and employee onboarding: Offer letters, NDAs, and policy acknowledgments use basic ESIGN e-signatures or eIDAS SES/AES, since the risk is lower.
- Government and public sector: Interactions with public administration in the EU frequently require QES specifically, since eIDAS was partly designed to enable secure cross-border e-government services.
- Insurance: Policy applications and claims often mirror the banking industry examples above.
Conclusion
ESIGN and eIDAS both govern the legal force of electronic signatures, but eIDAS provides a more defined framework that satisfies ESIGN at all levels.
For teams building signature capabilities that need to work globally, the practical takeaway is to design for the more demanding EU requirements first: capture strong authentication and a tamper-evident audit trail and treat the specific tier or disclosure flow as a configuration decision. A workflow built this way will satisfy ESIGN's requirements without modification and can be dialed up to AES or QES for EU transactions that need it.
With Apryse, developers can easily implement SES signatures using annotations, including in the WebViewer base package. The Digital Signatures add-on provides support for AES workflows out of the box, and powers QES signatures with the addition of the required device and certificate providers described above. For the broader picture of how digital signatures fit into document authentication overall, see our digital signatures and authentication guide.
FAQ
Q: ESIGN vs. eIDAS: what's the difference?
A: ESIGN is a U.S. federal law which states that a signature can't be denied legal effect solely because it's electronic. eIDAS is a single EU regulation applying uniformly across all member states, with a tiered structure (SES, AES, QES) where legal weight depends on which tier is satisfied. The Apryse Digital Signature SDK supports both laws.
Q: Are digital signatures legally binding?
A: Yes, under both ESIGN and eIDAS as well as other regulations across the globe (such as PIPEDA in Canada) digital signatures are legally binding. However, signers can allege that the content of the document has changed, or that they didn’t sign the document. With a digital certificate secured by public key infrastructure, there is a strong audit trail that proves the identity of the signer and any changes to the document. The Apryse SDK generates the audit trail metadata (signer identity, timestamps, IP address, tamper-evident hash chain) that supports enforceability under both laws.
Q: What types of digital signatures exist?
A: eIDAS defines three tiers:
- SES: Basic electronic data used to sign, such as a typed name.
- AES: a digital signature secured by encryption.
- QES: An AES created using a qualified signature creation device and a qualified certificate.
Q: How do you implement compliant signing workflows?
A: The Apryse SDK handles this end to end: it generates audit trail metadata automatically, supports PKI-based AES workflows out of the box, and enables QES when combined with a qualified creation device and QTSP-issued certificates, so teams don't have to build compliance infrastructure from scratch.
Q: Is an electronic signature the same as a digital signature?
A: No. An electronic signature is any digital mark used to indicate intent to sign; a typed name or a drawn image both qualify, but neither can prove the document wasn't altered afterward. A digital signature is a specific technical implementation that uses public-key infrastructure (PKI) to cryptographically bind the signature to both the signer's identity and the exact document content, so any post-signing change becomes detectable. Every digital signature can serve as an electronic signature, but not every electronic signature meets the bar of a digital signature.
Q: What is Long-Term Validation (LTV), and why does it matter?
A: Long-Term Validation embeds a signing certificate's validity status directly into the signed document at the moment of signing. Without it, a signature can become unverifiable years later if the original certificate expires or its revocation-check service goes offline. LTV matters most for records with long retention requirements for financial, healthcare, or legal documents that may need to be validated a decade or more after signing.
