Inde : CERT-In impose 12h de patch face aux exploits IA

Un blueprint de 38 pages qui redéfinit les standards de patching face à l'IA offensive

Le 25 mai 2026, l'Indian Computer Emergency Response Team (CERT-In) a publié un document de référence intitulé "Blueprint for Reducing Exposure and Defending against AI-Assisted Vulnerabilities Exploitation in Digital Infrastructure". Ce blueprint de 38 pages représente la réponse la plus directe jamais apportée par une autorité nationale de cybersécurité à la transformation de la menace par l'intelligence artificielle. Le document ne se contente pas d'observer : il impose des délais opérationnels contraignants et documentés.

La mesure phare est l'exigence d'un délai de patching de 12 heures pour les vulnérabilités critiques identifiées sur des systèmes exposés sur internet, lorsque cela est techniquement faisable. Ce seuil, qui paraissait encore utopique il y a deux ans, est désormais une obligation réglementaire en Inde pour les opérateurs d'infrastructures critiques. Le CERT-In justifie cette exigence par l'accélération mesurable des cycles d'exploitation : les outils IA et les grands modèles de langage permettent aujourd'hui à des acteurs malveillants d'identifier, d'armer et d'exploiter une vulnérabilité en un temps qui se compte en heures, là où cela nécessitait auparavant plusieurs jours voire plusieurs semaines.

Le blueprint articule une approche par niveaux de risque. Pour les vulnérabilités critiques sur des systèmes exposés externalement mais non classés comme directement accessibles depuis internet, le délai est porté à 24 heures. Les vulnérabilités critiques sur des systèmes internes à haute valeur disposent quant à elles d'une fenêtre de 72 heures. Enfin, les vulnérabilités à sévérité élevée — correspondant aux failles de niveau CVSS 7.0 à 8.9 — doivent être corrigées dans les cinq jours ouvrés. Ces fenêtres sont non négociables pour les entités régulées et représentent une rupture radicale avec les cycles de patching mensuels ou trimestriels encore en vigueur dans de nombreuses organisations.

Le CERT-In formule son diagnostic sans détours dans le préambule du document : l'exploitation cyber assistée par IA réduit le temps nécessaire aux adversaires pour identifier, armer et exploiter des vulnérabilités, des services exposés, des identités faibles, des API non sécurisées et des systèmes mal configurés. L'organisme cite notamment la prolifération d'outils offensifs fondés sur des LLM, capables de générer automatiquement des exploits à partir de la simple lecture d'un bulletin de sécurité ou d'une annonce CVE publique. La fenêtre entre la divulgation publique d'une vulnérabilité et son exploitation à grande échelle est passée, selon le CERT-In, de 7 à 30 jours en 2022 à moins de 6 heures dans certains cas documentés en 2026.

Ce n'est pas la première fois que le CERT-In adopte une posture réglementaire agressive. En 2022, l'organisme avait déjà imposé une obligation de signalement des incidents de sécurité dans les six heures suivant leur détection — une exigence qui avait alors fait débat au sein de l'industrie. Quatre ans plus tard, cette obligation est non seulement maintenue mais élargie sur le volet préventif : non seulement les organisations doivent signaler rapidement, mais elles doivent désormais corriger rapidement. L'Inde se positionne ainsi comme l'un des régulateurs les plus stricts au monde en matière de cyber-hygiène opérationnelle.

Sur le plan du périmètre d'application, le blueprint cible en priorité les opérateurs d'infrastructures critiques tels que définis par la loi indienne sur les technologies de l'information, incluant les secteurs de l'énergie, des télécommunications, des services financiers, de la santé et des transports. Mais le document formule également des recommandations applicables à toute organisation maintenant des systèmes exposés sur internet, indépendamment de sa taille ou de son secteur. Le CERT-In encourage explicitement les PME à adopter les mêmes standards, en soulignant que les chaînes d'approvisionnement constituent des vecteurs d'entrée privilégiés pour atteindre les grandes organisations via leurs sous-traitants les moins matures.

