The Role of CERT-In in Protecting India's Cyberspace

...which is probably why most people find out about CERT-In only after something's already gone wrong. A ransomware attack locks a hospital's patient records, a state electricity board's SCADA systems get probed at 2 a.m., some fintech startup discovers its customer database on a Telegram channel — and somewhere in the background, an agency you've likely never Googled swings into action. Or tries to. The Indian Computer Emergency Response Team, known as CERT-In, has been around since 2004, sitting under the Ministry of Electronics and Information Technology. For most of that time, it operated in relative obscurity, publishing vulnerability advisories that few read and coordinating incident responses that fewer heard about.

Then came April 2022, and everything changed.

A Brief, Incomplete History

CERT-In was formally established under Section 70B of the Information Technology Act, 2000, though the actual notification came years later. Its original mandate was modest by today's standards: collect and analyze information on cyber incidents, issue forecasts and alerts, coordinate emergency measures, and provide guidance on incident prevention. Think of it as a fire department for the internet — except one that also writes the building codes.

Through the 2010s, the agency grew quietly. It published advisories on everything from Android vulnerabilities to phishing campaigns spoofing SBI and ICICI Bank login pages. It ran training programs for government IT staff. It built relationships with counterpart agencies abroad — the US-CERT, JPCERT/CC in Japan, CERT-EU. But if you asked the average Indian netizen what CERT-In did, you'd get a blank stare. That isn't entirely the agency's fault; incident response work, by nature, happens behind closed doors.

What pushed CERT-In into public consciousness was a single document: the Directions under sub-section (6) of section 70B of the IT Act, released on April 28, 2022. These weren't suggestions. They were legally binding mandates, and they upended how companies across India — and several outside it — handle cybersecurity data.

The 2022 Directives: What Actually Changed

Before the directives, incident reporting was a loose affair. Organizations could take days, weeks, or sometimes never to report breaches. The new rules compressed that timeline to something almost absurd: six hours. Not six business hours. Six hours from when you notice the incident. That includes weekends, holidays, 3 a.m. on Diwali — whenever.

Here's what the directives mandated, stripped of the legalese:

Six-hour reporting. Any organization that experiences a cyber incident — unauthorized access, data breach, ransomware, denial-of-service attack, defacement, you name it — must report it to CERT-In within six hours of becoming aware. The list of reportable incidents is long. It includes things like targeted scanning of networks, compromised websites, identity theft, and attacks on IoT devices. You're supposed to report even if you're still figuring out the scope.

Log retention for five years. VPN providers, cloud service providers, data centers, and virtual private server providers must maintain logs of their customers for a rolling five-year period. That means subscriber names, IP addresses assigned, email addresses used at registration, timestamps, and purpose of use. Even after a customer cancels their account, those logs stick around.

VPN and crypto exchange KYC. VPN companies serving Indian customers must keep validated customer records. Cryptocurrency exchanges and wallet providers must maintain know-your-customer data and records of financial transactions for five years. This one got a lot of attention internationally — several VPN providers, including ExpressVPN and Surfshark, pulled their physical servers out of India rather than comply.

Mandatory NTP synchronization. All service providers must sync their system clocks to India's National Time Protocol servers (NTP from NIC or NPL) or to global NTP sources traceable to these. Sounds boring. It matters enormously for forensic investigations, because accurate timestamps are the backbone of incident reconstruction.

How Incident Response Actually Works

Say a mid-sized Indian bank discovers that an attacker exfiltrated customer records. Here's a rough sketch of what happens — keeping in mind that no two incidents play out identically:

The bank's security operations center spots anomalous data flows at, let's say, 11 p.m. on a Tuesday. Under the new rules, by 5 a.m. Wednesday, they need to have filed a report with CERT-In through the agency's incident reporting portal. The report doesn't need to be exhaustive at this stage — CERT-In understands that investigations take time — but it does need to cover the basics: what systems were affected, what type of incident occurred, preliminary scope, and contact information for the technical team.

