9 Min. Read Time \u00b7 <\/p>\n
Identity Detection will be the third, non-negotiable layer in the SOC by 2026. EDR sees the endpoint, SIEM sees the log, ITDR sees the identity context between the two. Organizations that omit this layer will only detect token theft, OAuth abuse, and privilege escalation once the damage appears in the SIEM. Gartner predicts that by 2026, 90 percent of enterprise organizations will have embedded ITDR capabilities. The question isn’t whether, but whether it will be a standalone layer or an E<\/p>\n Three architecture patterns have become established in the market. Each has its strengths, each its trade-offs. The choice doesn’t depend on vendor preference, but rather on identity maturity, the existing EDR stack, and who operates the SOC.<\/p>\n Source: Three Security Architecture Reviews with DACH mid-sized companies (200 to 1,500 employees), Q1 2026, anonymized<\/p>\n<\/div>\n The three options are not mutually exclusive, but they compete for budget and personnel. Anyone running all three in parallel will have the same identity event appear three times in three different consoles. Anyone running none will only detect token theft during the SIEM correlation job at two in the morning. The right answer depends on two variables: How many identity providers<\/p>\n The same arguments have repeatedly emerged in the three reviews from the last quarter. The insurer with Hybrid AD and Microsoft 365 opted for the EDR-integrated variant because they already use CrowdStrike Falcon in their SOC, and the identity module was the natural next step. The machine manufacturer, running Entra ID and Okta in parallel, implemented its own ITDR layer because none of the EDR providers offered equally deep support for both IDPs. The SaaS provider with a pure cloud setup and 80 engineers chose an IDP-native protection package because their SOC was too small for an additional tool.<\/p>\n What Justifies a Dedicated ITDR Layer<\/p>\n Where the EDR Module Suffices<\/p>\n An important observation: the choice depends less on vendor marketing and more on your own identity hygiene. Anyone who hasn’t cleaned up service accounts for years, never audited OAuth consents, or lacks a clear privilege hierarchy has an identity problem that no tool can solve instantly. The correct order is: first identity inventory, then tool selection. Those who reverse this order acquire a tool for a reality they don’t yet understand.<\/p>\n Microsoft’s extension of Defender for Identity to Okta identities in April 2026 is noteworthy in this context. It changes the equation for organizations that previously had two IDPs and thus required their own ITDR<\/p>\n No matter which option is chosen, one truth remains: ITDR is detection, not an identity hygiene program. Those who don’t clean up their identity architecture, clearly define privilege hierarchies, or audit service accounts will find ITDR generates more alerts and less clarity. The tools detect anomalies, but they don’t fix a poorly planned identity landscape.<\/p>\n In a practical check with the machine manufacturer, exactly this happened. After the ITDR implementation, the number of alerts exploded from 30 per day to 380. Three weeks of triage revealed: Most alerts were not attacks, but rather daily operations unfamiliar to the ITDR engine. Service accounts with excessive privileges, OAuth consents with overly broad scopes, old device sign-ins from decommissioned laptops. Reducing alerts to 50 per day took two months of identity housecleaning, not tool tuning.<\/p>\n A second practical point from the reviews: Responsibility for ITDR alerts is often not organizationally clear. SOC analysts are traditionally trained on endpoint events, while identity specialists typically reside within the IT operations team. When an ITDR alert arrives, initially no one knows who should triage it. The clean answer: ITDR alerts are initially escalated within the SOC, with clear handover points to the identity team for privilege cleanup and service account hygiene. Those who don’t define this handover point will have alerts without an owner.<\/p>\n A third observation concerns alert severity. ITDR tools provide risk scores, but most mid-sized SOCs lack an established scale for identity risks. A “high” risk sign-in from Brazil for a user on vacation in Brazil is not an attack. A “medium” risk OAuth consent can be an attack if the app is unknown. Organizations that activate ITDR should simultaneously define a severity mapping that connects the ITDR risk logic with their own business context.<\/p>\n The lesson: ITDR without an identity hygiene plan produces alert fatigue in the SOC. Those implementing this layer should simultaneously set up an identity housecleaning program: Service account inventory, OAuth consent audit, privilege review, device hygiene. These tasks aren’t spectacular, but they make the difference between a useful ITDR setup and a permanently screaming console.<\/p>\n Three developments are intensifying the ITDR challenge. First: In April 2026, Microsoft extended Defender for Identity to Okta, which makes multi-IDP detection more affordable. Second: Since the beginning of 2026, NIS2 audits in DACH have increasingly demanded identity detection evidence, especially for critical infrastructure (KRITIS) operators. Third: Token-based attacks significantly increased in 2025, and classic MFA bypass patterns like session cookie theft are still effective in 2026.<\/p>\n At a minimum, service accounts, OAuth consents, and privileged roles. Without these three inventories, ITDR primarily generates alert clutter because normal daily operations appear as anomalies. With these three inventories, the triage load is reduced by a factor of five to ten in the first three weeks.<\/p>\n Microsoft Defender for Identity (for M365-centric organizations, with Okta coverage since April 2026), CrowdStrike Falcon Identity (EDR-consolidated setups), Silverfort and Semperis for Multi-IDP setups, Okta Identity Threat Protection for Okta-centric organizations. The choice depends on the existing identity stack, not vendor marketing.<\/p>\n Editor’s Reading Tips<\/p>\nThree Architecture Options for 2026<\/h2>\n
\n\n
\n \nOption<\/th>\n What it is<\/th>\n When suitable<\/th>\n<\/tr>\n<\/thead>\n \n Dedicated ITDR Layer<\/strong><\/td>\n Specialized tool (Silverfort, Semperis, Authomize) alongside EDR and SIEM<\/td>\n Multi-IDP Setup, Hybrid AD+Cloud, Regulated Industry<\/td>\n<\/tr>\n \n EDR-Integrated<\/strong><\/td>\n Identity modules within EDR (Microsoft Defender for Identity, CrowdStrike Falcon Identity)<\/td>\n Existing EDR vendor with ID module, a single Identity Provider<\/td>\n<\/tr>\n \n IDP-Native<\/strong><\/td>\n Identity Threat Protection within the IDP (Okta IPT, Microsoft Entra ID Protection)<\/td>\n Cloud-only, a central IDP, small SOC<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Where Architectural Decisions Are Made in Practice<\/h2>\n
\n
\n
Drift Risk: What an ITDR Setup Doesn’t Solve<\/h2>\n
What Security Teams Need to Decide by Q3 2026<\/h2>\n
Which ITDR tools are relevant for DACH mid-market companies?<\/h3>\n