Chapter VIII of the Information Technology Act, 2000 is the shortest substantive chapter in the statute — just three sections, Sections 40 to 42, plus the inserted Section 40A — yet it carries the weight of the entire public-key infrastructure on its shoulders. A Certifying Authority can issue a flawless Digital Signature Certificate, and a relying party can verify it perfectly, but the whole architecture of trust collapses the instant a subscriber lets the private key slip out of his hands. These provisions therefore fix the subscriber — the person in whose name the certificate is issued — with a short list of non-delegable duties: to generate the key pair securely, to accept the certificate with full knowledge of what acceptance certifies, and above all to retain control of the private key and shout the moment it is compromised. This chapter unpacks each duty against the verified bare text, traces how the courts have treated electronic authentication and the reliability of digital records, and shows why, in the words of the Explanation to Section 42, the subscriber stays liable until he tells the Certifying Authority the key is gone.
Where Chapter VIII sits in the IT Act scheme
The Information Technology Act, 2000 builds trust in electronic transactions through a chain of actors. Chapter VI licenses and regulates Certifying Authorities; Chapter VII governs the issue, suspension and revocation of Digital Signature Certificates; and Chapter VIII — Sections 40 to 42 — imposes duties on the last and most important link, the subscriber. A subscriber is defined in Section 2(1)(zg) as a person in whose name the Digital Signature Certificate is issued. The logic of the Act is sequential: the Certifying Authority vouches for the link between a public key and a named person, but only the subscriber holds the corresponding private key, and only the subscriber can keep it secret. If you have followed our chapters on digital and electronic signatures and on secure electronic records and signatures, you will recognise that Sections 40 to 42 are where the cryptographic theory meets human responsibility.
It is worth stressing at the outset that Chapter VIII is deliberately spare. Parliament did not attempt to legislate every operational nuance of key management — much of that detail is pushed down into regulations made by the Controller and into the Certifying Authority's Certification Practice Statement. What the chapter does is establish the irreducible statutory minimum: a subscriber cannot say he generated the key carelessly, cannot disown a certificate he has published and relied upon, and cannot escape liability for a key he failed to guard. For the hub treatment of the whole Act, see our Information Technology Act notes hub.
Section 40 — Generating key pair
Section 40, headed Generating key pair, reads: "Where any Digital Signature Certificate, the public key of which corresponds to the private key of that subscriber which is to be listed in the Digital Signature Certificate has been accepted by a subscriber, the subscriber shall generate that key pair by applying the security procedure." Two amendments by the notification S.O. 1015(E) (with effect from 19 September 2002) tidied the original language — the word "then" was omitted and the phrase "the key pair" was substituted by "that key pair" — but the substance is unchanged.
The duty is narrow but precise. It is triggered only where a Digital Signature Certificate, whose public key corresponds to the subscriber's private key, has been accepted by that subscriber. Once that condition is met, the subscriber must generate the key pair by applying the security procedure. The phrase "security procedure" connects Section 40 back to Section 2(1)(ze) and to Section 16, under which the Central Government prescribes the security procedure having regard to the commercial circumstances, the nature of the transaction and similar factors. In practical terms this means the asymmetric key pair — a mathematically linked public and private key — must be generated using a cryptographically sound, prescribed method rather than an ad hoc or insecure process. The integrity of the entire signature depends on this: a weakly generated private key is a key that can be reverse-engineered, defeating the asymmetric crypto system that Section 3 relies upon for authentication of electronic records.
Students should note the slightly counter-intuitive drafting: the section appears to assume the certificate is "accepted" before the key is "generated", whereas operationally the key pair must exist before any certificate listing the public key can issue. The better reading — and the one consistent with the definitions chapter — is that Section 40 fixes a continuing obligation: whenever a subscriber operates under an accepted certificate, the key pair underpinning it must have been, and must remain, the product of the prescribed security procedure.
Section 40A — Duties for Electronic Signature Certificates
Section 40A was inserted by Act 10 of 2009 (the Information Technology (Amendment) Act, 2008) with effect from 27 October 2009, and reads in full: "In respect of Electronic Signature Certificate the subscriber shall perform such duties as may be prescribed." This single sentence is the bridge between the original 2000 Act, which was built around digital signatures (the specific RSA-style asymmetric-key, hash-function technology), and the technology-neutral electronic signature regime introduced by the 2009 amendment.
The 2008 amendment broadened Section 3A to recognise electronic signatures using any reliable technique notified in the Second Schedule, not merely the digital-signature technique of Section 3. Having opened the door to new authentication technologies — for instance Aadhaar e-KYC e-signatures — Parliament needed a duty provision that did not hard-code the key-pair language of Section 40. Section 40A therefore delegates the content of a subscriber's duties to subordinate legislation, allowing the Government to prescribe duties appropriate to whatever electronic-signature technique is in use. The architecture mirrors the way the electronic governance chapter and the secure-records provisions were re-cast for technology neutrality. For a digital signature the detailed duties remain those in Sections 40 to 42; for any other electronic signature, the operative duties are whatever the Rules prescribe.
Section 41 — Acceptance of a Digital Signature Certificate
Section 41 governs how and when a subscriber is taken to have accepted a Digital Signature Certificate, and — critically — what that acceptance certifies to the world. Sub-section (1) provides that a subscriber shall be deemed to have accepted a Digital Signature Certificate if he publishes or authorises the publication of it (a) to one or more persons, or (b) in a repository, or otherwise demonstrates his approval of the certificate in any manner. Acceptance is thus a conduct-based, not a form-based, concept: there is no prescribed acceptance form. The moment a subscriber holds the certificate out — by publishing it, lodging it in a repository, or simply using it in a transaction in a way that signals approval — acceptance is complete.
Sub-section (2) is the heart of the section. By accepting a Digital Signature Certificate the subscriber certifies to all who reasonably rely on the information in it that: (a) the subscriber holds the private key corresponding to the public key listed in the certificate and is entitled to hold it; (b) all representations made by the subscriber to the Certifying Authority, and all material relevant to the information in the certificate, are true; and (c) all information in the certificate that is within the subscriber's knowledge is true. The phrase "all who reasonably rely" is the doctrinal pivot — acceptance creates a statutory representation running in favour of relying parties generally, not merely the Certifying Authority. This is a deliberate piece of trust-engineering: a third party who acts on a digitally signed record is entitled to treat the subscriber's acceptance as a warranty of the three matters in clauses (a) to (c).
The practical consequence is that a subscriber who accepts a certificate cannot later escape a transaction by claiming the underlying representations to the Certifying Authority were false — by accepting, he has certified them as true to everyone who reasonably relied. This dovetails with the reliability premise that runs through the case law on electronic authentication, discussed below.
Section 42 — Control of the private key
Section 42 is the operative heart of Chapter VIII. Sub-section (1) provides: "Every subscriber shall exercise reasonable care to retain control of the private key corresponding to the public key listed in his Digital Signature Certificate and take all steps to prevent its disclosure." The original section had ended with the words "to a person not authorised to affix the digital signature of the subscriber"; those words were omitted by notification S.O. 1015(E) with effect from 19 September 2002, broadening the duty so that the subscriber must prevent any unauthorised disclosure, full stop.
Sub-section (2) imposes the reporting duty: "If the private key corresponding to the public key listed in the Digital Signature Certificate has been compromised, then, the subscriber shall communicate the same without any delay to the Certifying Authority in such manner as may be specified by the regulations." The word "compromised" is broad — it covers theft, copying, loss of the cryptographic token, or any event giving an unauthorised person access to the key. The communication must be "without any delay", a demanding standard that reflects how quickly a compromised key can be abused to forge signatures.
The teeth of Section 42 lie in its Explanation: "For the removal of doubts, it is hereby declared that the subscriber shall be liable till he has informed the Certifying Authority that the private key has been compromised." This is a continuing-liability rule. Until the moment the subscriber reports the compromise, he bears liability for what is done with his key. The standard of care is calibrated as "reasonable care" — not strict liability — but the burden of cutting off liability is placed squarely on the subscriber's prompt reporting. The interplay with the revocation machinery is important: reporting under Section 42(2) is what enables the Certifying Authority to suspend or revoke the certificate under Sections 37 and 38, so that relying parties are put on notice.
The 'reasonable care' standard and continuing liability
Section 42(1) deliberately adopts a reasonable care standard rather than an absolute guarantee of secrecy. A subscriber is not an insurer of his key against every conceivable attack; he is required to take the steps a prudent person in his position would take — using a secure cryptographic token or hardware security module, protecting the activation PIN or passphrase, not sharing the key with employees beyond those authorised, and storing the key medium safely. What converts a mere lapse into continuing liability is the Explanation's timing rule: liability persists "till he has informed the Certifying Authority that the private key has been compromised".
This produces a sharp practical lesson for examinees. Imagine a subscriber whose USB cryptographic token is stolen on Monday but who reports the loss only on Friday. For transactions purportedly signed between Monday and Friday, the subscriber remains liable, because the statutory shield does not drop until the report is made. The reasonable-care duty and the reporting duty work in tandem: the first asks whether the subscriber guarded the key prudently; the second fixes the cut-off date for his exposure. A subscriber who can show both prudent custody and immediate reporting on discovery has discharged Chapter VIII; one who delays the report carries the risk of intervening misuse. This allocation of risk is rational — the subscriber alone knows when his key is gone and is the cheapest cost-avoider of the resulting harm.
Acceptance as a warranty to relying parties
The most analytically interesting feature of Section 41 is that acceptance is not a private matter between the subscriber and the Certifying Authority. Section 41(2) makes acceptance a representation "to all who reasonably rely on the information contained in the Digital Signature Certificate". In effect, the subscriber gives the world a three-fold warranty — that he holds and is entitled to the private key, that his representations to the Certifying Authority were true, and that the certificate information within his knowledge is accurate.
This warranty is the mechanism by which the IT Act manufactures commercial trust in faceless electronic dealings. A counterparty who receives a digitally signed purchase order need not investigate the signatory's identity or the provenance of the key; she is statutorily entitled to rely on the subscriber's certified warranty. The structure echoes the broader policy of the Act, visible in the attribution, acknowledgment and dispatch of electronic records provisions, which similarly allocate risk to the party best placed to control the relevant technical step. Where attribution rules (Section 11) ask whose record an electronic message is, Section 41 supplies the complementary assurance that the signature on it carries a genuine, warranted authentication.
Judicial recognition of electronic authentication
There is little reported litigation directly construing Sections 40 to 42 — a reflection of how operational and back-end these duties are — but the courts' treatment of electronic authentication and the reliability of electronic records illuminates the policy these sections serve. The landmark early decision is State of Tamil Nadu v. Suhas Katti (decided 5 November 2004 by the Court of the Additional Chief Metropolitan Magistrate, Egmore, Chennai), widely recognised as the first conviction under the Information Technology Act, 2000. Although the case concerned obscene and defamatory messages under Section 67 of the Act read with Sections 469 and 509 of the Indian Penal Code, its enduring significance lies in the court's willingness to accept certified electronic evidence — including records drawn from the service provider's servers — to establish authorship of electronic communications. The decision signalled judicial readiness to treat electronic records as reliable proof of who did what online, the very premise on which the subscriber-duty regime rests.
The reliability premise was then placed on a rigorous statutory footing by the Supreme Court's electronic-evidence jurisprudence. In Anvar P.V. v. P.K. Basheer, (2014) 10 SCC 473, a three-judge Bench (R.M. Lodha, C.J., Kurian Joseph and R.F. Nariman, JJ.) held that a certificate under Section 65B(4) of the Indian Evidence Act, 1872 is a condition precedent to the admissibility of an electronic record adduced as secondary evidence, and that Sections 65A and 65B form a complete code on the point. In doing so the Court expressly overruled the contrary view in State (NCT of Delhi) v. Navjot Sandhu, (2005) 11 SCC 600 — the Parliament-attack case — which had allowed secondary electronic evidence under Sections 63 and 65 irrespective of Section 65B. The throughline to Chapter VIII is conceptual: just as a relying party may bank on the subscriber's Section 41 warranty, a court will only repose trust in an electronic record when its integrity and authentication chain are properly vouched.
From Anvar to Arjun Panditrao: tightening the chain of trust
The certification requirement laid down in Anvar P.V. v. P.K. Basheer was briefly destabilised by Shafhi Mohammad v. State of Himachal Pradesh, (2018) 2 SCC 801 (and the order reported at (2018) 5 SCC 311), in which a two-judge Bench suggested that the Section 65B certificate was merely procedural and could be relaxed where the party was not in possession of the device. That dilution was decisively corrected in Arjun Panditrao Khotkar v. Kailash Kushanrao Gorantyal, (2020) 7 SCC 1, where a three-judge Bench (R.F. Nariman, S. Ravindra Bhat and V. Ramasubramanian, JJ.) held, on 14 July 2020, that the Section 65B(4) certificate is mandatory wherever the electronic record is produced as secondary evidence, expressly overruling Shafhi Mohammad and affirming Anvar. The Court clarified that where the original device is itself produced, no certificate is needed, and it built in a practical remedy allowing a party to seek the court's help in compelling production of the certificate.
For the subscriber-duties chapter, this line of authority matters because it confirms the judicial philosophy underlying Sections 40 to 42: electronic trust is only as good as the verifiable integrity of the authentication chain. A signature founded on a securely generated key (Section 40), accepted with full warranty (Section 41), and kept under prudent control (Section 42) is the practical, transactional counterpart to the evidentiary rigour that Anvar and Arjun Panditrao demand at the courtroom door. The two regimes — one preventive, one evidentiary — are pulling in the same direction.
Electronic acceptance and the formation of obligations
Section 41's deeming of acceptance through conduct resonates with the Supreme Court's recognition that obligations can be formed and concluded through electronic means. In Trimex International FZE Ltd. v. Vedanta Aluminium Ltd., (2010) 3 SCC 1, the Court held that a concluded contract had come into existence through an exchange of e-mails, the unconditional acceptance of an offer by e-mail being sufficient to bind the parties even before a formal contract was drawn up. The principle — that electronic conduct can constitute legally significant acceptance — is the contractual cousin of Section 41's rule that publishing or otherwise approving a Digital Signature Certificate constitutes acceptance with binding consequences.
The analogy is instructive for examinees. Just as Trimex refused to let a party resile from an e-mail acceptance by pointing to the absence of a signed paper contract, Section 41 refuses to let a subscriber resile from the warranties in Section 41(2) by pointing to the absence of a formal acceptance instrument. In both settings, the law reads conduct in the electronic medium as carrying the same weight as conduct in the paper world, consistent with the legal-recognition philosophy of Sections 4 and 5 explored in our electronic governance chapter.
Consequences of breaching the subscriber's duties
Chapter VIII does not itself prescribe a penalty for breach; instead the consequences flow through other parts of the Act and the general law. A subscriber who fails in his Section 42 duty to guard the private key and report compromise bears civil liability for misuse during the window before reporting, by force of the Explanation to Section 42. Where misuse of a private key results in damage to a computer resource or to the relying party, the adjudicatory mechanism for compensation under Section 43 and the power to adjudicate under Section 46 may be engaged. Penal provisions can also bite on the wrongdoer who exploits the key: identity theft is punishable under Section 66C, and cheating by personation using a computer resource under Section 66D — both inserted by the 2009 amendment — capture the misuse of another person's electronic signature credentials.
False representations also carry consequences upstream. A subscriber who makes a false representation to obtain a certificate exposes himself to liability under Section 71 (penalty for misrepresentation to the Controller or Certifying Authority for obtaining a licence or certificate), and the Section 41(2) warranty makes such falsity actionable at the suit of any relying party who is misled. The picture that emerges is of a layered liability scheme: Chapter VIII sets the duties, and the penalty, compensation and offence chapters supply the sanctions. The subscriber who generates securely, accepts knowingly and guards diligently has little to fear; the careless or dishonest subscriber is exposed at several points at once.
Key management in practice: tokens, custody and reporting
The abstract duties of Chapter VIII translate into concrete key-management practices. In Indian practice, Class 3 Digital Signature Certificates — the highest assurance class, used for e-tendering, company filings and high-value transactions — are routinely issued on FIPS-compliant cryptographic USB tokens from which the private key cannot be exported. This hardware design is itself a way of discharging the Section 40 "security procedure" and the Section 42(1) "reasonable care" duties simultaneously: a key that never leaves the tamper-resistant token is far harder to compromise. The activation PIN guards the token, and a subscriber who shares that PIN, or hands the token to an unauthorised employee, risks breaching the reasonable-care standard.
The reporting duty under Section 42(2) is operationalised through the Certifying Authority's revocation and suspension machinery. On learning of a compromise, the subscriber must communicate "without any delay", and the Certifying Authority will typically suspend or revoke the certificate and publish the revocation, often through a Certificate Revocation List, so that relying parties cease to trust signatures made with the compromised key. This is why the chapter must be read alongside the certificate lifecycle in Chapter VII and the secure-record framework in our secure electronic records and signatures notes: the subscriber's report is the trigger that allows the whole system to quarantine a poisoned key.
Exam focus: how Sections 40–42 are tested
For judiciary and CLAT-PG aspirants, Chapter VIII rewards precision over breadth because it is so short. Examiners favour the exact triggers and timing rules. Common questions include: When is a subscriber deemed to have accepted a Digital Signature Certificate? — answer with the three limbs of Section 41(1): publication to one or more persons, lodging in a repository, or otherwise demonstrating approval. What does acceptance certify, and to whom? — the three clauses of Section 41(2), certified to "all who reasonably rely". Until when is a subscriber liable for a compromised key? — until he informs the Certifying Authority, per the Explanation to Section 42.
Watch for the amendment traps. Section 40A was inserted only by the 2009 amendment (with effect from 27 October 2009) to cover Electronic Signature Certificates, delegating the duties to prescribed Rules; do not confuse it with the digital-signature duties in Sections 40 to 42. Remember too that the 2002 notification broadened Section 42(1) by deleting the limiting words about disclosure "to a person not authorised to affix the digital signature", so the duty now covers any unauthorised disclosure. Finally, distinguish the reasonable care standard in Section 42(1) from strict liability: the subscriber's escape route is prompt reporting, not proof that compromise was impossible. Cross-reference the definitions chapter for "subscriber", "key pair", "private key" and "security procedure", all of which examiners expect you to deploy accurately.
Frequently asked questions
Who is a 'subscriber' under the Information Technology Act, 2000?
A subscriber is defined in Section 2(1)(zg) as a person in whose name the Digital Signature Certificate is issued. Chapter VIII (Sections 40 to 42) fixes that person with three core duties: to generate the key pair by applying the security procedure (Section 40), to accept the certificate with the warranties in Section 41, and to retain control of the private key and report any compromise without delay (Section 42).
When is a subscriber deemed to have accepted a Digital Signature Certificate?
Under Section 41(1), a subscriber is deemed to have accepted a Digital Signature Certificate if he publishes or authorises its publication to one or more persons, or lodges it in a repository, or otherwise demonstrates his approval of it in any manner. Acceptance is conduct-based — there is no prescribed acceptance form — and once acceptance occurs the subscriber gives the three-fold warranty in Section 41(2) to all who reasonably rely on the certificate.
Until when does a subscriber remain liable if his private key is compromised?
Under the Explanation to Section 42, the subscriber remains liable until he has informed the Certifying Authority that the private key has been compromised. Section 42(2) requires that communication to be made 'without any delay'. So liability for any misuse of the key continues right up to the moment of reporting; prompt reporting is the only way to cut off the exposure, and a delayed report leaves the subscriber carrying the risk of intervening misuse.
What standard of care does Section 42 impose on the subscriber?
Section 42(1) imposes a 'reasonable care' standard, not strict liability. The subscriber must exercise reasonable care to retain control of the private key and take all steps to prevent its disclosure. Following the 2002 notification (S.O. 1015(E)), the limiting words about disclosure to an unauthorised person were deleted, so the duty now covers any unauthorised disclosure. In practice the standard is met by using a secure cryptographic token, guarding the activation PIN, and not sharing the key beyond authorised persons.
How is Section 40A different from Section 40?
Section 40 is the original duty to generate the asymmetric key pair underlying a digital signature by applying the security procedure. Section 40A, inserted by the Information Technology (Amendment) Act, 2008 with effect from 27 October 2009, deals with Electronic Signature Certificates — the technology-neutral category introduced by Section 3A — and simply provides that the subscriber 'shall perform such duties as may be prescribed', delegating the content of those duties to subordinate Rules so they can fit whichever electronic-signature technique is in use.
Is there case law directly interpreting Sections 40 to 42?
Direct litigation on Sections 40 to 42 is scarce, because these duties are operational and back-end. However, the policy they serve — trust in electronic authentication and the reliability of electronic records — is reflected in cases such as State of Tamil Nadu v. Suhas Katti (2004), the first conviction under the IT Act, and in the Supreme Court's electronic-evidence line: Anvar P.V. v. P.K. Basheer, (2014) 10 SCC 473, and Arjun Panditrao Khotkar v. Kailash Kushanrao Gorantyal, (2020) 7 SCC 1, which together insist on a verifiable authentication chain through the Section 65B(4) certificate.