CERT-In's analysts, working from their operations center in New Delhi (with satellite presence in a few other cities), triage the report. If it's a known attack vector — say, a vulnerability in an unpatched Apache server — they might issue remediation guidance quickly. For more complex incidents, they'll assign a response coordinator who works directly with the bank's IT team. In some cases, CERT-In deploys on-site support, though the agency's staffing constraints probably limit how often this happens in practice.

The agency also cross-references the incident against its database of ongoing threats. If the same attacker infrastructure — command-and-control servers, phishing domains, malware signatures — has shown up in reports from other organizations, CERT-In can connect those dots and issue targeted alerts. This threat intelligence sharing, even when it's imperfect, is probably the single most valuable thing the agency does.

Vulnerability Coordination and Advisories

CERT-In's advisory output is staggering in volume, if not always in accessibility. In a typical month, the agency publishes dozens of vulnerability notes covering everything from flaws in Microsoft Windows and Google Chrome to bugs in lesser-known software used by Indian government departments. Each advisory gets a severity rating and includes affected versions, a description of the vulnerability, and recommended patches or workarounds.

The trouble is presentation. CERT-In's advisories read like they were written for other CERT-In analysts, not for the sysadmins and CISOs who need to act on them. They're heavy on CVE numbers and light on plain-language risk assessment. A hospital IT manager in Lucknow trying to figure out whether a particular OpenSSL vulnerability affects their patient records system will struggle with the format. This isn't a unique problem — most national CERTs have similar readability issues — but it does limit the advisories' practical reach.

That said, some of their work has had tangible, measurable impact. The Cyber Swachhta Kendra (Botnet Cleaning and Malware Analysis Centre), launched around 2017, provides free tools for Indian users to detect and remove botnet infections from their devices. Internet service providers get notified about compromised IP addresses on their networks, and the cleanup rates, while not publicly reported in great detail, appear to have improved over the years.

Criticisms — and There Are Several

No honest assessment of CERT-In can skip the criticisms, and they're not trivial.

Staffing. For a country with over 800 million internet users — a number that's probably outdated by the time you read this — CERT-In's team is surprisingly small. Exact headcount figures aren't regularly published, but estimates from various government reports and parliamentary questions suggest a core technical staff of somewhere between 100 and 200 people. Compare that with the United States' CISA, which employs thousands, or even Singapore's CSA with several hundred for a country of 6 million people. India's ratio of cyber defenders to internet users is, to put it mildly, concerning.

The six-hour window. Privacy advocates and industry groups have both pushed back on this. Six hours is unrealistic for many organizations, particularly smaller ones without dedicated security operations centers. Even large companies often take days to confirm an incident, let alone characterize it. The concern isn't just about compliance burden — it's that the rush to report within six hours might produce low-quality, misleading incident reports that waste CERT-In's limited analytical resources.

VPN and privacy tensions. The log retention requirements for VPN providers created a genuine conflict between CERT-In's law enforcement mandate and individual privacy. VPN users in India — journalists, activists, regular citizens avoiding ISP snooping — chose VPN services specifically because they didn't keep logs. When the directives forced logging, several major providers opted to remove Indian server locations entirely. Indian users can still connect to servers in Singapore or the Netherlands, which arguably makes the data less accessible to Indian authorities than before. Whether this outcome is what CERT-In intended is an open question.

Transparency. CERT-In doesn't publish detailed annual reports the way some of its international counterparts do. You'll find aggregate statistics in MeitY's annual report or in parliamentary responses — the agency handled over 14 lakh reported incidents in 2022, for instance — but granular breakdowns of incident types, response times, and outcomes are hard to come by. For an agency asking others to be transparent about their incidents, this is, at minimum, ironic.

International Cooperation

Cyberattacks don't respect national boundaries, and CERT-In's international relationships are probably more developed than most people realize. The agency participates in the FIRST (Forum of Incident Response and Security Teams) global network, which connects over 600 incident response teams across 100 countries. It has bilateral agreements with counterpart agencies in the US, Japan, South Korea, Australia, the UK, and several ASEAN nations.

In practice, this cooperation shows up in things like coordinated takedowns of botnet infrastructure, shared threat intelligence about state-sponsored hacking groups, and joint capacity-building exercises. India's membership in the Quadrilateral Security Dialogue (Quad) has added another dimension — cybersecurity is a regular agenda item, and CERT-In participates in Quad cyber exercises alongside the US, Japan, and Australia.

