The CBSE-OSM controversy exposes deeper faults in cybersecurity audits, procurement and institutional accountability
In February 2026, Nisarga Adhikary, a 19-year-old security researcher and Grade 12 student, discovered vulnerabilities in the online platform used for Central Board of Secondary Education’s (CBSE) pilot on on-screen marking (OSM) system. CBSE used a platform developed by Coempt Eduteck Private Limited, a private company that also provides technology solutions to state education boards and universities.
Keeping aside the purported merits and efficiency of OSM, as well as the controversies surrounding the procurement process, it is worth examining the failures that led to CBSE’s embarrassing OSM pilot and discussing how security should be addressed in mission-critical systems going forward.
Nisarga reported the vulnerabilities he found to the Indian Computer Emergency Response Team (CERT-In) on February 25 and received an acknowledgement from the agency the following day. Security researchers often report vulnerabilities to CERT-In because of its status as the national nodal agency for receiving and responding to vulnerability, and incident reports. However, many are unaware that CERT-In has no real enforcement powers.
Following Nisarga’s responsible disclosure, Coempt Eduteck Private Limited fixed the most serious of the several vulnerabilities he had reported. The vulnerability in question involved a client-side hardcoded credential that could be used to bypass the normal authentication process altogether, effectively functioning as an easily discoverable backdoor for anyone who examined the application. Nisarga sought updates from CERT-In on the status of his report for several weeks but did not receive a satisfactory response.
That remained the case until May 22, when Nisarga publicly disclosed all the vulnerabilities he had discovered, on his blog, including those that had not been fixed. It is worth noting that public disclosure of vulnerabilities is a recognised practice in the cybersecurity industry, particularly when vendors are unresponsive — a process commonly known as “full disclosure.” Google’s own vulnerability disclosure policy provides a 90-day disclosure timeline from the date of initial notification, which is reduced to seven days when there is evidence of active exploitation.
