ITDR neben SIEM und EDR: Detection-Architektur 2026

9 Min. Lesezeit · Stand: April 2026

Identity-Detection ist 2026 die dritte Schicht im SOC, die nicht mehr verschoben werden kann. EDR sieht den Endpoint, SIEM sieht das Log, ITDR sieht den Identity-Kontext zwischen beiden. Wer die Schicht weglässt, sieht Token-Diebstahl, OAuth-Abuse und Privilege-Escalation erst, wenn der Schaden im SIEM landet. Gartner sagt, dass 2026 90 Prozent der Enterprise-Organisationen ITDR-Funktionen embedded fahren werden. Die Frage ist nicht ob, sondern als eigene Schicht oder als Modul im EDR.

VerwandtIdentity-Sprawl im Mittelstand  /  Adaptive MFA als NIS2-Standard

Was ITDR ist und warum SIEM und EDR sie nicht ersetzen

Was ist Identity Threat Detection and Response? Eine Detection-Schicht, die Identity-spezifische Angriffsmuster erkennt und automatisiert reagiert. Sie überwacht Authentifizierungs-Events, Privilege-Veränderungen, OAuth-Token-Nutzung, Service-Account-Verhalten und Cross-Tenant-Bewegungen. Ihre Analyse-Basis sind Identity-Provider-Logs (Entra ID, Okta, Active Directory) und nicht Endpoint-Telemetrie oder Netzwerk-Flows.

Der Unterschied zu EDR und SIEM liegt im Kontext, nicht im Datenstrom. EDR sieht was auf dem Endpoint passiert. SIEM sammelt was an Logs hereinkommt. ITDR setzt darüber die Identity-Linse: Welcher Account hat welches Token in welcher Tenant-Konfiguration verwendet, war der Sign-In riskant, wurde eine Privilege-Eskalation versucht, gibt es OAuth-Consents an verdächtige Apps. Diese Fragen beantworten EDR und SIEM nur indirekt, oft Stunden später, manchmal gar nicht.

2025 hat Expel im SOC-Report festgestellt, dass 68,6 Prozent des beobachteten Threat-Volumens identity-based war. Okta meldet für das gleiche Jahr über 15 Milliarden geblockte bösartige Login-Versuche bei mehr als 10.000 Organisationen. Das sind keine Vendor-Marketing-Zahlen, sondern operative Realität: Wer 2026 Security-Detection ohne Identity-Schicht plant, plant am tatsächlichen Angriffsmuster vorbei.

Konkret bedeutet das: Ein Angreifer, der über Phishing einen Session-Cookie stiehlt und sich damit als legitimer User in Microsoft 365 anmeldet, hinterlässt am Endpoint keine verdächtige Spur. EDR sieht einen normalen Browser-Tab. Im SIEM landet ein Sign-In, der von der MFA-Engine als gültig markiert wurde. Erst die ITDR-Schicht erkennt, dass der Sign-In aus einer ungewöhnlichen Geo-Location kommt, dass der Token-Lifetime ungewöhnlich lang ist, dass der User direkt nach dem Sign-In ein OAuth-Consent für eine unbekannte App akzeptiert hat. Diese Verkettung von Identity-Signalen ist die Stärke von ITDR.

In der Praxis ist das auch der Grund, warum klassische MFA in 2026 nicht mehr ausreicht. Token-Diebstahl, Adversary-in-the-Middle und Session-Hijacking funktionieren auch bei aktivierter MFA. Adaptive MFA und Risk-basierte Authentifizierung helfen am Front-Door, ITDR ergänzt am Back-Door: Was passiert nach dem Login, wenn die Session bereits besteht, wenn der Token bereits gestohlen wurde. Beide Schichten zusammen bilden eine zeitgemäße Identity-Verteidigung.

Drei Architektur-Optionen für 2026

Im Markt haben sich drei Architektur-Pattern etabliert. Jedes hat seine Stärken, jedes seine Trade-offs. Die Wahl hängt nicht von der Vendor-Präferenz ab, sondern von der Identity-Reife, dem bestehenden EDR-Stack und der Frage, wer das SOC fährt.

Die drei Optionen schließen einander nicht aus, aber sie konkurrieren um Budget und Personal. Wer alle drei parallel fährt, hat dreimal das gleiche Identity-Event in drei Konsolen. Wer keine fährt, sieht den Token-Diebstahl erst im SIEM-Korrelations-Job um zwei Uhr nachts. Die richtige Antwort hängt von zwei Variablen ab: Wie viele Identity-Provider sind im Spiel? Wer hat den primären Detection-Stack im Haus?

Wo die Architektur-Entscheidung in der Praxis fällt

