Section 3A of the IT Act: what it actually requires your eSign stack to do

When a prospective customer's legal team asks whether your eSign is Section 3A compliant, most product teams reach for their vendor's compliance page and hope it says yes. The question sounds like a yes/no and it isn't. Section 3A sets four operational conditions your signing implementation must satisfy, and your audit trail must prove all four were met for each individual signature. Here's what that means in practice.

What Section 3A is and isn't

Section 3 of the IT Act 2000 recognised digital signatures: the kind issued by CCA-licensed Certifying Authorities using X.509 certificates and stored on hardware tokens. The technology worked, but it was tied to a specific infrastructure that didn't scale to consumer volumes. Issuance took days; the hardware cost money; and most individuals didn't have a certificate at all.

The 2008 amendments added Section 3A to fix this. Instead of specifying a technology, it specifies a reliability threshold. Any authentication method that satisfies the conditions can be notified by the Central Government and added to Schedule II of the Act. Today, two methods are listed there: Aadhaar-based eSign, notified in 2015 and revised in 2017 and 2023, and an OTP-based electronic authentication technique. Section 3A didn't replace Section 3 — digital signatures remain fully valid and are a parallel path. What Section 3A added was a route to legal recognition for signing methods that can reach anyone with an Aadhaar number.

The four reliability conditions

Section 3A(2) lists five conditions, but the operative ones collapse to four. The fifth is a catch-all: 'fulfil such other conditions as may be prescribed', with the CCA's guidelines and each method's Schedule II notification filling those in. The four that matter for implementation:

What gets a method into Schedule II

The Central Government can only add a method to Schedule II after satisfying itself that all four conditions are met by that method's design. When Aadhaar eSign was notified, UIDAI's OTP and biometric channels were evaluated against each condition.

Uniqueness is satisfied because an OTP or biometric authenticates the holder of a specific Aadhaar number — the credential is structurally single-owner. Signatory control is satisfied because the OTP is delivered to the mobile number the signatory registered with UIDAI, expires within 10 minutes, and cannot be reused; biometric capture requires the signatory's physical presence. Both tamper conditions are satisfied by the PKCS#7 signature output: it wraps a hash of the exact document content, and any modification to either the signature or the document body breaks verification on open.

This is also why most consumer OTP flows without a similar delivery-control mechanism don't qualify for Schedule II. If an OTP could plausibly arrive on a device the signatory doesn't control — a shared phone, a forwarded message — condition 2 breaks. The channel through which the credential arrives is as important as the credential itself.

Where Aadhaar eSign meets the conditions, and one gap to watch

When an Aadhaar eSign transaction completes without error, all four conditions are satisfied and the resulting document carries a verifiable signature backed by a UIDAI authentication record. The gap is in error handling, specifically what happens when the session fails mid-way.

What your audit trail needs to capture

For an Aadhaar eSign transaction, a Section 3A-compliant audit record should contain at minimum:

• The UIDAI authentication transaction ID (ASA reference) for each signing event
• A timestamp from UIDAI's authentication response, not from your server clock
• The hash of the document that was presented to the signatory during authentication
• The hash of the signed document output by the eSign service provider
• The eSign service provider's certificate and the chain back to the CCA root

The hash linkage is where audits surface gaps most often. The hash sent to the eSign service provider at signing time must match the hash embedded in the resulting signature. If your workflow pre-generates the signed PDF before the UIDAI authentication completes, or if any field is populated after the hash is computed, you risk a mismatch that will fail signature verification. The eSign service provider's Certificate Practice Statement specifies the exact sequence of operations; follow it precisely rather than inferring the order.

One thing that catches teams off guard: the timestamp from your application server is not sufficient for audit purposes. A UIDAI-sourced timestamp, embedded in the authentication response, is the evidence that proves when the authentication actually happened. Supplement it with an RFC 3161 timestamp from a trusted time-stamping authority applied to the signed document. That timestamp is what makes the signature verifiable years after the signing authority's certificate expires.

The compliance checklist your legal team is asking for

When a legal team asks for Section 3A compliance confirmation, they're asking for proof that these conditions were satisfied for each signature. In practice, that means:

• A signed PDF where the signature validates as intact in a standard PDF verifier, meaning the certificate chain is unbroken and the document hash matches
• A per-signature record that includes the UIDAI authentication transaction ID and a UIDAI-sourced timestamp for each signing event
• Hash linkage confirmed: the hash used during UIDAI authentication is the same hash embedded in the final signature
• An RFC 3161 timestamp from a trusted time-stamping authority, independent of your application server
• An audit report that can be produced on demand for any signed document, without requiring an engineering ticket

FlowVerify's audit trail export includes the authentication transaction reference, the document hash at signing time, the signing authority's certificate chain, and the RFC 3161 timestamp in a single downloadable report. That's the artefact a legal-ops team hands to an auditor without further processing.

Section 3A's four conditions are specific enough to audit against and technology-neutral enough that the question 'are you compliant?' has a real answer: produce the audit record, verify the signature, check the hash linkage. If all four conditions are provable from the artefacts your system generates for each signing event, the answer is yes.