ITDR aux côtés du SIEM et de l’EDR : l’architecture de détection 2026

9 min de lecture ·

La détection des identités deviendra en 2026 la troisième couche du SOC, une couche qui ne pourra plus être repoussée. L’EDR surveille l’endpoint, le SIEM analyse les logs, tandis que l’ITDR apporte le contexte d’identité entre les deux. Qui omet cette couche ne détectera le vol de jetons, l’abus d’OAuth ou l’escalade des privilèges qu’une fois que le dommage sera déjà apparu dans le SIEM. Selon Gartner, en 2026, 90 % des organisations d’entreprise intégreront des fonctions ITDR. La question n’est pas de savoir si cela se fera, mais plutôt de décider s’il s’agira d’une couche autonome ou d’un module intégré à l’EDR.

Articles connexesL’étalement des identités dans les PME  /  MFA adaptative comme norme NIS2

Qu’est-ce que l’ITDR et pourquoi le SIEM et l’EDR ne peuvent pas la remplacer

Qu’est-ce que la détection et la réponse aux menaces liées à l’identité ? Une couche de détection qui identifie les schémas d’attaque spécifiques à l’identité et réagit automatiquement. Elle surveille les événements d’authentification, les changements de privilèges, l’utilisation des jetons OAuth, le comportement des comptes de service et les mouvements inter-locataires. Sa base d’analyse repose sur les journaux des fournisseurs d’identité (Entra ID, Okta, Active Directory), et non sur la télémétrie des endpoints ni sur les flux réseau.

La différence avec l’EDR et le SIEM réside dans le contexte, et non dans le flux de données. L’EDR observe ce qui se passe sur l’endpoint. Le SIEM collecte les logs entrants. L’ITDR, quant à elle, ajoute la lentille de l’identité : quel compte a utilisé quel jeton dans quelle configuration locataire, le sign-in était-il risqué, une tentative d’escalade des privilèges a-t-elle eu lieu, y a-t-il eu des consentements OAuth accordés à des applications suspectes ? Ces questions, EDR et SIEM ne les répondent qu’indirectement, souvent plusieurs heures plus tard, voire jamais.

En 2025, Expel a constaté dans son rapport sur les SOC que 68,6 % du volume de menaces observé était basé sur l’identité. Okta rapporte, pour la même année, plus de 15 milliards de tentatives de connexion malveillantes bloquées chez plus de 10 000 organisations. Ce ne sont pas des chiffres de marketing des fournisseurs, mais une réalité opérationnelle : qui planifie en 2026 une détection de sécurité sans couche d’identité passe à côté du véritable schéma d’attaque.

Concrètement, cela signifie qu’un attaquant qui obtient un cookie de session via du phishing et s’en sert pour se connecter légitimement à Microsoft 365 ne laisse aucune trace suspecte sur l’endpoint. L’EDR voit simplement un onglet de navigateur normal. Dans le SIEM, arrive un sign-in validé par le moteur MFA. Ce n’est qu’avec la couche ITDR que l’on comprend que ce sign-in provient d’une localisation géographique inhabituelle, que la durée de vie du jeton est anormalement longue, et que l’utilisateur a immédiatement après la connexion accepté un consentement OAuth pour une application inconnue. Cette chaîne d’indices liés à l’identité constitue la force de l’ITDR.

Dans la pratique, c’est aussi la raison pour laquelle la MFA classique ne suffit plus en 2026. Le vol de jetons, l’adversaire au milieu et le détournement de session fonctionnent même lorsque la MFA est activée. La MFA adaptative et l’authentification basée sur le risque aident à la porte d’entrée, tandis que l’ITDR complète le travail à la porte arrière : que se passe-t-il après la connexion, lorsque la session est déjà établie, lorsque le jeton a déjà été volé ? Ensemble, ces deux couches constituent une défense moderne de l’identité.

Trois options d’architecture pour 2026

Trois modèles d’architecture se sont imposés sur le marché. Chacun a ses forces, chacun ses compromis. Le choix ne dépend pas de la préférence envers un fournisseur, mais de la maturité en matière d’identité, de la pile EDR existante et de la question de savoir qui gère le SOC.

Les trois options ne s’excluent pas mutuellement, mais elles entrent en concurrence pour le budget et les ressources humaines. Celui qui déploie les trois en parallèle voit le même événement d’identité apparaître trois fois dans trois consoles différentes. Celui qui n’en déploie aucune ne détecte le vol de jeton qu’à travers la tâche de corrélation du SIEM à deux heures du matin. La bonne réponse dépend de deux variables : combien de fournisseurs d’identité sont impliqués ? Qui possède la pile principale de détection en interne ?

Où la décision architecturale se concrétise sur le terrain