In den drei Reviews aus dem letzten Quartal sind dieselben Argumente immer wieder aufgetaucht. Der Versicherer mit Hybrid AD und Microsoft 365 hat sich für die EDR-integrierte Variante entschieden, weil er bereits CrowdStrike Falcon im SOC fährt und das Identity-Modul der natürliche Ausbauschritt war. Der Maschinenbauer mit Entra ID und Okta parallel hat eine eigene ITDR-Schicht aufgesetzt, weil keiner der EDR-Anbieter beide IDPs gleich tief unterstützt. Der SaaS-Anbieter mit reinem Cloud-Setup und 80 Engineers hat IDP-natives Schutzpaket gewählt, weil das SOC zu klein für ein zusätzliches Tool ist.

Eine wichtige Beobachtung: Die Wahl hängt weniger vom Marketing der Anbieter ab als von der eigenen Identity-Hygiene. Wer Service-Accounts seit Jahren nicht aufgeräumt hat, wer OAuth-Consents nie auditiert hat, wer keine klare Privilege-Hierarchie hat, hat ein Identity-Problem, das kein Tool sofort löst. Die richtige Reihenfolge ist: erst Identity-Inventar, dann Tool-Auswahl. Wer die Reihenfolge umdreht, kauft sich ein Werkzeug für eine Realität, die er noch nicht versteht.

Die Microsoft-Erweiterung von Defender for Identity auf Okta-Identitäten im April 2026 ist in dem Kontext bemerkenswert. Sie verändert die Rechnung für Häuser, die bisher zwei IDPs hatten und dafür eine eigene ITDR-Schicht brauchten. Wer Defender for Identity ohnehin im Microsoft-Stack hat, kann die Okta-Identitäten jetzt mit einbeziehen, ohne ein zusätzliches Tool zu lizenzieren. Das spart Lizenz-Kosten und reduziert die Konsolen-Anzahl im SOC.

Drift-Risiko: Was das ITDR-Setup nicht löst

Egal welche Option gewählt wird, eine Wahrheit bleibt: ITDR ist Detection, kein Identity-Hygiene-Programm. Wer die Identity-Architektur nicht aufräumt, wer Privilege-Hierarchien nicht klar zieht, wer Service-Accounts nicht audiert, hat mit ITDR mehr Alerts und weniger Klarheit. Die Tools detectieren Anomalien, aber sie reparieren keine schlecht geplante Identity-Welt.

Im Praxischeck mit dem Maschinenbauer ist genau das passiert. Nach der ITDR-Einführung explodierte die Alert-Zahl von 30 pro Tag auf 380. Drei Wochen Triage haben gezeigt: Die meisten Alerts waren keine Angriffe, sondern Tagesgeschäft, das die ITDR-Engine nicht kannte. Service-Accounts mit übermäßigen Privilegien, OAuth-Consents mit zu breiten Scopes, alte Geräte-Sign-Ins von ausgemusterten Laptops. Die Alert-Reduktion auf 50 pro Tag hat zwei Monate Identity-Hausputz gekostet, nicht ein Tool-Tuning.

Ein zweiter Praxis-Punkt aus den Reviews: Die Verantwortung für ITDR-Alerts ist organisatorisch oft nicht klar. SOC-Analysten sind klassisch auf Endpoint-Events trainiert, Identity-Spezialisten sitzen meist im IT-Operations-Team. Wenn ein ITDR-Alert ankommt, weiß zunächst niemand, wer ihn triagiert. Die saubere Antwort: ITDR-Alerts werden im SOC erst-eskaliert, mit klaren Übergabe-Punkten an das Identity-Team für Privilege-Bereinigung und Service-Account-Hygiene. Wer diesen Übergabe-Punkt nicht definiert, hat Alerts ohne Owner.

Eine dritte Beobachtung betrifft die Alert-Severity. ITDR-Tools liefern Risiko-Scores, die meisten Mittelstands-SOCs haben aber keine etablierte Skala für Identity-Risiken. Ein „Hoch“-Risiko-Sign-In aus Brasilien für einen User, der in Brasilien Urlaub macht, ist kein Angriff. Ein „Mittel“-Risiko-OAuth-Consent kann ein Angriff sein, wenn die App unbekannt ist. Wer ITDR scharf schaltet, sollte parallel ein Severity-Mapping definieren, das die ITDR-Risiko-Logik mit dem eigenen Geschäfts-Kontext verbindet.

Die Lehre: ITDR ohne Identity-Hygiene-Plan produziert Alert-Müdigkeit im SOC. Wer die Schicht einführt, sollte parallel ein Identity-Hausputz-Programm aufsetzen: Service-Account-Inventar, OAuth-Consent-Audit, Privilege-Review, Geräte-Hygiene. Diese Aufgaben sind nicht spektakulär, aber sie machen den Unterschied zwischen einem nützlichen ITDR-Setup und einer permanent schreienden Konsole.

