CERT-In Logs and End-to-End Encrypted Messaging: What a Provider Can and Cannot Log

Short answer: India's CERT-In Directions of 28 April 2022 require service providers to keep logs of their ICT systems for 180 days and report serious incidents within 6 hours. They do not require anyone to keep, or be able to read, message content. An end-to-end encrypted messenger can comply with the logging rules without weakening encryption, because the logs that matter are about systems and accounts, not conversations. What it cannot avoid is that those logs, and the metadata it needs to deliver messages, are readable and can be ordered out.

The Directions have been summarised many times since 2022, usually for banks, cloud hosts and VPN companies. This guide applies them to an end-to-end encrypted (E2EE) messaging provider, reconciles them with the logging rules in the Digital Personal Data Protection (DPDP) Rules 2025 and sections 69 and 69B of the IT Act, and then uses Lupyd as a worked example. It is written for anyone choosing a messaging vendor, including CA and law firms that need to know what a provider could be asked to hand over.

What the CERT-In Directions Require

CERT-In issued the Directions (No. 20(3)/2022-CERT-In) under section 70B(6) of the Information Technology Act, 2000, which lets it call for information from and give directions to "service providers, intermediaries, data centres, body corporate and any other person." They took effect 60 days after issue. A follow-up order dated 27 June 2022 pushed the date to 25 September 2022 for micro, small and medium enterprises.

The six CERT-In directions, and whether each applies to a messaging provider
Direction	What it requires	Applies to an E2EE messenger?
(i)	Synchronise all ICT system clocks to the NTP servers of NIC or NPL, or to a source that does not deviate from them.	Yes. Applies to every covered entity.
(ii)	Report the incident types in Annexure I to CERT-In within 6 hours of noticing them or being told about them.	Yes. Includes data breaches, data leaks, unauthorised access and attacks on servers and cloud systems.
(iii)	Provide information or assistance when CERT-In orders it, and designate a Point of Contact.	Yes.
(iv)	Enable logs of all ICT systems and keep them securely for a rolling 180 days, and hand them over with an incident report or on CERT-In's order.	Yes. This is the direction that matters most for a messaging provider.
(v)	Data centres, VPS, cloud and VPN service providers must keep validated subscriber details for 5 years.	Usually not, unless the provider also sells hosting, cloud or consumer VPN services.
(vi)	Virtual asset providers must keep KYC and transaction records for 5 years.	No.

The log direction reads in full: covered entities "shall mandatorily enable logs of all their ICT systems and maintain them securely for a rolling period of 180 days and the same shall be maintained within the Indian jurisdiction." Logs must be provided to CERT-In "along with reporting of any incident or when ordered / directed by CERT-In." Failing to comply, the Directions say, "may invite punitive action under sub-section (7) of the section 70B."

What the May 2022 FAQs Clarified

On 18 May 2022 CERT-In published a 28-page FAQ. It says it is "not a legal document" and does not amend the Act or the Directions, but it is the clearest statement of how CERT-In reads its own rules. The answers that matter for messaging providers:

Who is covered (Q7, Q25, Q26). Service providers, intermediaries, data centres, body corporate and government organisations; "individual citizens are not covered." A "body corporate" takes the section 43A meaning, which includes "a firm, sole proprietorship or other association of individuals engaged in commercial or professional activities." For incident reporting, the Directions apply "to any entity whatsoever," including foreign firms serving Indian users.
Which logs (Q37). It depends on the sector. CERT-In lists firewall, intrusion prevention, SIEM, web, database, mail, FTP and proxy server logs, event logs of critical systems, application logs, SSH logs and VPN logs, and says the list is "not exhaustive." Both successful and unsuccessful events should be recorded. Message content is not on the list.
Where logs are kept (Q35, Q36). Q35 says logs "may be stored outside India also as long as the obligation to produce logs to CERT-In is adhered to by the entities in a reasonable time." Q36 then says any provider serving Indian users "needs to enable and maintain logs and records of financial transactions in Indian jurisdiction." Law firms, including Linklaters, have pointed out that the two answers pull in different directions. The cautious reading is to keep logs that can be produced from India quickly.
Privacy (Q20). CERT-In says the Directions do not envisage "seeking of information by CERT-In from the service providers on continuation basis as a standing arrangement," only case by case for incidents.
Who can ask (Q38). A requisition for logs may come from a CERT-In officer not below the rank of Deputy Secretary.
Reporting can't be contracted away (Q13, Q22). Any entity that notices an incident must report it. The duty "overrides any confidentiality clause in any contract."
Enforcement (Q23). Non-compliance may attract section 70B(7), but CERT-In says this power "will be exercised reasonably and on occasions when the non-compliance is deliberate."

