The Supreme Court upheld Section 63 BSA. Most audit trails still can't produce its certificate.

Every SaaS product keeps some version of an audit trail: who signed in, who clicked what, who approved a document, and when. Engineering teams treat this as self-evidently reliable, because from inside the system it is. Indian courts do not extend the same courtesy. Under Section 63 BSA, an electronic record produced without the right certificate is not admissible at all, however complete the underlying log turns out to be.

That distinction stopped being theoretical in May 2026. A three-judge bench of the Supreme Court, led by Chief Justice Surya Kant, rejected a constitutional challenge to Section 63(4) of the Bharatiya Sakshya Adhiniyam, 2023 (BSA), brought by the Pune Bar Association. The judgment did more than settle a legal argument. It confirmed that the certificate requirement, hash value included, is staying, and it clarified who is allowed to sign it.

For anyone who owns a company's logging or audit-trail architecture, the more useful way to read that judgment isn't as case law. It reads closer to a specification, one most engineering teams haven't looked at, for the format a system's output needs to take before an Indian court will consider it at all.

Section 65B is gone. Section 63 BSA asks for more

The Indian Evidence Act, 1872, and its Section 65B, governed electronic evidence for close to two decades. It required a single certificate: a written statement from the person in charge of the relevant computer, confirming how the record was produced, attached to whatever printout or copy was being submitted. Courts leaned on it constantly, and litigators built entire practices around getting it right, or exploiting when the other side didn't.

The BSA replaced the Evidence Act entirely on 1 July 2024. Section 63 is the direct successor to Section 65B and keeps its core idea: an electronic record produced without the original device still needs a certificate to be admitted. What changed is the scope and the weight of that certificate. The word "computer" became "computer or any communication device", pulling phones and messaging apps into the same framework. And under Section 63(4), the single certificate became two, with a hash value required in both.

What the Supreme Court settled in May 2026, and what it left open

The Pune Bar Association argued that Section 63(4), read with its Schedule, was unconstitutional: it placed an unreasonable burden on an ordinary litigant, requiring a hash value and a second, expert-signed certificate just to get a WhatsApp message or an email into evidence. The three-judge bench disagreed. Hash value, the court said, works as an electronic fingerprint, giving judges a reliable way to check whether a file has been altered. Requiring it in the certificate protects the authenticity of the record; it doesn't punish the person submitting it.

The judgment also answered a narrower but practical question: who is allowed to sign Part B, the expert half of the certificate. A Madras High Court ruling had suggested this needed to be an examiner formally notified under Section 79A of the IT Act, a government list with limited entries. The Supreme Court disagreed, holding that anyone with demonstrable expertise in computer science or cyber forensics can sign it, and that the Madras position shouldn't be treated as binding precedent. That widens the pool considerably. It doesn't remove the requirement that the signer actually understands the system well enough to certify it honestly.

For a business, this rarely shows up as a landmark dispute. It shows up as something mundane: a vendor payment approved over email, a discount agreed over WhatsApp, a contract variation confirmed in a chat thread. Any of these can need a Section 63(4) certificate before a court will look at them at all, and that certificate has to be assembled after the fact, by whoever can credibly say they controlled the relevant device or system at the time the record was made.

Two parts, and Part B is the harder half

The certificate format is set out in the Schedule to the BSA, split into two parts. Part A is filled in by whoever had lawful control of the device or system the record came from: basic facts about how the record was produced, plus that person's own statement of the hash value. Part B is filled in by the expert clarified in the May 2026 ruling: a second, independent hash computation and a certification that the record hasn't been altered.

Section 65B never asked for a second signature or a hash value at all. Adding both is a real jump in what a company needs to be able to produce, and it needs to be able to produce it on someone else's timeline, once a dispute is already under way, not at a moment it controls.

What an audit trail means to an engineer, and what it needs to mean to a court

An engineering team's idea of an audit trail is usually an event log: user X performed action Y at timestamp Z, recorded in an append-only table somewhere. That's a reasonable definition for debugging and for most internal disputes. It isn't what Section 63(4) asks for.

The certificate needs a hash value computed against a specific record, using a named algorithm, produced by someone who can honestly say which algorithm they used and stand behind the computation. Most application logs were never built with that requirement in mind. They record that something happened. They rarely capture, at the moment of creation, a fixed cryptographic fingerprint of the exact bytes that later get pulled into a certificate.

Producing a hash after a dispute has already started is legally weaker than producing one that existed from the moment the record was made. A court asked to trust a hash computed months later, on a system the same party controls, is being asked to trust that party's own account of its own evidence. That's exactly the scenario the certificate requirement exists to test, and it's a harder position to argue from than most teams realise until they're already in it.

A minimum viable audit trail for Section 63(4) readiness

None of this requires a rebuild. It requires a short list of decisions made in advance, rather than under deadline once a dispute arrives.

1. Compute a hash of each record that might end up in a dispute at the moment it's created, not when it's requested. SHA-256 is the safer default; the Schedule also accepts SHA-1 and MD5, but both are weak against deliberate collision attacks, which undercuts the fingerprint argument the Supreme Court relied on.
2. Store the hash alongside the record, somewhere that isn't writable by the same process that could alter the record itself.
3. Name, in writing, who inside the organisation counts as the person in lawful control of the relevant system for Part A. This shouldn't be a surprise question once a dispute starts.
4. Keep access to at least one person, inside or outside the company, who understands the hashing and storage well enough to sign Part B. The May 2026 ruling widened who qualifies; it didn't remove the need for real expertise.
5. Retain the original record, not just its hash, for as long as a plausible dispute window runs, which for commercial contracts is usually longer than typical log-retention defaults.

def store_record(record_bytes, db):
    digest = hashlib.sha256(record_bytes).hexdigest()
    db.insert(
        record=record_bytes,
        hash_algorithm="SHA-256",
        hash_value=digest,
        created_at=now(),
    )
    return digest

What this doesn't fix

A Section 63(4)-compliant certificate makes a record eligible for a court's consideration. It doesn't make the record automatically believed. Judges can still question whether the named custodian genuinely had control of the system, whether the expert's qualifications hold up under cross-examination, or whether a record with a matching hash was nonetheless manipulated before the hash was taken. The certificate is a floor, not a verdict.

It's also worth being precise about which law is doing the work here. The BSA is evidence law: it governs what a court will look at. That's a different statute from the IT Act, which governs the legal recognition of electronic signatures and records more broadly. A record can satisfy one and still run into trouble under the other, and neither replaces specific legal advice on an active dispute.

The Supreme Court closed the constitutional question in May 2026, but High Courts are still working out the operational edges case by case, over what exactly counts as lawful control of a system, and how far back the hash requirement reaches for records created before the ruling. Companies whose logs might end up in front of a judge have a window, probably not a long one, to fix this before it turns into case law with sharper edges than a Schedule most engineering teams have never opened.