By Anuradha Gandhi and Prateek Chandgothia
Introduction
On January 12, 2026, Press Information Bureau (hereinafter referred to as ‘PIB’) posted on ‘X’ denying any claims and reports stating that the Indian Government has proposed to force smartphone makers to give source code of their respective operating systems. PIB clarified that, as a regular and routine consultation, the Ministry of Electronics and Information Technology (hereinafter referred to as ‘MeitY’) has started the process of stakeholders’ consultations with the industry to devise an appropriate regulatory framework. However, no final regulations have been frame yet and any future framework will be formulated only after due consultations with the relevant industry stakeholders.[1]
Concerns around the alleged Proposal
On January 11, 2025, news reports surfaced claiming that the Indian Government had reportedly issued a proposal wherein smartphone makers will be mandated to disclose the source code of their respective software to government designated testing labs for the purpose of ensuring system security and compliance with published security standards. The reports state that smartphone manufacturers have flagged concerns around this proposal citing confidentiality and cybersecurity issues that may arise due to disclosure of their software source code to government designated testing labs.[2]
Why is disclosure of Source Code risky?
Source Code refers to a set of instructions written in a specific programming language such as Java or Python. These set of instructions govern the functioning and operation of an Operating System or an application. The digital devices use assistance applications, like compiler or interpreter to translate these set of instruction into an executable format. In essence, source code is the underlying skeleton of any digital operating system.[3]
Disclosure of source code can result in a major cybersecurity risk as it allows the hackers or other recipients of such source code to analyze and discover vulnerabilities in the code and allow the hackers to start a chain of cyber-attacks such as data base takeovers, remote code executions and SQL injection attacks.[4]
Disclosure of Source Code – Public Interest v. Confidential Trade Secrets
Disclosure of Source Code for purpose of testing safety and security of Mobile User Equipment can be considered as legitimate Public Interest. This draws an interesting scale of balance – whether disclosure of source code for public interest supersedes the interest of corporates to maintain trade secrecy and confidentiality?
Drawing a parallel from the decision of the Court of Justice of the European Union (hereinafter referred to as ‘CJEU’) in CK v. Dun & Bradstreet Austria GmbH[5] wherein the Court was required to balance the interest of Corporates to maintain trade secrecy with user’s right to request meaningful information about the logic involved when she is affected by decisions made solely on the basis of automated/ algorithmic processes. The respondent company argued that disclosing information about its credit assessment logic would reveal proprietary trade secrets as they would have to divulge sensitive information regarding their algorithm and other processes. However, the CJEU decided that trade secrets cannot be invoked as a general defense as the automated process is directly linked to making decisions that affect an individual and that it is the responsibility of the company to implement a mechanism to provide meaningful information while protecting its trade secrets.
Therefore, in this instance the scales of balance leaned in the favor of user’s rights and interests. It is important to note that the context of this decision is fairly distinct to the disclosure of source code by software makers to government registered labs for conducting security and safety tests. However, such disclosure may pass the legality test if the underlying purpose of such disclosure being security and safety is considered as a matter of Public interest. This is a question that remains to be answered by policy frameworks and Court judgements.
Mechanism for testing Smartphones for Safety and Security.
Indian Telegraph Act, 1885 [6]
Smartphones are considered ‘telegraphs’ under India Law. As per Section 2(1AA) of the Indian Telegraph Act, 1885, a ‘telegraph’ means –
“Any appliance, instrument, material or apparatus used or capable of use for transmission or reception of signs, signals, writing, images and sounds or intelligence of any nature by wire, visual or other electro -magnetic emissions, Radio waves or Hertzian waves, galvanic, electric or magnetic means”
In 2017, The Indian Telegraph Rules 1951[7] were amended by the Indian Telegraph (Amendment) Rules, 2017 (hereinafter referred to as ‘2017 Amendment’) [8] which inserted Part XI dealing with ‘Testing and Certification of Telegraph’. Through this 2017 Amendment, the definition of ‘Original Equipment Manufacturer’ (hereinafter referred to as ‘OEM’) was inserted along with some testing and certification obligations of the OEMs.
As per Rule 528 of the amended rules, OEM means –
“A manufacturer of telegraph under whose brand the telegraph is sold or proposed.”
Therefore, in context of smartphones, the smartphone manufacturers shall be considered ‘OEMs’
Under the rules inserted by the 2017 Amendment, telegraphs intended to be used, sold or imported in India must undergo mandatory testing as per the prescribed standards. In 2018, the Department of Telecommunications (hereinafter referred to as ‘DoT’) issued the Procedure for Mandatory Testing and Certification of Telecommunication Equipment (hereinafter referred to as ‘MTCTE’) which required all telecom equipment used, sold or imported in India to meet the essential requirement such as –
- Electromagnetic Interface and Electromagnetic Compatibility Requirements
- Safety Requirements
- Technical Requirements
- Cybersecurity Requirements
- Other Requirement as prescribed.
DoT launched a scheme named ‘Communication Security Certification Scheme’ (hereinafter referred to as ‘ComSec’) to implement the mandatory testing and certification in respect of security requirements in telecom equipments and established the National Centre for Communication Security (hereinafter referred to as ‘NCCS’) as the responsible entity to implement ComSec.[9]
Disclosure of Source Code under NCCS Security Standards for Smartphones
On April 6, 2023, the NCCS released the Indian Telecom Security Assurance Requirements (hereinafter referred to as ‘ITSAR’) for Mobile User Equipment defining the minimum security baseline standard for Mobile User Equipment such as smartphones, irrespective of the make, model or OS Platform of such Equipment. [10]
Section 6.17 of this ITSAR requires the performance of complete security assessment, Source Code Review/ Analysis, vulnerability analysis, penetration testing and fuzzing on all OEM- developed components on the mobile system by registered Telecom Security Testing Laboratories (hereinafter referred to as ‘TSTL’). Thereafter, the OEM shall provide the TSTL and the NCCS with documentary evidence including test reports as well as required inputs such as source code to review the full security development lifecycle to secure certification for use, sale and import of such Mobile User Equipment in India.
While these standards were released in 2023, they are yet to be enforced. Notably, enforcement of these Standards might be a part of the stakeholders’ discussion undertaken by MeitY as stated in the clarification issued by PIB. However, as of now, there is no confirmation or clarity regarding this.
Data Protection Requirements under the ITSAR for Mobile User Equipment
Cybersecurity Measures to Protect Data
The ITSAR for Mobile User Equipment also lists multiple requirements for ensuring Data Protection under Section 6.5. Therefore, if these standards are enforced, the OEMs will be required to comply with the following requirements:
- Encryption – Cryptographic protection of all or portions of a device’s data storage locations.
- SIM Card Locking – Device shall provide an option to the device users to lock the SIM card with authentication attribute.
- Secure Storage – The device shall offer a secure storage solution that uses hardware/ software-based mechanisms to protect the data.
- Memory Isolation – One Process shall not be able to access or modify another processes memory.
User Privacy and Mobile Device Management
The ITSAR also addresses the issue of user privacy in devices with Mobile Device Management (hereinafter referred to as ‘MDM’). MDM is a type of security software that enables organizations to secure, monitor, manage and enforce policies on employee’s mobile devices. The requirements seek to separate business data and personal data by ensuring –
- Access Controls – The MDM admin shall possess only the access rights approved by the user as per the access control policies. MDM shall not be given access to data belonging to other applications installed on the device unless user consent is granted and shall not be allowed to install or remove any applications/ processes without user consent.
- Data Separation – The Mobile User Equipment shall enforce the MDM application to create and use its own container to isolate business data (like corporate emails, corporate documents on devices) and personal data. The MDM application shall not be able to access user’s personal data such as photos, videos, email, location etc.
Other Privacy Related Requirements
- Permissions from User – Application seeking permission to access to Camera, Micro phone, Location Services, Phone and Contacts can only use the permissions when the application is in use and when in use, the user shall be notified of the same in the notification/ status bar.
- User Consent for Advertisements – If device implementations include adding or pushing of items such as advertisements etc. then those shall be explicitly intimated to the user and ask for user consent before enabling the same.
- Malware Protection – Mobile User Equipment shall provide service for known malware detection and protection. It shall scan the devices periodically to identify the known malware to protect the user data.
- Isolate System Privileges – System Apps shall not run with shared system unique identifier with any other Partner, 3rd Party or Pre-Installed Application to avoid unintended privilege escalation thus endangering user’s privacy.
- Privacy Policy – Mobile User Equipment shall intimate the owners regarding the privacy implications of certain device and application functionality during device management setup/ device setup through a privacy policy presented to users in the form of a warning banner which should be short and crisp. Any information regarding collection of usage statistics and user data shall be clearly indicated in the banner itself in highlighted text.
- Logs to exclude Personal Data – The log entries shall not include messages with privacy-related information such as e-mail addresses, passwords, contact information, SMS or MMS, One Time Passwords, Financial Information, Credit/ Debit Card Information, etc. The preinstalled or system applications shall not log any sensitive or personal information.
- Retention of Logs – The Mobile User Equipment shall log all important security events with unique System Reference and shall be stored for a minimum period of 12 months.
Relevance of the Digital Personal Data Protection Framework
The requirements under ITSAR are in alignment with the Digital Personal Data Protection Act, 2023 and the Rules made thereunder (hereinafter referred to as ‘DPDP’). DPDP prescribes user consent as the main ground for lawfully processing personal information. Additionally, DPDP prescribes certain obligations for Data Fiduciaries, in this case the OEMs when PI is collected through system processes and application. OEMs shall therefore, comply with the obligations of the Data Fiduciaries as given under DPDP.
(To read more on the obligations of Data Fiduciaries under DPDP, refer – https://ssrana.in/articles/meity-notifies-final-digital-personal-data-protection-rules-2025/ )
[3] https://www.invicti.com/learn/source-code-disclosure
[4] https://www.acunetix.com/blog/articles/source-code-disclosure-dangerous/
[6] https://www.indiacode.nic.in/bitstream/123456789/13115/1/indiantelegraphact_1885.pdf
[8] https://www.tec.gov.in/pdf/Whatsnew/eGazetteNotif.pdf