Tout savoir sur la sécurité des identités non humaines

Une identité non humaine (NHI) est une entité logicielle, telle qu’un compte de service, une charge de travail, une instance d’ cloud , un appareil ou un agent automatisé, capable de s’authentifier et de se voir accorder des autorisations d’accès aux ressources. Aucune personne ne se cache derrière elle, et elle est créée par un événement logiciel plutôt que par le recrutement d’un employé. En dehors du domaine de la cybersécurité, cette expression a une signification tout à fait différente, et l’acronyme NHI est généralement associé, dans les recherches, à une signification sans rapport avec le sujet ; par conséquent, pour être clair : cette page traite des entités logicielles au sein des systèmes d’identité d’entreprise.

Ces identités constituent désormais la majeure partie des éléments d'authentification au sein d'un environnement moderne. Elles bénéficient de privilèges permanents, fonctionnent en continu, ont rarement un propriétaire désigné et leurs informations d'identification survivent généralement aux systèmes qui les ont émises. Cette page définit cet ensemble d'identités, en délimite les contours par rapport aux identités machine et à la gestion des identités et des accès (IAM), explique comment ces identités sont concrètement compromises et décrit les mesures prises par une équipe de sécurité lorsqu'une d'entre elles déclenche une alerte.

Qu'est-ce qu'une identité non humaine ?

Une identité non humaine désigne toute entité logicielle capable de s'authentifier et d'être autorisée à accéder à des ressources, sans qu'aucune personne ne se cache derrière elle. Les comptes de service, les charges de travail, les instances d'cloud , les appareils et les agents automatisés entrent tous dans cette catégorie. Cette catégorie existe car l'automatisation nécessite des identifiants d'accès. Chaque tâche planifiée, chaque pipeline, chaque intégration et chaque microservice doit prouver son identité avant de pouvoir effectuer une action utile.

La sécurité des identités non humaines, souvent abrégée en « sécurité NHI », consiste à recenser cette population, à attribuer à chaque identité un propriétaire et un ensemble de droits bien délimité, à réduire la durée de validité de ses identifiants, et à détecter tout comportement inhabituel. Les programmes de gestion des risques internes intègrent de plus en plus ces identités, car un compte de service sans propriétaire et un employé non surveillé posent un problème de gouvernance similaire.

Le critère de délimitation : ce qui compte et ce qui ne compte pas

