Cybersecurity Act 2.0 et NIS2 : la Commission européenne frappée par une cyberattaque… juste après son paquet cybersécurité

Fin janvier 2026, la Commission européenne s’est pris une cyberattaque dans un coin qu’on oublie souvent: la plateforme centrale qui gère les smartphones et autres terminaux mobiles du personnel. Pas une boîte mail piégée au hasard, pas un ransomware qui met tout à genoux. Un accès non autorisé à l’outil d’administration à distance, avec à la clé des données pro qui peuvent faire mal: des noms et des numéros de téléphone de membres du staff.

Cyberattaque contre la Commission européenne : noms et numéros du staff volés via la gestion mobile

La Commission dit avoir détecté l’incident le 30 janvier et l’avoir contenu en neuf heures. Elle insiste sur un point: pas de trace de compromission des appareils mobiles eux-mêmes, et pas d’indice que des données sensibles type mots de passe, finances ou communications classifiées aient été touchées. Sauf que même “juste” des identités et des numéros, c’est du carburant premium pour du phishing bien sale. Et ça, sur une institution qui écrit les règles du jeu numérique en Europe, ça pique.

Une attaque sur la plateforme MDM, pas sur les téléphones

Le cur de l’affaire, c’est l’infrastructure de gestion des terminaux mobiles, le fameux MDM (Mobile Device Management). C’est l’outil qui permet de pousser des réglages, imposer un code PIN, effacer un appareil à distance, gérer des applis pro. En clair, un tableau de bord avec des droits très élevés. Les attaquants ont visé ce point-là, et c’est logique: quand tu touches l’admin, tu touches potentiellement tout le parc, ou au minimum l’annuaire des gens qui utilisent les appareils.

La Commission explique qu’aucune compromission des appareils n’a été détectée. Donc pas de signe que les smartphones ont été “pris” un par un, ni que des contenus ont été siphonnés directement depuis les terminaux. Ça ne veut pas dire “zéro risque”, ça veut dire que, dans les traces qu’ils ont, ils n’ont pas vu de prise de contrôle des mobiles. Et dans ce genre d’incident, l’absence de preuve n’est pas une preuve d’absence – surtout quand tu dois investiguer vite.

Sur les données, le discours est cadré: des noms et des numéros de téléphone mobile de certains membres du personnel ont pu être accessibles. D’autres informations professionnelles sont évoquées dans la couverture de l’affaire, comme des adresses e-mail pro. Mais le message central reste le même: pas de données hautement sensibles. Pas de mots de passe, pas de données financières, pas de contenu classifié. C’est important, parce que ça change la nature du scénario: on est plus sur l’amorçage d’attaques futures que sur un pillage massif immédiat.

Ce qui est frappant, c’est le choix de la cible technique. Le MDM, c’est souvent un empilement de composants, parfois d’éditeurs tiers, avec des consoles web, des API, des comptes à privilèges, et des connexions à des annuaires internes. C’est pratique, mais c’est un aimant à ennuis. Quand ça tombe, même partiellement, tu offres aux attaquants une vue claire: qui travaille là, qui a un téléphone géré, et comment le joindre. Pour une campagne de manipulation, c’est déjà énorme.

Neuf heures pour contenir l’incident: ce que ça dit

La Commission met en avant un chiffre: neuf heures entre la détection et le “nettoyage” du système. Sur le papier, c’est rapide. Dans la vraie vie, neuf heures, c’est long et court à la fois. Court parce que certaines intrusions dorment des semaines avant d’être vues. Long parce que, quand un attaquant a une fenêtre d’accès, il peut automatiser des extractions et repartir vite, surtout si la console d’admin donne accès à des listes d’utilisateurs et à des attributs de contact.

