Aadhaar eSign in production: designing fallbacks for UIDAI downtime

Aadhaar eSign depends on UIDAI's authentication infrastructure at the moment a signer submits their OTP. When UIDAI is unavailable, the eSign Service Provider (ESP) cannot complete the authentication, and the signing fails. This is not a bug in your integration. The certifying authority cannot produce a valid Section 3A signature without a live UIDAI authentication response, so the failure is correct.

The problem is what happens around it: signers see a generic error or an indefinite spinner, your support queue fills with 'the link doesn't work' tickets, and agreements that needed to be signed yesterday sit unsigned. UIDAI publishes scheduled maintenance windows, typically late-night or early-morning IST. Unplanned outages happen too, often lasting 20 minutes to a few hours. If your product runs bulk-send campaigns, a 90-minute window can affect hundreds of signing requests at once.

If you haven't designed for this scenario, you've already been caught by it. This article covers three fallback patterns, what each one requires in your audit trail, and how legal validity holds under Section 3A for each approach.

Why this is a UIDAI dependency problem, not a vendor problem

The signing chain looks like this: your application calls the ESP, the ESP calls UIDAI for eKYC authentication, UIDAI responds with the authentication result, the ESP issues the cryptographic signature, and the certifying authority embeds it in the PDF.

If UIDAI times out at step two, nothing downstream can proceed. No ESP can sign the document without that authentication response, regardless of how well their own infrastructure is performing. This is a structural dependency on government infrastructure, not a quality-of-service issue with your vendor.

For most workflows, a 90-minute outage is tolerable if users are informed and documents queue gracefully. The damage comes from silent failures: the signer doesn't know whether signing worked, the sender doesn't know whether to follow up, and the audit trail has a gap that's hard to explain later.

The three fallback strategies

There is no fallback that replicates Aadhaar eSign exactly, because Aadhaar eSign is specific to UIDAI authentication. Any fallback changes what authentication method was used. What differs across the three approaches is how much that change matters for your specific workflow, and how much implementation work each requires.

Async queue: capture intent, complete authentication later

The async queue pattern is the lowest-risk fallback for most production workflows. When UIDAI is unavailable at signing time, you store the signer's document state and pending authentication intent, then retry the UIDAI authentication call at regular intervals until it succeeds.

From the signer's perspective: they visit the link, enter their Aadhaar number, submit the OTP, and receive a confirmation that their request is processing. Two notifications are required. The first confirms receipt of their details. The second, sent once UIDAI authentication completes, delivers the signed document. Do not let the gap pass silently.

The legal character of this approach is clean. The signed PDF carries the timestamp when UIDAI authentication actually occurred (T2), not when the signer submitted their details (T1). This is correct — the signature was produced at T2. The audit trail should log both timestamps and the reason for the gap, but a multi-hour delay between T1 and T2 does not affect the validity of the Section 3A signature.

The main risk with async queue is signer drop-off. If T1 to T2 stretches beyond a couple of hours and the signer receives no status update, they may assume the process failed and contact support, or sign a paper copy. That creates a duplicate-signing problem that is harder to resolve than the original outage. Clear status communication at every state transition is not optional.

[T1 09:14:22] Signer visited signing link (IP: 103.x.x.x, UA: Chrome/124)
[T1 09:14:51] Signer submitted Aadhaar number for eKYC authentication
[T1 09:14:53] UIDAI authentication request failed (error: SERVICE_UNAVAILABLE)
[T1 09:14:53] Signing request queued for retry (queue_id: q_abc123)
[T2 10:47:02] UIDAI authentication succeeded (txn_id: uidai_xyz456)
[T2 10:47:04] Certifying authority issued signature (cert_serial: CA_789)
[T2 10:47:06] Signed PDF delivered to sender and signer

DSC drop-in: high validity, limited population

If your signers have Class-3 Digital Signature Certificates, offering DSC signing as a fallback is practical and legally sound. The signer uses their USB token or .pfx file instead of an Aadhaar OTP. No UIDAI dependency at all.