L'Alliance pour la sécurité de l'Cloud e ( Security Alliance) établit une définition très stricte. Dans son document de 2026 intitulé « Defining Non-Human Identity » (Définition de l'identité non humaine), une entité est considérée comme une identité non humaine (NHI) « uniquement lorsqu'elle est capable de s'authentifier (prouver son identité) et d'être autorisée (se voir accorder des autorisations), directement ou indirectement, à accéder à des ressources » (Cloud Security Alliance).

Ce critère exclut plusieurs éléments que l'on qualifie souvent à la légère d'« identités non humaines ». Un enregistrement de configuration, tel qu'une entrée de CMDB décrivant un serveur, n'est pas une identité à moins d'être utilisé pour s'authentifier ou obtenir des droits d'accès. Il en va de même pour les objets de métadonnées, ainsi que pour le code et les scripts qui ne servent jamais à s'authentifier. Plus important encore, les secrets, les jetons, les clés API et les certificats ne constituent pas non plus des identités, à moins d’être liés à l’une d’entre elles. Cette dernière exclusion modifie la manière dont un programme est exécuté, et la section suivante explique pourquoi.

Le gouvernement américain utilise son propre terme pour désigner ce même concept. Le NIST définit une « entité non humaine » (NPE) comme « une entité liée aux technologies de l’information, dotée d’une identité numérique et agissant dans le cyberespace, mais qui n’est pas un acteur humain », en s’appuyant sur les normes CNSSI 4009-2015, NIST SP 800-162 et NIST SP 800-207 (NIST CSRC). Lorsqu’un cadre de contrôle ou un contrat fédéral mentionne le terme « NPE », il s’agit d’une identité non humaine.

Combien d'identités non humaines une organisation possède-t-elle ?

Il n'existe pas de consensus au sein du secteur quant à l'ampleur du déséquilibre entre les identités non humaines et les identités humaines, et les chiffres publiés sont contradictoires. Ils portent sur des populations différentes : l'ensemble des entreprises dans une étude, les environnements natifs d'cloud s dans une autre, et uniquement les grandes organisations dans une troisième. Ils utilisent des dénominateurs différents, comptant les identités de machines par employé dans un cas, et les identités non humaines par identité humaine dans un autre. De plus, ils proviennent de méthodes variées, allant de la télémétrie d'authentification à l'analyse des référentiels, en passant par les déclarations des personnes interrogées dans le cadre d'enquêtes. Considérez tout ratio présenté dans les titres comme indicatif d’une tendance et limité à son contexte, jamais comme une référence pour votre propre situation.

Ce qu'on peut affirmer sans risque, c'est la tendance. Les identités non humaines sont désormais largement plus nombreuses que les identités humaines dans la plupart des environnements, et cet écart ne cesse de se creuser à mesure que l'automatisation et les flux de travail basés sur des agents se développent.

Ce chiffre, accessible et daté, qui n’est pas un ratio, sert de référence. Un rapport de 2026 a révélé que 91 % des identités actives en production étaient non humaines, issues des environnements AWS et Google Cloud surveillés par ce fournisseur (Help Net Security). Il s’agit d’une part des identités actives observées au sein du parc surveillé par un fournisseur. Ce n’est pas un ratio, et le convertir en tant que tel reviendrait à inventer un chiffre que l’étude ne corrobore pas.

Quels sont les différents types d'identités non humaines ?

Les identités non humaines se répartissent en cinq catégories, regroupées en fonction de ce à quoi l'identité est liée plutôt qu'en fonction du titre qu'elle présente.

Cinq thèmes liés à l'identité

Tableau : Les cinq types d'identité non humaine selon la taxonomie de l'Alliance de sécurité « Cloud », ce à quoi chaque identité est liée, ainsi qu'un exemple concret pour chacune d'entre elles.

C'est la colonne du milieu qui fait le vrai travail. Un compte de service est associé à une entité d'application, ce qui lui permet de survivre à un redéploiement. Une identité de charge de travail est associée à un pod, un service ou une fonction en cours d'exécution ; elle peut donc n'exister que pendant quelques secondes. Les identités d'infrastructure sont associées à des instances et à des nœuds, les identités de périphériques au matériel et aux micrologiciels, y compris les capteurs IoT, et les identités d'agent à un acteur autonome. Les identités de charge de travail constituent le groupe qui connaît la croissance la plus rapide dans les environnements conteneurisés, ce qui explique pourquoi, dans la pratique, les travaux sur la sécurité de Kubernetes et ceux sur les identités non humaines se recoupent si fortement.

Le sujet d'identité n'est pas le mécanisme d'authentification

Les organisations confondent systématiquement l’identité avec l’élément utilisé pour la prouver, en traitant une clé API, un jeton ou un certificat comme s’il s’agissait de l’identité elle-même. Ce n’est pas le cas. Il s’agit de mécanismes d’authentification, que la taxonomie classe en cinq catégories : les secrets statiques tels que les mots de passe, les clés API et les clés SSH ; les jetons signés tels que les assertions JWT, OIDC et SAML ; les certificats, notamment les X.509 et les SPIFFE SVID ; les identifiants protégés par matériel ou par attestation stockés dans un TPM, un HSM ou un élément sécurisé ; et les identifiants de session natifs d’ cloud, de nature temporaire et à durée de vie courte.

La règle de gouvernance découle directement de cette distinction. Il faut associer la propriété, le cycle de vie et les droits à l’entité concernée, c’est-à-dire le compte de service ou la charge de travail qui perdure. Il faut adapter la robustesse des identifiants, la fréquence de rotation et leur renouvellement au mécanisme, qui peut être remplacé sans modifier l’identité de la personne concernée. Les programmes qui inversent cette approche finissent par faire tourner les secrets avec rigueur, alors que personne ne peut dire à qui appartient le compte auquel ces secrets se rapportent. C’est également la raison pour laquelle un inventaire des clés API n’est pas un inventaire des identités.

Les agents d'IA sont-ils des identités non humaines ?

Oui, à une condition. La taxonomie de l’ Cloud Security Alliance désigne les « identités d’agents (acteurs autonomes, y compris l’IA) » comme l’un de ses cinq types ; un agent IA est donc une identité non humaine et présente tous les modes de défaillance mentionnés sur cette page : privilège permanent, identifiants non renouvelés et absence de propriétaire désigné. La condition est que l’autorisation « agent-outil » dispose désormais de son propre modèle normatif. La spécification du Model Context Protocol (MCP) datée du 28 juillet 2026 fait des serveurs MCP des serveurs de ressources OAuth 2.1 qui « DOIVENT vérifier que les jetons d’accès ont bien été émis spécifiquement pour eux en tant que destinataires visés » (Model Context Protocol). Les questions de gouvernance, de cycle de vie et de contrôle spécifiques aux agents relèvent de la sécurité de l’IA agentique.

Le lien entre l'identité non humaine, l'identité des machines et la gestion des identités et des accès (IAM)

La sécurité des identités non humaines consiste à appliquer la gestion des identités et des accès (IAM) à des entités qui n'ont jamais fait l'objet d'un processus d'embauche, de mutation ou de départ. Le tableau distingue ces trois termes, qui sont souvent utilisés de manière interchangeable.

Tableau : Différences entre les identités humaines, non humaines et machines en fonction de leur origine, de leurs informations d'identification, de leur propriété et de leur fin de vie.

Identités humaines et non humaines

Ce qui fait toute la différence, c’est l’origine de cette identité. Les identités humaines passent par des processus de gestion des entrées, des mutations et des départs pilotés par les RH ; leur cycle de vie est donc associé à un système d’enregistrement et à une personne qui en est responsable. Les identités non humaines, quant à elles, trouvent leur origine dans des événements liés au cycle de vie des logiciels : un déploiement, une opération de provisionnement, le démarrage d’une charge de travail, l’exécution d’un pipeline, un événement d’auto-scaling, l’invocation d’un agent. Aucun système RH n’a connaissance de ces événements. C’est pourquoi les modèles de gouvernance fondés sur les processus d’embauche, de mutation et de départ ne s’appliquent pas naturellement à cette population.

Identité de la machine et structure du certificat

Ces termes se recoupent sans pour autant être synonymes. La gestion des identités machines s'inscrit dans la tradition de l'infrastructure à clé publique (PKI) et s'articule autour des certificats, des clés et du renouvellement avant expiration. La gestion des identités non humaines s'articule quant à elle autour des comptes de service, des jetons OAuth, des clés API et de l'autorisation de service à service. La distinction entre « sujet » et « mécanisme » explique cette différence : un certificat est un mécanisme, et non un type d'identité.

Le calendrier de validité des certificats se resserre selon son propre rythme. Le CA/Browser Forum a adopté le scrutin SC-081v3 le 11 avril 2025, réduisant progressivement la durée de validité maximale des certificats TLS de confiance publique de 398 jours à 47 jours, ces réductions étant « proposées pour débuter en mars 2026 et s'achever en mars 2029 » (CA/Browser Forum). Ce calendrier ne s'applique qu'aux certificats TLS de confiance publique. Il ne concerne pas les infrastructures PKI internes et n'a aucune incidence sur les jetons OAuth et les clés API qui constituent l'essentiel du contenu de cette page.

Place occupée par la sécurité NHI par rapport à l'IAM

L'IAM est une discipline de la cybersécurité, et la sécurité des identités non humaines en est la partie qui concerne les entités auxquelles aucune personne n'est associée. Cette distinction est d'ordre opérationnel plutôt qu'académique, car les outils IAM traditionnels ont été conçus autour des événements du cycle de vie humain. Dans une enquête de la Security Alliance de l’ Cloud , commanditée par un éditeur et menée en ligne en août et septembre 2025 auprès de 383 professionnels, 92 % des personnes interrogées ont déclaré ne pas être convaincues que leurs solutions IAM traditionnelles puissent gérer efficacement les risques associés à l’IA et aux identités non humaines (Security Alliance de l’ Cloud ). L’analyse des identités est le domaine où ces deux populations se rejoignent dans la pratique, en appliquant la modélisation comportementale aux deux.

Comment les identités non humaines sont compromises

Les identités non humaines sont compromises par des procédures de désinscription qui ne révoquent jamais les identifiants, par des intégrations tierces conservant des jetons actifs et par des secrets qui n’ont jamais été renouvelés. Ce qui les rend attractives, c’est leur nature structurelle plutôt qu’exotique. Elles disposent de privilèges permanents, fonctionnent en continu, ont rarement un responsable en mesure de détecter un problème, et leur activité ressemble en tous points à l’automatisation légitime qu’elles imitent.

Privilège de présence et prolifération des secrets

Toute identité non humaine disposant de droits dont elle n’a pas besoin à l’heure actuelle élargit la surface d’attaque, car les identifiants restent valides, qu’ils soient utilisés ou non. Les identifiants non humains volés constituent également une voie directe vers la propagation latérale, puisqu’un compte de service qui communique déjà avec cinq systèmes offre un chemin tout tracé entre ceux-ci. Ces identités se concentrent là où la surveillance directe est la plus faible, ce qui explique pourquoi la sécurité de l’cloud et les programmes de gestion des identités non humaines ne cessent de converger.

La prolifération des secrets constitue la partie mesurable du problème. La cinquième édition du rapport « State of Secrets Sprawl », publiée le 17 mars 2026, a détecté 28 649 024 nouveaux secrets dans les commits publics de GitHub au cours de l'année 2025, soit une augmentation de 34 % par rapport à l'année précédente, dont 1 275 105 secrets appartenant à des services liés à l'IA, en hausse de 81 % par rapport à l'année précédente (GitGuardian). Il s’agit d’identifiants correspondant à des identités créées par quelqu’un et dont personne n’a assuré le suivi ; or, le vol d’identifiants qui trouve son origine dans un dépôt public ne nécessite aucune intrusion.

L'implication de tiers aggrave encore la situation. Verizon indique que la participation de tiers dans les violations de données a augmenté de 60 % par rapport aux données de l'année dernière, les violations impliquant un tiers représentant désormais 48 % de l'ensemble des violations (Verizon Newsroom). Son résumé exécutif 2026 ajoute que l'exploitation des vulnérabilités « a atteint 31 % dans l'ensemble de données de cette année » en tant que vecteur d'accès initial le plus courant (résumé exécutif du rapport DBIR 2026 de Verizon). Le rapport complet situe la période couverte par les incidents du 1er novembre 2024 au 31 octobre 2025. Une attaque de la chaîne d'approvisionnement visant les jetons d'une intégration affecte tout ce à quoi ces jetons ont accès.

Ce que révèlent trois incidents avérés

Tableau : trois incidents avérés, illustrant chacun une défaillance différente d'une identité non humaine, avec la cause profonde et l'enseignement qui en découle.

Mise en correspondance du « Top 10 des identités non humaines » de l'OWASP avec des incidents réels

Le classement « Top 10 des identités non humaines » (NHI) de l'OWASP comprend exactement dix entrées, numérotées de NHI1 à NHI10. Leur mise en correspondance avec des incidents vérifiés permet de distinguer les risques théoriques de ceux qui ont déjà eu des conséquences.

Tableau : Cinq éléments tirés du Top 10 « Identités non humaines » de l'OWASP (2025), chacun étant associé à un incident vérifié qui en illustre un exemple concret.

Les cinq éléments qui ne figurent pas dans le tableau ci-dessus sont les suivants : NHI4:2025 « Authentification non sécurisée », NHI6:2025 « Configurations de déploiement non sécurisées d’ Cloud », NHI8:2025 « Isolation de l’environnement », NHI9:2025 « Réutilisation des NHI » et NHI10:2025 « Utilisation des NHI par des personnes » (OWASP). Ce dernier élément est celui qui est le plus souvent omis dans les résumés de la liste.

En termes d’ MITRE ATT&CK , les clés API, les jetons OAuth et les clés de signature volés sont obtenus dans le cadre de 0006 Accès aux identifiants. Remarque concernant la nomenclature à l'attention de ceux qui cartographient d'anciennes logiques de détection : la matrice Enterprise de la version 19.2 comporte 15 tactiques, et la tactique « Évasion défensive » n'en fait plus partie, puisqu'elle a été supprimée dans la version 19 et remplacée par 0005 Discrétion et 0112 Déficience en matière de défense.

On retrouve la même tendance dans les rapports sur les vulnérabilités. CVE-2026-12564, publié le 18 août 2026, décrit un plugin de gestion des identifiants dans lequel un attaquant authentifié disposant de privilèges de création d'identifiants peut provoquer la lecture du jeton du compte de service Kubernetes d'un pod contrôleur et son envoi vers une URL contrôlée par l'attaquant. Le CNA lui a attribué une note de 9,6 (critique), et le NVD n'avait pas encore publié sa propre note au moment de la rédaction de cet article (NVD).

Comment détecter et endiguer la compromission d'identités non humaines

Détecter une compromission d'identité non humaine implique de définir un profil de référence des activités normales de chaque entité machine et de signaler tout écart, car les identifiants sont valides et l'authentification en elle-même ne semble présenter aucune anomalie. Le confinement consiste alors à procéder d'abord à la révocation, puis à résoudre les dépendances en production, une décision que la plupart des équipes n'ont pas prise à l'avance. Cela en fait donc autant un problème d'exploitation du SOC qu'un problème de gouvernance des identités.

Il convient de préciser cette lacune de manière précise plutôt que vague. Des recommandations existent concernant les capacités d’identification des entités non humaines et l’ordre des étapes d’intervention, et cette page les cite ci-dessous. Ce qu’aucune page de classement ne fournit, et ce que même l’organisme de normalisation de la catégorie ne propose pas, ce sont des critères de triage adaptés aux SOC ou un guide d’intervention de confinement structuré et séquentiel. C’est précisément ce que cette section apporte.

Pourquoi les signaux de détection axés sur les personnes ne se déclenchent-ils pas en présence d'entités non humaines ?

Les utilisateurs humains accèdent aux systèmes de manière prévisible, depuis des lieux précis ou à des moments précis de la journée, et une grande partie de la détection d’identité repose sur cette prévisibilité. Les identités non humaines ne présentent pas ces schémas de comportement physique, ce qui explique pourquoi le « déplacement impossible », l’exemple canonique, est décrit par l’Alliance pour la sécurité de l’ Cloud e comme un schéma « centré sur les humains, mais pas sur une identité non humaine » (Alliance pour la sécurité de l’ eCloud ). Les mécanismes de détection hérités de la population humaine échouent discrètement dans ce cas. Ils ne se déclenchent pas par erreur, ils ne se déclenchent tout simplement jamais.

Cinq capacités viennent les remplacer. La détection et l’identification continues permettent de repérer les identités que personne n’a enregistrées. Les graphes d’identité cartographient les chaînes de rôles assumés et la confiance déléguée, qui créent des chemins transitifs d’escalade des privilèges. L’établissement de références comportementales définit la norme pour chaque identité. La détection en temps réel couvre les premiers accès aux données clients, les mises à jour suspectes et les téléchargements massifs de secrets. La réponse aux incidents boucle la boucle. La fonction elle-même consiste en la détection et la réponse aux menaces liées aux identités, tandis que l’analyse comportementale des identités fournit la modélisation sous-jacente.

Critères de triage pour une alerte relative à une identité non humaine

Évaluez l'alerte à l'aune de ces huit questions, classées en fonction de leur poids respectif dans la décision finale.

1. Cette identité correspond-elle à une personne identifiée ? Personne ne peut confirmer que cette activité était prévue.
2. Ce comportement s'écarte-t-il de la norme établie pour cette identité ? Une charge de travail qui en effectue une sixième après en avoir effectué cinq pendant deux ans constitue un signe révélateur.
3. S'agit-il d'un premier accès à un référentiel de données sensibles ? L'écart le plus élevé disponible pour une identité à longue durée de vie.
4. Ces identifiants ont-ils une durée de validité prolongée ou ont-ils dépassé leur intervalle de rotation ? Le retard de rotation allonge la période pendant laquelle des identifiants volés restent valides.
5. L'identité confère-t-elle un privilège allant au-delà de sa fonction ? Un droit trop large transforme un petit compromis en un impact de grande ampleur.
6. L'identité est-elle accessible depuis une intégration tierce ? Les jetons tiers constituent une exposition de première partie, comme l'a démontré Salesloft Drift.
7. Le « graphique des identités » montre-t-il un chemin transitif vers des privilèges plus importants ? Les chaînes de rôles présumés permettent à des identités ordinaires d'atteindre des positions exceptionnelles.
8. Existe-t-il des preuves d'une récupération massive et secrète de données ? Les lectures en masse à partir d'un coffre-fort relèvent rarement d'un processus automatisé normal.

‍

‍

Une séquence de confinement et le choix entre « révocation » et « interruption de la production »

L'Alliance de sécurité de l'Cloud , fournit cette procédure, qui est tout à fait pertinente. Dès la détection d'une intrusion, il convient de révoquer en priorité les jetons et clés d'accès compromis afin de couper l'accès de l'attaquant. Il faut ensuite isoler les charges de travail affectées et évaluer l'étendue de l'incident en parcourant le graphe d'identité. Enfin, la restauration doit être automatisée, y compris le remplacement des identifiants, uniquement après vérification de la propreté de l'environnement, en conservant une validation humaine pour les incidents de gravité élevée ou ambigus, afin d'éviter que de nouveaux secrets ne soient émis dans un contexte encore compromis.

Ce que cette procédure présuppose, sans toutefois le fournir, c'est la couche décisionnelle qui la sous-tend. Il convient de répondre à trois questions avant la survenue d'un incident, et non pendant celui-ci. À qui revient la décision de révocation lorsque l'identité n'a pas de propriétaire désigné ? Quelle est la solution de secours lorsque la révocation rompt une dépendance en production ? Comment organiser la révocation pour un compte de service dont les utilisateurs sont inconnus ?

Ce compromis n’a rien d’hypothétique. Dans l’enquête « SANS State of Identity Threats and Defenses » de 2026, menée auprès de plus de 500 professionnels de la sécurité à l’échelle mondiale, 92 % d’entre eux ne procèdent pas à la rotation des identifiants des machines tous les 90 jours, craignant que cela n’entraîne la défaillance des comptes de service (Infosecurity Magazine). Une approche progressive et viable consiste à restreindre progressivement les droits d’accès avant de les supprimer : retirer d’abord les autorisations, observer ce qui ne fonctionne plus tant que les identifiants sont encore actifs, puis les révoquer.

La révocation doit également s’étendre à la couche des jetons. L’avis du FBI concernant les applications connectées malveillantes souligne que l’autorisation d’une telle application permet de contourner les mesures de sécurité telles que l’authentification multifactorielle, la réinitialisation des mots de passe et la surveillance des connexions, et que, les jetons OAuth étant émis par la plateforme elle-même, l’activité de l’application malveillante peut passer pour une intégration fiable. Dans le cas de la compromission de Drift, le confinement a pris cette forme : le 20 août 2025, tous les jetons d’accès et de rafraîchissement actifs de l’application ont été révoqués (FBI FLASH).

À partir de quelle vitesse peut-on considérer que c'est assez rapide ?

Un éditeur fournit à la fois un objectif et une mesure, dans la même unité et pour la même action, ce qui rend cette association particulièrement claire. Son groupe de travail IAM propose un exemple d'objectif : « moins de 24 heures pour mettre en place les mesures correctives visant à contenir les identités compromises avant que les attaquants ne parviennent à se déplacer latéralement ». Il s'agit là d'un objectif pour un programme abouti, et non d'un repère observé.

À l'aune de ces chiffres, selon l'enquête de 2026 menée par un éditeur auprès de 383 professionnels, près d'un quart (24 %) des organisations mettent plus de 24 heures à renouveler ou à révoquer un identifiant après une exposition potentielle, et 30 % mettent plus d'une journée à évaluer une fuite d'identifiants à haut risque (Cloud Security Alliance). Lisez attentivement ce deuxième chiffre. Il mesure la rapidité avec laquelle les équipes procèdent au triage, et non les éléments sur lesquels porte ce triage.

Quels éléments de preuve faut-il conserver ?

Considérez la télémétrie d’identité non humaine comme un élément de contrôle conservé et surveillé plutôt que comme un artefact accessoire. Coupang en est le meilleur exemple. Les autorités de régulation ont ordonné la conservation des journaux d’accès, et six jours plus tard, l’entreprise a supprimé manuellement environ six mois de journaux d’accès au Web. Environ 13 % des journaux couvrant la période de l’attaque ont été perdus, « rendant impossible l’identification de toutes les victimes concernées », et la commission a renvoyé l’entreprise devant la justice pénale pour destruction de preuves (The Record).

Comment gérer le cycle de vie des identités non humaines

La gestion des identités non humaines consiste à les identifier, à attribuer à chacune d'elles un propriétaire humain et à limiter la durée de validité de chaque identifiant. Ces étapes se déroulent dans l'ordre.

1. Découvrez toutes les identités non humaines sur cloud, en mode SaaS et sur site
2. Attribuer un responsable désigné à chaque identité identifiée
3. Limiter les droits d'accès à ce que l'identité utilise réellement
4. Enregistrer les identifiants dans un coffre-fort et automatiser leur rotation
5. Certifier l'inventaire selon un cycle de révision périodique
6. Supprimer l'identité lorsque celle-ci n'a plus d'utilité

Identification, propriété et inventaire

La découverte vient en premier lieu, car rien d’autre ne fonctionne sur une population que vous n’avez pas recensée, et celle-ci doit couvrir à la fois l’ cloud, le SaaS et les environnements sur site, plutôt que de se limiter à l’un de ces trois types. La responsabilité vient en second lieu, et c’est l’étape que la plupart des programmes négligent. Dans la même enquête de 2026, commanditée par un fournisseur et menée auprès de 383 professionnels, 51 % des organisations ont indiqué que l’absence de responsabilité ou d’obligation de rendre des comptes clairement définies constituait leur principal point faible (Cloud Security Alliance). Un inventaire certifiable découle de ces deux éléments. Le privilège permanent est également le point de convergence entre la surveillance des accès privilégiés et la gestion des identités non humaines, et zero trust constitue le modèle de référence, car il n’accorde aucun accès sur la seule base de l’emplacement ou d’une authentification préalable.

Rotation et gestion des secrets

Trois mesures indépendantes convergent vers le même résultat à partir de trois points de départ différents. Elles ne doivent en aucun cas être moyennées, fusionnées ou soustraites les unes des autres, car aucune paire d'entre elles ne partage de dénominateur commun.

Tableau : trois mesures indépendantes de la rotation des identifiants, issues respectivement d'une cible illustrative, d'une déclaration de l'utilisateur et des données télémétriques du fournisseur. Chaque ligne comporte un dénominateur différent ; ces chiffres ne doivent donc en aucun cas être moyennés, fusionnés ou soustraits les uns des autres.

La ligne de données télémétriques date de 2025 et commence à être obsolète ; elle reflète davantage la clientèle d'un fournisseur en particulier que l'ensemble du marché. Cela dit, la convergence entre les données issues d'une cible, d'une auto-évaluation et de la télémétrie constitue une preuve plus solide que chacune de ces trois sources prise isolément.

Identité éphémère des charges de travail avec SPIFFE et SPIRE

La solution, fondée sur les normes, au problème des identifiants à durée de vie prolongée consiste à ne plus les utiliser. Le « Secure Production Identity Framework for Everyone » (SPIFFE) est un ensemble de spécifications open source permettant la mise en place et l'attribution d'identités à des services dans des environnements dynamiques et hétérogènes, à l'aide de documents d'identité à durée de vie limitée récupérés via une API simple. SPIRE est l'implémentation de ces spécifications par le projet SPIFFE.

Quatre concepts constituent la base du modèle. Un identifiant SPIFFE (SPIFFE ID) est un nom au format URI attribué à une charge de travail. Un SVID, ou « SPIFFE Verifiable Identity Document » (document d’identité vérifiable SPIFFE), est le certificat qui l’atteste, au format X.509 ou JWT. L’API de charge de travail permet à une charge de travail de récupérer son propre SVID sans conserver de secret statique. Un domaine de confiance est la limite à l’intérieur de laquelle ces identités sont émises et considérées comme fiables. La documentation en est actuellement à la version v1.15.2 (SPIFFE). La gouvernance est établie : SPIFFE a été accepté au sein de la Native Computing Foundation de l’ Cloud le 29 mars 2018, est passé au statut « Incubation » le 22 juin 2020 et a obtenu son diplôme le 23 août 2022 (CNCF).

Cela s'inscrit dans ce contexte car l'identité de charge de travail éphémère et attestée supprime totalement les identifiants permanents, ce qui constitue la réponse structurelle au document NHI7:2025 « Long-Lived Secrets ». Les structures d'identité comportent toutefois leurs propres failles. CVE-2026-18677, publié le 12 août 2026, décrit un service mesh dans lequel un plan de données présentant un jeton lié à des balises pourrait s'enregistrer sous une étiquette de charge de travail arbitraire et obtenir l'identité SPIFFE d'une autre charge de travail ; cette vulnérabilité a reçu une note de 6,0 (niveau moyen) de la part de la CNA et n'avait pas encore été notée par le NVD au moment de la rédaction du présent article (NVD).

Indicateurs illustrant la réduction des risques

Dans ce domaine, on ne publie pratiquement jamais de résultats de tests de performance mesurés ; il convient donc de considérer les objectifs fixés par les programmes comme des cibles à atteindre plutôt que comme des performances observées.

Tableau : Objectifs des programmes publiés par l’Alliance pour la sécurité de l’ Cloud , avec un critère de comparaison mesuré fourni uniquement lorsque l’unité de mesure et l’action correspondent. Avertissement de la source : « Les objectifs présentés ici sont des objectifs indicatifs pour des programmes de sécurité NHI arrivés à maturité et doivent être adaptés en fonction du risque organisationnel, de la criticité du NHI et des exigences opérationnelles. » Il ne s’agit pas de références observées.

Sécurité et conformité en matière d'identité non humaine

NIS2 et DORA abordent la question de l'identité non humaine sous l'angle du contrôle d'accès et des risques liés aux technologies de l'information et de la communication (TIC) provenant de tiers, plutôt qu'en la désignant explicitement.

Tableau : Comment les deux principaux instruments de l'UE abordent la question de l'identité non humaine, et le libellé exact de l'article sur lequel repose chaque disposition.

L'article 21, paragraphe 2, de la directive NIS2 énumère dix mesures, de (a) à (j), mais la clause-cadre revêt une importance plus grande que le nombre de mesures. Les mesures « doivent reposer sur une approche tenant compte de tous les risques […] et doivent inclure au moins les éléments suivants », ce qui fait de ces dix mesures un seuil minimal plutôt qu’une liste exhaustive. Il convient également de noter ce que l’article 21, paragraphe 2, point j), ne prévoit pas. Comme il se termine par les termes «le cas échéant», la directive NIS2 n’impose pas de manière inconditionnelle l’authentification multifactorielle. Les États membres avaient jusqu’au 17 octobre 2024 pour adopter et publier les mesures de transposition, et devaient les appliquer à compter du 18 octobre 2024 (Commission européenne).

L’annexe G du document de l’Alliance pour la sécurité de l’ Cloud ( Security Alliance) établit une correspondance indépendante entre les pratiques en matière d’identité non humaine et les normes SOC 2, ISO 27001:2022, NIST SP 800-53 et NIST CSF, RGPD, HIPAA, PCI-DSS v4.0, DORA et NIS2, en associant l’application du principe du privilège minimal à l’article 21, paragraphe 2, point i). Il convient toutefois de garder à l’esprit la mise en garde suivante : « Les correspondances indiquent une adéquation mais ne garantissent pas la certification. » Les programmes de conformité plus larges considèrent de plus en plus la population non humaine comme relevant de leur champ d’application par défaut.