The Directions were controversial. SFLC.in criticised the log requirement for failing to "define the kind of logs" to be kept, and several VPN companies removed their Indian servers. SnT Hostings, an Indian VPN and hosting provider, challenged the Directions in the Delhi High Court; notice was issued in September 2022 and the government filed its counter affidavit in December 2022. We could not find a reported final decision, so the Directions should be treated as in force.

What an E2EE Provider Can and Cannot Log

End-to-end encryption means the keys that decrypt messages are generated and kept on users' devices. The provider's servers relay and store ciphertext. That draws a clean line through the CERT-In requirements:

The provider cannot log message content in readable form. It never has it. Nothing in the Directions or FAQs requires a provider to be able to read messages, and the FAQ's list of logs is about systems, networks and applications.
The provider can and should log its own systems. Server access, authentication, firewall, database and deployment logs are ordinary security practice, and they are what an incident responder needs.
The provider will hold metadata. To deliver messages it needs to know which account sends to which, and when. Encryption protects what you say, not that you said something to someone.

The practical risk is not that CERT-In logging breaks encryption. It is that careless logging leaks what encryption protects. Application logs that print request bodies, debug traces with decrypted previews, or crash reports with message text would all put content into a 180-day log. A well-built E2EE service keeps content out of its logs by design, and its server never sees plaintext to log in the first place.

Log types at an end-to-end encrypted messaging provider
Log type	Who holds it	Can the provider read content?	CERT-In and legal relevance
Message, file and backup content (ciphertext)	Provider's relay or storage, in encrypted form	No. Keys stay on users' devices	Not an ICT system log. The provider can only produce ciphertext it cannot decrypt.
Encryption keys	Users' devices only	Not applicable: the provider never holds them	None directly. Under the 2009 decryption rules, a decryption order to an intermediary is limited to what it encrypted or holds the key for.
Account identifiers (username, email, phone)	Provider, or its sign-in provider	Yes, these are not message content	Supports incident analysis. Separately, the IT Rules 2021 require registration data to be kept 180 days after an account is closed.
Sign-in and authentication events	Provider or its identity provider	Yes	Core evidence for 'unauthorised access' and 'unauthorised access to social media accounts' incidents.
Device records and push tokens	Provider; push services such as Google FCM	Yes	Helps reconstruct which device did what, and when.
Delivery metadata (who messaged whom, when)	Provider's relay	Yes, but not what was said	Falls within 'traffic data' under section 69B and 'associated traffic data' under DPDP Rule 8(3).
Group names, membership, join and leave times	Provider	Yes, for most E2EE group designs	Useful in investigations; part of what an order can reach.
IP addresses and HTTP request logs	Provider's servers and/or its CDN or edge network	Yes	Classic ICT logs: web and proxy server logs are named in CERT-In's FAQ list.
Firewall, IDS, SSH, database and application logs	Provider's infrastructure and cloud hosts	Yes, and they should not contain message content	The core of direction (iv) and FAQ Q37.

Note the second column. A messaging provider rarely holds every log itself. Sign-in providers, CDNs, cloud hosts and push services each keep their own records, and the FAQ (Q13, Q31) makes each entity that notices an incident responsible for reporting it. When you assess a vendor, ask about its sub-processors' logs as well as its own.

Clock Sync and the 6-Hour Report

Two other directions apply to a messaging provider in the same way they apply to any online service.

Clock synchronisation. All ICT systems must sync to NIC (samay1.nic.in, samay2.nic.in) or NPL (time.nplindia.org), or to a standard source that does not deviate from them. The FAQ (Q40 to Q42) confirms that clocks need not run in IST, that UTC is fine if the time zone is recorded, and that cloud customers can keep using their provider's native time service. The reason is practical: incident timelines are built by lining up logs from many systems, and that fails if the clocks disagree.

Six-hour reporting. Incidents listed in Annexure I, which include data breaches, data leaks, unauthorised access, attacks on servers and cloud systems, malicious mobile apps and fake apps, must be reported within 6 hours of noticing them. FAQ Q30 allows a partial first report, with more detail "within reasonable time." For an E2EE messenger, a breach of its servers usually exposes metadata and ciphertext rather than message content, but a metadata leak is still a data leak and is still reportable. Our first-24-hours breach checklist for India covers the reporting steps.

How the DPDP Rules 2025 Change the Picture

