Are Electronic Signatures Secure? What Each Indian Method Proves and What to Check Before You Buy
How secure an electronic signature is depends on the method, the audit trail and the provider's controls. This explainer maps the three Indian methods to what they actually prove, what Indian evidence law needs, and a security checklist for buyers.
"Is an e-signature secure?" is really three questions: can someone forge it, can the document be altered afterwards, and can you prove in court who signed what and when. The answers differ for each of the three methods Indian businesses use. This explainer sets them out and ends with the questions to put to any provider. Position as of October 2026.
The three methods and what each proves
Digital Signature Certificate (DSC). Under section 3 of the IT Act, 2000, a digital signature uses an asymmetric crypto system and hash function; the signer holds a private key on a token and a licensed Certifying Authority (CA) issues the certificate under the Controller of Certifying Authorities. What it proves: the signature was created with a private key bound to an identity verified by the CA, and any change to the document after signing breaks the signature. What it does not prove by itself: that the token was in the right hands.
Aadhaar eSign. Under section 3A read with the Second Schedule (the e-authentication technique using Aadhaar e-KYC, notified in 2015), the signer authenticates with UIDAI through OTP or biometric, and an eSign Service Provider obtains a one-time certificate from a CA and signs the document's hash. The CCA's eSign API specification describes the flow: the application computes a SHA-256 hash of the document, the ESP authenticates the user, generates a key pair and certificate, and signs the hash. What it proves: identity at the moment of signing, linked to Aadhaar e-KYC, plus tamper evidence through the hash. The CCA's specification classes OTP-based eSign as "single factor" and biometric eSign as "multi factor".
Platform signature. Typed, drawn or click-to-sign through a platform that records an audit trail (email or phone verification, IP address, timestamps, document hash). Not a technique under the Second Schedule, so not an "electronic signature" under section 3A, and it will not satisfy a statutory signature requirement under section 5. It can evidence that a contract was formed electronically (section 10A) and is proved as an electronic record. What it proves: that someone with access to that email or phone took that action at that time against that document hash.
Tamper evidence is the easy part
All three methods can make post-signature alteration detectable: the DSC and eSign signatures bind to the document hash; a platform signature should record the hash and seal the final PDF. If a provider cannot show you the hash and a verification method, it is not giving you tamper evidence.
Proving it in court is the part to plan for
Since 1 July 2024, electronic records are admitted under sections 61 and 63 of the Bharatiya Sakshya Adhiniyam, 2023. Section 63(4) requires a certificate that identifies the electronic record, describes how it was produced and gives particulars of the device, signed by a person responsible for the system. The Supreme Court's decision in Arjun Panditrao Khotkar v. Kailash Kushanrao Gorantyal (14 July 2020), on the predecessor section 65B, treated the certificate as a condition precedent for secondary electronic evidence. The practical consequence is that "secure" includes "can produce the record, the audit trail and the certificate on demand". That is a provider capability, not a cryptographic property.
Where breaches actually happen
Security incidents around e-signed documents are rarely cryptographic. They are:
- Signing links forwarded to the wrong person (no identity verification beyond email).
- Documents altered before signature by inserting pages the signer did not read.
- Executed documents stored in shared drives with broad access.
- Provider accounts compromised through weak admin credentials.
Each is addressed by process and access control, not by a stronger algorithm.
Security checklist for buyers
| Question | Why it matters |
|---|---|
| Which Second Schedule methods are supported (DSC, Aadhaar eSign)? | Determines whether section 5 is satisfied |
| Is the document hash recorded and is a verification tool provided? | Tamper evidence |
| What does the audit trail contain and can it be exported with a certificate? | BSA s. 63 |
| Is identity verified beyond an email link (OTP to phone, Aadhaar, DSC)? | Wrong-signer risk |
| Where is data hosted and is an Indian region available? | Residency; RBI 2025 Directions for regulated entities |
| Does the provider hold ISO 27001 or SOC 2 and will it sign a processing agreement under DPDP s. 8(2)? | Organisational controls |
| Is the provider within CERT-In's 2022 Directions (6-hour incident reporting, 180-day logs in India)? | Incident response |
| Are admin accounts protected by MFA and role-based access? | Account compromise |
| What is the exit process and format? | Lock-in |
On CERT-In: the Directions of 28 April 2022 under section 70B(6) of the IT Act require service providers, intermediaries, data centres, body corporates and government organisations to report listed cyber incidents to CERT-In "within 6 hours of noticing such incidents or being brought to notice", and to keep ICT system logs "securely for a rolling period of 180 days" within India. Your provider's incident clause should align with this, and with the DPDP Rules' 72-hour breach report to the Data Protection Board once rule 7 commences on 13 May 2027.
Where Legatio fits. Legatio supports DSC and Aadhaar eSign, records the document hash and audit trail per signer, and can export the record for a section 63 certificate. The checklist applies to any provider, including us.
Position stated as of October 2026. General information, not legal advice.