Digital Signature vs Electronic Signature: legal intent, cryptographic proof and when you need each

"Electronic signature" is a legal category defined by intent to sign, while "digital signature" is a cryptographic mechanism, and treating the two as synonyms leads to contracts that are valid but hard to prove, or to expensive PKI where a click would have done. An electronic signature can be a typed name, a checkbox or a scanned image; a digital signature is a value computed with a private key that lets anyone holding the public key check integrity and origin. The law in the EU, the UK and the US recognises electronic signatures broadly, and adds tiers (advanced and qualified under eIDAS) that in practice rely on digital signatures and PKI. This guide is for security, legal operations and IT teams choosing a signing approach, and explains the legal meaning, the cryptographic meaning, the eIDAS levels, evidential weight and what PKI each option needs. For the mechanics of signature algorithms, see the Digital Signatures Guide.

Key takeaways

• Two different questions. "Is this an electronic signature?" is about intent and legal effect; "is this a digital signature?" is about cryptography. A qualified electronic signature is both; a typed name is only the first; a TLS server signature is only the second.
• Broad validity, unequal proof. eIDAS Article 25(1), the US ESIGN Act (15 U.S.C. 7001) and UK Electronic Communications Act 2000 section 7 stop a signature being rejected just because it is electronic, but they do not make every electronic signature equally easy to prove.
• Only QES equals handwriting by law in the EU. Article 25(2) gives a qualified electronic signature the equivalent legal effect of a handwritten signature; simple and advanced signatures must prove their reliability if challenged.
• PKI is what turns intent into evidence. Advanced and qualified signatures depend on certificates, signer key control and validation data; long-term proof needs timestamps and preserved revocation data (AdES B-T to B-LTA).
• Match the method to the risk, not the fashion. Most commercial agreements are fine with a well-evidenced simple signature; regulated filings, cross-border public sector work and documents a counterparty is likely to dispute justify AdES or QES.

The short answer

An electronic signature is any electronic data a person uses, with intent, to sign. A digital signature is a cryptographic operation (for example RSA, ECDSA or EdDSA under NIST FIPS 186-5) that provides integrity, origin authentication and support for non-repudiation. Many electronic signatures contain no digital signature from the signer at all; the platform may seal the finished document with its own key, which proves the document has not changed since sealing, not which person signed. Choose a simple electronic signature with a strong audit trail for routine agreements, an advanced electronic signature where you need the signature cryptographically linked to an identified signer, and a qualified electronic signature where EU law or a counterparty requires handwritten equivalence. Some document types are excluded from general e-signature laws altogether.

Side by side: legal concept versus cryptographic mechanism

The legal frameworks

EU: eIDAS

Regulation (EU) No 910/2014, as amended by Regulation (EU) 2024/1183 (consolidated text dated 18 October 2024 on EUR-Lex, checked November 2026), defines three tiers. Article 3(10) defines an electronic signature as data in electronic form attached to or logically associated with other electronic data and used by the signatory to sign. Article 3(11) defines an advanced electronic signature (AdES) as one meeting Article 26, and Article 3(12) defines a qualified electronic signature (QES) as an AdES created by a qualified electronic signature creation device (QSCD) and based on a qualified certificate for electronic signatures. Under Article 26, an AdES must be uniquely linked to the signatory, capable of identifying the signatory, created using signature creation data the signatory can, with a high level of confidence, use under their sole control, and linked to the signed data so that any later change is detectable.

Article 25(1) says an electronic signature shall not be denied legal effect and admissibility as evidence in legal proceedings solely because it is electronic or does not meet the requirements for QES. Article 25(2) gives a QES the equivalent legal effect of a handwritten signature. Electronic seals are the equivalent for legal persons (Article 3(25) and Article 35); see the eIDAS Qualified Trust Services Guide for providers and supervision, and the eIDAS 2.0 and the European Digital Identity Framework Guide for the wallet changes.

US: ESIGN and UETA

The ESIGN Act, 15 U.S.C. 7001(a), says a signature, contract or other record relating to a transaction in or affecting interstate or foreign commerce may not be denied legal effect, validity or enforceability solely because it is in electronic form. Section 7006(5) defines an electronic signature as an electronic sound, symbol or process, attached to or logically associated with a contract or other record and executed or adopted by a person with the intent to sign. ESIGN is technology neutral: it does not require a digital signature or PKI. Section 7001(c) adds consumer consent and disclosure duties before electronic records replace required written notices, and 7001(d) allows electronic retention where the record stays accurate, accessible and reproducible. Section 7003 excludes wills, codicils and testamentary trusts, family law matters, most of the Uniform Commercial Code, court documents, and certain notices such as utility shut-off, foreclosure or eviction on a primary residence, health or life insurance cancellation, product recalls and hazardous materials documents. At state level the Uniform Electronic Transactions Act (UETA) provides a parallel framework.

