Aller au contenu principal
Retour à l'aperçu

NIS2 communications sécurisées : la moitié de l'article 21(2)(j) que la plupart des programmes ignorent

Par NIS2Certify
nis2article-21communications-securiseescommunication-urgencereponse-incidentsmsp
NIS2 communications sécurisées : la moitié de l'article 21(2)(j) que la plupart des programmes ignorent

Entre février et juin 2026, Sophos a suivi une campagne qu'il nomme STAC4749. Les attaquants ont créé des comptes Microsoft Teams sur des domaines à consonance IT, appelé des employés en se faisant passer pour le helpdesk et les ont convaincus d'ouvrir une session Quick Assist. Au moins trois de ces intrusions se sont terminées par le ransomware Chaos. L'une est passée du premier appel Teams aux fichiers chiffrés en moins de 17 heures.

Demandez-vous maintenant ce que ces organisations ont utilisé pour coordonner leur réponse. Teams. Outlook. Le même tenant dans lequel l'attaquant était déjà entré.

C'est le problème que les exigences NIS2 en matière de communications sécurisées doivent résoudre. L'article 21(2)(j) est la mesure qui le couvre, et c'est la moitié de cet article que la plupart des programmes de conformité ne mettent jamais en œuvre.

L'article 21(2)(j) a deux moitiés, et la plupart des programmes n'en construisent qu'une

La formulation de la directive est courte : « l'utilisation de solutions d'authentification à plusieurs facteurs ou d'authentification continue, de communications vocales, vidéo et textuelles sécurisées et de systèmes sécurisés de communication d'urgence au sein de l'entité, selon les besoins ».

Tout le monde lit la première partie. La MFA obtient un budget, un projet et une ligne dans le rapport au conseil. Nous avons expliqué en début d'année pourquoi la MFA seule ne passe plus un audit.

La seconde partie est ignorée. Elle contient deux obligations distinctes : sécuriser vos canaux voix, vidéo et texte du quotidien, et disposer d'un système de communication d'urgence qui fonctionne encore quand les canaux du quotidien ne fonctionnent plus.

« Selon les besoins » n'est pas une clause de sortie. C'est un qualificatif fondé sur le risque. Si vous décidez qu'une mesure n'est pas appropriée, la décision doit figurer dans l'analyse des risques, avec sa justification. Un auditeur traite le silence comme une lacune, pas comme une décision.

Article 21 — 10 Mesures de Cybersécurité NIS2

Article 21

10 Mesures de Cybersécurité

Gouvernance & Stratégie

1Analyse des risques & politiques de sécurité de l'information
6Évaluation de l'efficacité des mesures de sécurité

Incidents & Continuité

2Gestion des incidents & notification
3Continuité des activités & reprise après sinistre

Chaîne d'approvisionnement & Systèmes

4Sécurité de la chaîne d'approvisionnement
5Sécurité dans le développement des systèmes d'information

Contrôles Techniques

8Cryptographie & chiffrement
10Authentification multifacteur & communications sécurisées

Personnel & Actifs

7Cyber-hygiène & formation
9Sécurité RH & contrôle d'accès

Le règlement d'exécution disperse l'exigence sur cinq sections

Le règlement d'exécution (UE) 2024/2690 de la Commission est le référentiel détaillé pour les infrastructures numériques, la gestion des services TIC et les fournisseurs numériques. Les MSP et MSSP en relèvent donc directement. Les autorités nationales des autres secteurs l'utilisent comme référence pour définir ce qui est « approprié ».

Il ne contient aucune section intitulée « communications sécurisées ». Cherchez-en une et vous conclurez que l'obligation est mince. Elle ne l'est pas. Elle est dispersée :

Le point 3.5.3 exige des plans et procédures de communication pour la réponse aux incidents : avec le CSIRT ou l'autorité compétente, entre vos propres collaborateurs et avec les parties prenantes externes.

Le point 4.1.2(c) exige que le plan de continuité d'activité et de reprise après sinistre liste les contacts clés et les canaux de communication internes et externes.

Le point 4.2.4(d) exige une redondance au moins partielle des « canaux de communication appropriés », aux côtés de la redondance des systèmes, des installations et du personnel.

Le point 4.3.2(b) exige que le processus de gestion de crise définisse les moyens de communication avec les autorités compétentes, tant pour les notifications obligatoires que pour les échanges non obligatoires.

Les points 6.7.2(i) et (k) exigent des canaux de confiance isolés entre les systèmes et un plan de mise en œuvre des normes modernes de communication par e-mail.

Le point 11.7 couvre la moitié MFA.

Conséquence pratique : un auditeur ne demandera pas « avez-vous des communications sécurisées ? ». Il demandera votre procédure de réponse aux incidents, votre plan PCA/PRA et votre processus de gestion de crise, et cherchera le canal de communication dans chacun. Si la réponse est « e-mail et Teams » dans les trois, le constat s'écrit tout seul.

Votre réponse aux incidents tourne sur le système où se trouve l'attaquant

