Section 65B is not a stamp on a printout — it is the chain of custody reduced to a certificate.

Introduction

Ask most junior lawyers what a Section 65B certificate is for, and you will get some version of the same answer: it is the paper you attach to a printout so the judge will accept it. That answer is not wrong exactly — it is just so incomplete that it ends up misleading people about what the document is actually doing. Digital evidence does not behave like a letter or a contract. A physical document carries its own history in its texture, its ink, its folds, sometimes a signature that can be traced. A digital file has none of that. It is a string of binary states that can be edited, truncated, or fabricated cleanly, without leaving a mark anyone would notice just by looking. Worse still, no bad intentions are even required to damage it — booting up a seized laptop for a quick look, or opening a file the wrong way, can quietly alter the very metadata a court might later rely on.

Indian law responded to this problem with a dedicated evidentiary gate for electronic records: Section 65B of the Evidence Act, 1872, now carried forward almost unchanged as Section 63 of the Bharatiya Sakshya Adhiniyam, 2023. Yet the certificate this section demands is still routinely treated as a formality, something obtained the week before trial and forgotten thereafter. That habit costs parties cases they should have won, and it allows flimsy certificates to slip past defence counsel who never learned to read them properly. This piece works through the doctrine, but it spends most of its effort on the forensic mechanics underneath it, because that is the level at which a certificate actually succeeds or fails. A lawyer who cannot engage an expert witness on those terms is negotiating half-blind.

Why Digital Evidence Needed Its Own Rule

The traditional chain-of-custody concept was built for physical objects: track who held the item, where it sat, who examined it, how it moved from hand to hand. That works when objects show wear, take fingerprints, or otherwise resist silent tampering. None of that holds for a hard drive. Copying a file across devices leaves no scuff marks. A bit-for-bit forensic image of a disk is mathematically identical to the original, yet a derivative of that same data — a printed email, an exported chat log — can be doctored in a basic text editor with no visible trace. Because a printout tells a court nothing about what happened to the underlying data before it arrived on that page, the law had to anchor trustworthiness somewhere else entirely: in the environment the data came from, and the process used to extract it. That is the actual function of the certificate. It stands in for physical custody, translating a process that would otherwise be invisible into something a court can weigh.

Two Decades of the Courts Changing Their Mind

This is one of those areas of law that did not settle quietly. It took several hard swings before arriving at its present position, and understanding that arc matters because each swing reflects a different judicial view of how much technical rigor the certificate ought to demand.

The starting point was State (NCT of Delhi) v. Navjot Sandhu, 2005 Legal Eagle (SC) 566 : (2005) 11 S.C.C. 600, the Parliament Attack case, which took the loose approach: even without a Section 65B(4) certificate, call records could still be admitted as secondary evidence if other proof of authenticity existed. This was convenient for prosecutions in a hurry, but it left the door open to precisely the kind of unverified digital evidence the statute was meant to guard against.

Anvar P.V. v. P.K. Basheer, 2014 Legal Eagle (SC) 708 : (2014) 10 S.C.C. 473 shut that door. A three-judge bench held that Section 65B is a complete code unto itself for electronic records, so that without the certificate, secondary electronic evidence simply does not come in — the general secondary-evidence provisions of Sections 63 and 65 no longer apply to computer output once the record in question is electronic. The reasoning was that a special provision, deliberately enacted to deal with the particular fragility of digital records, would be rendered pointless if parties could sidestep it by falling back on the ordinary rules meant for physical documents.

Tomaso Bruno v. State of Uttar Pradesh, 2025 Legal Eagle (SC) 41 : (2015) 7 S.C.C. 178 (India), dealt with CCTV footage specifically, and it added an important corollary: a party sitting on available digital evidence rather than producing it can face an adverse inference under what is now Section 119 of the BSA. The logic here is straightforward — if a party controls best evidence and withholds it, courts are entitled to presume that its production would have been unfavourable to that party's case.

Shafhi Mohammad v. State of Himachal Pradesh, 2018 Legal Eagle (SC) 235 ; (2018) 5 S.C.C. 311 (India), tried to soften the position for people who genuinely did not control the source device, such as someone relying on a shopkeeper's CCTV footage, by holding the certificate requirement directory rather than mandatory in those situations. The underlying concern was fairness: it seemed harsh to deny a litigant the benefit of decisive evidence simply because a third party who held the original device would not cooperate.