Dans les trois revues du dernier trimestre, les mêmes arguments sont revenus de manière récurrente. L’assureur avec une architecture AD hybride et Microsoft 365 a opté pour la variante intégrée à l’EDR, car il utilise déjà CrowdStrike Falcon dans son SOC et que le module d’identité constituait l’étape logique suivante. Le constructeur mécanique, qui fait coexister Entra ID et Okta, a déployé sa propre couche ITDR, aucun des fournisseurs EDR ne prenant en charge ces deux IDP avec la même profondeur. Le fournisseur SaaS, disposant d’une infrastructure purement cloud et de 80 ingénieurs, a choisi un package de protection natif IDP, son SOC étant trop petit pour accueillir un outil supplémentaire.

Une observation importante : ce choix dépend moins du marketing des éditeurs que de votre propre hygiène identitaire. Si vous n’avez pas nettoyé vos comptes de service depuis des années, si vous n’avez jamais audité les consentements OAuth, si vous ne disposez pas d’une hiérarchie claire des privilèges, vous faites face à un problème d’identité qu’aucun outil ne résout instantanément. La bonne séquence est la suivante : inventaire de l’identité d’abord, puis sélection de l’outil. Inverser cet ordre revient à acheter une solution adaptée à une réalité que vous ne comprenez pas encore.

L’extension par Microsoft de Defender for Identity aux identités Okta en avril 2026 est remarquable dans ce contexte. Elle modifie l’équation pour les entreprises qui disposaient jusqu’ici de deux IDP et devaient donc recourir à une couche ITDR dédiée. Si vous utilisez déjà Defender for Identity au sein de la stack Microsoft, vous pouvez désormais y intégrer les identités Okta sans devoir licencier un outil supplémentaire. Cela permet de réduire les coûts de licence et diminue le nombre de consoles à gérer au sein du SOC.

Risque de dérive : ce que la configuration ITDR ne résout pas

Quelle que soit l’option choisie, une vérité demeure : l’ITDR est de la détection, pas un programme d’hygiène des identités. Ceux qui ne nettoient pas leur architecture d’identité, qui ne définissent pas clairement les hiérarchies de privilèges, qui n’auditaient pas les comptes de service, auront avec l’ITDR plus d’alertes et moins de clarté. Les outils détectent les anomalies, mais ils ne réparent pas un monde des identités mal planifié.

C’est exactement ce qui s’est produit lors du test pratique avec le constructeur de machines. Après le déploiement de l’ITDR, le nombre d’alertes a explosé, passant de 30 par jour à 380. Trois semaines de tri ont montré que la plupart des alertes n’étaient pas des attaques, mais des opérations quotidiennes que le moteur ITDR ne connaissait pas. Comptes de service avec des privilèges excessifs, consentements OAuth avec des scopes trop larges, connexions d’appareils anciens provenant d’ordinateurs portables mis au rebut. La réduction des alertes à 50 par jour a coûté deux mois de nettoyage des identités, pas un simple réglage d’outil.

Un deuxième point pratique issu des retours : la responsabilité des alertes ITDR est souvent floue sur le plan organisationnel. Les analystes SOC sont classiquement formés aux événements endpoint, tandis que les spécialistes de l’identité siègent généralement dans l’équipe IT Operations. Lorsqu’une alerte ITDR arrive, personne ne sait initialement qui doit la trier. La réponse claire : les alertes ITDR sont d’abord escaladées au SOC, avec des points de transfert clairs vers l’équipe Identity pour le nettoyage des privilèges et l’hygiène des comptes de service. Ceux qui ne définissent pas ce point de transfert se retrouvent avec des alertes sans propriétaire.

Une troisième observation concerne la sévérité des alertes. Les outils ITDR fournissent des scores de risque, mais la plupart des SOC de PME n’ont pas d’échelle établie pour les risques liés à l’identité. Une connexion à risque « Élevé » depuis le Brésil pour un utilisateur en vacances au Brésil n’est pas une attaque. Un consentement OAuth à risque « Moyen » peut être une attaque si l’application est inconnue. Ceux qui activent l’ITDR devraient définir parallèlement un mappage de sévérité qui relie la logique de risque ITDR au contexte métier propre à l’entreprise.

La leçon : l’ITDR sans plan d’hygiène des identités génère une fatigue d’alerte au sein du SOC. Ceux qui déploient cette couche devraient mettre en place parallèlement un programme de nettoyage des identités : inventaire des comptes de service, audit des consentements OAuth, revue des privilèges, hygiène des appareils. Ces tâches ne sont pas spectaculaires, mais elles font la différence entre une configuration ITDR utile et une console qui crie en permanence.

