9 min de lectura \u00b7 <\/p>\n
La detecci\u00f3n de identidad es en 2026 la tercera capa en el SOC que ya no se puede posponer. EDR ve el endpoint, SIEM ve el log, ITDR ve el contexto de identidad entre ambos. Quien omite esta capa solo detecta robo de tokens, abuso de OAuth y escalaci\u00f3n de privilegios cuando el da\u00f1o ya llega al SIEM. Gartner afirma que en 2026 el 90 % de las organizaciones empresariales implementar\u00e1n funciones de ITDR integradas. La pregunta no es si, sino si como capa independiente o como m\u00f3dulo dentro de EDR.<\/strong><\/p>\n Lo m\u00e1s importante en resumen<\/p>\n Relacionado<\/span>Identity-Sprawl en pymes<\/a> \/<\/span> MFA adaptativa como est\u00e1ndar NIS2<\/a><\/p>\n \u00bfQu\u00e9 es la detecci\u00f3n y respuesta de amenazas de identidad?<\/strong> Una capa de detecci\u00f3n que identifica patrones de ataque espec\u00edficos de identidad y responde de forma automatizada. Supervisa eventos de autenticaci\u00f3n, cambios de privilegios, uso de tokens OAuth, comportamiento de cuentas de servicio y movimientos entre tenants. Su base de an\u00e1lisis son los logs de proveedores de identidad (Entra ID, Okta, Active Directory), no la telemetr\u00eda de endpoint ni flujos de red.<\/p>\n La diferencia con EDR y SIEM radica en el contexto, no en el flujo de datos. EDR ve lo que ocurre en el endpoint. SIEM recopila los logs que llegan. ITDR a\u00f1ade la lente de identidad: \u00bfQu\u00e9 cuenta us\u00f3 qu\u00e9 token en qu\u00e9 configuraci\u00f3n de tenant? \u00bfFue el inicio de sesi\u00f3n riesgoso? \u00bfSe intent\u00f3 una escalaci\u00f3n de privilegios? \u00bfExisten consentimientos de OAuth a aplicaciones sospechosas? EDR y SIEM responden a estas preguntas solo indirectamente, a menudo horas despu\u00e9s, o nunca.<\/p>\n En 2025, Expel constat\u00f3 en su informe SOC que el 68,6 % del volumen de amenazas observado ten\u00eda base en identidad. Okta report\u00f3 para el mismo a\u00f1o m\u00e1s de 15.000 millones de intentos de inicio de sesi\u00f3n maliciosos bloqueados en m\u00e1s de 10.000 organizaciones. Estas no son cifras de marketing de proveedores, sino realidad operativa: quien planea detecci\u00f3n de seguridad en 2026 sin una capa de identidad, est\u00e1 ignorando el patr\u00f3n real de ataque.<\/p>\n Concretamente: un atacante que, mediante phishing, roba una cookie de sesi\u00f3n y se autentica como usuario leg\u00edtimo en Microsoft 365, no deja rastro sospechoso en el endpoint. EDR ve solo una pesta\u00f1a normal del navegador. En SIEM aparece un inicio de sesi\u00f3n marcado como v\u00e1lido por el motor de MFA. Solo la capa de ITDR detecta que el inicio de sesi\u00f3n proviene de una ubicaci\u00f3n geogr\u00e1fica inusual, que la duraci\u00f3n del token es anormalmente larga, y que el usuario acept\u00f3 inmediatamente un consentimiento de OAuth para una aplicaci\u00f3n desconocida. Esta cadena de se\u00f1ales de identidad es la fortaleza de ITDR.<\/p>\n En la pr\u00e1ctica, esto tambi\u00e9n explica por qu\u00e9 la MFA cl\u00e1sica ya no basta en 2026. El robo de tokens, el atacante en el medio y el secuestro de sesi\u00f3n funcionan incluso con MFA activada. La MFA adaptativa y la autenticaci\u00f3n basada en riesgo ayudan en la puerta frontal; ITDR complementa en la puerta trasera: \u00bfqu\u00e9 ocurre tras el inicio de sesi\u00f3n, cuando ya existe la sesi\u00f3n, cuando el token ya fue robado? Ambas capas juntas forman una defensa de identidad moderna.<\/p>\n En el mercado se han consolidado tres patrones de arquitectura. Cada uno tiene sus fortalezas y tambi\u00e9n sus compromisos. La elecci\u00f3n no depende de la preferencia del proveedor, sino de la madurez de la identidad, del stack EDR existente y de qui\u00e9n gestiona el SOC.<\/p>\n Fuente: Tres revisiones de arquitecturas de seguridad con medianas empresas de DACH (de 200 a 1.500 empleados), Q1 2026, anonimizadas<\/p>\n<\/div>\n Las tres opciones no se excluyen entre s\u00ed, pero compiten por presupuesto y personal. Quien las implementa todas en paralelo tendr\u00e1 tres veces el mismo evento de identidad en tres consolas. Quien no implementa ninguna ver\u00e1 el robo de tokens reci\u00e9n en el trabajo de correlaci\u00f3n del SIEM a las dos de la madrugada. La respuesta correcta depende de dos variables: \u00bfcu\u00e1ntos proveedores de identidad est\u00e1n involucrados? \u00bfQui\u00e9n tiene el stack principal de detecci\u00f3n en casa?<\/p>\n En los tres an\u00e1lisis del \u00faltimo trimestre, los mismos argumentos han vuelto una y otra vez. El asegurador con Hybrid AD y Microsoft 365 ha optado por la versi\u00f3n integrada en EDR, porque ya utiliza CrowdStrike Falcon en su SOC y el m\u00f3dulo de identidad era el paso natural de expansi\u00f3n. El fabricante de maquinaria que cuenta con Entra ID y Okta de forma paralela ha creado su propia capa de ITDR, porque ninguno de los proveedores de EDR ofrece soporte profundo para ambos IDPs. El proveedor SaaS con configuraci\u00f3n totalmente en la nube y 80 ingenieros ha elegido un paquete de protecci\u00f3n nativo para IDP, porque el SOC es demasiado peque\u00f1o para un herramienta adicional.<\/p>\n Qu\u00e9 implica contar con una capa de ITDR propia<\/p>\n D\u00f3nde alcanza el m\u00f3dulo EDR<\/p>\n Una observaci\u00f3n importante: la elecci\u00f3n depende menos del marketing de los proveedores y m\u00e1s de la propia higiene de la identidad. Quien no ha limpiado sus cuentas de servicio durante a\u00f1os, quien nunca ha auditado los consentimientos OAuth o quien no tiene una jerarqu\u00eda clara de privilegios, enfrenta un problema de identidad que ning\u00fan herramienta puede resolver de inmediato. La secuencia correcta es: primero el inventario de identidades, luego la selecci\u00f3n de herramientas. Quien invierte en el orden inverso se est\u00e1 comprando una herramienta para una realidad que a\u00fan no comprende.<\/p>\n La extensi\u00f3n de Microsoft Defender for Identity a las identidades de Okta en abril de 2026 resulta notable en este contexto. Cambia la manera de pensar para aquellos hogares que hasta ahora contaban con dos IDPs y necesitaban una capa de ITDR propia. Quienes ya tienen Defender for Identity en su stack de Microsoft pueden incluir ahora las identidades de Okta sin necesidad de licenciar una herramienta adicional. Esto permite ahorrar costos de licencia y reducir el n\u00famero de consolas en el SOC.<\/p>\n Independientemente de la opci\u00f3n elegida, una verdad permanece: ITDR es detecci\u00f3n, no un programa de higiene de identidad. Quien no sanea la arquitectura de identidad, quien no delimita claramente las jerarqu\u00edas de privilegios y quien no audita las cuentas de servicio, obtendr\u00e1 m\u00e1s alertas con ITDR y menos claridad. Las herramientas detectan anomal\u00edas, pero no reparan una arquitectura de identidad mal planificada.<\/p>\n En la prueba pr\u00e1ctica realizada con el fabricante de maquinaria sucedi\u00f3 precisamente eso. Tras la implementaci\u00f3n de ITDR, el n\u00famero de alertas se dispar\u00f3 de 30 al d\u00eda a 380. Tres semanas de triaje mostraron que la mayor\u00eda de las alertas no correspond\u00edan a ataques, sino a actividades cotidianas que la m\u00e1quina de ITDR no reconoc\u00eda: cuentas de servicio con privilegios excesivos, consentimientos OAuth con \u00e1mbitos demasiado amplios y accesos desde dispositivos obsoletos, como port\u00e1tiles ya retirados. Reducir las alertas a 50 al d\u00eda requiri\u00f3 dos meses de limpieza profunda de la identidad, no simplemente ajustar las configuraciones de la herramienta.<\/p>\n Otro punto pr\u00e1ctico surgido de las revisiones: la responsabilidad por las alertas de ITDR suele estar poco clara desde el punto de vista organizativo. Los analistas del SOC est\u00e1n formados principalmente para gestionar eventos en endpoints, mientras que los especialistas en identidad suelen pertenecer al equipo de operaciones de TI. Cuando llega una alerta de ITDR, inicialmente nadie sabe qui\u00e9n debe realizar el triaje. La soluci\u00f3n adecuada es que las alertas de ITDR sean primero escaladas al SOC, con puntos claros de transferencia al equipo de identidad para la depuraci\u00f3n de privilegios y la higiene de las cuentas de servicio. Quien no defina este punto de transferencia terminar\u00e1 con alertas sin responsable asignado.<\/p>\n Una tercera observaci\u00f3n concierne a la gravedad de las alertas. Las herramientas de ITDR proporcionan puntuaciones de riesgo, pero la mayor\u00eda de los SOC de medianas empresas no cuentan con una escala establecida para los riesgos de identidad. Un inicio de sesi\u00f3n con \u201calto\u201d nivel de riesgo procedente de Brasil para un usuario que est\u00e1 de vacaciones en ese pa\u00eds no constituye un ataque. En cambio, un consentimiento OAuth con \u201criesgo medio\u201d puede serlo si la aplicaci\u00f3n es desconocida. Quien activa ITDR deber\u00eda definir paralelamente un sistema de mapeo de gravedad que vincule la l\u00f3gica de riesgo de ITDR con el contexto empresarial propio.<\/p>\n La lecci\u00f3n es esta: ITDR sin un plan de higiene de identidad genera fatiga por alertas en el SOC. Quien introduce esta capa debe, de forma paralela, poner en marcha un programa de limpieza de la identidad: inventario de cuentas de servicio, auditor\u00eda de consentimientos OAuth, revisi\u00f3n de privilegios y mantenimiento de los dispositivos. Estas tareas no son espectaculares, pero marcan la diferencia entre un despliegue \u00fatil de ITDR y una consola permanentemente inundada de alertas.<\/p>\n Tres movimientos intensifican la cuesti\u00f3n de la ITDR. Primero: Microsoft ampli\u00f3 Defender for Identity a Okta en abril de 2026, lo que abarata la detecci\u00f3n multi-IDP. Segundo: las auditor\u00edas NIS2 en la regi\u00f3n DACH exigen desde principios de 2026 cada vez m\u00e1s pruebas de detecci\u00f3n de identidad, especialmente para operadores de infraestructuras cr\u00edticas (KRITIS). Tercero: los ataques basados en tokens aumentaron significativamente en 2025; los patrones cl\u00e1sicos de elusi\u00f3n de MFA, como el robo de cookies de sesi\u00f3n, siguen funcionando en 2026.<\/p>\n Quien inicie esta hoja de ruta en el T2 de 2026 tendr\u00e1 una capa ITDR operativa al cambio de a\u00f1o. Este es el requisito previo para la pr\u00f3xima ola de auditor\u00edas NIS2 y para cubrir la brecha de detecci\u00f3n que los ataques basados en identidad dejan abierta en cualquier configuraci\u00f3n sin ITDR. Quien espere mantendr\u00e1 la brecha abierta en 2027, con la complicaci\u00f3n adicional de una presi\u00f3n de auditor\u00eda m\u00e1s estricta.<\/p>\n Una recomendaci\u00f3n concreta de las revisiones pr\u00e1cticas: quien comience en el T2 de 2026 deber\u00eda completar el inventario de identidades en las primeras cuatro semanas. Esto incluye una lista de todos los IDP con IDs de tenant, una lista de todas las cuentas de servicio con propietario y privilegios, una evaluaci\u00f3n de consentimientos OAuth por IDP y un perfil de privilegios por rol privilegiado. Estas cuatro listas cuestan entre 15 y 25 d\u00edas-persona, dependiendo del tama\u00f1o del entorno de identidad. Son la base sobre la que se sustenta cualquier elecci\u00f3n de ITDR.<\/p>\n Lo que no pertenece a esta hoja de ruta: un cambio de herramienta sin higiene de identidad. Quien active la ITDR sin higiene de cuentas de servicio, sin revisi\u00f3n de consentimientos OAuth, sin revisi\u00f3n de privilegios, generar\u00e1 basura de alertas. La pregunta m\u00e1s honesta en cada revisi\u00f3n de seguridad de los pr\u00f3ximos dos trimestres no es, por tanto, \u00abqu\u00e9 herramienta ITDR\u00bb, sino \u00abc\u00f3mo es nuestra realidad de identidad antes de implementar una herramienta sobre ella\u00bb. Esta es la respuesta aburrida. Es la correcta. Y ahorra la costosa correcci\u00f3n dentro de doce meses, cuando llegue el pr\u00f3ximo informe de auditor\u00eda del BSI.<\/p>\n S\u00ed, en la mayor\u00eda de las configuraciones. El EDR ve el endpoint, el SIEM correlaciona logs, pero ambos ven el contexto de identidad solo indirectamente. El robo de tokens, el abuso de OAuth y los movimientos cross-tenant suelen aparecer en ambos sistemas horas m\u00e1s tarde. La ITDR cubre esta brecha, ya sea como capa propia o como m\u00f3dulo en la pila existente.<\/p>\n La ITDR es detecci\u00f3n m\u00e1s respuesta, el ISPM (Identity Security Posture Management) es higiene del inventario. El ISPM muestra qu\u00e9 est\u00e1 mal configurado en la pila de identidad, la ITDR detecta cuando alguien explota activamente la configuraci\u00f3n. Ambos se complementan, no se sustituyen.<\/p>\n Para entornos puramente de Microsoft, a menudo s\u00ed; para entornos multi-IDP, no. Entra ID Protection cubre bien las identidades de Entra, pero no ve dentro de los tenants de Okta, Workspace o AD on-premise. Quien tenga varios proveedores de identidad necesita o bien la licencia ampliada de Defender for Identity o una capa ITDR propia.<\/p>\n Al menos cuentas de servicio, consentimientos OAuth y roles privilegiados. Sin estos tres inventarios, ITDR produce principalmente ruido de alertas, ya que los procesos diarios normales aparecen como anomal\u00edas. Con los tres inventarios, la carga de triaje se reduce en un factor de cinco a diez durante las primeras tres semanas.<\/p>\n Microsoft Defender for Identity (para hogares afines a M365, desde abril de 2026 con cobertura Okta), CrowdStrike Falcon Identity (configuraciones consolidadas EDR), Silverfort y Semperis para configuraciones multi-IDP, Okta Identity Threat Protection para hogares centrados en Okta. La selecci\u00f3n depende del stack de identidad existente, no del marketing del proveedor.<\/p>\n Consejos de lectura de la redacci\u00f3n<\/p>\n\n
Qu\u00e9 es ITDR y por qu\u00e9 SIEM y EDR no lo sustituyen<\/h2>\n
Tres opciones de arquitectura para 2026<\/h2>\n
\n\n
\n \nOpci\u00f3n<\/th>\n Qu\u00e9 es<\/th>\n Cu\u00e1ndo es adecuada<\/th>\n<\/tr>\n<\/thead>\n \n Capa ITDR propia<\/strong><\/td>\n Herramienta especializada (Silverfort, Semperis, Authomize) junto con EDR y SIEM<\/td>\n Configuraci\u00f3n multi-IDP, AD h\u00edbrido + nube, sector regulado<\/td>\n<\/tr>\n \n Integrada en EDR<\/strong><\/td>\n M\u00f3dulos de identidad en el EDR (Microsoft Defender for Identity, CrowdStrike Falcon Identity)<\/td>\n Proveedor de EDR existente con m\u00f3dulo de identidad, un proveedor de identidades<\/td>\n<\/tr>\n \n Nativa de IDP<\/strong><\/td>\n Protecci\u00f3n contra amenazas de identidad en el IDP (Okta IPT, Microsoft Entra ID Protection)<\/td>\n Solo en la nube, un IDP centralizado, SOC peque\u00f1o<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Donde la decisi\u00f3n arquitect\u00f3nica se toma en la pr\u00e1ctica<\/h2>\n
\n
\n
Riesgo de deriva: Lo que el despliegue de ITDR no resuelve<\/h2>\n
Lo que los equipos de seguridad deben decidir antes del T3 de 2026<\/h2>\n
Preguntas frecuentes<\/h2>\n
\u00bfNecesitamos ITDR si ya tenemos EDR y SIEM?<\/h3>\n
\u00bfCu\u00e1l es la diferencia entre ITDR e ISPM?<\/h3>\n
\u00bfEs suficiente Microsoft Entra ID Protection como soluci\u00f3n ITDR?<\/h3>\n
\u00bfQu\u00e9 tan profundo debe ser el inventario de identidades antes de la implementaci\u00f3n de ITDR?<\/h3>\n
\u00bfQu\u00e9 herramientas ITDR son relevantes para pymes en la regi\u00f3n DACH?<\/h3>\n