NIS 2 et supply chain: obligations concrètes et certification

La règle générale

La directive NIS 2 impose aux entités « essentielles » et « importantes » de mettre en place des mesures techniques, opérationnelles et organisationnelles proportionnées (art. 21). Parmi ces mesures figure explicitement la sécurité de la chaîne d’approvisionnement, y compris les aspects liés aux relations avec les fournisseurs et prestataires directs (art. 21(2)(d)). Texte officiel : Directive (UE) 2022/2555 (NIS 2), voir art. 21 et 21(2)(d).

Point d’attention sur la numérotation : la gestion de la supply chain relève juridiquement de l’article 21(2)(d), tandis que l’article 24 traite de l’« utilisation de schémas européens de certification de cybersécurité » pour démontrer la conformité à certaines exigences de l’article 21. En clair : vous devez gérer le risque fournisseurs (art. 21), et vous pouvez être tenus — par l’État membre ou par acte délégué de la Commission — d’utiliser des produits/services/processus ICT certifiés au titre du Cybersecurity Act (art. 24). Voir art. 24 NIS 2 : CELEX 32022L2555, et le cadre de certification défini par le Cybersecurity Act : Règlement (UE) 2019/881 et ENISA – EU Cybersecurity Certification Framework.

Ce que dit le régulateur

• Luxembourg (ILR). L’ILR rappelle aux entités concernées de se préparer sans attendre en s’alignant sur les normes européennes/internationales et précise son rôle d’autorité compétente pour la majorité des secteurs au Luxembourg (renvoi au projet de loi transposant NIS 2). Voir la FAQ officielle NISS : ilr.lu/faq/niss.
• Commission européenne / Groupe de coopération NIS. Un « EU ICT Supply Chain Security Toolbox » a été adopté pour guider les États et les organisations sur les contrôles à instaurer dans les relations fournisseurs. Voir : Toolbox to improve ICT supply chain security et la page NIS2 : digital-strategy.ec.europa.eu – NIS2.
• ENISA (agence de l’UE). L’ENISA publie des bonnes pratiques de gestion du risque de supply chain (cartographie, due diligence, clauses contractuelles, suivi continu). Référence : Good Practices for Supply Chain Cybersecurity (juin 2023). ENISA rappelle aussi le lien entre l’art. 21(2)(d) et la politique de supply chain dans ses documents techniques NIS2.
• Base juridique de la certification. L’article 24 NIS 2 autorise les États membres à exiger l’usage de produits/services/processus ICT certifiés sous des schémas européens (CSA, art. 49). Cadre officiel : ENISA – EU Cybersecurity Certification Framework et texte du CSA : Publications Office – 2019/881.

Comment l’appliquer en pratique

Objectif dirigeant : démontrer que vos relations avec prestataires et éditeurs (cloud, MSSP, intégrateurs, logiciels métiers, opérateurs OT, infogérance) n’introduisent pas de risques non maîtrisés pour la disponibilité, l’intégrité et la confidentialité de vos services.

Avant (conception et sélection)

1. Politique Supply Chain Security exigée par l’art. 21(2)(d) : portée, rôles (achats, sécurité, juridique), critères de criticité, niveaux d’exigence par catégorie de fournisseurs. Base : NIS 2 et Toolbox.
2. Cartographier et classifier les dépendances ICT : opérateurs de systèmes critiques, localisation des données, interconnexions. S’inspirer de l’ENISA : Good Practices.
3. Exigences minimales par catégorie de risque : journaux/télémétrie exportables, MFA/segmentation, politiques de correctifs, SSO/SCIM, chiffrement, VDP/gestion vulnérabilités, notification d’incident sous X heures, RPO/RTO, réversibilité/portabilité.
4. Preuves attendues : SOC 2/ISO 27001 utiles mais non suffisantes. Vérifier l’adéquation au périmètre et aux contrôles NIS 2 art. 21. Envisager l’usage de produits/services certifiés UE (art. 24) lorsque des schémas pertinents existent ; à défaut, privilégier standards ouverts et attestations renforcées. Références : NIS 2 art. 24 et cadre CSA.
5. Clauses contractuelles : intégrer le « Toolbox » et l’ENISA comme check-list : droits d’audit proportionnés, tests de sécurité, exigences SBOM, délais de patch, obligation d’information (incidents et near misses), mesures si exposition d’identifiants, résilience (BCP/DRP), exigences de sous‑traitance en cascade, conditions de fin de contrat (effacement/restitution/transfert). Sources : Toolbox UE, ENISA Good Practices.