UK

Section 7 of the Electronic Communications Act 2000, as amended in 2016 by the Electronic Identification and Trust Services for Electronic Transactions Regulations 2016 (S.I. 2016/696), makes an electronic signature and its certification admissible in legal proceedings on questions of authenticity or integrity. Section 7(2) defines an electronic signature as so much of anything in electronic form as is incorporated into or logically associated with electronic communications or data and purports to be used by the individual creating it to sign.

This page summarises these laws for security teams; check sector rules (financial services, healthcare, public procurement) and the governing law of each agreement.

Electronic signatures in depth: threat model, architecture and failure modes

Threat model

The main risks for simple electronic signatures are repudiation ("I never signed that"), impersonation through a compromised email account, and alteration of the document or audit trail after signing. Because the signer typically holds no key, the evidence of who signed is circumstantial: authentication events, email delivery, IP and device data, and the platform's records.

Architecture in words

A typical platform sends a link to the signer's email, optionally adds SMS one-time code, knowledge-based or document identity verification, records each step (view, consent to electronic records, signature placement, completion) with timestamps, then seals the completed document and a certificate of completion with the platform's own certificate. The platform's digital seal proves the document has not changed since completion; the audit trail and authentication evidence carry the "who" and "intent".

Failure modes and controls

• Weak signer authentication: email-link only signing is as strong as the signer's mailbox. Add a second factor or identity verification for higher-value agreements.
• Missing consumer consent: in the US, skipping the 7001(c) disclosures for required consumer notices undermines the electronic record.
• Audit trail held only by the vendor: if the account is closed or the platform is unavailable, the evidence goes with it. Export completed envelopes and certificates to your own retention system.
• Excluded documents: wills and the other 7003 exclusions need the formalities of the governing law.
• Admin and API abuse: platform admin accounts and integration keys can send, void or download agreements at scale; treat them as privileged non-human identities. See E-Signature Platform Security.

Digital signatures in depth: threat model, architecture and failure modes

Threat model

A digital signature defends against undetected modification and forged origin. FIPS 186-5 describes digital signatures as detecting unauthorised modification, authenticating the signatory and supporting non-repudiation, where a recipient can show a third party that the named signatory generated the signature. That last property is only as strong as the binding between the private key and the person: if the key sits in a shared file or an administrator can use it, non-repudiation collapses. eIDAS Article 26(c) "sole control" and the QSCD requirement exist for exactly this reason.

Architecture in words