Closer to home, CERT-In has worked with CERT-BD (Bangladesh) and Sri Lanka CERT on regional threat intelligence sharing. Given that many threat actors target South Asian countries using similar infrastructure and tactics, this kind of neighborhood-level cooperation seems underinvested but growing.

How Ordinary Citizens Actually Interact with CERT-In

Here's the slightly awkward truth: most citizens don't interact with CERT-In directly, and the agency isn't really designed for that. If you're a victim of online fraud — someone stole money from your bank account, you got scammed on a fake shopping site — your first stop should be the National Cyber Crime Reporting Portal at cybercrime.gov.in or the 1930 helpline. That's the law enforcement channel.

CERT-In's role is more infrastructure-level. But citizens can still benefit in a few ways:

The advisories on cert-in.org.in are public. If you're technically inclined, checking them periodically isn't a bad idea, especially for warnings about vulnerabilities in widely used software like WhatsApp, Chrome, or Android itself. The Cyber Swachhta Kendra offers a free bot removal tool that's worth running if you suspect your device is compromised. And if you discover a vulnerability in a government website or a system that handles public data, CERT-In's Responsible Vulnerability Disclosure Program gives you a channel to report it — though the response times and acknowledgment practices could probably use some work.

For businesses, especially those in regulated sectors like banking, telecom, and energy, CERT-In's relationship is much more direct and mandatory. Non-compliance with the 2022 directives can result in penalties under the IT Act, including imprisonment for up to a year. That's not a theoretical threat — the directives carry statutory force.

What CERT-In Gets Right, Despite Everything

It's easy to catalog shortcomings and harder to acknowledge what works, but some things deserve mention. The six-hour reporting rule, for all its impracticality, has forced Indian organizations to actually build incident detection and response capabilities they should've had years ago. Before the directive, plenty of companies had no incident response plan at all. The compliance pressure, annoying as it is, has pushed the baseline upward.

The agency's malware analysis capabilities, while not widely publicized, are apparently solid. CERT-In maintains its own malware analysis lab, and the technical indicators of compromise they share through sectoral channels — banking, energy, government — have helped organizations block attacks they wouldn't have detected on their own. Several banking sector security professionals describe CERT-In's threat feeds as genuinely useful, which is not something they say about every government initiative.

And the Cyber Swachhta Kendra, quiet as it is, represents something unusual for a government program: a free service that actually works and doesn't require you to fill out seventeen forms to access it. For a country where millions of devices are compromised by botnets — often old Android phones running outdated firmware — this kind of silent, unglamorous work matters more than most people realize.

Looking Forward, and Sideways

CERT-In's next few years will probably be defined by scale. India's internet user base is still growing, IoT adoption is accelerating (smart meters, connected vehicles, industrial automation), and the threat environment is getting more complex. State-sponsored attacks are increasing in sophistication, ransomware gangs are specifically targeting Indian healthcare and manufacturing, and the intersection of AI and cyberattacks hasn't even fully materialized yet.

Whether the agency can keep up depends on things largely outside its control: government budget allocations, ability to recruit and retain technical talent (hard when the private sector pays three to five times more), and political will to give it genuine operational independence. The structural challenge is that CERT-In sits under MeitY, which also promotes digital adoption — there's an inherent tension between "put everything online" and "everything online needs protecting."

Speaking of which, it's worth noticing how the conversation about CERT-In always seems to circle back to the same question: is this an agency that serves citizens, or one that serves the state's surveillance interests? The 2022 directives, with their VPN logging requirements and broad definition of reportable incidents, gave ammunition to both interpretations. The answer is probably that it's both, in proportions that shift depending on who's asking, which is maybe the most honest thing you can say about any national cybersecurity agency anywhere in the world. The uncomfortable part is sitting with that ambiguity and still trying to figure out whether the agency's net effect is positive — which it likely is, but not by as wide a margin as its annual reports would suggest, and not without costs that nobody's doing a great job of measuring.