Pendant (exécution et monitoring)

6. Due diligence renforcée : questionnaires fondés sur art. 21(2) a–j, preuves d’implémentation (politiques, rapports de tests, métriques patching), visites/entretiens ciblés pour fournisseurs critiques. Voir NIS 2 art. 21.
7. Supervision continue : SLA sécurité, revues trimestrielles, suivi des vulnérabilités majeures, collecte de journaux pertinents côté prestataire, exercices conjoints de gestion de crise.
8. Intégration détection/réponse : scénarios d’incident incluant prestataires (ex. attaque de chaîne logicielle), canaux d’alerte, partage d’IoC, playbooks dédiés. Référence : art. 21(2)(b)(c) NIS 2.

Après (retour d’expérience et amélioration)

9. Revues post‑incident fournisseur, actions correctives contractuelles, mise à jour de la classification et des exigences.
10. Cycle de vie : à chaque évolution majeure (nouvelle version SaaS, relocalisation, sous‑traitant de rang 2), réévaluer l’exposition et les garanties.

Exemple concret (Luxembourg, 2026)

Un opérateur de services de paiement (entité « essentielle ») externalise l’infogérance réseau à un MSSP et migre des applications vers un cloud public.

• Cartographie : le MSSP détient des accès d’administration — classé « critique ». Le cloud héberge des données de production — « très critique ».
• Exigences : MFA/PAM, segmentation, journaux exportés vers SIEM interne, RTO ≤ 4 h, notification d’incident en 12 h, SBOM pour composants sensibles.
• Preuves : ISO 27001 du MSSP + rapports de red team ; pour le cloud, priorité aux services disposant d’un schéma de certification européen pertinent dès qu’il sera disponible (art. 24 NIS 2 + CSA).
• Contrat : droit d’audit sur contrôles NIS 2, délais de patch (7/30/90 jours), réversibilité, gestion vulnérabilités (CVE critiques ≤ 7 jours).
• Suivi : comité sécurité mensuel, exercices de crise conjoints, KPIs de détection.

Pièges fréquents

1. Conformité documentaire vs efficacité : un certificat générique ne couvre pas nécessairement les contrôles ciblés NIS 2 art. 21(2)(d). Référez-vous au texte et au Toolbox : NIS 2 art. 21, Toolbox.
2. Oublier la chaîne en cascade (N+1/N+2) : imposez des exigences équivalentes aux sous‑traitants du fournisseur. Appui : ENISA 2023.
3. Clauses d’audit inopérantes : droits d’audit vagues ou sans mécanisme de remédiation/SLA. Inspirez‑vous du Toolbox pour cadrer preuves, délais et mesures correctives : Commission – Toolbox.
4. Ignorer l’article 24 : lorsque des schémas européens pertinents existent (ou seront rendus obligatoires), intégrez-les à vos achats. Voir NIS 2 art. 24 et cadre CSA.
5. Anticipation insuffisante au Luxembourg : l’ILR recommande de se préparer dès maintenant ; attendre complexifie les migrations contractuelles. Source : ILR – FAQ NISS.

Sources officielles

• Directive (UE) 2022/2555 (NIS 2) – articles 21 et 24 : EUR‑Lex et version CELEX bilinguée : CELEX 32022L2555.
• Cadre européen de certification (Cybersecurity Act, Règlement (UE) 2019/881) : texte EUR‑Lex 32019R0881, présentation ENISA du cadre : ENISA – Certification Framework, Publications Office : 2019/881.
• EU ICT Supply Chain Security Toolbox : digital-strategy.ec.europa.eu et page NIS2 : digital-strategy.ec.europa.eu – NIS2.
• ENISA – Good Practices for Supply Chain Cybersecurity (juin 2023) : enisa.europa.eu.
• Luxembourg – ILR (autorité compétente NIS) : FAQ NISS : ilr.lu/faq/niss et page secteur NISS : ilr.lu/en/sectors/niss.

Remarque : les obligations de supply chain découlent de l’art. 21(2)(d) NIS 2 ; l’art. 24 encadre l’usage (potentiellement obligatoire) de schémas de certification européens pour démontrer la conformité à certaines exigences de l’art. 21.

Article d'expertise Luxgap. Pour un cadrage personnalise sur ce sujet, contactez-nous ou configurez votre devis en ligne.