Ce que NIS 2 demande vraiment à vos équipements réseau
La directive NIS 2 (UE 2022/2555) a remplacé la première directive NIS et élargi considérablement le nombre d'entités concernées. Son article 21 impose des mesures de gestion des risques « proportionnées », formulées en termes de résultats plutôt que de produits. Pour une équipe réseau, cette formulation ouverte est le vrai sujet : il faut traduire des obligations juridiques en preuves techniques.
Cet article décrit ce que ces obligations impliquent concrètement pour un parc de commutateurs, routeurs et pare-feux, sans prétendre remplacer l'analyse de votre autorité nationale de référence.
Cinq obligations qui touchent directement le réseau
1. Connaître son parc
Aucune mesure de sécurité n'est démontrable sur un équipement que vous ignorez. L'inventaire n'est pas cité comme une mesure en soi, mais il conditionne toutes les autres : analyse de risques, gestion des vulnérabilités, contrôle d'accès. Un inventaire exploitable identifie le constructeur, le modèle, la version de firmware, l'emplacement et le responsable de chaque équipement — et il se met à jour tout seul, sinon il devient faux en quelques semaines.
2. Traiter les vulnérabilités
L'article 21 cite explicitement la gestion et la divulgation des vulnérabilités. Côté réseau, cela signifie être capable de répondre à une question simple quand un avis du CERT-FR paraît : quels équipements sont concernés, dans quelle version, et où sont-ils ? Si la réponse demande une semaine de collecte manuelle, l'obligation n'est pas tenue.
3. Maîtriser les accès
Le texte demande des politiques de contrôle d'accès et, pour les accès privilégiés, une authentification renforcée. Sur un réseau, le point faible habituel est le compte local partagé : un mot de passe enable connu de toute l'équipe, jamais changé après un départ, jamais tracé. Les mesures attendues sont l'identification nominative, l'authentification multifacteur sur les accès d'administration, et une trace de qui a fait quoi.
4. Assurer la continuité
Gestion des sauvegardes et reprise après sinistre figurent dans les mesures. Pour le réseau, la sauvegarde utile n'est pas celle du serveur de supervision : c'est la configuration de chaque équipement, versionnée, avec la capacité de revenir à l'état d'avant une modification. Une sauvegarde dont personne n'a jamais testé la restauration ne constitue pas une preuve.
5. Déclarer les incidents dans les délais
L'article 23 impose une alerte précoce sous 24 heures, une notification sous 72 heures et un rapport final sous un mois. Ces délais sont tenables uniquement si l'historique existe avant l'incident : savoir quelle configuration était en place, ce qui a changé et quand, est ce qui permet de qualifier un événement en quelques heures au lieu de quelques jours.
La différence entre une politique et une preuve
L'erreur la plus fréquente est de documenter une intention. Un classeur qui affirme que « les configurations sont sauvegardées quotidiennement » ne vaut rien devant un auditeur si personne ne peut montrer la sauvegarde d'hier pour un équipement choisi au hasard. Ce que demande un audit, ce sont des éléments vérifiables :
- la liste des équipements, avec leur version logicielle, à une date donnée ;
- l'historique des modifications de configuration, avec leur auteur ;
- le résultat d'un contrôle de conformité, et l'écart résiduel assumé ;
- la trace des accès d'administration, rejouable si nécessaire ;
- la chronologie d'un incident passé, reconstituée à partir des données et non des souvenirs.
Ces cinq éléments sont produits par l'exploitation courante du réseau, pas par un chantier de mise en conformité séparé. C'est précisément l'intérêt d'un outil qui collecte en continu : la preuve est un effet de bord du fonctionnement normal.
Où commencer si vous partez de zéro
Dans cet ordre, parce que chaque étape rend la suivante possible : établir un inventaire automatique, puis une sauvegarde versionnée des configurations, puis un contrôle de conformité qui mesure l'écart avec votre politique, puis la maîtrise des accès d'administration. La déclaration d'incident vient en dernier, car elle consomme tout ce qui précède.
Notre page conformité NIS 2 détaille la correspondance entre ces exigences et les modules de la plateforme, et la page audit de conformité montre comment l'écart est mesuré à chaque collecte.
Un avertissement utile
NIS 2 est une directive : elle est transposée en droit national, avec des variantes. Le périmètre exact des entités concernées, les seuils et les modalités de déclaration dépendent de votre pays et de votre secteur. Les éléments techniques décrits ici sont nécessaires dans tous les cas, mais ils ne constituent pas un avis juridique : faites qualifier votre situation par votre autorité nationale.
