What's the Difference Between a Digital Signature and an Electronic Signature?

July 28, 2026 ·Gustav Poola ·

digital-signatureelectronic-signatureadeseidaspkises-ades-qesglobal-digital-identityauthenticationnon-repudiationcryptography

An electronic signature is any electronic mark that indicates intent to sign — a typed name, a click, a scanned image, a stylus mark, a biometric capture, or a cryptographic signature. A digital signature is a specific cryptographic subset of electronic signature — hash plus private-key transformation plus verification against a public key and a certificate. Every digital signature is an electronic signature. Not every electronic signature is a digital signature.

What's the Difference Between a Digital Signature and an Electronic Signature?

A Prague procurement director sent us a rejection notice she had just issued to a Balkan supplier last month. The supplier had returned a signed vendor contract by uploading a PDF containing a typed name at the bottom and a scanned image of a handwritten signature. The procurement director's compliance policy required a "digital signature." The supplier was insisting that what they had produced was a digital signature — the file was digital, and it contained a signature. She asked us for a technically defensible explanation of why she was right to reject it. This post is that explanation, in the shape a procurement, legal, or engineering audience actually needs to reach a defensible position of their own.

What is an electronic signature under the law?

An electronic signature is defined by intent, not by technique. eIDAS Regulation (EU) 910/2014 Article 3(10) states it 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." The US ESIGN Act uses substantially the same construction — "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 the record." Both definitions turn on the same two elements: an electronic mark of some kind, and the signer's intent that the mark serve as their signature.

Neither definition requires the mark to be cryptographic. A typed name at the bottom of an email counts. A click on an "I agree" button counts. A scanned image of a handwritten signature counts. A stylus mark on a tablet screen counts. A biometric capture counts. What matters at the legal-definition layer is the intent-to-sign element and the attribution element — can the mark be tied back to the person who made it. The UNCITRAL Model Law on Electronic Signatures (2001) inherits the same structure, and so does every downstream framework that traces to it — including all six framework families walked in Digital Signature Laws by Country.

The consequence is that "electronic signature" is a category broad enough to include marks with almost no cryptographic evidence attached. From an engineering standpoint that is worth naming directly: an electronic signature is a legal concept before it is a technical one. The technique it uses is a matter of what evidence the signer will be able to produce in a challenge, not a matter of whether the mark counts as a signature at all.

What is a digital signature technically?

A digital signature is a specific cryptographic construction. It is a hash of the signed data, transformed by the signatory's private key using an asymmetric algorithm, so that anyone in possession of the corresponding public key can verify both that the data has not changed since signing and that the transformation could only have been performed by the holder of that specific private key. The primitives are defined in NIST FIPS 186-5 (Digital Signature Standard), the hash is typically defined in FIPS 180-4 (SHA-2), the key material is bound to an identity via an X.509 certificate under RFC 5280, and the algorithms in production use are typically RSA-PSS (RFC 8017), ECDSA, or Ed25519 (RFC 8032). A more detailed walkthrough of how the hash and the signature are structurally related lives in What's the Difference Between Hash and Digital Signature?.

For the digital signature to be usable at the enterprise or cross-border level, it is typically wrapped in an AdES envelope defined by ETSI: CAdES (EN 319 122) for CMS-based flows, XAdES (EN 319 132) for XML flows, or PAdES (EN 319 142) for PDF documents. The envelope binds the cryptographic signature to the document's specific bytes, timestamps the signature, and — in the LTV variants — embeds enough certificate-chain and revocation-status evidence to remain independently verifiable for the retention period the deployment requires. What the envelope does not do is turn a non-cryptographic mark into a digital signature. If the underlying operation was a click, a typed name, or an image, wrapping it in a PAdES envelope does not upgrade its cryptographic status. The envelope is a container, not a promotion mechanism.

The way I typically summarise this in an architecture review: the technical definition is narrow, and it has to be narrow, because the evidentiary weight the definition unlocks — burden reversal in the EU under eIDAS Article 25(2), independent verifiability in dispute, long-term admissibility — depends on the specific cryptographic properties being intact. Weakening the definition weakens everything the definition unlocks.

Where does the distinction actually matter operationally?

Three deployment scenarios where the distinction is not academic. First — compliance policies that require a specific class. A Copenhagen bank's compliance team came to us last quarter because their policy for outbound counterparty-onboarding documents required "digital signature" and their existing e-signing platform was returning a mix of typed-name captures and PKI-based signatures depending on which counterparty was signing. Only some of the returned documents actually met the policy. The remediation was not a policy amendment — it was reconfiguring the signing flow to require a specific AdES-strength envelope on every outbound instance. The distinction between electronic and digital, at their policy level, was the difference between a document that satisfied compliance review and one that would be flagged.

Second — evidentiary weight in a dispute. A signed document containing only a click-acceptance capture is an electronic signature. In an EU court under eIDAS, that document is admissible under Article 25(1) — no denial of legal effect solely because it is electronic. But it does not receive the burden-reversal effect of Article 25(2), which is reserved for Qualified Electronic Signatures produced against an EU-listed QTSP. If the signer denies the click, the party trying to rely on the signature must independently prove attribution. If the same document had been signed with an AdES-strength digital signature over the equivalent hash, the party relying on the signature could produce cryptographic evidence that mathematically ties the signature to a specific private-key holder and a specific document instance — a substantially stronger evidentiary posture, walked in more detail in What Happens if Someone Denies They Signed Digitally?.