Ce que les équipes de sécurité doivent décider d’ici Q3 2026

Trois mouvements aggravent la question de l’ITDR. Premièrement : Microsoft a étendu Defender for Identity à Okta en avril 2026, ce qui réduit le coût de la détection Multi-IDP. Deuxièmement : Les audits NIS2 dans la zone DACH exigent depuis début 2026 de plus en plus de preuves de détection d’identité, surtout pour les exploitants KRITIS. Troisièmement : Les attaques basées sur des tokens ont nettement augmenté en 2025 ; les modèles classiques de contournement MFA comme le vol de cookies de session fonctionnent encore en 2026.

Si vous lancez ce plan en Q2 2026, vous disposez d’une couche ITDR en exploitation opérationnelle au changement d’année. C’est une condition préalable pour la prochaine vague d’audits NIS2 et pour la lacune de détection que les attaques basées sur l’identité laissent ouverte dans tout setup sans ITDR. Si vous attendez, la lacune restera ouverte en 2027, avec la complication supplémentaire d’une pression d’audit accrue.

Une recommandation concrète issue des retours terrain : Si vous démarrez en Q2 2026, vous devriez finaliser l’inventaire d’identité dans les quatre premières semaines. Cela inclut une liste de toutes les IDP avec les IDs de locataire, une liste de tous les comptes de service avec propriétaires et privilèges, une évaluation des consentements OAuth par IDP et un profil de privilège par rôle privilégié. Ces quatre listes coûtent entre 15 et 25 jours-homme, selon la taille du monde de l’identité. Elles constituent le socle sur lequel repose chaque choix ITDR.

Ce qui ne fait pas partie de ce plan : un changement d’outil sans hygiène d’identité. Si vous activez l’ITDR sans hygiène des comptes de service, sans revue des consentements OAuth, sans revue des privilèges, vous produisez des alertes inutiles. La question la plus honnête lors de chaque revue de sécurité des deux prochains trimestres n’est donc pas « quel outil ITDR », mais « à quoi ressemble votre réalité d’identité avant de mettre un outil dessus ». C’est la réponse ennuyeuse. C’est la bonne. Et elle permet d’économiser la correction coûteuse dans douze mois, lorsque le prochain rapport d’audit BSI approche.

Foire aux questions

Avons-nous besoin d’ITDR si nous avons déjà EDR et SIEM ?

Oui, dans la plupart des setups. L’EDR voit l’endpoint, le SIEM corrèle les logs, les deux voient le contexte d’identité seulement indirectement. Le vol de tokens, l’abus OAuth et les mouvements Cross-Tenant apparaissent souvent des heures plus tard dans les deux. L’ITDR comble cette lacune, soit comme couche dédiée, soit comme module dans la pile existante.

Quelle est la différence entre ITDR et ISPM ?

L’ITDR est Détection plus Réponse, l’ISPM (Gestion de la posture de sécurité d’identité) est l’hygiène des actifs. L’ISPM montre ce qui est mal configuré dans la pile d’identité, l’ITDR détecte quand quelqu’un exploite activement la configuration. Les deux se complètent, ne se remplacent pas.

Microsoft Entra ID Protection suffit-il comme solution ITDR ?

Pour les setups purement Microsoft souvent oui, pour les setups Multi-IDP non. Entra ID Protection couvre bien les identités Entra, mais ne voit pas dans Okta, Workspace ou les tenants AD On-Prem. Si vous avez plusieurs fournisseurs d’identité, vous avez besoin soit de la licence Defender for Identity étendue, soit d’une couche ITDR dédiée.

Quelle doit être la granularité de l’inventaire des identités avant le déploiement de l’ITDR ?

Au minimum les comptes de service, les consentements OAuth et les rôles privilégiés. Sans ces trois inventaires, l’ITDR génère principalement du bruit d’alertes, car les activités quotidiennes normales sont considérées comme des anomalies. Grâce à ces trois inventaires, la charge de triage est réduite d’un facteur cinq à dix au cours des trois premières semaines.

Quels outils ITDR sont pertinents pour les PME de la zone DACH ?

Microsoft Defender for Identity (pour les entreprises fortement intégrées à M365, avec prise en charge d’Okta depuis avril 2026), CrowdStrike Falcon Identity (pour les environnements consolidés EDR), Silverfort et Semperis pour les architectures Multi-IDP, Okta Identity Threat Protection pour les écosystèmes centrés sur Okta. Le choix dépend de la pile d’identité existante, et non du marketing des éditeurs.

Source de l’image de couverture : générée par IA avec Google Imagen 4 Fast, vérifiée par SynthID

À propos de l'auteur: Alec Chizhik

Plus d'articles de Alec Chizhik