A certification authority verifies the signer's identity and issues a certificate binding a name to a public key. For qualified certificates, Article 24(1a) lists permitted identity verification methods: the European Digital Identity Wallet or a notified eID at assurance level high, an existing qualified certificate, other methods confirmed by a conformity assessment body, or physical presence. The signer's private key is generated and used on a device (a smart card, token or a remote QSCD operated by a trust service provider). The signing application hashes the document, signs the hash, and embeds the signature and certificate in an AdES format. A relying party validates the signature, the certificate chain to a trusted root (for EU qualified services, the EU Trusted Lists reached through the Commission's List of Trusted Lists), revocation status at signing time and, for QES, the qualified status of certificate and device under Article 32.

AdES formats and long-term levels

Failure modes and controls

• Signature without identity: a self-signed or internally issued certificate proves key control to you, but a counterparty or court has no reason to trust it. Use a CA the relying party already trusts.
• B-B only for long-lived records: once the certificate expires or the CA's OCSP service is retired, validation becomes INDETERMINATE. Use B-LT or B-LTA for contracts and records kept for years; Article 34 qualified preservation services exist to extend trustworthiness beyond the technological validity period.
• Shared or exported keys: a signing key in a shared mailbox certificate or a file on a file share fails "sole control". Keep keys on smart cards, HSMs or a remote QSCD.
• Algorithm ageing: plan for algorithm transition, including post-quantum signatures; see the ML-DSA and SLH-DSA Post-Quantum Signatures Guide.
• Validation shortcuts: a viewer that shows a green tick based on a local trust store is not an Article 32 validation. Use a validation service that reports TOTAL-PASSED, TOTAL-FAILED or INDETERMINATE against a defined policy.

Evidential weight: what each level gives you in a dispute

In the US and UK, where there are no statutory tiers for general commerce, the same logic applies informally: the more the signature process authenticates the signer and fixes the document, the easier it is to prove. A digital signature from a trusted CA plus a signed timestamp is strong integrity evidence; it is still the surrounding process that shows intent.

Decision guidance and trade-offs

• Cost and friction: QES needs identity verification to a high level and a QSCD, which adds onboarding time and per-signature cost; remote QSCD services reduce hardware but not identity proofing.
• Counterparty reach: a simple signature works for anyone with email; QES works only for signers who hold or can obtain a qualified certificate.
• Small versus large organisations: small firms usually rely on a signing platform's simple or advanced options; larger organisations with EU regulated workflows run a policy that maps document types to levels and integrate a qualified trust service provider. In-house PKI for signing makes sense only where you control both signer and relying party; see the Enterprise PKI Design and CA Hierarchy Guide.

Worked scenarios

Scenario 1, a supplier NDA: both parties are businesses, the governing law is English, and the value at risk is modest. A simple electronic signature through a platform with SMS second factor, consent capture and a sealed completion certificate is proportionate. Export the completed envelope and audit trail to your contract repository.

Scenario 2, an EU public tender submission: the contracting authority requires a QES on the bid documents. The bidder's authorised signatory obtains a qualified certificate after identity verification, signs with a remote QSCD in PAdES B-LT, and checks the result with a validation service against the EU Trusted Lists before upload. A scanned handwritten signature or a simple platform signature would not meet the requirement.

Scenario 3, a loan agreement disputed years later: a lender signs with AdES at B-B. Five years on the CA has rotated its roots and retired its OCSP responder, and validation returns INDETERMINATE. Had the lender used B-LT with embedded revocation data and B-LTA archive timestamps, or a qualified preservation service, the signature would still validate.

How to implement

1. Classify documents: list document types, governing law, retention period and dispute likelihood; mark statutory exclusions.
2. Set a signature policy: map each class to simple, advanced or qualified signatures or seals, and to minimum signer authentication.
3. Choose trust services: for AdES and QES, select CAs or qualified trust service providers on the relevant trusted list; for simple signatures, evaluate platforms on authentication, audit trail and export.
4. Protect keys: signer keys on smart cards, HSMs or remote QSCDs; platform and seal keys in HSMs with dual control.
5. Pilot: run one document class end to end, including validation by an independent tool and retrieval of evidence from your own archive.
6. Configure long-term validation: B-T minimum, B-LT or B-LTA for records kept longer than the signing certificate's validity.
7. Roll back safely: keep a wet-ink or alternative path for counterparties who cannot use the chosen level, and record the exception.

Detection and measurement

Monitor signing platform admin actions, API key use, bulk downloads, envelope voids and template changes, and alert on signing from unusual locations for high-value agreements. Run scheduled re-validation of archived signed documents so INDETERMINATE results surface before a dispute.

• Policy coverage: percentage of document classes with an assigned signature level (target 100%).
• Signer authentication strength: share of high-value agreements signed with a second factor or identity verification.
• Long-term validation readiness: share of long-retention records stored at B-LT or B-LTA.
• Re-validation pass rate: percentage of sampled archived signatures returning TOTAL-PASSED.
• Evidence independence: share of completed agreements with audit trail exported to your own repository.

Framework mapping

Practitioner checklist

• Stop using "digital signature" and "electronic signature" interchangeably in policies and contracts.
• Map every document class to simple, advanced or qualified signature or seal, and list statutory exclusions.
• Require a second factor or identity verification for high-value or likely-disputed agreements.
• Capture US consumer consent and disclosures where electronic records replace required written notices.
• Keep signer and seal keys on smart cards, HSMs or QSCDs, never in shared files.
• Use B-LT or B-LTA, or a qualified preservation service, for records kept beyond certificate validity.
• Validate QES with a service that checks EU Trusted List status, not a viewer's local trust store.
• Export audit trails and signed documents to your own retention system.
• Treat signing platform admins and API keys as privileged identities with logging and review.

Standards and references

• EUR-Lex: Regulation (EU) No 910/2014 (eIDAS), consolidated text
• Cornell LII: 15 U.S.C. 7001 General rule of validity (ESIGN Act)
• Cornell LII: 15 U.S.C. 7006 Definitions (ESIGN Act)
• Cornell LII: 15 U.S.C. 7003 Specific exceptions (ESIGN Act)
• legislation.gov.uk: Electronic Communications Act 2000, section 7
• NIST: FIPS 186-5 Digital Signature Standard
• European Commission: Digital Signature Service (DSS) documentation

Related NHI Mgmt Group resources: Digital Signatures Guide · eIDAS Qualified Trust Services Guide · E-Signature Platform Security · Digital Signatures vs Encryption. This guide summarises the EU eIDAS Regulation, the US ESIGN Act and the UK Electronic Communications Act 2000 and is not legal advice.