Third — cross-border recognition. A Vienna-based e-signing platform serving customers in Frankfurt, Milan, and Warsaw has to produce signatures that satisfy AdES criteria in each of those jurisdictions to preserve consistent evidentiary weight when a document crosses jurisdictions. A typed-name capture that is legally sufficient for many contract types in a party-autonomy jurisdiction is not sufficient for many document classes in a tier-based jurisdiction. If the platform captures both — electronic-only for some flows and digital for others — and does not label the two consistently at the interface layer, the customer's downstream compliance team ends up doing the classification manually, and manual classification at that layer is where audit findings appear.

My take on where teams get this wrong most often: they conflate the two categories in product copy — advertising "digital signatures" for what is technically an electronic-signature capture — because it sounds more secure and because the legal-definition layer does not force them to be precise. That works commercially until a compliance review, a court challenge, or a cross-border deployment forces the distinction to surface. At that point the cleanup cost is high. Getting the taxonomy right at product-copy time is cheaper than getting it right at incident-response time.

How does chip-anchored identity change what either type is worth?

Both categories inherit an implicit identity-proofing requirement. eIDAS calls it "reliable methods for identity verification." ESIGN calls it "attribution by any means available." Every framework I named in Digital Signature Laws by Country carries the same implicit demand under its own vocabulary. What differs is what evidence the deployment can produce at challenge time.

For an electronic signature that is not cryptographic — a click, a typed name, a scanned image — the attribution evidence typically consists of session logs, authentication events, IP address, device fingerprint, and the surrounding audit trail. Those artefacts are useful in dispute, but they are all platform-produced — the platform vouches for them. If the platform's identity-proofing at account-creation time was weak, the entire attribution chain is anchored on that weak point.

For a digital signature, the attribution evidence is cryptographic — the signature can be verified independently of any platform's assertion. But the certificate that binds the private key to a person still had to be issued to someone, and the person the certificate was issued to still had to be identity-proofed at some prior moment. If that proofing was based on a scanned identity document without liveness verification, the cryptographic strength of the signature does not compensate — the weak proofing propagates all the way through to the signature's evidentiary posture at challenge time.

This is why the load-bearing layer, under both electronic and digital signatures, is the identity-proofing primitive. ICAO Doc 9303 chip-anchored proofing — passport-NFC read plus live biometric face match against the on-chip portrait, verifiable against the ICAO Public Key Directory — currently covers 179 countries and produces evidence that no commercial party controls. Every other country reduces cleanly to a document-plus-face-match capture with the same audit-defensible structure. That is the layer IdentiGate builds on, and it is what makes our signature products and evidence layer carry the same defensible attribution regardless of whether the deployment surfaces an electronic or a digital signature at the interface layer. Get the identity primitive right and the taxonomy above it becomes an implementation decision. Get it wrong and no cryptographic wrapper above it can save the challenge.

The Prague procurement director's rejection stood, and the supplier resubmitted with an AdES-envelope PAdES signature over the same document. Not because the original mark was legally invalid — it was an electronic signature and it was admissible — but because the procurement policy was drafted to require the narrower cryptographic subset, and the narrower subset is what unlocks the evidentiary posture the policy was written to produce. That is the distinction, and it is the distinction that keeps the two words from being interchangeable in any environment where the evidence matters.

Sources

Legal frameworks — definitions

Cryptographic primitives

AdES envelopes

Identity + assurance standards

About the author

Gustav Poola is a co-founder of IdentiGate, a European identity-verification and digital-signature company building on top of chip-anchored identity-proofing (ICAO 9303 passport NFC), Advanced Electronic Signatures (eIDAS Article 26), and Advanced Electronic Seals. He works on the architecture side — deployment patterns for cross-border teams in logistics, healthcare, fintech, HR-tech, defence, and cybersecurity — and writes about the intersection of cryptographic primitives, standards, and the practical decisions engineering and product teams have to make together.

The words we use in digital identity are load-bearing. Use the wrong one and the listener walks confidently down the wrong road — and in identity, security, and compliance, most of our everyday words send people the wrong way. This is the eleven-point vocabulary repair kit for anyone building identity infrastructure: data vs information, trust vs proof, authentication vs identity, permission vs authority, compliance vs evidence, disclosure vs predicate. If our language keeps reaching for words that can't be measured, are we building resilience — or performing security?

You verify the passport chip — remotely, in ninety seconds, with cryptographic evidence signed by the state that issued the document. The engineering answer for a remote-hire identity check without an in-person meeting is chip-anchored NFC read plus biometric face-match against the chip photo, wrapped in an AdES record retained under a Long-Term Validity envelope. This post walks the pattern for full-time employment remote hires (distinct from gig workers and contractor-of-record engagements), the four questions the pattern actually answers, and where the picture is genuinely harder than the identity layer alone.

Multi-party document signing takes one of two shapes — sequential (party A signs, then B, then C, each signature depending on the previous one) or parallel (all parties sign the same document independently, with an aggregator collecting and combining the signatures). Both are supported cleanly by the eIDAS AdES formats (PAdES, XAdES, CAdES) but the cryptographic semantics, the timestamp coordination, and the LTV envelope requirements differ meaningfully between them. This post walks the two patterns, when to use each, and what tends to break when the pattern is chosen wrong for the workflow.