The DPDP Rules 2025 were notified on 13 November 2025 (G.S.R. 846(E)). Two rules deal with logs, and both go further than CERT-In in one respect: they set a one-year period. We checked both against the Gazette text published by MeitY.

Rule 6(1)(c) and (e): security logs. A Data Fiduciary must have "visibility on the accessing of such personal data, through appropriate logs, monitoring and review," and, to detect and investigate unauthorised access, must "retain such logs and personal data for a period of one year, unless compliance with any law for the time being in force requires otherwise."
Rule 8(3): processing logs for State purposes. A Data Fiduciary "shall retain ... such personal data, associated traffic data and other logs of the processing for a minimum period of one year from the date of such processing, for the purposes as specified in the Seventh Schedule," then erase them unless another law requires more. The Seventh Schedule purposes are use by the State in the interest of sovereignty, integrity or security of India, use by the State to perform functions or meet obligations under Indian law, and assessment for Significant Data Fiduciary status.

Rule 8(3)'s own illustration shows the reach: an e-book platform "must retain the order details, personal data, and logs of the processing ... for at least one year from the date of the transaction, even if X deletes her account."

When they apply. Under Rule 1(4), Rules 6 and 8 come into force eighteen months after Gazette publication, which commentators put at 13 May 2027. In early 2026 MeitY reportedly consulted on shortening this window and bringing Rule 8(3) forward. As of this writing we have not found a notified amendment, so check the Gazette before relying on either date.

How CERT-In and DPDP fit together. They do not conflict. CERT-In sets 180 days as a floor for ICT system logs; DPDP sets one year for personal-data access logs and processing logs. A provider that keeps relevant logs for one year satisfies both. The harder questions for an E2EE provider are about Rule 8(3):

"Associated traffic data" plainly covers delivery metadata such as sender, recipient and timestamp. That metadata would need to be kept for a year even where a provider currently deletes it sooner.
Whether "such personal data" requires a relay to keep ciphertext it can never decrypt for a year is unclear. The rule does not mention encryption, and there is no guidance yet.
Rule 8(3) data is retained for State purposes, which makes it reachable by authorised officers. Data minimisation now has a legal minimum as well as a maximum.

For the wider DPDP obligations on team chat, see our DPDP Act guide for team messaging.

Sections 69 and 69B: What Can Be Ordered Out

CERT-In's power is about cyber security. The powers to intercept, decrypt and collect traffic data for law enforcement sit elsewhere in the IT Act:

Section 69 lets authorised government agencies intercept, monitor or decrypt information in any computer resource, and requires intermediaries to provide technical assistance. Rule 13(3) of the 2009 interception and decryption rules limits a decryption direction to an intermediary "to the extent the information is encrypted by the intermediary or the intermediary has control over the decryption key." A true E2EE provider holds no decryption keys for message content, so it can hand over ciphertext but cannot decrypt it.
Section 69B lets the government authorise an agency to monitor and collect "traffic data," defined as data identifying a person, computer or location a communication comes from or goes to, including its origin, destination, route, time, date, size, duration or type of service. This is exactly the metadata an E2EE relay sees.
IT Rules 2021, Rule 3(1)(h) separately requires intermediaries to keep information collected at registration for 180 days after an account is cancelled or withdrawn. It is a different 180 days from CERT-In's, and they are often confused.

Put together: under Indian law, an E2EE provider's metadata, account records and system logs are all within reach of a lawful order, and from 2027 some of them must be kept for at least a year. The content of messages is not, because the provider never had it in readable form. Traceability under Rule 4(2) of the IT Rules is a separate fight, covered in our piece on WhatsApp, encryption and traceability in India.

Worked Example: What Lupyd Holds

To make this concrete, here is what Lupyd stores today, based on a review of our own code. Message, file and backup content is end-to-end encrypted on the user's device: direct messages use the Signal Protocol and groups use MLS. Everything else in the table is readable to us or to the provider named.

What Lupyd and its providers hold
Data	Where	Readable by the holder?
Message, file and backup content	Lupyd relay and encrypted storage	No. Encrypted on device (Signal Protocol for DMs, MLS for groups)
Usernames	Lupyd servers	Yes
Device records: device ID, platform, last connected time, FCM push token	Lupyd servers	Yes
Sender, recipient and timestamp of queued DMs; conversation pairs	Lupyd relay	Yes. Delivered DMs are deleted from the relay 30 days after delivery
Group names, descriptions, membership, join and leave times	Lupyd servers	Yes
Meeting participation	Lupyd servers	Yes
IP addresses	Not stored by Lupyd's own app servers; Cloudflare, in front of our services, keeps request logs including IPs	Yes, at Cloudflare
Email address and login events	Auth0 (EU tenant)	Yes, at Auth0