Class-3 DSC signing under the IT Act is a strong option for commercial agreements. The private key never leaves the signer's hardware token, authentication is fully local, and the certificate chain traces back to a CCA-licensed certifying authority without any government authentication service in the loop at sign time.

The practical ceiling: most individuals in consumer-facing workflows don't hold a Class-3 DSC. This fallback works for B2B contracts where signers are company representatives with DSCs for their professional practice, for CA and CS firms, and for finance teams handling high-value agreements. It is not useful for HR onboarding forms, event waivers, or any flow where Aadhaar eSign was chosen because the signing population doesn't hold DSCs.

Implementation approach: detect the UIDAI failure at the ESP level, present the signer with an alternative signing method, and route the document through your DSC signing flow. The resulting PDF will carry a different signature type, which should be noted explicitly in the audit trail and in the envelope metadata — the document was signed via DSC because Aadhaar eSign was unavailable at the time.

Consent capture with deferred Aadhaar signing

The consent-capture pattern is the most complex and legally nuanced of the three. When UIDAI is down, you record the signer's explicit consent through non-Aadhaar means: typically an email confirmation, a mobile OTP to their phone number, or a combination with IP address and session fingerprint. Once UIDAI is available, you trigger the actual Aadhaar eSign using the stored Aadhaar number, producing a properly authenticated signed PDF.

The consent record at T1 is not itself a Section 3A signature. It's an intermediate evidence of intent. The Section 3A signature happens at T2. Whether the T1 consent record has independent legal weight depends on whether it qualifies as an electronic signature under another provision of the IT Act, or whether it stands only as evidentiary proof of consent.

For most standard commercial agreements — offer letters, NDAs, vendor contracts — a gap of a few hours between T1 consent and T2 Aadhaar signing is defensible, particularly if the signer is notified at each step and the audit trail is complete. For anything where the time of signing has commercial significance — an offer expiring at midnight, a bidding deadline, any clause where the signed date matters — this approach requires explicit agreement from all parties before the outage, not after.

What the audit trail must capture for any fallback path

Regardless of which fallback a signing went through, the audit trail should treat the fallback as a first-class event, not something to paper over. An audit trail that shows only 'signed at T2' without explaining the gap is harder to defend than one that shows the full sequence.

Minimum entries for any fallback signing:

• Signing request initiated by sender (timestamp, document hash)
• Signer visited signing link (IP, user agent, timestamp)
• Signer submitted Aadhaar number for eSign (timestamp)
• UIDAI authentication failure (error code, timestamp)
• Fallback path activated (which fallback, reason)
• Fallback authentication or consent completed (method, reference ID, timestamp)
• Certifying authority issued signed certificate (timestamp, cert serial)
• Signed document delivered to all parties (timestamp)

Each entry should be stored in a way that makes post-hoc alteration evident. Hash-chained logs or an append-only store are the standard approach. That's the audit trail that holds up if a signature is challenged six months after signing.

How FlowVerify handles UIDAI downtime

FlowVerify shows signers a live status when UIDAI is unavailable rather than a generic error. Signing requests that hit a UIDAI failure move to a retryable queue state automatically. The signer doesn't need to re-enter their details, and the sender doesn't need to resend the envelope.

The async retry runs in the background. Once UIDAI responds successfully, the document is signed, the audit trail is updated with both the failure timestamp and the completion timestamp, and both parties receive the signed PDF. The envelope dashboard shows which documents are in a pending UIDAI authentication state, so senders know exactly what's still in flight and why.

For workflows that need DSC as a fallback, the BYO-DSC feature lets signers bring their own .pfx file. An envelope can be configured to offer DSC as an alternative signing method when Aadhaar eSign fails. Both signature types produce a tamper-evident PDF with a complete audit trail; they carry different authentication provenance.

The one thing neither FlowVerify nor any other ESP can do: sign a document via Aadhaar eSign when UIDAI is unavailable. The fallback patterns above are your options. Build for this scenario before it shows up in production.