Au-delà des délais de patching, le blueprint couvre plusieurs autres dimensions. Il recommande une segmentation réseau agressive pour limiter le mouvement latéral d'un attaquant, l'adoption systématique de l'authentification multifacteur sur tous les accès administrateurs exposés et la mise en place de processus d'inventaire continu des actifs exposés sur internet. Le document préconise également une approche de patch en isolation pour les systèmes où l'interruption de service est critique : déploiement sur un environnement de test, validation accélérée, puis bascule de production — le tout dans la fenêtre impartie.

Pour les organisations qui ne disposent pas de la maturité opérationnelle nécessaire, le CERT-In propose un cadre de remédiation compensatoire. Si le patch ne peut être appliqué dans le délai imparti, l'organisation doit déployer des mesures d'atténuation documentées — filtrage réseau, désactivation de la fonctionnalité vulnérable, déploiement de règles WAF spécifiques — et informer l'autorité sectorielle compétente. Cette tolérance conditionnelle reconnaît les contraintes opérationnelles réelles des grandes infrastructures, tout en maintenant une pression réglementaire forte sur la traçabilité et la responsabilité.

Pourquoi cette directive indienne pourrait influencer la réglementation mondiale

L'Inde n'est pas un acteur mineur de l'écosystème cyber mondial. Avec 1,4 milliard d'habitants, un secteur IT qui représente plus de 8 % du PIB national et des entreprises technologiques qui opèrent des infrastructures critiques pour des dizaines de pays, les standards réglementaires indiens ont un effet de levier qui dépasse largement les frontières nationales. Des groupes d'outsourcing IT établis à Bengaluru ou Hyderabad gèrent des systèmes pour des banques européennes, des assureurs américains et des opérateurs télécom africains. Une exigence de patching en 12 heures imposée en Inde se répercute donc, par voie contractuelle, sur l'ensemble de la chaîne de sous-traitance mondiale.

Cette directive arrive dans un contexte où les référentiels réglementaires européens — NIS2 et DORA en tête — imposent des délais de patching dans des délais raisonnables sans préciser de fenêtres horaires. La position indienne, plus prescriptive, pourrait servir de référence lors des prochaines révisions de ces textes. L'ANSSI française et l'ENISA européenne observent de près les approches des partenaires internationaux, et il est probable que les prochaines versions des guides NIS2 prennent en compte les standards définis par les CERT les plus actifs en matière de SLA de patching.

Pour les équipes SOC et les RSSI, l'exigence de 12 heures est techniquement atteignable uniquement avec un haut degré d'automatisation. Cela suppose des pipelines de gestion des correctifs intégralement orchestrés, capables de détecter une nouvelle CVE critique, d'identifier les systèmes concernés dans l'inventaire en temps réel, de déclencher un déploiement en environnement de test et de pousser le patch en production sans intervention manuelle. Les plateformes de CAASM, les outils de gestion des vulnérabilités pilotés par IA et les systèmes de patching automatisé deviennent dans ce contexte non plus des options mais des prérequis réglementaires.

L'angle le plus préoccupant de cette directive est ce qu'elle révèle sur l'état réel de la menace. Le CERT-In est une organisation qui dispose d'un accès aux données d'incidents sur l'une des économies numériques les plus dynamiques du monde. Si cette autorité juge nécessaire d'imposer des délais de 12 heures, c'est qu'elle observe dans ses données opérationnelles une accélération documentée de la capacité d'exploitation post-divulgation. Cette réalité dépasse les frontières indiennes et devrait conduire toutes les organisations, quelle que soit leur juridiction, à réévaluer sérieusement leurs délais de patching actuels.

Ce qu'il faut retenir

• Le CERT-In impose une fenêtre de 12 heures pour patcher les systèmes critiques exposés sur internet, en réponse directe à l'accélération des cycles d'exploitation permise par les outils IA offensifs.
• Le blueprint de 38 pages définit quatre niveaux de délai (12h, 24h, 72h, 5 jours) selon la criticité et l'exposition du système — une approche graduée qui pourrait servir de modèle à d'autres régulateurs nationaux dont l'ANSSI.
• Les organisations qui ne peuvent respecter les délais doivent documenter et notifier des mesures compensatoires : filtrage réseau, règles WAF dédiées ou désactivation temporaire de la fonctionnalité concernée.