Why IIT Madras Was Called to Fix CBSE's Revaluation Portal

When 9.86 Million Scripts Go Digital

CBSE's deployment of On-Screen Marking for Class 12 board exams in 2026 was, by any measure, an extraordinary logistical achievement. Nearly 98.6 lakh physical answer scripts were scanned, uploaded, and distributed to over 77,000 trained teacher-evaluators who assessed them on-screen. Results were declared.

Then students tried to access their scanned answer sheets and apply for re-evaluation — and the portal buckled.

Login failures. Payment gateways that accepted fees but delivered nothing. Screens that refused to load the scanned scripts students had just paid Rs 100 to view. These were the complaints that flooded social media in the third week of May 2026. The Union Ministry of Education, already monitoring the OSM controversy, escalated quickly. Officials asked IIT Madras to step in and audit the technical infrastructure of CBSE's revaluation e-portal.

That decision — bringing in an IIT rather than scrambling a vendor patch — deserves attention from every institution that is building, scaling, or procuring a digital evaluation system.

What IIT Madras Was Asked to Examine

According to Ministry of Education officials, the IIT Madras team was tasked with three specific areas:

The team was also asked to propose strategies to prevent future disruptions. This is, in effect, an independent post-mortem that will shape CBSE's technical architecture for next year's revaluation cycle.

The Two-Layer Problem

Most institutions considering digital evaluation focus on the evaluation layer — the scanning hardware, the evaluator interface, the marking software, the double-blind moderation workflow. These are the right things to prioritise. But CBSE's May 2026 experience reveals a second, equally important layer: the student-facing interface that activates after marks are declared.

Under any evaluation system, students have rights once results are published: to view their evaluated scripts, to request mark verification, to apply for re-evaluation. Under paper-based systems, these rights were largely theoretical — slow, expensive (Rs 700 per subject until CBSE reduced the fee this year), and logistically inaccessible for most students. Digital evaluation should make these rights practically available. But only if the student portal holds up under load.

The evaluation layer produced 98.6 lakh evaluable scripts over several weeks, with thousands of evaluators working in shifts. The portal layer then needed to serve potentially hundreds of thousands of simultaneous requests from students, parents, and school administrators within a window of less than a week. That asymmetry — a slow, distributed production pipeline followed by a sharp, synchronised demand spike — is the design failure CBSE's portal was not prepared for.

Five Infrastructure Lessons for Universities

1. Separate the evaluation pipeline from the student portal

The infrastructure that powers evaluator access — authenticated, sequential, audited — has completely different load characteristics from the student portal, which is effectively a public web application with extreme concurrency spikes. Treating them as the same system, or even hosting them on the same infrastructure, is an architectural mistake that will surface under pressure.

2. Load-test against realistic demand curves, not averages

For CBSE, the revaluation window is short and heavily front-loaded. Demand is not spread evenly across five days — it peaks sharply on day one. Load testing must simulate this spike. Average concurrent users is a meaningless number here. For any university, the demand profile around result day and the re-evaluation window must be explicitly modelled and tested against.

3. Design payment gateway integration with failure in mind

Payment gateways are third-party dependencies with their own failure modes, rate limits, and maintenance windows. A robust student portal must handle gateway timeouts gracefully: logging the payment attempt, preserving session state, and allowing students to resume after a failure rather than forcing them to restart and potentially pay twice. Fee reconciliation logic must be built in, not bolted on.

4. Login authentication must degrade under load without locking users out

OTP-based authentication systems fail when the SMS provider or authentication server becomes a bottleneck. Under peak load, queuing OTPs is preferable to dropping them. Backup authentication paths — email OTP, pre-registered device tokens — provide redundancy. More critically, the system must give users clear feedback about delays rather than silent failures that students interpret as "my account is wrong."

5. The audit trail in the student portal is as important as the audit trail in the evaluation module

Part of what IIT Madras was asked to do was reconstruct exactly which students paid, which requests were processed, and which fell through the cracks. This forensic work is necessary — but it would be unnecessary if the portal had built-in audit logging from day one. Immutable payment and request logs, correlated with session IDs and timestamps, should be a standard feature of any student-facing evaluation portal.

What Makes This Different from the March 2026 Evaluator Glitches

It is worth distinguishing this incident from the evaluator-side glitches CBSE faced in March 2026, when teachers reported server crashes and interface issues during the evaluation phase itself. Those failures were about evaluator tooling — the marking software, the login system for teachers, the data synchronisation layer.

The May 2026 portal failure is categorically different: it is about student access to their own evaluation records after the fact. The stakes are also different. When an evaluator cannot log in, a supervisor can intervene. When a student pays a fee, submits an application, and receives nothing — with a closing deadline approaching — there is no institutional safety net. The consequences for individual students can be significant, particularly those applying for re-evaluation in subjects that affect university admissions.

What Affiliating Universities Should Take From This

CBSE operates at a scale that most universities will never approach. But the failure modes it encountered — portal load, payment integration, authentication bottlenecks — are not unique to that scale. Any university serving 40,000 or more students, with a concentrated post-result revaluation window, will encounter the same problems if the student portal is treated as secondary infrastructure.

The specific lesson from CBSE's decision to call IIT Madras is this: evaluation infrastructure is engineering, not just software procurement. Vendors offering "exam management solutions" may have excellent evaluation modules and deeply inadequate portal infrastructure. Procurement processes for digital evaluation systems should include explicit technical requirements for student portal performance, load capacity, payment gateway resilience, and audit logging — with independent technical assessment of whether those requirements are met.

CBSE's revaluation portal failure does not undermine the case for digital evaluation. It underlines it: the ability to call in IIT Madras, generate a technical audit, identify specific failure points, and commit to fixing them before next year is only possible because the system is digital. A paper-based revaluation process accumulates the same failure modes invisibly, and they never get systematically fixed.

Related Reading