Approches modernes de la sécurité de l'identité des entités non humaines

Le paysage des outils s'est structuré en cinq catégories indépendantes des fournisseurs : découverte et inventaire, gestion et stockage des secrets, gouvernance des droits et des accès, infrastructures d'identité des charges de travail, et détection comportementale pour les entités machines. La plupart des programmes combinent deux ou trois de ces éléments plutôt que d'opter pour une solution unique.

Évaluez les critères plutôt que les candidats. Demandez dans quelle mesure la découverte couvre les environnements « cloud », SaaS et sur site, et si l’outil cartographie les droits de propriété plutôt que de se contenter de répertorier les identités. Vérifiez l’étendue des types d’identifiants pris en charge, et si l’automatisation de la rotation tient compte des dépendances de production au lieu de supposer qu’il n’en existe aucune. Demandez si la détection comportementale est optimisée pour les entités machine ou héritée de modèles humains, et assurez-vous que les preuves générées sont prêtes pour un audit, car les opérations de détection et de réponse aux menaces d’identité s’appuient sur les mêmes données télémétriques que les preuves de conformité. La tendance est claire : les secrets permanents cèdent la place à des identités de charges de travail éphémères et certifiées.

Le point de vue d'Vectra AI sur la sécurité des identités non humaines

Vectra AI part d'un postulat de compromission. Si une identité non humaine peut s'authentifier, elle peut faire l'objet d'abus, et la véritable question est de savoir si quelqu'un s'en rendrait compte. La méthodologie est comportementale : les entités machines ont besoin de références conçues pour les machines, et non de mécanismes de détection hérités de ceux utilisés pour les humains.

‍