Applying the rules above to this list:

Content. We could produce only ciphertext. We do not hold the keys, so a decryption direction has nothing to act on.
CERT-In direction (iv). The logs that matter are our servers' own system, access and application logs, plus the request logs Cloudflare keeps at the edge and the login events Auth0 keeps. Because our application servers do not record IP addresses, the IP evidence for an incident would come from Cloudflare's logs, not ours. Meeting the Directions means making sure those logs exist, are kept for a rolling 180 days, are clock-synced, and can be produced promptly.
DPDP Rule 8(3). Our relay deletes delivered direct messages 30 days after delivery. That was a privacy choice. Rule 8(3), once in force, may require the associated traffic data, and possibly more, to be kept for a year.

We are reviewing our log retention against the CERT-In Directions and the DPDP Rules' commencement dates, and we will update our published retention details when that review is done. We are not claiming compliance here, and we would rather say so plainly. Our GDPR post lists our sub-processors and known gaps in more detail.

Questions to Ask a Messaging Vendor

Your firm is itself a "body corporate" under the FAQ's definition, so the Directions apply to your own ICT systems too, and your reporting duty cannot be handed to a vendor. When choosing a messaging provider, ask:

Is message, file and backup content end-to-end encrypted by default, and who holds the keys?
Which metadata do your servers see: who messages whom, when, group membership, IP addresses?
Which system logs do you keep, for how long, and do any of them ever contain message content?
Which third parties (sign-in, CDN, hosting, push) keep their own logs about our users, and for how long?
Are your clocks synced to NIC, NPL or an equivalent source?
Who is your CERT-In Point of Contact, and how will you tell us about an incident that affects our data?
How are you preparing for DPDP Rule 6 and Rule 8(3) retention?

A vendor that answers the first three questions vaguely is telling you something. For more on choosing tools for client work, see our guide to secure client communication for law and CA firms.

Frequently Asked Questions

Do the CERT-In Directions require messaging apps to store message content?

No. Direction (iv) requires logs of ICT systems to be kept for a rolling 180 days. CERT-In's FAQ lists examples such as firewall, server, application, SSH and VPN logs. Message content is not among them, and an end-to-end encrypted provider cannot read content anyway.

Can CERT-In make an end-to-end encrypted provider decrypt messages?

CERT-In's directions are about cyber security logs and incidents, not decryption. Decryption orders come under section 69 of the IT Act, and the 2009 rules limit them to information the intermediary encrypted or holds the key for. An E2EE provider does not hold message keys, so it can produce only ciphertext.

Must CERT-In logs be stored in India?

The Directions say logs must be maintained within Indian jurisdiction. CERT-In's May 2022 FAQ (Q35) says they may be stored outside India as long as they can be produced to CERT-In in a reasonable time, but Q36 says providers serving Indian users must maintain logs in Indian jurisdiction. The safe course is to keep logs that can be produced from India quickly.

How do the DPDP Rules 2025 change log retention?

Rule 6 requires Data Fiduciaries to keep access logs and related personal data for one year to detect and investigate unauthorised access. Rule 8(3) requires personal data, associated traffic data and processing logs to be kept for at least one year for State purposes listed in the Seventh Schedule. Both come into force eighteen months after the November 2025 notification, unless the timeline is amended.

Do the CERT-In Directions apply to CA and law firms?

Yes. CERT-In's FAQ applies the section 43A definition of "body corporate," which includes a firm or sole proprietorship engaged in professional activities. Firms must keep logs of their own ICT systems, sync clocks and report listed incidents within 6 hours, and the reporting duty cannot be contracted away to a vendor.

Final Takeaway

CERT-In's Directions ask for logs about systems, not conversations, so an end-to-end encrypted messenger can meet them without weakening encryption. What changes is the metadata. Under CERT-In for 180 days, and under the DPDP Rules for a year from 2027, the records of who used a service, from where and when, become a legal obligation to keep rather than a choice. When choosing a vendor, ask not only whether messages are encrypted but what the provider and its sub-processors log, and for how long. To see how an E2EE workspace handles this in practice, try Lupyd.

Sources & References:

Last updated: 3 November 2026. This article is general information, not legal advice. The CERT-In FAQs are not legally binding, the DPDP Rules' commencement dates may be amended, and a challenge to the Directions has been before the Delhi High Court since 2022; check primary sources and take advice before relying on any detail.