CERT-In Mandates 12-Hour Patching Window to Combat AI-Driven Exploits

India’s national cyber agency, CERT-In, has established a new 12-hour remediation standard for internet-facing and 'crown jewel' systems, responding to the dra…

On May 25, 2026, CERT-In released blueprint CISG-2026-02, a 38-page document establishing unprecedented remediation timelines for a national CERT: 12 hours for known vulnerabilities on internet-facing and "crown jewel" systems, 1 day for externally exposed critical flaws, and 3 days for internal criticalities on high-value assets. The move addresses the asymmetric compression of attack windows: artificial intelligence and large language models (LLMs) are shrinking the discovery-weaponization-exploitation cycle from weeks to hours—and potentially minutes—rendering traditional patch management cycles obsolete.

Key Takeaways

CERT-In has published blueprint CISG-2026-02, recommending patching within 12 hours for known vulnerabilities on internet-facing and "crown jewel" systems, where feasible.
Extended timelines include 1 day for external criticalities, 1 day for known internal exploits without mitigations, 3 days for internal criticalities on high-value systems, and 5 days for high-severity vulnerabilities with risk prioritization.
The agency documents that AI-assisted cyber exploitation compresses the time required to identify, weaponize, and exploit vulnerabilities, forecasting a future of autonomous attacks.
A real-world case from the Google Threat Intelligence Group—a zero-day 2FA bypass with an exploit likely generated by an LLM identified in the wild—corroborates the theoretical trend described by CERT-In.

The Blueprint: Timelines and Response Architecture

The document, titled "Blueprint for Reducing Exposure and Defending against AI-Assisted Vulnerabilities Exploitation in Digital Infrastructure," structures a differentiated temporal scale. The 12-hour window applies to "known exploited vulnerabilities affecting internet-facing and critical systems," qualified by the phrase "where applicable," which introduces a margin for operational feasibility not further quantified in the dossier. Subsequent timelines—1, 3, and 5 days—scale based on severity and attack surface exposure.

The approach is explicitly risk-based: the document does not mandate absolute uniformity but rather a risk hierarchy based on asset criticality and exposure. This reflects a practical reality: not all organizations possess the operational capacity for 12-hour patching across all systems. However, the directive is clear: the defensive benchmark is shifting toward a threshold of hours, not days.

"AI-assisted cyber exploitation reduces the time required for adversaries to identify, weaponize, and exploit vulnerabilities, exposed services, weak identities, insecure APIs, and misconfigured systems" — CERT-In, blueprint CISG-2026-02

The Mechanism: How AI Collapses Offensive-Defensive Asymmetry

CERT-In describes a structural mechanism rather than a hypothetical risk. AI-assisted automation—including automated reconnaissance, exploit generation, and potential operational autonomy—reduces the time between discovery and exploitation non-linearly. According to the agency, "organizations should expect exploitation timelines to collapse significantly and attacks to become autonomous."

The dossier does not specify particular AI techniques or specific models. It refers generally to AI and LLMs, with a specific focus on the fact that this acceleration affects the entire vulnerability stack: not just known CVEs, but also exposed services, weak identities, insecure APIs, and misconfigured systems. This expands the scope of intervention beyond traditional vulnerability management toward continuous exposure management.

The immediate context of the blueprint is significant: the document arrived one month after a CERT-In advisory regarding the cyber capabilities of frontier AI models from Anthropic and OpenAI, suggesting the agency is building a coherent narrative regarding frontier AI risks.

Field Evidence: The Google GTIG Case and the First AI-Generated Zero-Day

CERT-In’s theoretical framework finds a concrete parallel in work published by the Google Threat Intelligence Group (GTIG) during the same period. GTIG identified what it defines as "the first zero-day exploit in the wild likely developed with AI": a Python script that bypasses two-factor authentication. The script contains "an abundance of educational docstrings, including a hallucinated CVSS score, and uses a structured, textbook Pythonic format highly characteristic of LLMs training data."

While this case is not cited in the CERT-In blueprint—remaining separate events—it serves as independent evidence of the described phenomenon. The technical exhibit is particularly telling: the presence of a "hallucinated" CVSS score (a number generated by the model consistent with the format but without a basis in the official scoring architecture) is an LLM generation marker that eludes traditional automation. The code is not just produced quickly; it is produced with the structural characteristics—and cognitive flaws—typical of training on technical corpora.

The GTIG case demonstrates that the compression of timelines is not a future prospect: it has already occurred. The weaponization of a zero-day, an activity that traditionally requires specialized skills and prolonged development time, was executed using commercially available code generation tools.

Operational Priorities

Reduce the internet-facing exposure surface through continuous mapping of exposed services, utilizing automated prioritization based on asset criticality.
Implement layered, risk-based technical controls with continuous validation, as outlined in the blueprint, to reduce reliance on patching speed as the sole line of defense.
Continually reassess exposure, validate existing security controls, strengthen resilience capabilities, and enhance operational preparedness in a continuous, rather than event-driven, reassessment cycle.
Realign patch management processes with time metrics compatible with the new scale: where current cycles are weekly or monthly, a 12-hour timeline requires deployment and testing automation, not just manual acceleration.

Recommendation vs. Mandate: Unresolved Ambiguities

The dossier contains areas of uncertainty for operators. It is not specified whether these timelines are legally binding or merely recommendatory. While one general source claims "the blueprint itself does not create new legal obligations," it remains unclear if this excludes the activation of pre-existing directive powers under Section 70B of the IT Act. Furthermore, it is unclear how many organizations fall within the scope—whether only government entities or the private sector as well—nor how CERT-In intends to verify compliance or what the consequences of non-compliance might be.

The "where feasible" qualifier in the most aggressive timelines introduces a non-objective feasibility criterion, leaving an interpretive margin that could reduce the document's prescriptive force in complex operational environments.

Why This Shifts the Landscape for CISOs

The signal from CERT-In is not isolated but part of a broader trend: defensive standards are racing to close a gap that AI-driven offensives are systematically widening. In the United States, CISA has imposed aggressive timelines via Binding Operational Directives; CERT-In’s framework is the first instance of a national CERT explicitly quantifying the defensive response as a function of AI-assisted attack speed.

The operational consequence for CISOs is a transformation of processes, not a simple acceleration. Patching within 12 hours on critical systems requires automated deployment pipelines, rollback capabilities, testing environments that replicate production, and change management governance that tolerates near-zero decision latency. It is not a matter of will; it is a matter of operational infrastructure that most organizations do not currently possess.

For policymakers, the blueprint is an alarm signal regarding the nature of the gap: traditional defenses operate on timescales that AI-assisted exploitation tools are making obsolete. The response cannot be purely technical; it requires a rethinking of investments in resilience and the capacity to absorb impact when prevention fails.

Information has been verified against the cited sources and is current as of the time of publication.