Le 21 août 2026, Microsoft a publié la CVE-2026-69836 : une faille de désérialisation de données non fiables dans Microsoft Entra ID, notée CVSS 10.0, soit le maximum. Elle permettait à un attaquant non authentifié d'exécuter du code à distance sur le service qui gouverne les accès à Microsoft 365, à Azure et à l'ensemble des applications tierces branchées en SSO. Deux détails changent la lecture de l'événement. D'abord, la mitigation a été appliquée côté serveur par Microsoft avant la publication : selon l'éditeur, aucune action n'est requise des clients. Ensuite, la vulnérabilité n'a pas été exploitée dans la nature. Le chercheur ayant conduit à sa correction, Robert Fitzpatrick, ingénieur sécurité principal chez Microsoft, l'a signalée en interne. Sur le papier, l'incident est clos.
Cette clôture apparente est précisément le problème. Une CVSS 10.0 sur l'identity provider qui centralise vos accès mérite un retour d'expérience formel, même sans exploitation. Sans cette étape, votre registre des risques ignore un événement qui, s'il s'était produit un mois plus tôt, aurait été le point de départ d'un scénario de compromission massive. Vos obligations NIS2 et DORA imposent d'en tirer une trace : la mitigation transparente de Microsoft ne vous en dispense pas.
Le rayon de souffle d'un IdP compromis
Un identity provider n'est pas une application comme les autres. Il tranche les décisions d'accès pour l'ensemble de votre écosystème numérique : messagerie, stockage documentaire, ERP, CRM, outils de développement, plateformes SaaS tierces via SAML ou OIDC. Une exécution de code à distance sur Entra ID donne à l'attaquant la faculté d'émettre des jetons valides pour n'importe quelle identité, sans laisser de trace exploitable dans vos SIEM habituels. La détection côté client est alors quasi impossible : les journaux d'accès reflètent des authentifications techniquement légitimes.
En 2024, une compromission antérieure de ce type, l'incident dit Midnight Blizzard, avait permis à un groupe étatique russe d'accéder aux boîtes mail de plusieurs cadres dirigeants de Microsoft. La CISA avait alors publié l'Emergency Directive 24-02 en avril 2024, exigeant que toutes les agences fédérales américaines réinitialisent leurs jetons Entra ID et auditent leurs applications OAuth. Le cas fait jurisprudence : une CVSS 10.0 sur un IdP n'est jamais une vulnérabilité ordinaire, et le risque persiste après la mitigation, via les jetons émis pendant la fenêtre de vulnérabilité.
Ce que la concentration identitaire coûte déjà
Les chiffres 2025 de l'ANSSI, publiés dans son Panorama de la cybermenace du 11 mars 2026, sont éclairants. 196 incidents d'exfiltration de données ont été traités, en hausse de 51 % par rapport à 2024. Les modes opératoires attribués à des groupes russes et chinois restent les plus actifs contre les intérêts français. Les compromissions identitaires, vol de jetons, contournement de MFA, abus de comptes de service, sont surreprésentées dans cette statistique. L'ANSSI a également recensé 128 compromissions par rançongiciel sur la même période, dont une majorité entrent par un défaut d'authentification.
La CNIL sanctionne désormais explicitement les défauts identitaires. Le 13 janvier 2026, Free et Free Mobile ont écopé de 15 et 27 millions d'euros, soit 42 millions cumulés, pour des manquements de sécurité incluant l'absence d'authentification multi-facteurs sur des interfaces critiques. Le 22 janvier 2026, France Travail a écopé de 5 millions supplémentaires après une cyberattaque exploitant des faiblesses d'authentification. Ces montants illustrent une bascule réglementaire : le maillon identitaire n'est plus un détail technique, c'est un point d'inspection prioritaire.
Un exemple concret : le retour d'expérience qui manque
Prenez une ETI industrielle française de 800 collaborateurs, soumise à NIS2 en tant qu'entité importante. Son SI s'appuie sur Microsoft 365, Azure et une vingtaine d'applications SaaS branchées en SSO sur Entra ID. Le 21 août, la CVE-2026-69836 est publiée. Aucune alerte ne remonte dans son SIEM. Aucun ticket n'est ouvert. L'équipe sécurité, qui filtre les CVE par présence d'exploit connu, écarte le dossier au motif que la mitigation est déjà en place.
Trois mois plus tard, l'audit blanc préparant l'inspection ANSSI pose la question : quels événements sans impact affectant votre chaîne d'authentification ont fait l'objet d'un retour d'expérience documenté en 2026 ? Aucune fiche n'existe pour la CVE-2026-69836. L'auditeur note cette absence comme un défaut de traçabilité de l'article 21 de NIS2, qui exige une gestion continue des risques, pas seulement une réaction aux incidents avérés. Le rattrapage prend une demi-journée, la mention reste dans le dossier d'audit.
Quatre réflexes à ancrer avant la prochaine CVE
Cartographier la surface identitaire. Votre IdP principal, oui, mais aussi les fédérations SAML sortantes, les applications OAuth consenties (souvent oubliées), les comptes de service liés au provisioning, les identités non humaines synchronisées via SyncFabric ou équivalent. Sans cet inventaire, un incident IdP est impossible à circonscrire. L'article sur les identités non humaines dans les programmes NIS2 et DORA détaille la méthode.
Mettre en place un accès administrateur hors IdP. Le compte break-glass est une exigence de base d'un plan de continuité identitaire : deux comptes locaux, stockés hors Entra ID, avec des mots de passe scellés dans un coffre-fort accessible physiquement, testés une fois par trimestre. Sans ce chemin, une panne ou une compromission de votre IdP vous prive de tout moyen de reprise.
Écrire le scénario "IdP indisponible" dans le plan de continuité. La plupart des plans de continuité couvrent la panne d'un site, d'un hébergeur, d'un ERP. Peu couvrent la panne d'un fournisseur d'identité. Définir les objectifs de temps de reprise pour l'authentification, les jeux de scripts de bascule, la communication interne pendant l'incident : ces éléments manquent à une majorité des plans NIS2 audités.
Réviser vos clauses ICT tiers. L'article 28 de DORA exige que vos contrats avec les prestataires ICT critiques prévoient les modalités de notification d'incident, les droits d'audit et les tests de résilience. Un fournisseur d'identité en fait partie, même si votre acheteur ne l'a pas historiquement traité comme tel. Ajoutez une clause de notification rapide en cas de CVE critique, et exigez la publication des délais d'application des correctifs côté fournisseur.
Ce que cet épisode dit de votre gouvernance
La CVE-2026-69836 est un événement de niveau maximal qui n'a laissé aucune trace visible dans votre environnement. C'est précisément ce qui la rend piégeuse pour vos processus. Les équipes qui n'enregistrent que les incidents avec impact opérationnel manqueront ce type de signal. Les auditeurs NIS2, eux, ne le manqueront pas : la capacité à identifier, tracer et traiter les événements sans impact fait partie de l'article 21.
La bonne pratique consiste à ouvrir une fiche dans votre registre de gestion des risques dès la publication d'une CVE critique concernant un composant de votre chaîne identitaire, à documenter la décision de non-action si elle est justifiée, et à programmer un exercice de simulation dans les trente jours. Vingt minutes d'analyse valent mieux qu'un impact zéro non documenté. À la prochaine CVSS 10.0, la question de l'auditeur sera "où est votre analyse d'impact ?" avant celle du correctif.