Source: The Hacker News — https://thehackernews.com/2026/05/cert-in-mandates-12-hour-patching-for.html
CERT-In is tightening the patching clock#
India’s CERT-In has published new guidance urging organizations to remediate known exploited vulnerabilities on internet-facing and critical systems within 12 hours where feasible. The agency ties the shorter window to a clear pressure point: AI-assisted exploitation can compress the time attackers need to find exposed services, analyze flaws, build phishing content, and scale campaigns.
The wording matters. CERT-In is not saying every critical bug in every environment can always be fixed in half a day. The guidance uses risk-based language and includes “where feasible.” But the signal is still sharp. Publicly exposed systems with known exploitation are no longer treated as normal backlog items. They are emergency exposure.
CERT-In’s 38-page blueprint frames AI as a force multiplier for existing cyber operations. The document points to attack surface discovery, exploit analysis, weak identity abuse, insecure API targeting, misconfiguration discovery, malware generation, and more convincing phishing. None of those are new categories. The change is speed and scale.
That is the practical reading: AI does not need to invent a new class of vulnerability to change defender behavior. It only has to make the old workflow faster.
The proposed remediation windows#
The most concrete part of the guidance is the remediation timing. CERT-In recommends continuous, risk-based vulnerability and patch management, with the strongest urgency placed on systems that are internet-facing, critical, or already known to be exploited.
The remediation targets cited in the report are:
- Known exploited vulnerabilities affecting internet-facing and critical systems: within 12 hours where applicable.
- Critical externally exposed vulnerabilities: within 1 day.
- Known exploited vulnerabilities affecting internal systems: within 1 day unless other mitigations are implemented and documented.
- Critical internal vulnerabilities affecting high-value systems: within 3 days.
- High-severity vulnerabilities: within 5 days, based on risk prioritization.
For many organizations, the 12-hour target will be the headline. The harder work is the dependency behind it. A team cannot patch within 12 hours if it does not know what it owns, what is exposed, which systems are critical, who can approve downtime, and what compensating controls are already available.
That makes this less a pure patching policy and more an operational maturity test. Fast remediation depends on asset inventory, exposure management, vulnerability intelligence, change control, backup confidence, and incident coordination. Without those, the deadline becomes a slogan.
When there is no patch, mitigation still counts#
CERT-In also addresses the common failure mode in urgent vulnerability handling: waiting for a clean vendor patch while the exposed service remains reachable. Where patches are not immediately available, the agency recommends temporary mitigations such as isolation, access restriction, WAF or API protection, enhanced monitoring, or disabling affected features until a fix is released.
That is a useful distinction. Remediation is not always a package update. In some cases, the immediate objective is to remove the exploit path. If a vulnerable interface can be taken off the public internet, locked behind stricter access control, or monitored with higher confidence, risk can be reduced before a permanent fix lands.
The weak version of this approach is “we put it behind a WAF” with no validation. The stronger version is documented: what was changed, what attack path it blocks, what remains exposed, when the permanent fix is expected, and who owns the follow-up. CERT-In’s language about documented mitigations for internal exploited vulnerabilities points in that direction.
This is where many patch programs break. Teams close the ticket after a workaround, then lose the thread. The blueprint’s emphasis on continuous reassessment is a reminder that temporary controls are not debt forgiveness. They are rented time.
AI systems are also part of the attack surface#
The guidance does not treat AI only as an attacker tool. It also warns that AI-enabled systems can become targets. CERT-In names prompt injection, data leakage, jailbreaking, model manipulation, training data poisoning, model theft, and orchestration pipeline compromises as risks that can undermine confidentiality and integrity.
That part is important because many security programs still split “AI risk” into a separate governance discussion while leaving it out of day-to-day exposure management. CERT-In’s framing is broader. AI integrations, APIs, model dependencies, orchestration layers, data flows, and third-party models all become part of the operational attack surface.
The agency also calls out software supply chain exposure tied to third-party software, AI models, and dependencies. It recommends measures such as SBOM use, provenance validation, and assessments. Those controls will not stop every attack, and SBOMs alone are not security. But they help answer a basic question under pressure: are we affected, and where?
In a compressed exploitation timeline, that answer is valuable.
What defenders should take from it#
The blueprint repeats several familiar security principles: assume breach, Zero Trust, defense in depth, secure by design, protection of sensitive data, operational continuity, red teaming, vulnerability assessments, penetration testing, independent audits, and formal AI governance.
The list is broad. The useful part is the ordering implied by the threat model. CERT-In says controls should prioritize internet-facing systems, critical business applications, identities, cloud environments, APIs, sensitive data, AI-enabled systems, and operational infrastructure.
That priority is sensible. Attackers usually do not need the most elegant path. They need the reachable path. Externally exposed services, weak identities, unmanaged APIs, and misconfigured cloud assets remain high-yield targets, especially when automation reduces search cost.
A practical response starts with a few checks:
- Can the organization produce a current list of internet-facing assets?
- Are known exploited vulnerabilities mapped against that list daily, not monthly?
- Are critical systems labeled clearly enough to drive faster action?
- Is there an approved emergency change process for exploited exposure?
- Are mitigations documented when patches cannot be applied immediately?
- Are AI systems and AI integrations included in asset, identity, logging, and data-flow reviews?
If the answer is no, the 12-hour recommendation is still useful. It exposes the gap.
What not to overclaim#
The guidance does not prove that every attacker is now using frontier AI models successfully against every target. It also does not mean patching alone is enough. CERT-In’s own document points to identities, APIs, cloud environments, supply chains, operational technology, and AI workflows as part of the same risk picture.
The strongest claim supported by the source is narrower and more actionable: defenders should expect exploitation timelines to shrink, especially for exposed and known vulnerable systems, and should tune patching and mitigation processes around that assumption.
That is enough to change policy. A vulnerability on an internal low-value system can still move through risk-based handling. A known exploited flaw on a public critical system cannot wait for the next comfortable maintenance window unless the organization has a defensible mitigation in place.
The pressure is not theoretical. It is operational. The public edge has to be known, watched, and fixable fast.