On parle encore des mots de passe comme si c’était le cœur du problème. C’est confortable, parce que tout le monde comprend. Sauf que, dans la vraie vie, les pannes et les compromissions qui font mal partent rarement d’un employé distrait. Elles partent d’une machine. Un certificat qui expire un vendredi soir. Un token de pipeline oublié dans un dépôt. Une clé API créée « pour tester » et jamais supprimée. Et là, sous stress, on fait ce qu’on fait toujours : on répare vite. On élargit une permission. On désactive une vérification. On “temporaire” en production.
C’est ça, la machine identity crisis : une explosion d’identités non humaines que personne ne pilote vraiment, mais dont tout dépend.
Ce qu’on appelle “identité machine”, sans jargon inutile
Une identité machine, c’est tout ce qui permet à un logiciel de prouver qu’il est autorisé : clés API, comptes de service, service principals, tokens OAuth, secrets applicatifs, certificats TLS/mTLS, clés SSH, identités de pipelines CI/CD. À l’échelle, ça devient un cimetière de credentials : certains sont encore utilisés, d’autres pas, beaucoup sont sur-permissionnés, et presque aucun n’a un propriétaire clair.
Le piège, c’est la vitesse. Les identités machines naissent partout : un clic dans un tableau SaaS, une intégration Zapier-like, un module Terraform copié-collé, un pipeline GitHub Actions, un script “temporaire” sur le laptop d’un dev. Ensuite elles se reproduisent, parce que les projets dupliquent des repo, des charts Helm, des templates d’infra. Résultat : vous n’avez pas “quelques” secrets, vous avez un système reproducteur de secrets.
Les chiffres du rapport 2025 sur la sécurité des identités machines de CyberArk ne racontent pas une menace future. Ils décrivent une réalité déjà installée.
Les pannes de certificats : le signal d’alerte que le métier comprend
Les attaques font peur. Les pannes font perdre de l’argent tout de suite. C’est pour ça que les certificats sont le thermomètre le plus honnête de la machine identity crisis : ils expirent quoi qu’il arrive. Ce n’est pas “si”, c’est “quand”. Et quand vous en avez des dizaines de milliers, “quand” devient “souvent”.
CyberArk indique que 72 % des organisations ont subi au moins une panne liée à un certificat sur les douze derniers mois, et qu’une part significative en a subi plusieurs.
Visuel — Pannes liées aux certificats (2022 → 2025)
| Fréquence des pannes | 2022 | 2025 |
|---|---|---|
| Au moins une panne annuelle | 41 % | 72 % |
| Pannes mensuelles | 26 % | 67 % |
| Pannes hebdomadaires | 12 % | 45 % |
On peut débattre de “maturité sécurité” pendant des heures. Une API de paiement qui tombe à cause d’un certificat expiré, ça ne débat pas. Ça casse.
Le vrai scandale : la panne crée la brèche
Voici la dynamique que beaucoup d’équipes vivent, mais que presque personne ne décrit franchement en réunion : la pression opérationnelle pousse à des décisions de sécurité qu’on n’assumerait jamais à tête reposée.
Imaginez une passerelle API qui refuse des connexions parce que le certificat d’un service interne est expiré. Les erreurs s’empilent. Le support s’enflamme. Le responsable produit veut un retour à la normale. Et l’option “faire propre” (renouveler, redéployer, vérifier la chaîne, valider mTLS) prend du temps. Alors on choisit l’option “ça marche” : on assouplit la validation, on met une exception, on élargit une règle de confiance, on colle un secret en dur “pour dépanner”.
Le problème n’est pas la décision du moment. Le problème, c’est que le dépannage devient un état stable.
CyberArk rapporte aussi que 50 % des organisations ont connu des incidents ou compromissions liés aux identités machines, avec des impacts business réels (accès non autorisé, interruptions côté client, retards de livraison). Ce n’est pas une histoire de “si on a de la chance”. C’est une question de cycle.
Une panne est souvent la répétition générale d’une faille.
Visuel — Boucle panne → compromission
| Étape | Ce qui se passe vraiment |
|---|---|
| Certificat/clé expirée | Panne visible, priorité “remettre en ligne” |
| Correction d’urgence | Contournement d’un contrôle, permission élargie |
| Le “temporaire” reste | Dette de sécurité cachée en production |
| Exploitation ultérieure | Accès “légitime” pour l’attaquant, détection tardive |
Ce que les équipes sécurité ne disent pas à voix haute : l’inventaire est déjà faux
Le plus gros mensonge involontaire dans beaucoup d’entreprises : “Nous savons quelles identités existent.” Non. Vous savez ce que votre IAM principal montre. Mais une bonne partie des identités machines vivent hors de votre radar : tokens dans des plateformes SaaS, clés dans des projets cloud oubliés, secrets dans des variables CI, identités créées par des intégrations.
Microsoft le dit autrement dans son billet sur l’essor des identités non humaines : le périmètre d’identité s’est étendu, et il ne se limite plus aux utilisateurs. Quand ce périmètre explose, un contrôle trimestriel ou une rotation manuelle devient une formalité.
Si vous ne pouvez pas répondre rapidement à trois questions, vous êtes déjà dedans :
- Qui est propriétaire de cette identité (une équipe, pas une personne) ?
- Où est-elle utilisée (workload, pipeline, service) ?
- Quand expire-t-elle, et que se passe-t-il si elle casse ?
Les identités machines qui reviennent toujours dans les incidents
Vous pouvez perdre des mois à construire “une grande stratégie”. Ou vous pouvez commencer là où les incidents se concentrent. CyberArk pointe des catégories qui reviennent souvent : clés API, certificats TLS/SSL, tokens de comptes de service, certificats SSH.
Visuel — Identités machines souvent impliquées dans les incidents
| Type d’identité machine | Part rapportée |
|---|---|
| Clés API | 34 % |
| Certificats SSL/TLS | 34 % |
| Tokens de comptes de service | 29 % |
| Certificats SSH | 28 % |
| Secrets applicatifs | 20 % |
Ce tableau change une chose : il rend impossible l’argument “ce n’est que de la plomberie”. Quand une clé API se balade, elle ouvre souvent plus que ce qu’elle devrait. Quand un certificat tombe, il peut faire tomber un pan entier de vos dépendances.
Pourquoi le SOC se fait surprendre : les machines ont un comportement “normalement anormal”
Les détections classiques adorent les humains : géolocalisation bizarre, appareils inconnus, horaires suspects. Une machine, elle, est un métronome. Un pipeline s’authentifie à la minute. Un service appelle la même API des milliers de fois. Un agent tourne toute la nuit. Rien de tout ça ne ressemble à une anomalie… jusqu’au jour où l’attaquant utilise exactement la même identité, avec exactement le même rythme.
Le décalage est visible dans l’étude de la Cloud Security Alliance sur la sécurité des identités non humaines : seule une minorité d’organisations se dit très confiante dans sa capacité à prévenir ces attaques, alors qu’une large part exprime des inquiétudes.
Visuel — Écart de confiance sur les identités non humaines
| Indicateur | Valeur |
|---|---|
| Organisations “très confiantes” | 15 % |
| Organisations “inquiètes” | 69 % |
Traduction : beaucoup d’équipes savent qu’elles n’ont pas la visibilité nécessaire. Elles le sentent, même si elles ne peuvent pas toujours le prouver.
La solution n’est pas “tourner plus vite”. La solution est “arrêter d’émettre des secrets qui vivent trop longtemps”
On entend souvent : “On va faire une politique de rotation.” Bonne intention. Mauvaise stratégie si votre surface grandit plus vite que votre capacité d’exécution.
Le changement qui fait vraiment baisser le risque, c’est de supprimer les credentials longs durées et de les remplacer par des identités éphémères. Moins de secrets persistants = moins de choses à voler, moins de choses à oublier, moins de choses à faire expirer en silence.
Google pousse exactement ce modèle avec la fédération d’identités de charge de travail : des identités temporaires plutôt que des clés de comptes de service qui traînent. Ce n’est pas “une option cloud”. C’est une philosophie : l’identité doit être courte, contextuelle, et réversible.
Chaque secret longue durée que vous supprimez est un risque que vous n’aurez plus jamais à gérer.
Visuel — Clés statiques vs identités courte durée
| Critère | Clé longue durée | Identité courte durée |
|---|---|---|
| Durée de vie | Mois / années | Minutes / heures |
| Copiable | Oui | Beaucoup moins |
| Révocation | Manuelle, lente | Automatique, rapide |
| Rayon d’impact | Large | Limité |
| Traçabilité | Souvent floue | Généralement meilleure |
À quoi ressemble un système qui tient la route
La différence n’est pas “outil A vs outil B”. La différence, c’est le modèle d’exploitation.
| Aspect | Mauvaise pratique courante | Pratique qui tient à l’échelle |
|---|---|---|
| Propriété | Personne ne sait | Une équipe est responsable |
| Privilèges | “Admin pour dépanner” | Moindre privilège |
| Certificats | Renouvelés à la main | Émission + renouvellement automatisés |
| CI/CD | Secrets dans variables | Pipelines sans clés statiques |
| Durée de vie | “Jamais expiré” | Expiration forcée et courte |
Quand c’est en place, les pannes de certificats cessent d’être un événement. Elles deviennent un non-sujet. Et quand c’est un non-sujet, vous supprimez aussi la pression qui pousse aux contournements.
Un plan de 30 jours qui change vraiment la trajectoire
Semaine 1 : prendre la liste des systèmes qui peuvent vous mettre à genoux (API publiques, paiement, auth, pipeline de build, registre d’images, ingress/service mesh). Puis identifier les identités machines qui les font tourner.
Semaine 2 : pour chaque identité critique, imposer trois champs obligatoires : propriétaire (équipe), usage (workload/pipeline), expiration. Toute identité sans propriétaire est désactivée jusqu’à preuve d’utilité.
Semaine 3 : industrialiser les certificats. Pas une “bonne pratique”. Une obligation. Renouvellement automatique, monitoring d’expiration, et surtout validation du déploiement après rotation.
Semaine 4 : rendre un workflow critique “sans clé”. Un seul. Mais réel. Par exemple : votre pipeline qui pousse en production ne doit plus transporter de clé longue durée. Une fois ce premier succès obtenu, vous clonez le pattern.
Un seul workflow sans clé vaut mieux que dix comités.
Pourquoi ça va empirer en 2026 si on ne change rien
La création d’identités devient automatique : plus d’intégrations, plus de SaaS, plus de pipelines, plus d’agents. CyberArk note que la majorité des organisations s’attendent à une croissance notable des identités machines sur les douze prochains mois. Et c’est logique : on automatise la production… mais on laisse l’identité au modèle manuel.
Ce décalage est la machine identity crisis en une phrase : la création est instantanée, le contrôle est bureaucratique.
Verdict
La machine identity crisis n’est pas une mode. C’est une conséquence mécanique de la manière dont on construit et déploie aujourd’hui. Les organisations qui s’en sortent ne “mettent pas plus de process”. Elles changent la matière première : moins de secrets persistants, plus d’identités courtes, plus d’automatisation, et une propriété clairement attribuée.
Chaque clé longue durée est une faille avec un retard à l’allumage.