What “tamper-evident” actually proves — and what it doesn’t

A tamper-evident eSignature puts a cryptographic hash of the document inside the signed PDF. If anyone alters the document after signing — a date, a number, a single comma — the hash stops matching, and any PDF validator will flag the document as modified. That is a useful and specific property. It is not, however, the same as legally valid.

The distance between those two terms is where most confusion about eSignatures lives. This article draws the line precisely.

What a tamper-evident eSignature actually means

At the moment a PDF is signed, the signing software computes a hash of the document’s contents and embeds that hash inside the signature block. The hash is a fixed-length fingerprint: change one byte of the underlying document and the fingerprint changes entirely.

This protects against a specific threat: a counterparty quietly editing a PDF after you sent it, then denying any change occurred. A tamper-evident signature makes that undetectable alteration impossible. If the document was changed, the hash will not verify.

What the hash does not tell you is anything about the person who applied the signature. It verifies content. It says nothing about identity, authentication, or authority.

What Section 3A of the IT Act actually requires

Section 3A of the Information Technology Act, 2000 (as amended in 2008) sets out the conditions under which an electronic signature is legally recognised in India. Three conditions apply:

1. The signing method must be unique to the signatory.
2. The method must be capable of identifying that signatory.
3. The signatory must have had sole control of the signing data at the time of signing.

A PDF hash satisfies none of these. It verifies content integrity. The three Section 3A conditions speak to identity and control over the signing process itself.

This distinction matters in practice. A document with a valid tamper-evident hash and no associated authentication record is, from a legal-evidence standpoint, a document that proves its own content is intact but cannot prove who put the signature there.

The three things an audit trail proves that a PDF hash doesn’t

The hash tells you the document was not changed. An audit trail tells you who signed, when, what they saw, and how their identity was confirmed. For a dispute, you typically need all four.

A complete audit trail from a well-built eSignature platform captures:

• Signer identification: the name, email, and phone used to invite the signer, plus any identity verification step performed.
• Authentication event log: the timestamp of the OTP sent and confirmed, the IP address, and the device fingerprint at the moment of signing.
• Document hash at signing: the exact hash of the document at the moment each signature was applied, recorded independently in the audit log.
• Access log: when each recipient opened the document and which version they viewed before signing.

A signed PDF’s signature block contains the hash. It does not contain the access log, the OTP event record, or the signer’s contact details. Those live in the audit trail that a proper eSignature platform generates and retains alongside the document.

If you only have the signed PDF and no audit trail, you can prove the document was not altered. You cannot prove the named signer was the person who applied the signature.

Why authentication evidence carries more weight than most people expect

A paper contract signed by Priya Sharma is presumed authentic unless someone contests it. In a dispute, the burden shifts to the contesting party. Electronic signatures work the same way in principle, but courts examining contested eSignatures look carefully at how the signing platform can prove the signatory’s identity.

If the signature was applied via Aadhaar eSign, you have an OTP event tied to a specific Aadhaar number. The UIDAI authentication response — a signed XML the eSign provider receives at the time of signing — becomes part of your evidentiary record. That is a specific and traceable authentication chain.

If the signature was applied via a plain email-click mechanism with no identity step, the audit trail shows that someone with access to [email protected] clicked sign. Whether that was Priya, a colleague who borrowed her session, or an attacker who intercepted a link is something the document alone cannot establish.

Both documents can have a valid PDF hash. Neither is more or less tamper-evident than the other. The difference is the weight of identity evidence sitting behind the signature event.

What “legally valid” requires, end to end

For a signed document to be enforceable under Indian law, three things need to be in place simultaneously:

1. Content integrity: the PDF hash establishes this. A tamper-evident signature covers this requirement.
2. Signer authentication: the signing method must reliably identify the signatory, and an audit trail must capture that authentication event. Aadhaar eSign and DSC-based signatures cover this. Plain email-click signatures carry weaker evidence here.
3. Authorisation: the signatory must have had authority to sign on behalf of the entity named in the document. No eSignature platform solves this for you. A well-drafted document that names the signatory’s designation and signing authority, combined with an internal authorisation record, is your protection here.

Most disputes over electronic signatures in Indian court proceedings have turned on authorisation, not integrity or authentication. A company director signing a contract binds the company. An employee who happened to have access to a signing link may not. The tamper-evident hash is not the variable in that question.

A practical checklist before you rely on a signed document

If you want a signed document to hold up in a dispute 18 months from now, these are the questions worth asking today:

• Can you retrieve and re-verify the document hash against the signed PDF independently of the signing platform?
• Does the audit trail capture the authentication method used for each signatory, including any OTP or certificate event?
• If Aadhaar eSign was used, is the UIDAI authentication response retained as part of the document record?
• Does the document itself state the signatory’s designation and their authority to sign on behalf of the contracting entity?
• Does your document retention policy cover the signed PDF and the audit trail together? The audit trail is not useful if you cannot locate it when you need it.
• Was the document content finalised before signing was initiated? Some platforms permit template substitutions after a document is sent; understand what yours allows.

None of these are FlowVerify-specific requirements. They are the baseline for any eSignature workflow that is expected to survive scrutiny.

A tamper-evident PDF is the foundation. Authentication records and a complete audit trail are what you build on top of it. When a dispute arrives, it is the combination of all three that determines what you can actually prove.