India Sets a 12-Hour Clock on Exploited Vulnerabilities. Can Enterprises Actually Do It?
CERT-In's new AI-threat framework resets expectations around patch velocity, but the real test is whether organizations even know what's exposed.
Key points
- CERT-In's 38-page framework sets a 12-hour window to patch, mitigate, or isolate known-exploited vulnerabilities on internet-facing "crown jewel" systems.
- Tiered deadlines follow: one day for critical externally exposed flaws, three days for critical internal vulnerabilities on high-value systems, five days for high-severity findings by risk tier.
- CERT-In cites AI-accelerated reconnaissance, phishing, and automated exploitation as the reason monthly patch cycles are already obsolete.
- Compensating controls (WAF rules, network isolation, access restrictions, enhanced monitoring) are explicitly endorsed when immediate patching isn't feasible.
- Asset visibility, not patching speed, is the real blocker most organizations will hit first.
Should you worry?
CERT-In just published a 38-page framework that, depending on your patching culture, reads as either a serious operational challenge or a quiet indictment of how most enterprises still run vulnerability management.
The headline number is 12 hours: the window India's national cybersecurity agency calls for to contain known-exploited vulnerabilities on internet-facing "crown jewel" systems. Three days for critical internal flaws on high-value systems. Five days for high-severity findings by risk tier. CERT-In states flatly that AI is compressing exploitation timelines, that threat actors are using it to accelerate reconnaissance, phishing, and automated exploitation chains, and that attacks are expected to become "increasingly autonomous." That's a government agency telling you your monthly patch cycle is already obsolete, not vendor copy.
Sanchit Vir Gogia, chief analyst at Greyhound Research, told CSO Online the 12-hour figure is realistic only as a containment target on a narrow set of exposed assets, never a patch-completion mandate across sprawling infrastructure. "The five-day high-severity window is comfortable for most enterprises. The three-day critical-internal window is where the pressure actually bites," he said, especially in finance, telecom, and operational technology environments where change management is slow by design.
Where organizations will actually break
The failure mode isn't patching speed. Apeksha Kaushik, senior principal analyst at Gartner, identified the real blockers when speaking to CSO Online: no real-time asset inventory, no automated risk prioritization, no cross-functional incident response playbooks. Organizations will struggle to hit any window if they don't know what they're running or where it's exposed.
CERT-In partly accounts for this. Compensating controls are explicitly endorsed when immediate patching isn't feasible. Gogia's read: "If you cannot isolate, restrict, or monitor quickly, the problem was never patch cadence. The problem is that you do not know your own exposure."
The framework pushes toward continuous exposure management over periodic assessments, with continuous vulnerability assessment, AI-assisted adversarial simulations, and red teaming all featuring. Cloud-native security teams have been building toward this posture for years and still haven't fully reached it.
Globally, this is worth watching. Gogia noted that CISA's Known Exploited Vulnerabilities catalog uses per-vulnerability deadlines, while CERT-In runs standing clocks by asset category. That's a structurally different model, and arguably a more honest one given how fast attacker tooling moves. We first covered CERT-In's 12-hour posture on 28 May 2026, when the mandate was just landing.
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.
