Do Digital Signatures Require Proof of Identity?

July 14, 2026 ·Mairi Kutberg ·

proof-of-identitydigital-signatureadeseidasidentity-proofingglobal-digital-identitytrust-service-providernist-sp-800-63authenticationsignature-validity

Yes — and the proof requirement scales with the legal tier. Simple Electronic Signatures need no formal proofing. Advanced Electronic Signatures (AdES) under eIDAS Article 26 must be uniquely linked to a verifiably identified signer. Qualified Electronic Signatures require identity proofing by a Qualified Trust Service Provider before certificate issuance. The gap most platforms hit is between having a certificate and the certificate being bound to a globally verifiable person.

Do Digital Signatures Require Proof of Identity?

From the compliance desk, the proof-of-identity question lands on the engineering team a couple of weeks after the signing flow goes live. A Hamburg-based cross-border logistics integrator we worked with last quarter had passed every technical check the AdES vendor put in front of them — and then their first eIDAS audit returned a finding that the signing certificates were not "uniquely linked to the signer and capable of identifying them" under Article 26(1)(a). The cryptographic chain was clean. The certificates were issued by a recognised CA. What was missing was the bit before the certificate was issued: nobody had actually proofed the identity of the people behind the keys. The audit finding was not about the signature; it was about everything that should have happened upstream.

What does eIDAS actually require for proof of identity in a signature?

Different things for different tiers — and the answer is more specific than the regulation's reputation for being abstract.

Regulation (EU) 910/2014 (eIDAS), updated by Regulation (EU) 2024/1183 (eIDAS 2.0), sets a three-tier hierarchy of electronic signatures. Each tier has a different proof-of-identity requirement, and the requirements get progressively stricter as the tier rises.

A Simple Electronic Signature (SES) — Article 3(10) — is "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." That definition does not require any formal proof of identity at the signing step. A typed name at the bottom of an email, a checkbox indicating agreement, or a hand-drawn squiggle on a tablet all qualify. The reason these can still be legally relevant under Article 25 of eIDAS — the non-discrimination principle — is that the law refuses to deny admissibility purely because the signature is electronic, not because the signature carries any identity-proofing guarantee.

An Advanced Electronic Signature (AdES) — Article 26 — has to meet four cumulative requirements, and two of them speak directly to proof of identity. The signature must be: (a) uniquely linked to the signatory; (b) capable of identifying the signatory; (c) created using signature-creation data the signatory can use under their sole control; (d) linked to the signed data in a way that any subsequent change is detectable. Conditions (a) and (b) are the proof-of-identity clauses. The signature must be cryptographically bound to that specific person, and the verifier must be able to establish who that person is from the signature. A signing certificate issued without identity proofing fails both. A signing certificate issued with self-declared identity claims meets the letter only weakly — it identifies a name, not the person.

A Qualified Electronic Signature (QES) — Article 25(2) — has the equivalent legal effect of a handwritten signature across the EU. The proof-of-identity requirement here is the strictest. Under Article 24 of eIDAS, a Qualified Trust Service Provider issuing the qualified certificate must verify the applicant's identity through one of the following: physical presence, eID schemes notified under eIDAS that produce at least substantial assurance level, qualified certificates issued previously, or methods recognised at national level as providing equivalent assurance. The proofing is not optional and not the signing platform's responsibility — it is the QTSP's, and it happens before the certificate is issued. The signing event itself then carries the QTSP's proofing as its identity anchor.

The honest read is that the law's distinction between AdES and QES is largely about who does the proofing and at what assurance level. The cryptographic primitive at signing time is similar; the difference is the evidentiary chain that the certificate brings to the signature.

Where do most signing platforms fall short on identity proofing?

At the step before the certificate is issued — the part of the workflow that's invisible to the integrator and frequently outsourced to the certificate vendor without explicit assurance-level commitments.

The pattern I see in audits across 2025 and 2026 is consistent. The signing platform integrates an AdES library. The library calls out to a Certificate Authority for signing certificates. The CA's certificate request process collects the signer's name, email, and sometimes a phone number for an SMS one-time-password challenge. The certificate is issued. The signature is technically valid. The proof-of-identity question gets answered with "the signer entered their email and confirmed an OTP" — and that's the proofing claim that has to hold up at audit.

That proofing claim is roughly equivalent to NIST IAL1 under NIST SP 800-63-4 (May 2025 draft) — minimal assurance, suitable for low-risk personal accounts but not for regulated signing. The eIDAS Article 26 language "uniquely linked to the signatory" and "capable of identifying the signatory" reads as IAL2 at minimum; the ETSI EN 319 411-1 Trust Service Provider requirements for issuance of certificates expect proofing to meet specific identity-verification policies. The gap is real, and audit findings against it are getting more common as enforcement matures.

A São Paulo-headquartered fintech platform we worked with in the spring of 2026 went through this exact discovery. Their European operations had used a vendor-supplied "AdES out of the box" flow for 18 months. Their first cross-border audit by a Portuguese regulator returned a finding that the identity-proofing evidence supporting the signing certificates was self-declared, not independently verified, and that the platform had no retained evidence chain demonstrating how each signing user's identity had been established before certificate issuance. The technical signing chain passed every machine check. The regulatory finding was about the layer above the chain: the proof-of-identity primitive.

The thing nobody says out loud in the platform-vendor marketing is that "AdES-compliant" describes a single property. It doesn't. The cryptographic primitive can be AdES-compliant while the upstream proofing is not — and audit findings catch the gap.

What does a defensible proof-of-identity chain look like in 2026?

An identity-proofing event at IAL2 or higher, retained as evidence, cryptographically anchored to the signing certificate, and presentable on demand to a verifier or auditor walking the chain backward from the signature.

