Practice with national-level exam (FACT, FACT Plus, NET, CUET, etc.) mocks, learn from structured notes, and get your doubts solved in one place.
The legal and technical landscape of electronic signatures across the major jurisdictions: India's Aadhaar e-Sign and the IT Act 2000 s.3A digital-signature provisions, the EU eIDAS regulation's three signature tiers (simple electronic, advanced electronic, qualified electronic) and the Trust Service Provider model, the US ESIGN Act 2000 and UETA, the UK Electronic Communications Act 2000, the PKI infrastructure (certificate authorities, OCSP and CRL revocation checking, hash algorithms) the digital signatures rest on, and the verification workflow a forensic examiner runs on a contested signed document.
Last updated:
The forensic examination of electronic signatures is one of the most jurisdiction-sensitive areas in questioned document work, because the legal weight of a signature depends entirely on which statutory framework the jurisdiction applies, which tier of electronic signature the document claims, and whether the technical implementation of that signature matches the requirements of the claimed tier. A simple electronic signature (a typed name at the bottom of an email, a scanned ink signature pasted into a PDF) is legally valid in many contexts under US UETA and UK Electronic Communications Act 2000, but it provides almost no cryptographic assurance. A qualified electronic signature under EU eIDAS Regulation 910/2014, by contrast, must be backed by a qualified certificate issued by a Trust Service Provider on the EU Trusted List and must be created by a qualified signature creation device (QSCD) in hardware. These two signature types are worlds apart technically, but both may be called "electronic signatures" in everyday commercial correspondence.
Three signature families dominate international contested-document casework: the Aadhaar e-Sign framework used in India (with its distinctive Aadhaar authentication step and the role of the Controller of Certifying Authorities); the eIDAS three-tier system governing EU member states; and the ESIGN Act plus UETA framework governing US electronic commerce, alongside the UK's Electronic Communications Act 2000 which survived Brexit and continues to govern UK electronic signature validity. Understanding all four is essential for any examiner who works in a jurisdiction that receives commercial documents, contracts, or official records from international counterparties.
Every jurisdiction's electronic signature framework rests on the same cryptographic substrate: asymmetric key pairs, X.509 certificates, and a chain of trust from the signer to a root that both parties agree to trust.
Public Key Infrastructure (PKI) is the cryptographic architecture that makes digitally verifiable electronic signatures possible. The core concept is asymmetric cryptography: each participant in the system holds a key pair consisting of a private key (kept secret, used to sign) and a public key (distributed widely, used to verify). A signature is created by computing a cryptographic hash of the document being signed (SHA-256 or SHA-384 in current best practice; SHA-1 is deprecated for new signatures across all major frameworks) and encrypting that hash with the signer's private key. The resulting ciphertext is the signature. Any recipient who holds the signer's public key can decrypt the ciphertext, compare the decrypted hash with a freshly computed hash of the received document, and verify that the document has not been altered since signing.
The problem PKI solves is not the cryptographic operation but the identity binding: how does the verifier know that the public key they hold actually belongs to the claimed signer, rather than to an attacker who has substituted their own key? The answer is the X.509 digital certificate: a data structure that binds a public key to a named identity (the subject) and is itself signed by a Certificate Authority (CA). The CA's own certificate is either self-signed (a root CA) or signed by a higher CA (an intermediate CA). The resulting chain from the signer's certificate up through intermediate CAs to a root CA is the certificate chain. A verifier who trusts the root CA (because it is pre-installed in their operating system's trust store, or is on a government-mandated trusted list) can verify every link in the chain.
Hash algorithm choice matters forensically. SHA-1 collision attacks were practically demonstrated in 2017 (the SHAttered attack, CWI Amsterdam and Google Research). Documents signed with SHA-1 certificates before 2016 were issued in a context where SHA-1 was still widely considered acceptable, but signatures on documents claimed to be from before 2010 that use SHA-256 may be anachronistic if the claimed authoring application did not support SHA-256 at that date. NIST deprecated SHA-1 for digital signatures in FIPS 186-4 (2013). The CA/Browser Forum required all publicly trusted CAs to stop issuing SHA-1 certificates after January 2016. The examiner should verify that the hash algorithm used in each certificate in the chain is consistent with the claimed issuance date.
Revocation is the mechanism by which a CA declares that a certificate is no longer valid before its scheduled expiry date (typically because the private key was compromised, or the certificate was issued incorrectly). Two revocation mechanisms exist. The Certificate Revocation List (CRL) is a signed list of revoked certificate serial numbers published by the CA at a URL embedded in the certificate's CRL Distribution Points extension; verifiers download the CRL and check whether the certificate's serial number appears. The Online Certificate Status Protocol (OCSP) is a real-time query protocol in which the verifier sends the certificate's serial number to the CA's OCSP responder and receives a signed "good", "revoked", or "unknown" response. In PDF signature contexts, OCSP stapling embeds the OCSP response alongside the signature at signing time, preserving the revocation status as of the signing date even if the OCSP responder is later taken offline.
India's Aadhaar e-Sign is not merely an electronic signature; it is an authentication-linked signature that ties every signing event to a biometric identity verification, making mass issuance of fraudulent signatures fundamentally harder but introducing its own forensic complexity.
India's foundational electronic signature legislation is the Information Technology Act 2000, which established the concept of the digital signature (section 3, using asymmetric cryptography and a hash function) and the electronic signature (section 3A, introduced by the IT Amendment Act 2008, which broadened the definition to include any technique that is reliable and appropriate for the purpose). The Controller of Certifying Authorities (CCA), operating under the Ministry of Electronics and Information Technology (MeitY), is the root trust anchor for India's PKI hierarchy and maintains the National Repository of Digital Certificates (NRDC).
Aadhaar e-Sign is a specific electronic signature service authorised under the UIDAI (Unique Identification Authority of India) framework and the Electronic Signature or Electronic Authentication Technique and Procedure Rules, 2015. The workflow is as follows: the user is authenticated by their Aadhaar number and either a biometric (fingerprint or iris scan) or an OTP (one-time password sent to the Aadhaar-registered mobile number); upon successful authentication, UIDAI's Aadhaar Signing Service (ASP and ESP, Application Service Provider and e-Sign Service Provider) generates a temporary signing key pair on behalf of the user, obtains a short-validity certificate (typically valid for 30 minutes) from a licensed Certifying Authority, signs the document with the temporary private key, and immediately discards the private key. The resulting signature is backed by a CA certificate whose subject identity is drawn directly from the UIDAI's Aadhaar database.
The forensic significance of this architecture is substantial. First, the signature certificate's subject name and Aadhaar identity are bound at the time of each signature event, not at a one-time certificate issuance; the signer cannot deny awareness of the specific signing event. Second, the UIDAI logs each signing transaction (date, time, document hash, Aadhaar number) with a retention period sufficient for evidentiary access under court order. Third, the short certificate validity means that an Aadhaar e-Sign certificate presented for verification will always show as expired when verified without a trust anchor configured to accept historical OCSP staples or long-term validation (LTV) data embedded at signing time. The examiner must understand LTV validation and the role of archived OCSP responses to correctly verify older Aadhaar e-Sign documents.
In the Bharatiya Sakshya Adhiniyam (BSA) 2023 (which replaced the Indian Evidence Act 1872), electronic records and electronic signatures are addressed in sections 57 to 59. Section 63 of the BSA provides for the admissibility of electronic records in evidence subject to an electronic record certificate (the former section 65B certificate under the Indian Evidence Act). Courts have interpreted the Supreme Court's ruling in Arjun Panditrao Khotkar v. Kailash Kushanrao Gorantyal (2020) as requiring the person producing the certificate to be able to speak to the electronic record's integrity, which the Aadhaar e-Sign log and the LTV-embedded OCSP response together support.
eIDAS is the most architecturally rigorous electronic signature framework in the world, because it legally mandates which technical controls must be in place before a signature achieves qualified status.
EU Regulation 910/2014 (eIDAS) establishes three tiers of electronic signature, each with distinct technical requirements and legal effects. The Simple Electronic Signature (SES) is any data in electronic form that is attached to or logically associated with other data, and that the signatory uses to sign. A scanned handwritten signature, a typed name, a click-wrap agreement checkbox: all qualify as SES. SES carries no cryptographic assurance; its legal weight depends entirely on context and the broader evidentiary record.
The Advanced Electronic Signature (AdES) must meet four requirements under eIDAS Article 26: it is uniquely linked to the signatory; it is capable of identifying the signatory; it is created using electronic signature creation data (the private key) that the signatory can use with a high level of confidence under their sole control; and it is linked to the signed data in such a way that any subsequent change in the data is detectable. In practice, an AdES is implemented via a PKI signature with an appropriate certificate, but the certificate does not need to be a qualified certificate from the Trusted List. Most commercial electronic signature platforms (DocuSign, Adobe Sign, Skribble, SignNow) issue signatures at the AdES level in EU deployments.
The Qualified Electronic Signature (QES) carries the highest technical bar and the most significant legal effect. Under eIDAS Article 25(2), a QES has the equivalent legal effect of a handwritten signature across all EU member states. A QES must: be created by a Qualified Signature Creation Device (QSCD); be backed by a qualified certificate issued by a Trust Service Provider (TSP) on the EU Trusted List; and include a timestamp from a qualified timestamping authority on the Trusted List. A QSCD is a hardware or software device (most commonly a hardware security module, a USB token such as SafeNet eToken, or a remote HSM operated by the TSP) that stores the private key such that it cannot be extracted, ensuring that the key is under the sole control of the signatory.
The EU Trusted List (the EUTL, maintained by the European Commission at the esignature.europa.eu portal) lists all TSPs per member state that are permitted to issue qualified certificates or provide qualified timestamping. An examiner verifying a claimed QES must confirm that the issuing CA appears on the EUTL as a qualified TSP for the relevant service type at the claimed signing date: TSPs can be added to or removed from the list, and a certificate issued by a TSP after its removal from the list does not carry QES status.
| Tier | Technical basis | Certificate required | Legal effect (EU) | Typical use |
|---|---|---|---|---|
| Simple Electronic Signature (SES) | Any data linked to signature act (typed name, click, image) | None required | Not equivalent to handwritten; admissible but weight depends on context | Consumer click-wrap, email sign-off, informal commercial agreements |
| Advanced Electronic Signature (AdES) | Asymmetric cryptography; detectable alteration post-signing; key under signatory's sole control | Any PKI certificate; not required to be qualified | Admissible; weight depends on certificate quality and context | Commercial contracts, regulated documents in many member states |
| Qualified Electronic Signature (QES) | AdES requirements plus QSCD for key storage plus qualified certificate from EUTL TSP |
US law takes a technology-neutral, intent-based approach to electronic signatures: if the parties intended to sign, the method used is largely secondary.
The Electronic Signatures in Global and National Commerce Act (ESIGN Act, 15 U.S.C. § 7001 et seq.) was enacted in 2000 and established a federal baseline: no electronic signature may be denied legal effect solely because it is in electronic form. The Uniform Electronic Transactions Act (UETA), adopted in its model form by 49 US states and the District of Columbia (New York uses its own Electronic Signatures and Records Act, ESRA), provides the state-level parallel: an electronic record or electronic signature satisfies a requirement for a signature under applicable state law.
Neither ESIGN nor UETA mandates any specific technology. A handwritten signature on a tablet, a biometric voice signature, an asymmetric-key digital signature, a shared-secret OTP confirmation: all can constitute valid electronic signatures under ESIGN/UETA, provided the parties have agreed to transact electronically and the signer has demonstrated intent to sign. This technology-neutral approach differs substantially from eIDAS, which creates distinct legal tiers by technology type. The forensic consequence is that a US examiner investigating a contested electronic signature must evaluate: the evidence of the signatory's intent (click-to-agree logs, audit trails, email chains); the integrity of the document from the time of signing (hash logs, audit trail hashes); and the reliability of the electronic signature system's own record-keeping.
Commercial electronic signature platforms operating in the US market (DocuSign, Adobe Acrobat Sign, HelloSign, PandaDoc) maintain detailed audit trails including: the signatory's IP address, geolocation, device fingerprint (user-agent string), email address used for notification, timestamp of each signing event, and a hash of the signed document at the time of signing. These audit trails are themselves electronic records subject to the same evidence admissibility rules and are a primary forensic resource in contested-signature litigation. In federal court, ESIGN audit trail evidence is typically introduced under Federal Rule of Evidence 803(6) (records of a regularly conducted activity) through a qualified witness from the platform provider.
Courts have generally accepted electronic signature audit trails as reliable. In Nortek Controls Corp. v. Acuity Brands Inc. (US District Court, N.D. Cal., 2019), the court accepted a DocuSign audit trail as establishing that the signatory had electronically signed the document at the claimed time. In Phison Electronics Corp. v. Kingston Technology Co. (C.D. Cal., 2017), the court examined the authenticity of an electronically signed NDA. In the UK, the Law Commission's 2019 report "Electronic Execution of Documents" confirmed that ESIGN-equivalent simple electronic signatures satisfy UK law requirements in most commercial contexts under the Electronic Communications Act 2000, provided the parties intended to be bound.
The UK's electronic signature framework survived Brexit largely intact, but eIDAS mutual recognition no longer applies, creating a fragmentation problem for cross-border documents involving both UK and EU parties.
The Electronic Communications Act 2000 (ECA 2000) is the primary UK legislation governing electronic signatures. Section 7 provides that electronic signatures are admissible in evidence in relation to any question as to the authenticity or integrity of a communication or data, and section 7(2) defines an electronic signature as anything in electronic form that is incorporated or logically associated with the electronic communication and purports to be used to authenticate the communication. This definition is functionally equivalent to eIDAS SES and ESIGN Act definitions: broad, technology-neutral, and focused on intent to authenticate rather than technical method.
Following the UK's departure from the EU, the eIDAS Regulation was retained in UK domestic law as "UK eIDAS" by the European Union (Withdrawal) Act 2018, but mutual recognition of EU qualified signatures and EU Trusted List TSPs no longer operates automatically. A qualified electronic signature issued by an EU TSP on the EU Trusted List is not automatically recognised as a QES for UK legal purposes post-Brexit; the UK's own Conformity Assessment Bodies and TSP framework (operated under the DCMS and the National Cyber Security Centre, NCSC) apply independently. The Law Commission's 2019 report and subsequent consultations have confirmed that the UK does not intend to legislate a tiered QES regime equivalent to eIDAS; the broad ECA 2000 approach continues to apply.
For forensic examiners handling documents that have crossed between EU and UK jurisdictions, the key practical implication is that a QES under EU eIDAS may need to be presented to a UK court via expert evidence establishing its technical validity, rather than relying on automatic statutory equivalence. Similarly, a UK electronic signature does not automatically carry QES status in an EU member state court. In practice, most high-value cross-border contracts use platforms certified under both the EU Trusted List and the UK CAB framework, or fall back to wet-ink signatures for documents where QES equivalence is legally material.
Verification is not a single step. It is a four-layer audit: the document's structural integrity, the cryptographic signature, the certificate chain, and the revocation status as of the signing date.
The examiner workflow for a contested electronically signed document proceeds through four layers that must be addressed in sequence, because failures at a lower layer affect the interpretation of findings at higher layers.
The first layer is document integrity: has the document been altered since it was signed? For cryptographically signed documents (PDF with PKCS#7 signature, XML with XMLDSig, CMS-signed email), the hash verification at this layer is deterministic: re-compute the hash over the ByteRange or the canonicalised XML, compare with the decrypted signature value. For non-cryptographically signed documents (ESIGN audit trail-based signatures), this layer requires obtaining the platform's tamper-evident audit log and the hash of the document as recorded at signing time.
The second layer is certificate chain verification: is the signer's certificate validly issued by a CA that the applicable jurisdiction trusts? This requires traversing the full certificate chain (end-entity, intermediates, root) and verifying that each certificate was signed by its issuer, that no certificate was expired at the time of signing, and that the root CA is on the appropriate trust list (Windows root store, Mozilla NSS, Apple Trust Store, the EU Trusted List, India's NTR operated by the CCA, or a jurisdiction-specific equivalent).
The third layer is revocation status at signing time: was the certificate revoked before the document was signed? For OCSP, this requires either a stapled OCSP response embedded in the signature (verifiable without network access) or access to archived OCSP responses from the CA or a trusted OCSP archiver. For CRL-based systems, the relevant CRL as of the signing date must be retrieved. In long-term archival contexts (documents signed years before the examination), the examiner must rely on LTV (Long-Term Validation) data embedded at signing time under the PAdES-LTV profile (ETSI EN 319 102-1) or equivalent.
The fourth layer is timestamp authenticity: does the embedded timestamp from the TSA accurately record the signing time? The TSA timestamp is itself a cryptographic structure: the TSA signs a hash of the signature value and a time value using its own certificate, which must also be verified against a trusted root. The TSA timestamp is the primary evidence for the signing time and takes precedence over the document's EXIF creation date, the PDF information dictionary's ModDate field, and any other metadata that is not cryptographically protected.
Under EU eIDAS Regulation 910/2014, which of the following is the minimum technical requirement that distinguishes an Advanced Electronic Signature (AdES) from a Simple Electronic Signature (SES)?
Test yourself on Questioned Document with free, timed mocks.
Practice Questioned Document questions| Qualified certificate from Trusted List TSP mandatory |
| Legally equivalent to handwritten signature in all EU member states |
| Notarial acts, real estate transactions, regulated financial contracts |