Was Security-Teams bis Q3 2026 entscheiden müssen

Drei Bewegungen verschärfen die ITDR-Frage. Erstens: Microsoft hat im April 2026 Defender for Identity auf Okta erweitert, was die Multi-IDP-Detection verbilligt. Zweitens: NIS2-Audits in DACH verlangen seit Beginn 2026 zunehmend Identity-Detection-Nachweise, vor allem für KRITIS-Betreiber. Drittens: Token-basierte Angriffe haben in 2025 deutlich zugenommen, klassische MFA-Bypass-Pattern wie Session-Cookie-Theft funktionieren auch 2026 noch.

Wer diesen Fahrplan in Q2 2026 startet, hat zum Jahreswechsel eine ITDR-Schicht im operativen Betrieb. Das ist die Voraussetzung für die nächste NIS2-Audit-Welle und für die Detection-Lücke, die identity-basierte Angriffe in jedem Setup ohne ITDR offen lassen. Wer wartet, hat die Lücke 2027 weiterhin offen, mit der zusätzlichen Komplikation eines verschärften Audit-Drucks.

Eine konkrete Empfehlung aus den Praxis-Reviews: Wer Q2 2026 startet, sollte das Identity-Inventar in den ersten vier Wochen abschließen. Dazu gehört eine Liste aller IDPs mit Tenant-IDs, eine Liste aller Service-Accounts mit Owner und Privilegien, eine OAuth-Consent-Auswertung pro IDP und ein Privilege-Profil pro priviligierte Rolle. Diese vier Listen kosten zwischen 15 und 25 Personentagen, je nach Größe der Identity-Welt. Sie sind der Boden, auf dem jede ITDR-Wahl steht.

Was nicht in diesen Fahrplan gehört: ein Tool-Wechsel ohne Identity-Hygiene. Wer ITDR scharf schaltet ohne die Service-Account-Hygiene, ohne OAuth-Consent-Review, ohne Privilege-Review, produziert Alert-Müll. Die ehrlichste Frage in jedem Security-Review der nächsten zwei Quartale ist daher nicht „welches ITDR-Tool“, sondern „wie sieht unsere Identity-Realität aus, bevor wir ein Tool darauf setzen“. Das ist die langweilige Antwort. Es ist die richtige. Und sie spart die teure Korrektur in zwölf Monaten, wenn der nächste BSI-Audit-Bericht ansteht.

Häufige Fragen

Brauchen wir ITDR, wenn wir bereits EDR und SIEM haben?

Ja, in den meisten Setups. EDR sieht den Endpoint, SIEM korreliert Logs, beide sehen Identity-Kontext nur indirekt. Token-Diebstahl, OAuth-Abuse und Cross-Tenant-Bewegungen tauchen in beiden oft Stunden später auf. ITDR füllt diese Lücke, entweder als eigene Schicht oder als Modul im bestehenden Stack.

Was ist der Unterschied zwischen ITDR und ISPM?

ITDR ist Detection plus Response, ISPM (Identity Security Posture Management) ist Bestands-Hygiene. ISPM zeigt was im Identity-Stack falsch konfiguriert ist, ITDR detectiert wenn jemand die Konfiguration aktiv ausnutzt. Beide ergänzen sich, ersetzen sich nicht.

Reicht Microsoft Entra ID Protection als ITDR-Lösung?

Für reine Microsoft-Setups oft ja, für Multi-IDP-Setups nein. Entra ID Protection deckt Entra-Identitäten gut ab, sieht aber nicht in Okta, Workspace oder On-Prem-AD-Tenants. Wer mehrere Identity-Provider hat, braucht entweder die erweiterte Defender for Identity-Lizenz oder eine eigene ITDR-Schicht.

Wie tief muss das Identity-Inventar vor der ITDR-Einführung sein?

Mindestens Service-Accounts, OAuth-Consents und privilegierte Rollen. Ohne diese drei Inventare produziert ITDR primär Alert-Müll, weil normale Tagesabläufe als Anomalien erscheinen. Mit den drei Inventaren reduziert sich die Triage-Last um Faktor fünf bis zehn in den ersten drei Wochen.

Welche ITDR-Tools sind für DACH-Mittelständler relevant?

Microsoft Defender for Identity (für M365-affine Häuser, seit April 2026 mit Okta-Coverage), CrowdStrike Falcon Identity (EDR-konsolidierte Setups), Silverfort und Semperis für Multi-IDP-Setups, Okta Identity Threat Protection für Okta-zentrische Häuser. Die Auswahl hängt vom bestehenden Identity-Stack ab, nicht vom Vendor-Marketing.

Quelle Titelbild: KI-generiert mit Google Imagen 4 Fast, SynthID-verifiziert

Hier schreibt Alec Chizhik für Sie

Mehr Artikel vom Autor Alec Chizhik