The reference framework for the proofing event itself is NIST SP 800-63A (and the current SP 800-63-4 revision), which defines Identity Assurance Levels 1-3. IAL2 — the practical baseline for regulated signing — requires evidence-based identity verification: a government-issued document (passport, national identity card, driving licence with photo) verified for authenticity, plus binding of the document to the person presenting it (typically a biometric face match against the document's photograph). IAL3 raises the bar to in-person or supervised remote proofing with multiple strong pieces of evidence and biometric capture under controlled conditions.

The most defensible implementation in 2026 — the one that survives audits and translates across borders — is a chip-anchored proofing event. The biometric passports issued by all 179 ICAO 9303 countries carry a contactless chip containing the document data and the holder's biometric, signed by the issuing state's Country Signing Certificate Authority and verifiable offline against the ICAO Public Key Directory. Reading that chip and verifying its signature is a cryptographic operation; combining it with a biometric face match between the holder and the chip's stored biometric closes the document-to-person binding. The result is an identity-proofing record that is independently verifiable by any party who can validate the ICAO 9303 chain — which is every regulator inside the EU and most outside.

For countries whose documents do not carry an ICAO 9303 chip — older national IDs, certain travel documents, the small set of remaining cases — the equivalent IAL2 path is document authenticity verification (security feature checks, optical anti-fraud signals, MRZ consistency) combined with biometric face match against the document photo using a NIST IBPC-tested liveness algorithm. Both paths produce an evidence record that anchors the signing certificate's identity claim in a verifiable proofing event. Both paths are what we walked through in our earlier post on how doctor identity moves across EU borders and what the validation chain consumes in our verify-signature procedure post at stage 2 (certificate chain resolution).

The retention layer matters as much as the proofing event. The AdES record produced at signing time carries the signature; the proofing record produced at certificate issuance time carries the identity evidence. The two are linked by the certificate fingerprint. Auditing at month forty-eight requires both records to still be retrievable in a form the verifier can read — which is what makes PAdES-LTA / XAdES-A / CAdES-LTA long-term validation wrappers and a retained proofing evidence chain inseparable parts of the same defensibility story.

How does IdentiGate's identity primitive fit AdES?

At the foundation layer that produces the proofing evidence the AdES record relies on — and at the scale that makes global signing flows actually defensible across borders.

This is the layer the platform vendor's "AdES out of the box" pitch tends to gloss over, and where the audit findings consistently land. The IdentiGate Identity Verification product ships the chip-anchored proofing primitive itself: passport NFC chip read for the 179 ICAO 9303 countries, or document authenticity plus biometric face match for every remaining country, producing an AdES-bound proofing record under eIDAS Article 26. The proofing event lifts a signing certificate's identity claim from self-declared to IAL2 evidence-based. For the cross-border use cases that touch AMLR 2024/1624 identity obligations (10 July 2027 application), eFTI Article 5 road transport signing (9 July 2027), NIS2 Article 21 staff identity evidence, and EHDS patient and clinician verification, the proofing event is the audit anchor that survives walk-back at month 48.

The Signatures product produces the AdES signature itself, bound to the proofing record. The Evidence Layer product retains both records together — proofing event, signature, and the validation data behind both — in a form that a verifier in 2030 can read and validate. That is the chain a defensible audit needs: globally proofed identity at the foundation, AdES-bound signature at the signing layer, retained evidence wrapper for the long term.

If you sit on the procurement or compliance side, three questions are worth asking the integrator before assuming an AdES integration is audit-ready. What identity-proofing event sits behind each signing certificate? What assurance level does it meet? What evidence record demonstrates the proofing, and where is it retained? If the answers are "OTP", "IAL1", and "the certificate's CA might still have it" — the chain is fragile and audit findings will catch it. If the answers are "chip-anchored proofing event under ICAO 9303 plus biometric match", "IAL2 evidence-based", and "AdES-bound evidence record retained alongside the signature" — the chain is what a regulator can actually walk through and what a global signing operation can defend. That is what we ship, and it is the difference between an AdES integration that ticks a procurement box and one that survives the regulator's question at month forty-eight.

Sources

Primary — eIDAS and signature framework

Primary — ETSI signature and TSP standards

Primary — NIST identity assurance

Primary — ICAO document standards

Primary — adjacent EU regulatory framework

About the author

Mairi Kutberg is co-founder of IdentiGate. She focuses on identity-proofing operations under eIDAS, NIS2, AMLR, the AI Act, the EHDS, and adjacent regulatory frameworks, and on the institutional reality of running cross-border identity verification at scale.

The signature carries the burden of proof — but the burden falls back on whoever relied on it if the evidence chain behind the signature isn't complete. Under eIDAS Article 25(2), Qualified Electronic Signatures presume authenticity unless the challenger rebuts it. For Advanced signatures, the party asserting the signature has to demonstrate identity binding, integrity, and time — and courts have been consistent since 2020 that thin proofing evidence loses the case.

Strictly speaking, digital signatures don't encrypt anything — they use asymmetric cryptography to sign a hash of the data. The signer's private key transforms the hash into a signature; the corresponding public key verifies it. In 2026 production: RSA-PSS with SHA-256 (RFC 8017), ECDSA over P-256 or P-384 (RFC 6979), and Ed25519 (RFC 8032). ETSI TS 119 312 sets which cryptographic suites are acceptable for AdES, and the post-quantum migration is starting to reshape the algorithm shortlist through 2030.

Three things stacked in the right order under eIDAS Article 25: non-discrimination in principle for any electronic signature, equivalence to a handwritten signature only for Qualified Electronic Signatures under Article 25(2), and successful validation under the Article 32 procedure. The gap that costs cases in court is between 'the signature exists' and 'the signature validates against Article 32 requirements' — and the identity-proofing under the signing certificate is where most legal-validity claims quietly break.