Dans la description technique qui circule, on parle d’indicateurs de compromission repérés via la télémétrie interne, puis de protocoles de confinement, suppression d’artefacts malveillants, et remise en service. Ça ressemble à une réponse SOC classique: alerte, isolement, éradication, restauration. Le CERT-EU est cité comme partie prenante, avec une posture de surveillance continue. Ça ne fait pas disparaître le problème, mais ça montre qu’il y a une chaîne de réaction structurée.

Le truc, c’est que la Commission “entretient le flou” sur l’ampleur exacte. Combien de personnes concernées? Combien de numéros? Quels services touchés? Silence radio, ou presque. Je comprends la logique: tu ne veux pas donner une carte au trésor aux attaquants, ni déclencher une panique interne. Mais à force de rester vague, tu laisses aussi les employés dans le brouillard, et tu compliques la prévention côté humain: comment tu veux que les gens se méfient si tu ne leur dis pas précisément ce qui a fuité?

Et puis il y a le volet réglementaire: en Europe, une violation de données, ça se notifie, et vite. La règle des 72 heures du RGPD plane au-dessus de tout le monde. Là encore, on ne te demande pas de raconter ta vie, mais de décrire la nature de la violation, les données concernées, et les mesures prises. Dans ce dossier, la communication est très maîtrisée: on sent le souci de dire “on a contenu”, “pas de sensible”, “on enquête”. C’est propre, mais ça laisse des questions très concrètes en suspens.

Pourquoi des noms et numéros suffisent pour du phishing crédible

Tu pourrais te dire: “Bon, c’est juste des noms et des numéros, on s’en remet.” Sauf que c’est exactement le genre de données qui permet de fabriquer une attaque sur mesure. Imagine un SMS qui arrive sur ton téléphone pro: “Bonjour, ici support IT Commission, on doit ré-enrôler votre appareil suite à l’incident MDM. Cliquez ici.” Avec ton nom, ton service, et un ton crédible, tu cliques plus vite que tu ne veux l’admettre – surtout quand tu bosses sous pression.

Le phishing moderne, ce n’est plus le mail bourré de fautes qui te promet un héritage nigérian. C’est du social engineering qui colle au contexte. Là, le contexte est parfait: une attaque MDM, une communication interne, des procédures de sécurité, des liens vers des portails. Les attaquants peuvent se faire passer pour un prestataire, pour le helpdesk, ou même pour un collègue. Et le téléphone, c’est un canal encore plus traître: moins de visibilité sur l’URL, moins de réflexes, plus d’urgence.

Autre scénario: l’appel vocal. Tu reçois un coup de fil, la personne connaît ton nom et sait que tu es dans l’organisation. Elle te dit qu’il faut “valider” une opération de sécurité, ou “confirmer” un code. Si tu as déjà vécu une période de crise IT, tu sais que ça arrive pour de vrai, donc tu es moins sur la défensive. Et si en plus l’attaquant enchaîne avec un mail pro, un faux ticket, un vocabulaire interne, tu as un cocktail qui marche trop bien.

Je l’ai vu dans d’autres rédactions et chez des boîtes qui se croyaient blindées: la fuite de données “pas sensibles” devient la rampe de lancement vers le sensible. Tu commences par des contacts, tu obtiens un accès, tu pivotes, tu montes en privilèges. Là, la Commission dit ne pas avoir d’indice d’exploitation des données volées, ni de publication en ligne à ce stade. Tant mieux. Mais le risque, lui, ne s’évapore pas en neuf heures: il s’étale dans le temps, au rythme des tentatives de manipulation qui suivent.

Ivanti, les Pays-Bas, et l’effet domino des outils partagés

Dans les éléments évoqués autour de l’enquête, une piste technique revient: une possible exploitation de vulnérabilités dans un logiciel de type Ivanti Endpoint Manager Mobile. Prudence: tout n’est pas confirmé publiquement dans le détail, mais l’idée est crédible parce que ce genre d’outil est largement utilisé pour gérer des flottes mobiles. Et quand une vulnérabilité est connue, la vraie question devient bête et méchante: est-ce que le patch était appliqué partout, au bon moment?

