CERT-In 12-Hour Patch Mandate: AI Attacks Drive Rules

India's cybersecurity regulator, CERT-In, has issued a directive requiring organizations to patch internet-facing vulnerabilities within 12 hours of disclosure. The CERT-In patching mandate represents a sharp escalation from previous timelines, and it arrives as AI-assisted attack tooling compresses the gap between vulnerability disclosure and active exploitation to near zero.

This is not a theoretical concern. Security researchers have documented cases where working exploits appear on public forums within hours of a CVE dropping. AI tools now help attackers automate vulnerability analysis, generate proof-of-concept code, and scan for exposed targets at scale. A 12-hour window is tight. For most engineering teams, it will require process changes that go well beyond copy-pasting a patch into production.

Why AI-Assisted Attacks Demand Faster Patch Cycles

Traditional patch management was built around weekly or monthly cycles. Threat actors had to manually analyze patches, reverse-engineer fixes, and write exploits. That process took days or weeks. AI changes the math entirely.

Modern AI tooling can diff a patched binary against an unpatched one, identify the changed code paths, and generate candidate exploit code in under an hour. Automated scanning infrastructure then reaches millions of exposed hosts before most security teams have even opened their morning alert queue. CERT-In's directive acknowledges this reality directly. Waiting 24 or 48 hours is no longer defensible when exploitation is happening in single-digit hours post-disclosure.

What the CERT-In Directive Covers

The mandate specifically targets internet-facing systems, which includes web applications, APIs, VPN endpoints, remote access gateways, and any service with a publicly routable address. Internal systems get more breathing room, but anything exposed to the public internet falls under the 12-hour requirement.

Organizations operating in India or handling Indian user data need to treat this as a hard compliance requirement, not a recommendation. Non-compliance carries regulatory consequences, and CERT-In has shown increasing willingness to act on reported violations.

Practical Impact on Development and Security Teams

Twelve hours is a brutal timeline for most teams. A patch arrives, needs testing in staging, compatibility verification, deployment across potentially hundreds of instances, and rollback planning if something breaks. That workflow rarely fits inside half a business day.

Teams will need to pre-build deployment pipelines that can push emergency patches without manual bottlenecks. Feature freeze protocols for critical CVEs, automated regression suites that run in under 30 minutes, and clear on-call escalation paths are not optional anymore. If your current process involves filing a ticket and waiting for the next sprint, that process needs to change.

How to Reduce Your Exposure Window

Start with attack surface visibility. You cannot patch what you do not know is exposed. Regular automated scanning of your internet-facing assets gives you a baseline so that when a CVE drops, you already know which systems are in scope.

A few concrete steps worth prioritizing:

• Run continuous discovery scans on all public-facing endpoints, not just scheduled quarterly audits.
• Subscribe to vendor security advisories and NVD feeds with alerting, not just passive monitoring.
• Maintain a tested emergency patch runbook specific to your stack.
• Use a DAST tool to verify patches actually remediate the vulnerability, not just that a package version number changed.
• Segment internet-facing services so a single compromised component cannot pivot laterally.

The VibeWShield scanner can help confirm whether a patch closed the actual vulnerability in your running application, which is different from confirming a dependency was updated.

For deeper context on managing AI-accelerated threats to web applications, see our breakdown at /blog/ai-assisted-web-attacks-developer-guide.

FAQ

Does the 12-hour CERT-In requirement apply to SaaS products serving Indian customers? Yes. If your application is internet-facing and processes data subject to Indian regulations, CERT-In treats your public endpoints as in-scope regardless of where your infrastructure is physically hosted.

What counts as "patching" under this directive, can a WAF rule serve as a temporary fix? CERT-In accepts compensating controls as interim measures when a vendor patch is not yet available, but a WAF rule does not substitute for an actual patch once one exists. Document your interim mitigation and replace it as soon as the vendor fix ships.

How do we prove compliance if CERT-In audits us? Maintain timestamped records of when you received the vulnerability disclosure, when you deployed the fix, and post-patch scan results confirming remediation. Automated scanning logs work well as audit evidence.

Verify your internet-facing applications are actually patched, not just updated on paper, with an automated scan at VibeWShield.