Arjun Panditrao Khotkar v. Kailash Kushanrao Gorantyal, 2020 Legal Eagle (SC) 448 : (2020) 7 S.C.C. 1 (India), put an end to the oscillation. A three-judge bench overruled Shafhi Mohammad, restored Anvar P.V., and made strict compliance the rule: no certificate, no admission, unless the original device itself is produced by its owner or operator in court. Importantly, the bench did not simply reimpose a rigid requirement and leave litigants to fend for themselves — it also held that trial courts carry a positive duty to assist parties in obtaining certificates from custodians who refuse to cooperate, which is meant to prevent the strict rule from becoming an instrument of injustice in its own right.

Most recently, Kailas s/o Bajirao Pawar v. State of Maharashtra, 2025 Legal Eagle (SC) 1006 : 2025 INSC 1117 (India), confirmed that the same strict logic extends comfortably to newer storage formats such as compact discs and video files, without inventing extra procedural hurdles like a mandatory written transcript once the statutory requirements have actually been satisfied.

Read together, these decisions trace a clear trajectory from permissiveness to strictness, and that trajectory is precisely why the substance behind a certificate now matters as much as the fact of its existence. A court applying Arjun Panditrao Khotkar is not asking whether a certificate was signed; it is asking whether the process the certificate describes actually happened the way it claims.

What the Certificate Is Actually Asking For

Standard forensic practice, read alongside the statutory language, reveals that the certificate's requirements are not bureaucratic boilerplate at all. Each clause corresponds to a recognisable step in the way any competent forensic examiner would document the handling of evidence. The requirement to identify the electronic record and specify the exact device or server it came from mirrors the forensic step of cataloguing evidence at intake, so that everything downstream can be traced back to a single, unambiguous source. The requirement to confirm that the device was under lawful control and used regularly in the ordinary course of business mirrors the forensic concept of verifying the custodial environment, since a system used sporadically or configured ad hoc for a single extraction does not carry the same reliability as one running its normal, everyday processes. The requirement to certify that the system operated properly, and that no processing errors compromised the data, mirrors the forensic practice of confirming system integrity before relying on its output. And the requirement to describe the manner of production, together with hash values proving the data was not altered after extraction, mirrors the forensic discipline of documenting the extraction method and preserving a verifiable record of integrity.

The trouble is that most lawyers stop at the legal label and never ask what sits beneath it. Each of these requirements hides a set of technical questions that a competent expert ought to be able to answer without hesitation, and a certificate signed by someone who cannot answer them is, in practical terms, unsupported — regardless of how official the document looks on its face.

Who Should Actually Be Signing

A distinction gets blurred constantly in practice: having lawful control of a device is not the same thing as having the technical competence to certify how that device behaved. Section 45A of the former Evidence Act, now carried into the BSA, deals with the opinions of examiners of electronic evidence for precisely this reason — competence to certify a system's technical operation is treated as a distinct question from custody of its output.

An investigating officer who seized a server, or a telecom nodal officer who ran an export, may have unimpeachable custodial standing and still have no genuine basis for asserting that "the computer was operating properly throughout the material period." That is a technical claim, not an administrative one, and before trial it is worth establishing whether the signatory had administrative access to the system or only received the export someone else generated, whether the signatory is a system administrator or forensic examiner rather than simply the officer who happened to be holding the exhibit, and whether the certification rests on an actual review of logs or on the assumption that everything must have worked because the output looked normal. Where the system belongs to a third party — a bank, a telecom operator, the owner of a building's DVR — it is worth asking whether the signatory has any real standing to speak to that system's internal integrity at all, as opposed to merely confirming that a copy was received. This is usually where certificates quietly fall apart, long before anyone reaches cross-examination: they tend to be signed by whoever was procedurally convenient rather than whoever was actually positioned to know.

The Technical Ground a Practitioner Needs Under Their Feet

Forensically sound acquisition of data means considerably more than dragging a folder from one drive to another, and the distinction matters because the two methods carry very different evidentiary weight. A bit-stream image captures every sector of a device, including deleted files, slack space, and unallocated space, and it is typically taken through a write blocker that physically prevents the source device from being altered during the process. A logical copy, by contrast, captures only the visible, allocated files as the operating system presents them, and the act of making that copy can itself change metadata, miss deleted data entirely, and leave no reliable way to prove that nothing was altered along the way. When a certificate states that data was "copied," the natural follow-up is to ask how — whether through a validated forensic image made with a tool such as EnCase, FTK Imager, or the Unix utility dd, or through an ordinary drag-and-drop operation performed with no write protection at all. Those are two very different technical claims dressed in the same everyday word.

