India’s CERT-In Pushes 12-Hour Patching for Exposed Flaws

India’s CERT-In has set one of the more aggressive security expectations for organizations running systems exposed to the internet: critical vulnerabilities should be patched within 12 hours of being flagged, where feasible. According to The Hacker News, the guidance is tied directly to concerns that attackers are using AI tools and large language models to automate reconnaissance, target selection and exploitation of known flaws.

This is not a cosmetic change in regulatory language. A 12-hour window moves patch management out of the comfortable rhythm of quarterly maintenance and into something much closer to incident response. If a flaw is critical and the affected system is public-facing, an organization has far less room to claim it is still “assessing” the issue while exploit automation is already moving across the internet.

The important qualifier is “where feasible.” That leaves room for technical constraints, compatibility issues, testing and business risk, but it does not erase the obligation. The pressure therefore shifts to evidence: what was exposed, when the vulnerability was flagged, who made the decision, why an immediate patch was not possible and what temporary mitigations were put in place.

For large organizations, this means the inventory of public-facing infrastructure has to be real, not a spreadsheet refreshed after an audit. Critical flaws in VPNs, application gateways, web services, remote-access systems and edge security appliances become a race against automation. Context from resources such as CISA’s Known Exploited Vulnerabilities catalog and vulnerability records in the NVD shows why: once a known weakness is being exploited at scale, the gap between disclosure, scanning and compromise can shrink fast.

CERT-In already plays a broader regulatory role in India’s cyber ecosystem, including incident reporting and coordination obligations under earlier Section 70B directions. The new 12-hour logic fits that trajectory: less passive waiting, more operational accountability. AI is not the whole story here, but it is a force multiplier. If attackers can turn a public vulnerability into an automated campaign faster, defenders have to shorten their own decision cycle.

The hardest part will not always be installing a patch. It will be the system around the patch: knowing which assets are exposed, assigning owners to every critical component, defining exceptions in advance, preparing rollback plans and keeping evidence ready for scrutiny. Without that machinery, “12 hours” becomes less a security control than a record of how much of an organization’s infrastructure is still invisible to its own operators.