
India has temporarily restricted Telegram before the NEET UG 2026 re-examination. The stated reason is understandable. Fraudulent channels were allegedly selling “leaked papers”, collecting money from students and using Telegram’s message-editing feature to create false historical evidence. A message posted earlier could be edited after the examination, a different attachment could be inserted, and the old timestamp could then be presented as proof that the paper had circulated in advance.
Stopping this fraud is necessary. Students and families should not be exploited by people selling documents that may never have existed before the examination. Telegram channels used for deception should be investigated, payment accounts should be traced and those responsible should face the law.
But none of this answers the original question.
Telegram can circulate a file, advertise a claim and connect a seller with a buyer. It cannot enter a secured examination system, open a protected government account, access a printing facility or copy a confidential document from an official device. It cannot, by itself, explain how protected information first left the system that was supposed to secure it.
That is the question India has still not publicly answered.
The visible chain is not the complete chain
The present response follows what can be seen: a Telegram channel, a mobile number, a bank account, a seller and a payment. These are important leads, but they appear near the end of the journey.
A genuine source investigation must move backwards. It must begin with the Telegram operator and identify the person who supplied the material. It must then trace the supplier to the first device that handled the information, examine the applications installed on that device and identify every embedded software development kit communicating with external systems.
The investigation must continue from those applications to their network endpoints and from those endpoints to every company that received, analysed, retained or transferred the information.
Until that chain is reconstructed, investigators may identify the person selling a document without identifying the person—or the system—that first exposed it.
Closing the marketplace is not the same as finding the source.
I raised this issue before the Telegram action
This concern was not created after the latest headline.
I raised the wider data-security problem in connection with the Supreme Court’s suo motu digital-arrest proceedings and later through W.P. (Crl.) No. 163/2026. On 19 May 2026, the Supreme Court directed that the technical issues raised in my petition be examined by the Ministry of Electronics and Information Technology.
The petition concerned a larger weakness in India’s response to cybercrime. India has become increasingly effective at tracing money after a crime takes place, but there is still no clear public account of whether the stolen data that enabled the crime was recovered, destroyed or traced back to its original point of compromise.
A frozen bank account may stop one transfer. A compromised identity can generate the next hundred transfers.
The same principle applies to examination security. Blocking Telegram may stop one distribution channel, but it does not recover the original information, identify the first access point or establish whether the material came from an insider, a compromised official account, a contractor, a cloud system, an infected device or an application transmitting more information than its user understood.
The State may follow the payment and still miss the data trail that made the payment possible.
What DISHA identified
These questions emerged through the DISHA Intelligence Architecture, an evidence-first framework designed to connect information that is usually examined in isolation.
A device identifier may appear insignificant. A location signal may seem harmless. A file-opening event may look routine. A cloud login may not immediately attract attention, and an advertising request may appear unrelated to examination security.
But when these fragments are examined together, they can reveal a person, a routine, an institution and an opportunity.
That is the difference between data and intelligence. Data is the isolated signal. Intelligence appears when separate signals are connected and placed in context.
DISHA begins with the record rather than an accusation. It brings together device activity, location patterns, application behaviour, financial trails, government records, court proceedings and institutional responses. The purpose is not to declare guilt in advance. It is to identify the questions that institutions must investigate before the evidence disappears.
Through that architecture, digital arrest, examination security, financial systems and national security do not appear as entirely separate subjects. They are different environments in which compromised identity, behavioural and location data may be used against citizens or institutions.
The warnings were visible years ago
In 2020, India blocked several applications over data-security concerns. The names sounded ordinary: APUS Browser, APUS Launcher, APUS Security and APUS Turbo Cleaner.
A browser, launcher or phone-cleaning application does not immediately sound like a matter of national security. Yet the government itself referred to unauthorised data transmission, harvesting and profiling while announcing restrictions on several applications.
That should have led to a deeper investigation.
Was only the application blocked, or was the complete data architecture examined?
Modern applications are rarely built entirely by one company. They may contain third-party code for advertising, analytics, location, attribution, crash reporting and user engagement. The person installing one application may unknowingly communicate with several companies through software embedded inside it.
The user sees one icon. The device may communicate with many external systems.
Deleting one application does not necessarily remove the same SDK from another application. Blocking an app does not prove that information previously collected through it has been erased. Removing an icon from a phone also does not explain where the information had already travelled, who received it or whether profiles created from that information continue to exist.
The application is only the visible surface. The data pipeline may extend much further.
The microphone warning
SilverPush showed why the visible purpose of an application cannot be treated as a complete description of the code operating inside it.
In 2016, regulators in the United States warned developers whose applications appeared to contain SilverPush technology capable of detecting inaudible audio beacons through a phone’s microphone. A person might believe that the phone was inactive, while embedded software could still recognise a signal in the surrounding environment and connect that signal with the device.
This historical record does not prove that SilverPush caused an examination incident. It establishes a different and more important point: the user may not understand every function performed by code embedded inside an ordinary application.
That is why investigators must examine application packages, permissions, SDKs, runtime behaviour and network connections. The name of an application is not evidence of everything it does, and a privacy policy cannot replace forensic examination.
The location warning
The history involving InMobi provides another example.
In 2016, regulators in the United States alleged that its advertising technology could infer device location using information about nearby Wi-Fi networks, including in circumstances where ordinary location permission had been denied.
Again, this historical case does not prove that InMobi was involved in the NEET issue. It demonstrates why advertising technology cannot automatically be treated as a harmless banner displayed at the bottom of a screen.
Advertising infrastructure can connect applications, device identifiers, location signals and patterns of behaviour at enormous scale. That becomes relevant when the devices belong to examination officials, printers, contractors, vendors or other people with access to confidential material.
The question is not whether every SDK is guilty. The question is whether investigators examined this layer at all. If the answer is yes, the findings should be described. If the answer is no, then an important part of the examination-security environment remains unexplored.
A modern leak may begin without anyone stealing a paper
The public still imagines an examination leak as a simple physical event. Someone enters a secure room, photographs the paper and sends the image outside.
That can happen, but a modern data compromise may develop in a much less visible way.
A device may repeatedly appear near a printing facility. A cloud account may open an unusual file. A notification may expose part of a confidential filename. A backup application may synchronise a folder. A personal phone may connect to a restricted network. An advertising identifier may connect activity across several applications, while a location pattern reveals who was present when sensitive material was handled.
No single signal contains the entire examination paper. Together, however, the signals may reveal the person, the place, the time and the opportunity.
That is why examination security cannot stop at the door of a strongroom. It must extend to every connected device surrounding the examination chain, including official phones, contractor devices, cloud accounts, printing systems, vendor networks and third-party applications.
The examination paper may be protected while the people and devices around it remain visible.
What a real investigation should examine
A serious investigation should identify the first device that accessed, photographed, copied or transmitted the material. It should preserve forensic images of relevant official and contractor devices and document every application, package version and embedded SDK present on them.
Investigators should examine cloud-access records, file-opening histories, privileged-account activity, printing logs and vendor records. They should analyse network destinations contacted by relevant devices and determine whether advertising identifiers, location signals or other persistent identifiers were transmitted to external systems.
The original Telegram upload metadata, edit history and file hashes should also be preserved. Without that evidence, it may be impossible to distinguish a genuine pre-examination disclosure from a fraudulent offer to sell a paper that never existed or a post-examination edit created to manufacture false historical evidence.
These are three different events. Treating them as one problem risks confusing fraud, misinformation and actual leakage.
If the government disagrees, test the pathway
I am prepared to place the evidence, application history, SDK architecture and technical questions before MeitY, CERT-In, the investigating agencies or an independent forensic body.
If the government believes that the pathway described here is technically impossible, then the issue should not be settled through denial or public argument. It should be tested under controlled conditions.
The test can use synthetic examination files, laboratory devices, dummy identities and a sealed network. No genuine examination paper needs to be exposed. No candidate information should be published, no private credentials should be released and no operational vulnerability should be handed to criminals.
The purpose would be straightforward: to prove or disprove whether information can move from a device, application or embedded component to an external system without the user understanding the complete route.
That test should happen before the next real leak, not after another examination is cancelled, another group of students loses confidence and another trail of evidence disappears.
This would not be an attempt to create a leak. It would be a lawful effort to prevent one.
The real investigation begins before Telegram
Telegram sits at the visible end of the chain.
The real investigation begins before the message was written, before the PDF was attached, before money was demanded and before the seller approached a student.
It begins with the first unauthorised access, the first copied file, the first compromised account, the first unexplained device signal and the first external connection.
India has acted against the messenger. It must now investigate the machinery.
An examination paper does not leak itself. A platform may carry it, a fraudster may sell it and a bank account may receive the money. But somewhere before all of that, a person or a system must first open the vault. That is where the real NEET examination investigation begins. And that investigation has not yet been shown to the public.
Read the complete evidence record: www.thenitishkr.in
About the author: Nitish Kumar writes on digital constitutional personhood, Article 12, cyber evidence and public accountability through the DISHA Intelligence Architecture.
