India Sets a 12-Hour Clock on Exploited Vulnerabilities. Can Enterprises Actually Do It?

CERT-In just published a 38-page framework that, depending on your patching culture, will read as either a serious operational challenge or a quiet indictment of how most enterprises still run vulnerability management.

The headline number is 12 hours. That's the window India's national cybersecurity agency is calling for to patch, mitigate, or isolate known-exploited vulnerabilities on internet-facing "crown jewel" systems. One day for critical externally exposed flaws. Three days for critical internal vulnerabilities on high-value systems. Five days for high-severity findings based on risk tier.

The driver is AI. CERT-In states flatly that exploitation timelines are compressing as threat actors use AI to accelerate reconnaissance, vulnerability discovery, malware generation, and automated exploitation chains. Attacks are expected to become "increasingly autonomous." That's not vendor PR — that's a government agency telling you your monthly patch cycle is already obsolete.

In practice, the 12-hour figure is a containment target, not a patch-completion mandate across your entire estate. Sanchit Vir Gogia of Greyhound Research put it clearly: the tiered structure is more meaningful than the headline clock, because it ties response timelines to exposure and operational criticality. The three-day window for critical internal systems is where pressure actually lands, especially in finance, telecom, healthcare, and OT environments where change management is slow by design.

The failure mode here is not patching speed. It's asset visibility. Apeksha Kaushik at Gartner identified the real blockers: no real-time asset inventory, no automated risk prioritization, no cross-functional incident response playbooks. Organizations will struggle to hit any of these windows if they don't know what they're running or where it's exposed.

CERT-In partly accounts for this. The framework explicitly endorses compensating controls — WAF rules, network isolation, access restrictions, enhanced monitoring — when immediate patching isn't feasible. That makes the timelines workable. It also eliminates the excuses. As Gogia put it: if you can't isolate or restrict a system quickly, the problem was never your patch cadence. You don't know your own exposure.

The framework pushes hard toward continuous exposure management over periodic assessments. That's the right direction. AI-assisted adversarial simulations, continuous vulnerability assessment, and red teaming all feature. This is closer to the posture that cloud-native security teams at the platform layer have been building toward for years — and still haven't fully reached.

Globally, this is worth watching. CISA's Known Exploited Vulnerabilities catalog uses per-vulnerability deadlines. CERT-In is running standing clocks by asset category. That's a structurally different model, and arguably a more honest one given how fast attacker tooling now moves.

If your SLA for patching is still measured in weeks, this framework will feel aggressive. That's the point.

Operational takeaway: If you can't answer "what internet-facing systems hold our most sensitive data and are they patched right now," no remediation clock matters — fix the inventory problem first.