Identités non humaines : l'angle mort systémique dans vos programmes NIS2 et DORA

Pour chaque identité humaine, il existe désormais 45 identités non humaines dans une infrastructure d'entreprise. Tokens API, comptes de service, agents IA — vos programmes NIS2 et DORA les ignorent structurellement.

Écrans de supervision affichant des flux de connexions machine

Quand votre équipe GRC parle de « gestion des identités et des accès », elle pense aux collaborateurs : comptes Active Directory, accès VPN, revues de droits semestrielles. C'est la bonne réponse à la mauvaise question. En 2026, les identités humaines ne représentent plus qu'une minorité des identités actives dans une infrastructure d'entreprise. Une analyse de 350 organisations publiée par CyberArk en 2025 révèle que pour chaque identité humaine, il existe désormais en moyenne 45 identités non humaines (NHI) : comptes de service, tokens API, clés SSH, certificats, agents IA, pipelines CI/CD, connecteurs SaaS. Ces identités ne font l'objet d'aucune révision trimestrielle. Elles ne partent pas en congé. Et quand elles sont compromises, elles restent actives jusqu'à ce que quelqu'un les révoque — ce qui peut prendre des mois.

Le contexte réglementaire : NIS2, DORA et le silence sur les NHI

NIS2 (article 21, paragraphe 2, point i) exige le contrôle des accès et la gestion des identités comme mesures de sécurité obligatoires. DORA (article 9) requiert la gestion des accès privilégiés et la surveillance des droits critiques. Les deux textes sont clairs sur la nécessité d'un contrôle d'accès rigoureux. Aucun des deux ne définit explicitement le périmètre des « identités » à couvrir.

Dans la pratique, 83 % des DSSI ayant répondu à l'enquête Gartner Identity Security 2025 déclarent que leur programme IAM se concentre principalement sur les identités humaines. Leurs politiques de gestion du cycle de vie s'appliquent aux collaborateurs — rarement aux comptes de service, et presque jamais aux tokens API générés par des outils SaaS ou des pipelines automatisés.

Résultat : lors des premiers contrôles NIS2 menés en France et en Allemagne au premier semestre 2026, plusieurs entités ont reçu des observations portant sur des comptes de service avec des droits élevés actifs depuis plus de 24 mois, sans révision documentée. Ces observations n'ont pas donné lieu à des sanctions immédiates, mais elles figurent dans les rapports d'audit comme des « contrôles insuffisants » — ce qui, lors d'un incident ultérieur, peut faire basculer l'appréciation de la faute.

Les trois vecteurs d'attaque que vos programmes NHI ne couvrent pas

Tokens à longue durée de vie sans rotation. Les jetons d'accès API pour les intégrations SaaS (Salesforce, Jira, AWS, GitHub) sont souvent créés une fois, stockés dans un fichier de configuration, et jamais renouvelés. Selon une étude GitGuardian portant sur 3,4 millions de commits GitHub publics en 2025, 12 % contenaient au moins un secret actif (token, clé API, credential) qui n'avait pas été révoqué au moment de la détection. La durée de vie médiane de ces tokens exposés dépassait 14 mois.

Comptes de service orphelins. Chaque migration, fusion, ou rotation de prestataire laisse des comptes de service actifs dont le propriétaire organisationnel n'existe plus. Un audit conduit sur un échantillon de 120 organisations mid-market européennes en 2024 a révélé en moyenne 34 comptes de service actifs dont le propriétaire avait quitté l'organisation — avec des droits sur des systèmes critiques. Ces comptes ne font l'objet d'aucune revue parce qu'ils n'apparaissent pas dans le processus d'offboarding RH.

Agents IA avec accès persistants. C'est le vecteur émergent qui redéfinit la surface d'attaque en 2026-2027. Les agents IA déployés pour l'automatisation des processus GRC ou la détection d'anomalies opèrent avec des identités propres — souvent des comptes de service avec des droits élevés sur les systèmes qu'ils monitorent. La question n'est pas de savoir si ces agents sont fiables : c'est de savoir ce qu'il se passe si la clé API qui leur permet d'accéder à votre SIRH ou à votre registre de traitement RGPD est compromise par un tiers.

Quatre mesures accessibles sans refonte de votre architecture IAM

Inventorier avant de sécuriser. Vous ne pouvez pas gérer ce que vous ne voyez pas. L'inventaire des NHI est le prérequis à toute mesure. Il doit couvrir : tous les comptes de service Active Directory/Entra ID, tous les tokens API actifs, tous les certificats avec date d'expiration, et tous les pipelines CI/CD avec leurs droits associés. Des coffres-forts de secrets (CyberArk, HashiCorp Vault, AWS Secrets Manager) permettent de centraliser cet inventaire.

Appliquer le principe du moindre privilège aux comptes non humains. Un pipeline CI/CD n'a pas besoin de droits d'administration sur votre base de production. Un compte de service de supervision n'a pas besoin de droits d'écriture. La revue des droits des NHI suit les mêmes principes que la revue des droits humains — elle est simplement plus rarement faite. Un audit de périmètre NHI annuel est un début ; un cycle de revue trimestriel aligné sur votre programme DORA est la cible.

Mettre en place la rotation automatique des secrets. Les tokens et mots de passe des comptes de service ne doivent pas avoir une durée de vie indéfinie. La rotation automatique — 90 jours maximum pour les accès privilégiés, 30 jours pour les systèmes critiques — est une bonne pratique que NIS2 peut être interprétée comme exigeant implicitement au titre de la gestion des accès. Des coffres-forts modernes permettent d'automatiser cette rotation sans intervention manuelle.

Intégrer les NHI dans vos processus d'offboarding prestataire. Quand un prestataire ou un outil SaaS quitte votre périmètre, la procédure d'offboarding doit explicitement couvrir la révocation des tokens et comptes de service associés. C'est une modification de processus, pas d'architecture — mais elle nécessite que les équipes IT, sécurité et achats parlent le même langage.

Comment évaluer votre exposition actuelle

Le diagnostic NHI peut être initié en quatre heures d'entretiens structurés avec vos équipes IT et sécurité. Presidio intègre la cartographie des identités non humaines dans son module d'évaluation NIS2/DORA, avec une priorisation automatisée des risques par niveau d'exposition et un plan de remédiation séquencé. Demander un diagnostic gratuit →

Lire aussi : IAM et contrôle d'accès : les priorités d'audit NIS2 et DORADORA et les risques de concentration ICT.

Un projet ? Une question ?

Nous contacter →