Le 22 septembre 2026, l'ENISA a publié son rapport annuel Threat Landscape. L'édition 2026 couvre 4 875 incidents analysés sur la période juillet 2024 à juin 2025 (source : ENISA Threat Landscape 2026, 22 septembre 2026). Sa conclusion centrale est formulée sans ambiguïté : les dépendances numériques élargissent la surface d'attaque et exigent un niveau de vigilance nouveau pour prévenir les incidents et en limiter l'impact. Pour les équipes qui pilotent un programme NIS2 ou DORA, ce rapport n'est pas une lecture académique — il valide ou invalide vos choix de priorité actuels.
Ce que l'ENISA mesure — les vecteurs d'intrusion
Le rapport documente trois vecteurs qui concentrent l'essentiel de l'activité malveillante observée. Le déni de service distribué représente 51,3 % des incidents enregistrés sur des entités de l'Union européenne. Les accès non autorisés arrivent en deuxième position avec 39,5 %.
Mais c'est le chiffre sur l'exploitation de vulnérabilités qui mérite l'attention la plus soutenue : 60,4 % des intrusions abouties utilisent une vulnérabilité comme vecteur initial d'accès, qu'il s'agisse d'une faille de jour zéro ou d'une vulnérabilité connue et non corrigée (source : ENISA Threat Landscape 2026, 22 septembre 2026). Ce n'est pas une tendance émergente. C'est la confirmation, sur quatre mille huit cent soixante-quinze incidents, que l'attaquant choisit le chemin de moindre résistance — et que ce chemin passe presque toujours par un composant non patché, un service exposé ou une interface oubliée.
Sur le volet financier, 40 % des événements à motivation financière impliquent le déploiement d'un rançongiciel. Le reste se répartit entre exfiltration de données (31 %) et fraude par usurpation d'identité (19 %). L'administration publique reste le secteur le plus ciblé, devant la santé, le transport ferroviaire, le maritime et les services ICT.
Ce que "dépendances numériques" signifie dans la pratique
L'ENISA utilise l'expression "cyber dependencies" pour désigner l'ensemble des relations de confiance et de dépendance technique entre votre organisation et des tiers : fournisseurs de services cloud, éditeurs de logiciels, partenaires d'intégration, prestataires de maintenance. Ces dépendances ne sont pas nouvelles. Ce qui a changé, c'est leur densité. La numérisation des processus et l'adoption du cloud ont multiplié les points de contact entre votre système d'information et l'extérieur.
Le rapport identifie ici un angle mort structurel. Une organisation peut disposer d'une politique de gestion des vulnérabilités rigoureuse sur ses actifs connus et demeurer exposée via des actifs dont elle ignore l'existence, ou via des tiers dont elle n'a pas évalué la surface d'attaque. L'attaquant, lui, cartographie systématiquement. Il ne distingue pas vos actifs "connus" de vos actifs "inconnus". Il cherche l'entrée disponible.
Ce que NIS2 et DORA exigent déjà sur ce point
Pour les organisations soumises à NIS2 ou DORA, ce tableau n'est pas théorique. Les deux cadres réglementaires contiennent des obligations explicites sur la visibilité des actifs et la gestion des dépendances.
NIS2 (directive, article 21) impose une gestion des risques qui couvre la chaîne d'approvisionnement et les relations avec les fournisseurs. Cela suppose de savoir quels fournisseurs accèdent à vos systèmes, dans quelles conditions et avec quel niveau de risque résiduel. Une organisation qui ne peut pas répondre à ces questions lors d'un contrôle ANSSI expose une lacune documentable.
DORA va plus loin. Les entités financières doivent maintenir un registre d'informations ICT qui recense tous leurs prestataires de services TIC, avec leur niveau de criticité. Ce registre doit être maintenu à jour et communiqué à l'autorité compétente sur demande. L'AMF et l'ACPR ont signalé que le contrôle de ce registre constitue une priorité de supervision pour le second semestre 2026. En d'autres termes, ce que l'ENISA décrit comme un facteur de risque systémique, NIS2 et DORA le transforment en obligation documentaire.
Un scénario représentatif
Considérons le cas d'une entité de taille intermédiaire, soumise à NIS2 comme entité importante, qui déploie une application métier en mode SaaS. Le fournisseur SaaS intègre lui-même un composant d'authentification tiers. Ce composant, non géré directement par l'entité, présente une vulnérabilité connue depuis trois mois : le CVE est public, le correctif disponible, mais le fournisseur SaaS ne l'a pas encore appliqué.
L'entité ne sait pas que ce composant existe dans son périmètre. Son équipe de sécurité surveille les CVE critiques, mais uniquement sur les actifs qu'elle gère directement. L'attaquant exploite la faille via le fournisseur SaaS. L'entité NIS2 doit notifier l'ANSSI sous 24 heures — pour un incident causé par une dépendance dont elle ignorait l'existence.
Ce scénario est la traduction concrète de la conclusion ENISA : les dépendances non cartographiées sont des vecteurs d'intrusion que vos processus de détection et de patch management ne peuvent pas couvrir, précisément parce qu'ils ne savent pas qu'elles existent.
Ce que vos équipes doivent ajuster
Trois ajustements découlent directement du rapport.
Étendre la cartographie d'actifs au périmètre de vos dépendances de second rang. Il ne s'agit pas uniquement de lister vos fournisseurs directs. Il s'agit de comprendre quels composants tiers ils intègrent dans les services qu'ils vous livrent. Le standard SBOM (Software Bill of Materials) est l'outil structuré pour opérer cette visibilité. Exiger un SBOM de vos fournisseurs critiques est désormais une pratique alignée avec les attentes réglementaires — les détails de mise en oeuvre sont couverts dans l'article consacré à l'inventaire logiciel sous NIS2 et DORA.
Intégrer les alertes CVE relatives à vos composants tiers dans votre flux de veille. Un composant que vous ne gérez pas directement reste dans votre périmètre de risque. Si votre outil de veille sur les vulnérabilités ne couvre que vos actifs internes, il ne couvre pas votre surface d'attaque réelle.
Tester votre processus de notification sur un scénario de découverte tardive. Le rapport ENISA confirme que les incidents par exploitation de vulnérabilité sont rarement détectés à la source. Ils sont souvent identifiés par une alerte externe ou lors d'une investigation post-incident. Si votre plan de notification NIS2 ne prévoit pas ce cas, il sous-estime la réalité opérationnelle que les contrôleurs connaissent.
Ce que ce rapport change pour vos arbitrages
Le Threat Landscape 2026 donne à vos équipes un référentiel externe pour justifier des investissements internes. Lorsqu'un programme de cartographie des dépendances numériques est mis en discussion budgétaire, la réponse à la question "pourquoi maintenant ?" est désormais documentée par l'agence européenne de cybersécurité, sur la base de quatre mille huit cent soixante-quinze incidents réels.
Lorsque 60 % des intrusions passent par une vulnérabilité, la question posée lors d'un contrôle NIS2 ou d'une revue DORA n'est pas de savoir si votre organisation peut être touchée par ce vecteur. C'est de savoir si elle a la visibilité suffisante pour détecter, notifier et contenir un incident qui l'emprunterait. L'inventaire de vos dépendances est la réponse opérationnelle à cette question.