Hashing sits at the centre of the entire integrity argument. A cryptographic hash function takes data of any size and produces a fixed-length value that changes completely if even a single bit of the input changes, and this is the mechanism that allows a court to trust that the copy sitting in the courtroom today matches what was seized months or years earlier. Two algorithms recur constantly in practice. MD5 remains fast and common, but it is now cryptographically broken for security purposes, since collisions can be deliberately engineered, so while it still has a role as a quick integrity check, it is increasingly regarded as an insufficient sole safeguard where the stakes are genuinely high. SHA-256, part of the SHA-2 family, is the accepted current standard wherever collision resistance actually matters. The forensically correct sequence involves hashing the source before acquisition, taking the image, hashing the image, confirming that the two values match, and repeating the process at every subsequent point the evidence changes hands. Where a certificate mentions a hash value without specifying the algorithm used, the moment it was generated, or what it was checked against, that omission should be treated as a genuine gap rather than a minor drafting oversight, because a hash generated only after the evidence has already passed through several unverified hands proves nothing about what happened before that point.

Timestamps present a related, if subtler, problem. Most file systems track when a file was last modified, when it was last accessed, and when it was created — commonly referred to as the MAC times — and these are forensically significant because they can either support or contradict a party's account of when something occurred. The trap here is almost always the same: someone opens a file simply to check its contents, without a write blocker or a forensically sound viewer, and the access timestamp updates immediately, with other timestamps potentially changing as well depending on the file system in use, since NTFS, ext4, and APFS all behave somewhat differently in this respect. A witness who casually examined the original device before it was properly imaged has, in all likelihood, already altered precisely the metadata that will later be relied upon in court.

Certifying that a computer was "operating properly" is itself a technical claim, and technical claims of this kind ought to be supported by an actual review of system and application logs — Windows Event Logs, Linux syslog entries, application-level logs, and disk health diagnostics. Crash dumps, unexplained reboots, disk read and write errors, and a system clock that has quietly drifted out of synchronisation can all undercut a blanket assurance that everything functioned as expected during the relevant period. In practice, very few certificates are actually backed by this kind of review; the great majority simply assert normal functioning as a matter of routine, without anyone having checked.

Some categories of evidence exist only while a system remains powered on — running processes, open network connections, the contents of random-access memory, active encryption keys — and standard forensic practice captures this volatile data before touching anything persistent, because switching a device off for what seems like safe seizure can permanently destroy it. Where the record shows that a device was simply powered down and transported without any attempt to capture live data first, that omission constitutes a real, documentable gap in the chain, and it becomes especially significant in cases involving encrypted volumes or active network intrusions, where the evidence most likely to matter may only ever have existed in volatile memory.

Mobile devices raise their own distinct considerations. Extraction using tools such as Cellebrite, Magnet AXIOM, or Oxygen Forensic Detective generally falls into one of three categories. Logical extraction pulls user-visible data through the device's own interfaces; it is quick, but incomplete, and the process itself can nudge the device into altering its own state. File-system extraction reaches deeper, capturing some deleted or cached material that logical extraction would miss. Physical extraction is a full bit-level capture, often requiring the device to be jailbroken, rooted, or accessed through chip-off or JTAG methods, and while it is the most complete option, it is also the most invasive. Each method carries a distinct risk of contaminating the evidence, since a phone that reconnects to a network during extraction can trigger a remote wipe, push notifications, or a synchronisation event that changes data after seizure. A certificate covering mobile evidence should therefore specify which method was used and whether the device was isolated from network connectivity, whether through airplane mode or a Faraday enclosure, during and after acquisition.

Records held by third parties — call detail records, tower dumps, cloud-hosted logs — present a further complication, because the "device" in question is never in the party's own physical custody at all. These records arrive as an export generated by someone else's system, which means the person signing the certificate is often vouching for a process they did not control from beginning to end. It becomes worth establishing how long the provider retains this data before automatic rotation or deletion, whether the export itself was hashed at the point of generation, and whether the witness genuinely understands the underlying system architecture or has simply received a file handed over by a nodal officer.

