On 25 May 2026 CERT-In published its AI Threat Landscape guidance and, with it, an indicative 12-hour expectation for containing or remediating known exploited vulnerabilities on internet-facing and high-value 'crown-jewel' systems. The number is not arbitrary and it is not aspirational — it is calibrated to how fast AI-assisted attackers now weaponise a disclosed flaw. Read it as a leading indicator of where patch-compliance standards are heading everywhere, not an India-only curiosity.
CERT-In's guidance is the operational culmination of an advisory mapping the growing role of generative AI, large language models and autonomous agent frameworks across the attack lifecycle — reconnaissance, vulnerability scanning, targeted phishing and adaptive malware. The headline is the timeline, but the more important shift is the benchmark CERT-In chose: India's national cybersecurity authority is now pacing remediation expectations against AI-driven threat timelines rather than legacy IT change-management windows. Our reading below draws on CERT-In's advisory and the Cloud Security Alliance's May 2026 research note analysing the mandate; the framing is ours, the timeline is CERT-In's.
Prefer a PDF to share with your CISO or board? Grab the Macksofy-branded brief — the tiered schedule, the collapsing-exploit-window data, the compensating-control path and the 30/60/90-day action list on two pages, sources cited.
What CERT-In actually published
The guidance establishes a tiered remediation schedule keyed to the intersection of vulnerability severity and system-exposure profile — not a single deadline applied to everything. This is risk-based prioritisation, and it substantially reduces the operational burden relative to a flat 12-hour rule. The 12-hour window applies narrowly: to known exploited vulnerabilities (KEVs) — those already active in the wild and catalogued in threat-intelligence feeds — affecting systems directly exposed to the internet or classified as high-value internal assets.
| Vulnerability + exposure profile | Indicative window | What qualifies |
|---|---|---|
| KEV on internet-exposed / high-value system | 12 hours | Already exploited in the wild; internet-facing or crown-jewel asset |
| Critical, not yet actively exploited, externally exposed | 24 hours | Critical severity with external exposure but no confirmed exploitation |
| Critical on internal high-value system | 3 days | Critical severity, high-value, not directly internet-facing |
| High-severity, below critical threshold | 5 days | High severity flaws outside the critical band |
CERT-In's tiered remediation schedule (indicative, 25 May 2026)
Why 12 hours — the exploit window has collapsed
The 12-hour window reads less like an aspirational benchmark and more like a recognition of what attackers armed with AI tooling are already achieving. The standard was calibrated to attacker capability, not defender comfort. The empirical basis is a measurable collapse in the time between CVE publication and active exploitation.
AI frameworks capable of generating working exploits from a CVE description in ten to fifteen minutes at trivial cost have changed the economics of vulnerability weaponisation. Mandiant's M-Trends 2026 found 28.3% of CVEs now exploited within 24 hours of disclosure — a negative time-to-exploit trend, where exploitation increasingly precedes vendor patch availability. The practical consequence: any organisation maintaining 30-day or even 7-day windows for internet-exposed systems is running a risk posture formulated before the current AI capability environment existed.
This builds on the 6-hour reporting rule
The 12-hour patch guidance is not CERT-In's first compliance timeline to challenge legacy operations rhythms. Since 2022, Direction 20(3)/2022 has required organisations to report cybersecurity incidents within six hours of awareness — a mandate that forced Indian enterprises to restructure detection, escalation and internal communications pipelines. The patch guidance applies comparable operational urgency to the remediation side of the lifecycle. Together, the two requirements point toward a coherent regulatory posture: as AI shortens every phase of attack execution, defensive timelines must compress in parallel.
Where no patch exists — the compensating-control path
CERT-In explicitly accommodates the reality that the 12-hour window cannot always be met through vendor-patch availability alone. Where remediation cannot complete within the applicable window — because no patch exists yet, or because deployment cycles can't be compressed sufficiently — the guidance prescribes interim containment. The crucial nuance: the 12-hour deadline applies to the obligation to act, not exclusively to the obligation to patch. A documented containment measure implemented within 12 hours satisfies the intent of the standard.
- Network isolation of the affected system from non-essential reachability.
- Access restriction — limit to authenticated users only, tighten firewall and identity policy.
- WAF rule deployment to virtually patch the exploited path at the edge.
- Analogous compensating controls — segmentation, JIT access, protocol restriction — that neutralise the exposure.
India's position in the global patching-governance landscape
To the authors' knowledge, India is the first major national cybersecurity authority to publish a tiered patch timeline explicitly calibrated to AI exploitation speed. The closest US equivalent in design philosophy — CISA's Known Exploited Vulnerabilities catalog — currently uses deadlines averaging roughly 14 days in 2026, with reports that CISA is weighing a three-day federal standard for KEVs on high-value systems but has not finalised comparable guidance. The EU's NIS2 timeframes and the UK's pending Cyber Security and Resilience Bill signal awareness of changing exploitation timelines without yet publishing a comparable tiered patch standard.
- 12 hours for KEVs on internet-facing / crown-jewel systems
- Tiered by severity × exposure (12h / 24h / 3d / 5d)
- Explicitly calibrated to AI exploitation speed
- Compensating controls accepted as interim compliance
- ~14-day average remediation deadlines
- Moving toward a 14-day default window
- Three-day KEV standard reportedly under consideration
- Same AI threat data informing the debate
The gap between India's 12-hour expectation and the current US ~14-day standard reflects different regulatory response timelines, not different underlying threat realities — the same AI tooling targeting Indian infrastructure is targeting infrastructure globally. For multinationals, the patchwork of national timelines argues for a single unified vulnerability-prioritisation programme that applies the most stringent applicable standard to all internet-facing assets by default, rather than separate compliance tracks per jurisdiction.
The operational reality — MSMEs and the capability gap
An honest assessment: most enterprise environments, and essentially all small- and medium-enterprise environments, cannot achieve consistent 12-hour patch deployment for internet-facing systems without significant investment in automation, continuous asset monitoring and pre-tested deployment pipelines. India's large MSME segment — a substantial part of CERT-In's regulated constituency — faces the steepest climb here. This does not make the guidance irrelevant; it makes the compensating-control provisions essential. The capability to correlate threat intelligence with an asset inventory in near-real-time, and to act inside 12 hours, is the thing that does not exist in most smaller organisations without deliberate tooling investment.
What to do in the next 30 / 60 / 90 days
- Audit your internet-facing asset inventory and map it against CERT-In advisories and the CISA KEV catalog — you cannot meet a 12-hour KEV window without knowing which exposed assets exist.
- Integrate a threat-intelligence feed that tracks KEV-catalog additions in near-real-time, with automated alerting tied to the asset inventory. Periodic scan cycles measured in days are no longer timely enough.
- Build and test a compensating-control playbook — documented isolation procedures, WAF rule sets, access-restriction policies — that can be executed inside 12 hours when a patch is unavailable.
- Stand up low-friction, tested emergency patch-deployment automation for the internet-facing tier, outside the full change-advisory-board process.
- Update incident-response playbooks to include vulnerability-triggered containment scenarios alongside breach-response procedures.
- Run a tabletop against a live-KEV scenario: a CVE lands at 09:00 with confirmed exploitation — can you contain or remediate the exposed tier by 21:00?
- Map your readiness against the CERT-In AI-threat framing and identify control gaps before a supervisory review or an inspection does.
How Macksofy helps
As a CERT-In empanelled auditor, Macksofy delivers the readiness work this guidance demands: continuous VAPT against internet-facing assets, KEV-aligned threat-intelligence integration, compensating-control playbook design, and the emergency-remediation runbooks that make a 12-hour window operationally feasible. Engagements range from a focused exposure-and-readiness assessment to a managed programme that runs the detect-correlate-contain loop on your behalf. See /services/vapt for the assessment scope, /services/managed-soc for the continuous-monitoring and rapid-containment capability, /services/threat-intelligence for KEV-aligned feeds, /audit/cert-in-empanelled-audit for the empanelled-audit engagement, and /resources/cert-in-incident-reporting-checklist for the related 6-hour incident-reporting workflow.