CERT In requires patches in 12 hours to face Internet-exposed vulnerabilities by IA

The Indian incident response agency, CERT-In, has shaken the security team calendar with a practical requirement: critical vulnerabilities that expose Internet services must be parked in extremely short time, in many cases in the 12 hours when feasible. This measure responds to an emerging and worrying reality: malicious actors are already taking advantage of artificial intelligence tools and language models to automate the search, analysis and exploitation of failures, drastically reducing the time between the detection of vulnerability and its effective abuse.

The impact of IA on cybersecurity is double. On the one hand, the same capabilities that help developers and administrators - test automation, code analysis, test generation - can be reused by attackers to scan attack surfaces, generate exploits, create convincing phishing emails or even develop custom malware. On the other hand, IA systems themselves and model supply chains are an objective: prompt injection, training data poisoning, model theft and data leakage can turn an internal assistant into a filtration or handling vector.

For security officials this means that response windows must be compressed and defenses become more proactive and automated. The CERT-In guide emphasizes a mentality of "taking over the intrusion": quickly detect, contain and recover. In practice, this involves strengthening authentication and access control with least privileged and multifactor policies, segmenting networks to limit the scope of any commitment and implementing layer controls that prevent a single failure from becoming a disaster.

The operational standard proposed by the agency includes differentiated time frames: immediate remediation for known failures affecting exposed systems, 24-hour time limits for external critical vulnerabilities and some interns, up to 72 hours for internal failures affecting high-value assets and a multi-day window for high risks according to priority. When a patch is not available, it is recommended to apply temporary mitigation such as isolation, access restrictions, WAF / API level protection and increased monitoring until correction is reached.

These guidelines are ambitious and legitimate, but they pose implementation challenges. Not all organizations can park within 12 hours without generating operational interruptions or breaking critical integrations. It is therefore essential to document and justify technical compensation: if it is not possible to update immediately, pre-approved compensatory controls, emergency playbooks and clear communication chains with suppliers should be available to reduce total risk time.

The safety of IA models and pipelines also requires specific controls beyond the traditional patch. It is essential to maintain an inventory of models and dependencies, to verify the origin and integrity of weights and data, to apply differential privacy or masking techniques when confidentiality requires, and to control the exposure points of APIs that serve inferences. Governance of the use of IA should be formal: who can invoke models, with what data and records are kept for audit.

Response, testing and validation must receive constant investment. Network teaching, continuous penetration tests, independent validations and table exercises for incidents with IA scenarios will help to discover unsafe configurations before they are exploited by automated tools. Transparency in the software supply chain, through SBOM and source verifications, reduces the risk of integrating committed components or models into critical environments.

For those operating critical infrastructure or cloud services, it is key to prioritize the protection of exposed entry points: endpoints, public APIs, privileged identities and management services. Monitoring telemetry, log correlation and behavior-based detection are now more relevant than ever, because IA-assisted attacks can move at speeds that exceed human ability to react without defence automation.

The framework of action recommended by experts and international bodies complements CERT-In: promoting Zero Trust architectures, in-depth defenses and risk-based vulnerability management practices. Resources such as the NIST guidelines on risk management in IA offer a map to adapt technical and organizational controls to environments that incorporate language and automatic learning models ( NIST TO RMF). In turn, catalogues of publicly exploited vulnerabilities, maintained by entities such as CISA, help to prioritize patches that are already being weaponized ( CISA KEV).

In short, the CERT-In pattern is a call to transform traditional vulnerability management: it is not enough to list and patch each cycle, but it is necessary to automate detection and mitigation, tighten IA models and ensure the digital supply chain. Organizations should combine technical responses (patches, WAF, segmentation, MFA) with robust governance (IA use policies, inventories and audits) and operational preparation (playbooks, exercises and supplier agreements). The reaction time is no longer a comfortable window: the speed and scale provided by the IA to the attackers require equivalent response and resilience times.