CCTV evidence brings its own set of technical quirks. Proprietary DVR file formats frequently require the manufacturer's own playback software to open at all, timestamp overlays are notoriously prone to drift because DVR clocks are rarely synchronised and often reset after a power failure, variable frame rates complicate any subsequent motion analysis, and compression artefacts are introduced whenever footage is converted into a more common format such as MP4 for the purpose of playing it in court. That conversion step is itself a derivative work and needs its own documented integrity trail; it does not get a free pass simply because the original recording was, in some sense, the "real" evidence.

Where People Actually Go Wrong

Several mistakes recur across cases with striking regularity, and each one traces back to treating the certificate as paperwork rather than as a technical attestation. Generic templates get signed without anyone confirming whether the signatory genuinely had control of, or familiarity with, the source system. Certification arrives too late, in defiance of the timing expectations set out in Arjun Panditrao Khotkar, which anticipates that the certificate should travel with the charge-sheet rather than being assembled once a judge points out its absence. Hashing, where it happens at all, is often performed at the wrong moment — a hash taken of the exhibit as tendered in court means very little without an earlier hash, taken at the point of original extraction, against which it can be compared. Custody gets conflated with competence, on the assumption that whoever collected the exhibit is automatically qualified to speak to its technical integrity. Format conversions — proprietary CCTV formats, database exports, decrypted chat backups — are treated as incidental rather than as distinct steps each requiring their own integrity trail. And volatile data is often simply forgotten, particularly in cases involving live network activity, encryption, or active malware, where the most probative evidence may have existed only in memory before the device was switched off.

Cross-Examining the Person Who Signed the Certificate

For a lawyer facing the expert or officer behind a Section 65B or Section 63 certificate, the objective is to stop debating what the record shows and start interrogating the process that produced it. Because Anvar P.V. and Arjun Panditrao Khotkar demand strict compliance, every clause of the certificate — and every technical step sitting behind it — represents a place where the certificate can crack under sustained questioning.

The first line of inquiry concerns authority and technical grounding: whether the witness was genuinely the system administrator with real access at the relevant time, or whether the data instead arrived as someone else's export; whether the witness personally configured or monitored the system, or is simply relaying what they were told by someone else; and what training, if any, the witness actually holds in the extraction method that was used. The second line concerns the claims made about normal system operation — whether the witness reviewed event logs, crash dumps, or disk health data before certifying that the system worked properly, or whether that certification rests on nothing more than the assumption that the output looked normal, and whether the witness is aware of any clock drift, unexpected reboots, or read and write errors during the relevant window. The third line concerns the extraction itself — which tool was used, whether it involved a validated forensic image taken through a write blocker or merely an ordinary file copy, whether a hash value was generated the moment the data was pulled and before anything else touched it, which algorithm was used and what the resulting value was, whether that hash was verified again at every later transfer, whether a mobile device was isolated from any network during and after seizure, and whether any format conversion along the way was independently documented and hashed. The final line concerns timeline and custody — when the certificate was actually written, whether at the point of seizure or only after its absence was flagged in court, who had access to the evidence between seizure and the point it reached this witness, and whether an unbroken written record of that custody actually exists.

A witness who cannot answer these questions with any real specificity is not offering a technical certification at all. They are offering a guess dressed in the language of one, and establishing that distinction on the record is the substantive work of cross-examination — not the ritual act of confirming that a certificate exists somewhere in the case file.

The Point of All This

The underlying shift this approach demands is straightforward: stop arguing about what a digital record shows, and start asking where it came from and how it made its way to the courtroom. A certificate should never be accepted at face value simply because it exists and carries a signature, and equally, it should never be drafted or filed without the underlying technical work actually having been done — proper imaging, hashing performed at the right moments, genuine log review, careful handling of timestamps, network isolation where it matters, and an unbroken custodial record supporting all of it.

Approached this way, the certificate stops being a piece of paperwork and becomes something closer to a discipline. For the party relying on it, that discipline is a standard to be met well before trial begins, not a formality to be assembled at the last minute. For the party opposing it, the same discipline offers a precise map of exactly where the chain is most likely to be thin. Every missing hash value, every log that was never reviewed, every gap in the timeline is not a technicality to be waved away — it is a real, demonstrable hole between the evidence sitting in the courtroom and the data as it actually existed before anyone touched it.