Pourquoi les identités non humaines constituent votre plus grand risque pour la continuité des activités en 2026.
Chaque équipe de sécurité d’entreprise est confrontée à un problème de main-d’œuvre qu’elle ne peut voir dans aucun organigramme.
Bots, comptes de service, clés API, jetons OAuth, certificats de machine : les identités non humaines sont désormais plus nombreuses que les identités humaines dans la plupart des grandes organisations, souvent dans un facteur dix contre un. Ils s’authentifient constamment, opèrent dans tous les environnements et, lorsqu’ils sont oubliés, ils ne se retirent pas gracieusement. Ils s’attardent, accumulent des privilèges et attendent. Les professionnels de la sécurité ont pris l’habitude de les appeler des identités fantômes – et le nom leur convient.
Le secteur de la sécurité a reçu de nombreux avertissements. Il n’a tout simplement pas donné suite.
Revenez à l’histoire de SolarWinds. Les assaillants n’ont rien détruit. Ils se sont infiltrés, ont trouvé des identités de machines avec un accès important et les ont utilisées de la manière pour laquelle elles avaient été conçues : discrètement, légitimement et invisiblement. Dix-huit mille organisations. Mois non détectés. Les informations d’identification n’ont pas été volées au sens traditionnel du terme. Ils étaient juste là, sans surveillance, faisant ce que les attaquants attendaient d’eux.
Uber, 2022. Anatomie plus simple. Un compte de service dont personne n’appartient. Des pouvoirs qui n’avaient pas été alternés depuis on ne sait combien de temps. Trouvé dans un partage réseau par un attaquant qui recherchait déjà. Cette identité fantôme a ouvert un chemin direct vers le système PAM – et à partir de là, tout le reste a suivi. Environnements cloud. Code source. Outils internes. Un identifiant oublié. C’était le prix d’entrée.
Okta, 2023. Problème différent, plus difficile à résoudre. Les informations d’identification importantes ne se trouvaient même pas sur la propre infrastructure d’Okta. Ils vivaient avec un fournisseur de support tiers. Techniquement, l’environnement de quelqu’un d’autre. Mais ils détenaient des droits d’accès aux systèmes d’Okta, et lorsque ce fournisseur a été compromis, le chemin a également été compromis.
Trois incidents. Trois points d’entrée différents. Un point commun : une identité que personne ne surveillait, disposant d’un accès que personne n’avait récemment justifié, située exactement là où un attaquant en avait besoin.
Appeler cela un problème de sécurité n’est pas une erreur. Cela ne couvre tout simplement pas ce qui va suivre.
La crise programmée
En 2026, les conséquences des identités non humaines non gérées prennent une nouvelle forme. Pas une violation. Un événement du calendrier.
Les certificats d’identité des machines ont une durée de vie limitée. Pendant une grande partie de la dernière décennie, les organisations les ont délivrés avec des périodes de validité de trois à cinq ans. Entre 2020 et 2022, les entreprises ont étendu leur infrastructure numérique à une vitesse extraordinaire : migrations vers le cloud compressées en quelques mois, pipelines d’automatisation résistés à la pression et nouveaux services se connectant à d’autres services avec une gouvernance après coup.
Ces certificats expirent maintenant. Pas en un ou deux. En volume.
Le scénario d’échec en cascade n’est pas compliqué. Un certificat expire inaperçu. Le service qu’il prend en charge est supprimé. Les applications dépendantes authentifiées via ce service commencent à échouer. Les outils de surveillance exécutés sur la même infrastructure ne reçoivent pas l’alerte. L’équipe de réponse aux incidents travaille sur le problème sans avoir une vision complète de ce qui est lié à quoi. Les heures passent. Parfois une journée complète. Ce qui a commencé comme un identifiant négligé avec une date d’expiration se transforme en une panne avec un chiffre d’affaires attaché et un régulateur prenant des notes.
Cela s’est déjà produit à plus petite échelle : un seul certificat expiré a mis Microsoft Teams hors ligne pour des millions d’utilisateurs en 2020. Ce que présente 2026 est le même mode d’échec, répliqué dans des organisations qui se sont développées rapidement et ont mal gouverné, frappant simultanément.
L’expiration des certificats est généralement traitée comme un problème d’exploitation informatique. Ce cadrage ne survit pas à une panne qui entraîne une interruption des services destinés aux clients pendant dix-huit heures.
Le fossé structurel
La cause profonde n’est pas la négligence. C’est de l’architecture.
Les outils sur lesquels les organisations s’appuient pour gérer l’identité (contrôles d’accès basés sur les rôles, plateformes de gestion des accès privilégiés, campagnes de certification d’accès) ont été conçus pour les individus. Ils supposent qu’une identité a un propriétaire, un gestionnaire et un cycle de révision. Les identités non humaines ne correspondent pas à ce modèle. Ils sont créés pour résoudre un problème immédiat, bénéficient d’un large accès pour faire fonctionner la chose et restent opérationnels longtemps après la progression du projet.
Le surprovisionnement aggrave le risque. Chaque compte de service non examiné est un point pivot potentiel. Chaque clé API dormante avec accès en écriture est une porte ouverte. Pour les identités fantômes dotées de droits d’administrateur hérités – et elles sont plus nombreuses que la plupart des organisations ne veulent l’admettre – le rayon d’action d’une compromission s’étend souvent à l’ensemble de l’organisation.
À quoi ressemble le bien
La réponse n’est pas un outil. Tous les vendeurs de cet espace vous diront le contraire. Ils se trompent sur l’ordre des opérations.
La gouvernance passe avant tout. L’outillage le prend en charge. Et la gouvernance commence par une question à laquelle la plupart des organisations ne peuvent actuellement pas répondre : quelles identités non humaines dirigeons-nous ?
Cette question semble simple. Ce n’est pas. Les NHI ne sont pas créés de manière centralisée. Ils sont créés par des développeurs qui résolvent des problèmes, par des équipes de plateforme qui mettent en place des services, par des fournisseurs connectant leurs produits aux vôtres. Chaque décision avait du sens à l’époque. Aucun d’entre eux n’a été connecté à un endroit utile. Le résultat, dans la plupart des grandes entreprises, est un domaine dont personne n’a une carte complète – et qu’aucun outil ne peut gouverner jusqu’à ce que quelqu’un en construise un.
Alors, commencez par là. Pas avec une évaluation de plateforme. Pas avec un document politique. Avec un sprint découverte. Quatre à six semaines, axées sur vos environnements les plus à risque. Le cloud d’abord. Pipelines CI/CD. Intégrations tierces. Un inventaire imparfait reste infiniment plus utile qu’une opération à l’aveugle.
Pendant que ce travail est en cours, extrayez les données d’expiration de votre certificat. Aujourd’hui, pas le trimestre prochain. Trier par date d’expiration. Filtrez tout ce qui expire au cours des dix-huit prochains mois. Associez un propriétaire nommé à chaque entrée et, lorsqu’aucun propriétaire ne peut être identifié, traitez le certificat comme une identité fantôme. Faites-le remonter en conséquence. Cette seule action répond directement au risque d’expiration en 2026 avant qu’il ne devienne une panne.
Enfin, effectuez un audit des privilèges sur vos comptes de service les plus sensibles. Tout NHI doté de droits d’administrateur qui n’a pas été examiné au cours des douze derniers mois doit être traité comme étant trop privilégié jusqu’à ce que les preuves indiquent le contraire. Assumer l’excès. Prouver la nécessité.
Rien de tout cela ne nécessite une nouvelle ligne budgétaire. Il faut que quelqu’un décide que cela vaut la peine de le faire avant que l’alternative ne décide à sa place.
Le problème plus large
Une seule organisation réparant son patrimoine NHI ne résout pas le problème. Cela signifie simplement qu’une organisation est moins exposée que les autres.
Le marché autour de l’identité des machines est encore en train de trouver ses marques. Demandez à trois fournisseurs de définir la portée de la gouvernance du NHI et vous obtiendrez trois réponses différentes. Les normes de cycle de vie qui devraient exister n’existent pas. Les cadres sur lesquels s’appuient les équipes de sécurité (NIST, ISO 27001) abordent le moindre privilège en tant que concept, mais ne disent pas à quiconque quoi faire avec cinquante mille comptes de services non gérés répartis dans un environnement de cloud hybride.
Ce qui manque, ce n’est pas l’ambition. C’est la spécificité. Taxonomie convenue. Normes de cycle de vie partagées. Des orientations réglementaires qui placent la gouvernance du NHI au même niveau que toute autre obligation d’identité – non enfouies dans une note de bas de page, non implicites par un principe, mais énoncées clairement et appliquées en conséquence.
Cette conversation a lieu. Les organismes de normalisation bougent. Les régulateurs y prêtent une plus grande attention. Mais le rythme se mesure en années, et la vague d’expiration des certificats se mesure en mois.
Les dates de péremption n’attendent pas que l’industrie rattrape son retard.
Le délai est intégré
La main-d’œuvre fantôme ne s’annonce pas. Il ne démissionne pas et ne demande pas d’évaluation des performances. Il fonctionne jusqu’à ce que quelque chose l’arrête : une violation, une expiration ou une équipe de sécurité qui a finalement décidé de faire l’inventaire.
En 2026, pour les organisations qui n’ont pas cartographié et gouverné leur patrimoine NHI, quelque chose va l’arrêter. La seule variable est de savoir si ce quelque chose est un programme délibéré ou une panne imprévue.
La piste est très fine.
Cet article est publié dans le cadre du Foundry Expert Contributor Network.
Voulez-vous nous rejoindre ?