Partez du principe que vous êtes compromis. Ce n'est pas de la paranoïa, c'est un comportement documenté.

Microsoft et la CISA décrivent tous deux comment Octo Tempest, plus connu sous le nom de Scattered Spider, fouille le Slack, le Teams et l'Exchange Online de sa victime à la recherche de conversations sur sa propre intrusion, et rejoint les appels de réponse aux incidents pour apprendre comment les défenseurs le traquent. En juin 2026, des affiliés de DragonForce ont été observés en train de faire transiter leur trafic de commande et contrôle par des relais Microsoft Teams légitimes pour se fondre dans le trafic collaboratif normal.

Si l'attaquant détient un compte Entra ID privilégié, chaque canal qui s'authentifie auprès d'Entra ID lui est lisible. Y compris le canal Teams « de secours » que vous avez créé pour la cellule de crise.

Un système de communication d'urgence passe trois tests :

Identité séparée. Il ne s'authentifie pas via votre fournisseur d'identité principal. Si le SSO vous y fait entrer, un SSO compromis y fait entrer l'attaquant.

Infrastructure séparée. Il n'est pas hébergé dans le même tenant, sur le même domaine ou derrière le même DNS que vous devrez peut-être couper.

Provisionné à l'avance et répété. La liste de contacts existe hors ligne, les comptes existent avant l'incident et le canal a été utilisé lors d'un test. Le point 4.1.4 exige que les plans PCA/PRA soient testés à intervalles planifiés. Le canal d'urgence fait partie de ce plan, donc de ce test.

En pratique, ce n'est pas coûteux. Un groupe Signal ou Threema sur des appareils gérés par MDM avec des comptes non liés au SSO de l'entreprise. Une carte de contacts imprimée dans le classeur de crise. Une boîte mail de secours chez un autre fournisseur. Le coût n'est pas dans l'outil. Le coût est dans la discipline de le maintenir à jour.

Un autre détail souvent oublié : l'alerte précoce sous 24 heures de l'article 23 doit atteindre votre CSIRT même quand c'est votre serveur de messagerie qui est tombé. Les coordonnées que vous avez fournies au registre national des entités lors de l'enregistrement sont celles que le CSIRT utilisera pour vous rappeler. Si c'est une boîte mail dans le tenant compromis, vous avez un problème de notification en plus d'un problème de sécurité. La procédure de gestion des incidents doit nommer explicitement la voie de repli vers le CSIRT.

Calendrier de Notification des Incidents NIS2

24h

Alerte Précoce

Notifiez l'autorité compétente (CSIRT/ANC) dans les 24 heures suivant la prise de connaissance d'un incident significatif.

72h

Notification d'Incident

Soumettez une notification détaillée dans les 72 heures avec une première évaluation de la gravité, de l'impact et des indicateurs de compromission.

1mo

Rapport Final

Remettez un rapport final complet dans un délai d'un mois couvrant l'analyse des causes, les mesures prises et l'impact transfrontalier.

NIS2 communications sécurisées : un standard de configuration, pas un achat de produit

Teams, Google Meet et Zoom chiffrent tous en transit. Personne n'échoue à un audit parce que ses appels vidéo ne sont pas chiffrés. La vraie question que pose le règlement est : qui peut joindre vos collaborateurs, par quels canaux et sous quels contrôles ?

Traduisez cela en paramètres concrets et le tableau devient clair.

Accès externe. STAC4749 et la campagne Black Basta avant elle reposaient toutes deux sur la capacité de comptes Teams externes à écrire et appeler des employés. Restreindre la fédération externe à une liste blanche de domaines partenaires, ou bloquer le chat et les appels externes pour la plupart des utilisateurs, supprime le point d'entrée. Le point 6.7.2(c) exige déjà d'empêcher les communications réseau non nécessaires à l'exploitation. C'est la version « couche collaborative » de cette règle.

Authentification des e-mails. Le point 6.7.2(k) demande un plan de mise en œuvre des « normes modernes de communication par courrier électronique convenues au niveau international et interopérables ». Les orientations techniques de mise en œuvre de l'ENISA de juin 2025 renvoient à SPF, DKIM et DMARC pour l'authentification de l'expéditeur et à MTA-STS ou DANE pour le chiffrement du transport. Un enregistrement DMARC en p=none, c'est de la surveillance, pas de la protection. Les auditeurs ont appris la différence.

Outils approuvés par classification. Votre politique de cryptographie au titre de l'article 21(2)(h) doit indiquer quels outils de messagerie et de visioconférence sont approuvés pour quel niveau de classification des actifs. Un conseil qui discute d'un incident sur WhatsApp depuis des téléphones personnels est un constat, parce qu'aucune politique ne l'autorise et qu'aucun contrôle ne l'encadre.

Hygiène des réunions. Salle d'attente activée, accès authentifié pour les réunions internes, partage d'écran et enregistrement réservés à l'hôte, et une règle selon laquelle personne n'est anonyme sur un appel de crise.

