India’s CERT-In quietly raised the bar last week: organizations now have 12 hours to patch critical vulnerabilities in internet-facing systems “where feasible,” with that timeline tied explicitly to adversaries using LLMs to accelerate vulnerability triage and exploit development. It’s the tightest formal patch window any national CERT has put in writing. And it’s landing in the same week Microsoft confirmed the May 2026 cumulative update for Windows Server 2016 is breaking domain controller lookups in production, while CISA gave US federal agencies roughly 24 hours to remediate an actively exploited Drupal SQL injection flaw. The cybersecurity industry has been told for years to patch faster. Regulators have finally written down what “faster” means. Almost nobody can actually do it.

The gap between the new patch SLA and what enterprise IT can realistically execute is the story everyone is going to spend the next year pretending isn’t there. So let’s name it.

The Math Behind A 12-Hour SLA

A 12-hour window assumes a vendor advisory exists, a tested patch exists, your inventory tells you which systems are affected, your change management process can be bypassed, and your test environment matches production closely enough to catch regressions. In most organizations, three of those five are aspirational on a good day.

CERT-In’s framing matters. The agency tied the new timeline directly to AI-assisted exploitation, citing how LLMs let attackers move from CVE disclosure to working exploit faster than defenders can read the advisory. That tracks with what we’ve been seeing all month. Drupal CVE-2026-9082 went from patch to active exploitation in under a week, with CISA now forcing federal remediation against the same flaw on a one-day clock. The Laravel-Lang supply chain compromise published malicious tags within a 15-minute publication window, with exfiltration payloads ready to harvest CI secrets the moment a build ran. The attacker timeline isn’t measured in days anymore.

CERT-In carved out “where feasible” for a reason. Most internet-facing systems don’t have a 12-hour deployment lane. They have ITIL-flavored change boards, weekly maintenance windows, and a small graveyard of past patches that took down production. The mandate is a target, not a guarantee, and the gap between target and operational reality is exactly where the next 7-Eleven-sized breach will land.

When The Patch Itself Is The Outage

Microsoft’s confirmation that KB5087537 is breaking domain controller lookups on Windows Server 2016 is the kind of news that should make every “patch within 12 hours” champion pause. The May 2026 security update fixed real flaws. It also broke a core function authentication depends on. Some organizations pushed that update aggressively because it was rated critical. They got authentication failures as a thank-you.

This is the dirty secret of fast-patching policy: patches themselves are an attack on availability. A defense in depth posture cannot pretend otherwise. The same week regulators want you patching in hours, you’re being asked to roll back updates that broke production, validate a workaround, and explain to the business why your DCs can’t resolve.

Fast patching requires real investment in canary deployment rings, fast rollback, and automated verification of the functions that depend on the patched system. If your patch pipeline is “approve change, push to all DCs, hope,” you have a coin flip dressed up as a process. Speed without a safety net is how outages happen on schedule.

Behavioral Threat Detection Covers The Window You Can’t Close

Even a perfect 12-hour patch process leaves a window. And there are vulnerabilities you simply will not patch in 12 hours, no matter what CERT-In writes. The Drupal SQL injection CISA flagged this week was actively exploited before the federal deadline; agencies on the slower side of remediation will get hit during their compliance window, not after it.

Your firewall is not going to save you from a patch-window intrusion against a flaw it doesn’t recognize. Neither is signature-based threat detection. What works in the gap between disclosure and patch is behavioral: outbound traffic baselines on internet-facing systems, process-execution anomalies that flag a web server suddenly spawning a shell, identity telemetry that catches the post-exploitation pivot when an attacker uses a foothold to grab a token and move laterally.

Treat patching as your only defense and you’ve conceded the window. Defense in depth means you can detect the attacker who beat you to the patch. That’s the whole point.

What An Honest Cybersecurity Patch Program Looks Like Now

Match CERT-In’s 12-hour target on the assets where it’s achievable and worth the risk. Accept longer windows where it isn’t. The point is to stop pretending the same SLA fits everything from a public-facing CMS to a legacy DC running half your authentication.

Practical steps that meaningfully tighten the window without breaking production:

• Rank internet-facing assets by exposure score, not CVSS alone. A vulnerable Drupal instance on the public internet outranks a vulnerable internal CMS by an order of magnitude.
• Build at least one canary ring for OS and middleware patches with automated verification of core functions (domain controller lookups, authentication flows, critical API health) before the wider rollout.
• Pre-stage virtual patching at the WAF or reverse proxy layer so you can deploy a temporary signature in minutes while the real patch moves through change control.
• Subscribe to actively exploited vulnerability feeds (CISA KEV, vendor advisories, threat intelligence) and route those into a separate, faster lane than your normal patch process.
• Run a quarterly tabletop where the trigger is “an unpatchable critical flaw is being actively exploited and the patch breaks production.” If your incident response team has never rehearsed that scenario, you haven’t earned the right to a 12-hour SLA.

The 7-Eleven breach this week, exposing 185,000 customer records via ShinyHunters’ continued tour, is a reminder that none of this stays theoretical. Once an attacker is inside, the patch debate is over. Incident response is what’s left, and how you ran your patch program for the previous six months decides how that response plays out.

Sources

• CERT-In Mandates 12-Hour Patching for Internet-Facing Flaws Amid AI-Assisted Attacks
• CISA orders feds to patch actively exploited Drupal vulnerability
• Microsoft: Domain Controller lookup may fail on Windows Server 2016
• Laravel-Lang Packages Poisoned for Malware Delivery
• 7-Eleven data breach exposes personal information of 185,000 people