Ce dossier ne touche pas que Bruxelles. Des institutions néerlandaises ont aussi été impactées: l’autorité de protection des données (celle qui est censée surveiller la confidentialité, ironie totale) et le Conseil de la justice. Quand plusieurs organisations se font toucher dans la même fenêtre, ça sent l’exploitation en série: même produit, même faille, mêmes méthodes. C’est l’effet domino des chaînes d’approvisionnement logicielles: tu partages un outil, tu partages aussi ses problèmes.

Ce qui est intéressant, c’est la dimension “infrastructure centrale”. Un MDM, c’est souvent mutualisé, standardisé, administré par des équipes qui doivent gérer du volume. Tu as des politiques globales, des profils, des certificats, des intégrations. Du coup, la moindre faiblesse devient systémique. Et plus tu dépends d’un éditeur, plus tu dépends aussi de sa capacité à publier des correctifs, à documenter les failles, à prévenir correctement. C’est exactement le genre de sujet que l’UE veut encadrer avec ses textes sur la supply chain numérique.

Je mets quand même une nuance: il ne suffit pas de dire “c’est la faute du fournisseur”. Dans la vraie vie, la sécurité, c’est une chaîne. Tu as l’éditeur, oui, mais tu as aussi la configuration, les comptes admin, la segmentation réseau, la supervision, les accès à distance. Et tu as la réalité opérationnelle: des équipes qui patchent la nuit, des compatibilités à vérifier, des contraintes de continuité de service. C’est là que les incidents arrivent: dans les interstices entre “on aurait dû” et “on a pu”.

Cybersecurity Act 2.0, NIS2: la Commission face à ses propres règles

Le timing est cruel: l’incident survient juste après la présentation d’un paquet cybersécurité daté du 20 janvier 2026, avec un Cybersecurity Act 2.0 mis en avant, et l’idée d’une “Trusted ICT Supply Chain” plus contrôlée. Sur le papier, ça vise à réduire les risques liés aux fournisseurs et aux dépendances logicielles. Et là, quelques jours plus tard, tu as une attaque qui vise précisément une brique centrale de gestion, potentiellement liée à un éditeur tiers. Niveau symbole, c’est du brut.

Il y a aussi NIS2, qui pousse des exigences de sécurité, de gouvernance et de coopération entre secteurs, et le Cyber Solidarity Act, avec ce qui est présenté comme un bouclier cyber européen et des mécanismes d’urgence. Dans cette affaire, on voit déjà la logique: détection, partage interne, mobilisation d’équipes spécialisées, revue post-incident. La Commission explique qu’un examen approfondi est en cours et que les enseignements serviront à renforcer ses capacités. C’est le discours attendu, mais c’est aussi la seule sortie possible: apprendre, durcir, vérifier.

Sur la gouvernance, le CERT-EU et les structures interinstitutionnelles jouent un rôle central. Le message, c’est “on a un SOC 24/7, on a des alertes, on coordonne”. Très bien. Mais la vraie question politique est simple: si même l’institution qui pousse la régulation se fait toucher, quel niveau de maturité cyber peut-on raisonnablement exiger de collectivités, d’hôpitaux, de PME, qui n’ont ni les budgets ni les équipes? Ça ne dédouane personne, mais ça remet l’échelle des promesses face à la réalité.

Et puis il y a l’historique: ce n’est pas la première fois que la Commission se fait secouer. Il y a une quinzaine d’années, une attaque ciblée avait paralysé la messagerie, avec changement de mots de passe et mesures d’urgence, et ça avait contribué à accélérer la mise en place d’une capacité dédiée type CERT-EU. On retrouve le même schéma: incident, réaction, renforcement. Sauf qu’en 2026, la surface d’attaque a explosé: mobiles, cloud, identités, prestataires. On n’est plus dans le monde où “changer les mots de passe” suffit à tourner la page.