Voix. Trunks SIP et VoIP via TLS et SRTP, et, pour les sites où cela compte, une capacité d'appel d'urgence qui ne dépend pas du fonctionnement du réseau de l'entreprise.

Rien de tout cela n'exige l'achat d'un nouveau produit. Tout cela exige quelqu'un qui possède la configuration et sait en exporter la preuve.

Ce qu'un auditeur demandera réellement

Les autorités de supervision demandent désormais des dossiers de preuves plutôt que des déclarations de politique. Nous avons couvert la checklist générale des preuves il y a deux semaines. Pour l'article 21(2)(j), attendez-vous à ces huit éléments :

  1. La section communication de la procédure de réponse aux incidents, nommant les canaux principaux et de repli avec leurs responsables.
  2. La section contacts clés et canaux du plan PCA/PRA, datée dans le cycle de révision en cours.
  3. Une déclaration de redondance des canaux de communication au titre du point 4.2.4(d).
  4. Un compte rendu de test montrant que le canal d'urgence a été utilisé lors d'un exercice.
  5. Un export de la configuration d'accès externe de Teams ou Google Workspace.
  6. Les enregistrements DNS pour DMARC, MTA-STS et, le cas échéant, DANE.
  7. La liste des outils de communication approuvés, liée aux niveaux de classification des actifs.
  8. Les entrées de l'analyse des risques justifiant toute décision « non approprié ».

Si vous pouvez produire les huit en une journée, vous en avez fini avec cette mesure. Si vous pouvez en produire trois, vous savez où commence l'analyse des écarts.

Pour les MSP, cette mesure s'applique deux fois

Un MSP est une entité de gestion des services TIC au sens de l'annexe I de NIS2. Le règlement 2024/2690 s'applique à lui directement. C'est votre propre obligation.

Puis il y a le côté client. La politique de sécurité de la chaîne d'approvisionnement de chaque client, au titre du point 5.1, est censée évaluer les pratiques de cybersécurité de ses prestataires. Votre capacité à communiquer avec un client pendant un incident, par un canal qui n'est ni le tenant compromis du client ni votre tenant compromis, fait partie de ces pratiques.

Jouez ce scénario : votre RMM ou votre tenant M365 est compromis. Quarante clients doivent l'apprendre en quelques heures. Votre messagerie est précisément ce qui est compromis. Quelle est la liste, où est-elle, et qui l'a sur un téléphone qui ne se synchronise pas avec le SSO de l'entreprise ?

S'il n'y a pas de réponse, c'est le premier point de votre propre plan de remédiation. Le Cyberbeveiligingswet néerlandais est en vigueur depuis le 15 août 2026, et la RDI supervise directement la gestion des services TIC. Le BSI allemand et le CCB belge le font depuis plus longtemps. La double obligation des MSP n'est plus théorique sur aucun de ces marchés.

Escalade des sanctions NIS2 — Au-delà de l'amende

!

Déclencheur

Non-conformité détectée ou incident survenu

Une autorité de contrôle identifie une lacune de conformité ou une organisation ne respecte pas les exigences NIS2

Les autorités peuvent imposer
Sanctions non financières
1

Ordres de mise en conformité avec délais contraignants

2

Audits de sécurité obligatoires à vos frais

3

Divulgation publique des violations

4

Instructions contraignantes sur des mesures de sécurité spécifiques

Escalade vers
Conséquences opérationnelles et personnelles
1

Suspension de certifications ou licences d'exploitation

2

Interdiction temporaire de fonctions de direction pour les individus

3

Désignation publique des personnes physiques responsables

Déclencheur
Non financier
Opérationnel / personnel

Par où commencer ce mois-ci

Ce n'est pas un projet avec un comité de pilotage. Ce sont quatre tâches.

Choisir le canal d'urgence et le provisionner. Identité séparée, infrastructure séparée, liste de contacts stockée hors ligne.

L'écrire. Ajouter le canal à la procédure de réponse aux incidents sous 3.5.3 et à la section contacts clés du plan PCA/PRA sous 4.1.2(c).

Fermer la porte d'entrée. Restreindre la fédération externe dans Teams. Passer DMARC en p=reject une fois que les rapports confirment vos expéditeurs légitimes.

Le tester. Le premier message de votre prochain exercice sur table part uniquement par le canal d'urgence. Si personne ne le voit, vous avez appris quelque chose d'important à un moment opportun.

Si vous voulez savoir où se situe l'article 21(2)(j) par rapport aux neuf autres mesures pour un client donné, le quick scan NIS2Certify couvre les dix en une dizaine de minutes et vous fournit une liste d'écarts priorisée pour démarrer.

Une autre question ?

Les réponses sont générées à partir de nos articles et ne constituent pas un avis juridique. N'entrez pas de données personnelles ou confidentielles.

    NIS2 communications sécurisées : la moitié de l'article 21(2)(j) que la plupart des programmes ignorent — NIS2Certify