Historia de IAM: las cuatro olas

Por qué leer la historia de un dominio técnico

Hay un patrón que se repite en cualquier organización con más de diez años de vida: abres una consola IAM y encuentras tres cosas mezcladas. Una herramienta de provisioning que nadie sabe quién instaló pero “siempre estuvo ahí”, una iniciativa de certificación de accesos creada después de una auditoría externa, y un proyecto reciente de MFA universal que sigue avanzando a tropezones. Cada una de esas cosas pertenece a una ola distinta de IAM.

Si no conoces la historia, vas a creer que todo es ruido y desorden. Si la conoces, ves capas geológicas: cada herramienta y cada práctica responde a una pregunta concreta que la industria estaba haciéndose en su momento. Eso te permite predecir, con sorprendente precisión, qué problemas tiene la organización hoy y cuáles va a tener mañana.

En este artículo recorremos las cuatro olas que llevaron a IAM desde un humilde proyecto de optimización TI en los años 90 hasta la disciplina de Identity Security que vemos hoy. Cada ola respondió a una crisis o a una nueva exigencia del entorno, y cada una dejó residuos en forma de prácticas, productos y decisiones que todavía nos rodean.

Vista general: las cuatro olas

IAM evolucionó en cuatro olas que se solapan: Optimización de TI (reducir costos), Gobernanza (pasar auditorías), Seguridad (frenar brechas) e Identity Security (tratar la identidad como el plano de control unificado). Cada ola se apiló sobre la anterior en lugar de reemplazarla.

Antes de meternos en cada una, mira el panorama completo. Las fechas son aproximadas — las organizaciones no migran en bloque y siempre hay rezagados y adelantados — pero como mapa mental funcionan.

timeline
  accTitle: Cuatro olas de IAM de 1990 al presente
  accDescr: Línea de tiempo que muestra cuatro olas sucesivas de la evolución de IAM — Optimización TI (1990–2005), Gobernanza (2005–2015), Seguridad (2015–2022) e Identity Security (2022–presente) — cada una con sus herramientas y prácticas definitorias.
  title Las cuatro olas de IAM (fechas aproximadas)
  1990-2005 : Ola 1 — Optimización TI : SSO + provisioning básico
  2005-2015 : Ola 2 — Gobernanza : IGA + cumplimiento normativo
  2015-2022 : Ola 3 — Seguridad : MFA + PAM + Zero Trust
  2022-presente : Ola 4 — Identity Security : ITDR + NHI + agentes IA

Las herramientas de la Ola 1 siguen vivas; las de la Ola 2 son la base de los programas de cumplimiento actuales; las de la Ola 3 son el día a día del SOC moderno. La Ola 4 las une bajo un paraguas más amplio.

El patrón común

Si miras las cuatro olas con suficiente distancia, vas a notar un patrón:

1. Una crisis externa crea presión sobre las organizaciones (costos, leyes, brechas, IA).
2. Aparecen herramientas y prácticas nuevas para resolver lo que la ola anterior no atendía.
3. Surgen vendors emblemáticos que capitalizan ese momento (Tivoli, SailPoint, Okta, CrowdStrike Identity).
4. Después de unos años, la solución se vuelve “lo normal” y la siguiente crisis empieza a presionar.

Tener este patrón en la cabeza te permite leer titulares de la industria con criterio. Cuando un analista dice “esta es la nueva ola de X”, lo que está describiendo casi siempre es un fenómeno que cumple los cuatro puntos anteriores.

Ola 1 — Optimización TI (~1990–2005)

El problema que la disparó

A finales de los años 90, las empresas medianas y grandes vivían un dolor cotidiano simple pero costoso: los empleados tenían demasiados usuarios y contraseñas. Cada aplicación corporativa — el ERP, el correo, el portal interno, el sistema de RR. HH., el sistema de tickets — venía con su propio sistema de autenticación. Un empleado típico mantenía entre 5 y 15 cuentas distintas, con contraseñas que se olvidaba constantemente.

El resultado: el help desk se volvió un cuello de botella. Estudios de la época estimaban que hasta el 30 o 40% de los tickets de soporte eran solo resets de contraseña. Cada reset costaba entre 25 y 70 dólares en tiempo de operadores, según los reportes de Gartner y Forrester de esa década. Una empresa de 5,000 empleados podía estar gastando varios millones de dólares al año en lo que era esencialmente una tarea repetitiva.

La respuesta de la industria

La conversación se centró en optimización TI: cómo reducir el costo operativo del help desk y mejorar la productividad del usuario. Las soluciones que emergieron:

• Single Sign-On (SSO): una sola autenticación para acceder a múltiples aplicaciones. Las primeras versiones eran web SSO con cookies cruzadas; después se extendió a aplicaciones empresariales con conectores propietarios.
• Aprovisionamiento automatizado básico: cuando un empleado ingresaba, scripts creaban sus cuentas en los sistemas principales. Cuando salía, los scripts las desactivaban.
• Self-service de contraseña: el empleado podía resetear su contraseña sin ticket, respondiendo preguntas de seguridad (“¿el nombre de tu primera mascota?”).
• Directorios centralizados: Active Directory de Microsoft (lanzado en Windows 2000) consolidó este patrón. LDAP, ya estandarizado, fue su lenguaje de consulta.

Vendors emblemáticos de la ola

Una historia para fijar la ola

Imagina una empresa fabricante de electrodomésticos en 2002, con 3,000 empleados distribuidos en cinco plantas. El director de TI llega a una reunión con dos números bajo el brazo: “el año pasado gastamos 1.8 millones de dólares en operaciones del help desk, y el 38% de los tickets fueron resets de contraseña”. El CFO le pregunta: “¿qué hacemos al respecto?”. La respuesta: comprar Sun Identity Manager, instalar self-service de contraseñas, integrar todas las apps al directorio corporativo. Tres años después, los tickets bajaron un 60%, el ROI fue obvio y nadie cuestionó la inversión.

Esa conversación, multiplicada por miles de empresas, fue la que financió la Ola 1.

Lo que esta ola no resolvió

La Ola 1 fue muy exitosa en su objetivo: bajaron los tickets de help desk y los empleados podían entrar a sus apps con menos fricción. Pero dejó dos huecos enormes:

• No había gobernanza: una vez que se otorgaba un acceso, nadie revisaba si seguía siendo necesario. Los empleados acumulaban privilegios al cambiar de equipo (lo que hoy llamamos privilege creep).
• La seguridad era un complemento, no el centro: las contraseñas se almacenaban a veces sin hashing apropiado, MFA no existía, las cuentas privilegiadas vivían en hojas de cálculo compartidas.

Esos dos huecos se volverían el motor de las dos olas siguientes.

Ola 2 — Gobernanza (~2005–2015)

El problema que la disparó

A inicios de los 2000s, una serie de escándalos contables (Enron en 2001, WorldCom en 2002) hicieron tambalear la confianza en los reportes financieros corporativos en Estados Unidos. La respuesta legislativa fue la Ley Sarbanes-Oxley (SOX) de 2002, que exigió a las empresas cotizadas tener controles internos demostrables sobre sus sistemas financieros. SOX se acompañó muy pronto de otras presiones regulatorias: HIPAA en salud, Basel II en banca y, más tarde, GDPR en privacidad europea.

De pronto la pregunta para muchas organizaciones cambió. Ya no era “¿cómo reduzco el tiempo del help desk?”, sino:

• ¿Quién tiene acceso a qué sistemas financieros?
• ¿Quién aprobó ese acceso y cuándo?
• ¿Sigue siendo necesario hoy?
• ¿Hay personas que pueden registrar Y aprobar el mismo pago (un caso clásico de fraude)?
• ¿Cómo le pruebo eso a un auditor externo?

Las herramientas de Ola 1 no podían responder esas preguntas. Estaban diseñadas para crear cuentas, no para vigilarlas.

La respuesta de la industria

Nació una nueva categoría: IGA (Identity Governance and Administration). Su misión es responder las preguntas anteriores con evidencia auditable. Los componentes que se volvieron estándar:

• Certificación de accesos (recertification): cada cierto tiempo (típicamente trimestral o semestral), los managers o dueños de aplicación revisan los accesos de su gente y aprueban o revocan.
• Solicitud de acceso con flujo de aprobación: cualquier acceso nuevo pasa por un workflow donde el usuario solicita, su jefe aprueba y, opcionalmente, el dueño de la app revisa.
• Separación de funciones (SoD): reglas que detectan combinaciones tóxicas de permisos. “Crear vendor + aprobar pago” en SAP es la combinación clásica que SOX vino a perseguir.
• Auditoría continua: logs de cada cambio de acceso, exportables a auditores externos.
• Modelado de roles: en lugar de gestionar permisos individuales, se crean roles funcionales (“analista contable”) que agrupan accesos.

Vendors emblemáticos de la ola

Cómo se vivió en la práctica

Quien haya trabajado en una empresa cotizada entre 2005 y 2015 conoce la palabra “campaña de certificación”. Era ese período (a veces dos semanas, a veces un mes) en que todos los managers recibían listas con los accesos de sus reportes directos y tenían que ir aprobando o revocando uno por uno, fila por fila, en una herramienta IGA. Era tedioso, generaba mucha resistencia y muchos managers terminaban aprobando todo en bloque (“approve all”) solo para terminar a tiempo.

Esa experiencia produjo dos efectos importantes:

1. La gobernanza de identidad se volvió un proyecto serio dentro de TI: los Identity Programs modernos nacen aquí.
2. La industria se dio cuenta de que la certificación masiva sin contexto no era muy efectiva. Eso plantó la semilla de la certificación basada en riesgo que veremos en la Ola 4.

Lo que esta ola no resolvió

IGA fue muy buena respondiendo “¿quién tiene acceso a qué y por qué?”. Pero seguía dejando huecos:

• No detectaba uso indebido: una persona con acceso legítimo que abusaba de él no levantaba alertas. La SoD detectaba combinaciones tóxicas pero no actividad maliciosa real.
• Estaba diseñada para empleados: las cuentas de servicio, las identidades de máquina y los clientes externos quedaban fuera.
• El cloud era un blind spot: muchas plataformas IGA tradicionales tenían dificultad para conectarse a proveedores SaaS en la nube, que crecían en paralelo.

Ola 3 — Seguridad (~2015–2022)

El problema que la disparó

Los años entre 2013 y 2017 trajeron una avalancha de breaches que cambiaron la conversación de la industria entera:

• Target (2013): 40 millones de tarjetas de crédito robadas. El vector inicial: credenciales de un proveedor de HVAC.
• OPM (2015): 21.5 millones de registros de empleados federales de EE. UU. expuestos, incluyendo expedientes de seguridad nacional. Uso de credenciales válidas robadas.
• Anthem (2015): 78.8 millones de registros médicos. Phishing dirigido a un administrador.
• Equifax (2017): 147 millones de personas. Aunque entró por una vulnerabilidad en Apache Struts, el atacante se movió lateralmente usando credenciales internas.
• Marriott (2018): 500 millones de huéspedes. Acceso persistente durante 4 años.

El patrón se volvió obvio: los atacantes ya no rompían perímetros, conseguían credenciales y se logueaban. Las herramientas de Ola 1 y Ola 2 no estaban diseñadas para defenderse contra ese vector. Mientras tanto, el cloud y el trabajo remoto erosionaban el perímetro de red — el tema que ya cubrimos en el segundo artículo de esta serie.

La respuesta de la industria

La conversación pivotó hacia identidad como el plano de seguridad. Las soluciones que se volvieron estándar:

• MFA universal: ya no opcional para administradores, sino obligatorio para toda persona. Plataformas como Duo (fundada 2010) y Authy crecieron explosivamente. Push notifications, TOTP y gradualmente FIDO/WebAuthn.
• PAM (Privileged Access Management): las cuentas administrativas se trataron como activos de altísimo valor. Bóvedas de credenciales, grabación de sesiones, rotación automática.
• IDaaS (Identity as a Service): el IdP en la nube. Okta (fundada 2009, IPO 2017) lideró esta categoría junto con Microsoft Entra (entonces Azure AD) y Ping Identity.
• Zero Trust: el NIST publicó SP 800-207 en agosto de 2020, formalizando lo que Google y otros ya practicaban con BeyondCorp desde 2014.
• Federación moderna: SAML primero, OIDC después, se volvieron infraestructura crítica para conectar el ecosistema SaaS.

Vendors emblemáticos de la ola

El cambio de mentalidad

Lo que empezó como “agreguemos MFA” terminó siendo una redefinición completa de cómo se piensa la seguridad. Tres frases que nacieron en esta ola y siguen vivas:

“Identity is the new perimeter.”

“Assume breach.”

“Never trust, always verify.”

Cada una resume un cambio profundo. La primera, que la red ya no protege; la segunda, que hay que diseñar como si el atacante ya estuviera dentro; la tercera, que la verificación no termina en el login sino que continúa en cada decisión.

Lo que esta ola no resolvió

La Ola 3 fue tremendamente exitosa en levantar el listón de seguridad. Pero quedaron huecos:

• Identity threat detection era inmaduro: tenías MFA, pero si alguien lograba burlarlo (con MFA bombing, AitM, etc.) el sistema no necesariamente lo detectaba.
• NHI quedaba en segundo plano: PAM cubría administradores humanos, pero las identidades de máquina, los workloads y los secretos en código seguían siendo un campo minado.
• Las plataformas seguían siendo silos: AM, IGA y PAM eran productos distintos de vendors distintos, con poca integración.

Ola 4 — Identity Security (~2022–presente)

Lo que la está disparando

Estamos viviendo esta ola ahora mismo, así que lo que sigue es lectura tentativa más que historia consolidada. Hay tres fuerzas concurrentes que la definen:

• Ataques sofisticados a la infraestructura de identidad: SolarWinds (2020), el breach de Okta (2022), Lapsus$, MOVEit (2023), Snowflake (2024). Los atacantes ahora atacan al IdP mismo, no solo a los usuarios.
• Explosión de identidades no humanas: workloads en cloud, microservicios, agentes IA. La pregunta cambia de “¿quién es este usuario?” a “¿cuántas identidades de máquina tiene mi organización y qué pueden hacer?”.
• Ransomware industrializado: grupos profesionales con ofertas de ransomware-as-a-service. El ROI del ataque es tan alto que la inversión en defensa es directamente proporcional.

A esto se suma una expectativa creciente de que la identidad no solo proteja, sino que habilite el negocio: que las identidades digitales abran nuevos canales (banca embebida, ecosistemas de plataformas, agentes IA al servicio del cliente) en lugar de solo poner barreras.

La respuesta emergente

La Ola 4 está produciendo categorías nuevas que aún no se asentaron, pero ya tienen nombres reconocibles:

• Identity Threat Detection and Response (ITDR): el ojo automatizado sobre el plano de identidad. Gartner formalizó la categoría en 2022.
• Identity Security Posture Management (ISPM): visibilidad continua del riesgo en infraestructura de identidad. ¿Tienes shadow admins? ¿hay golden tickets activos? ¿qué tan expuesto estás?
• Identity Fabric: enfoque arquitectónico promovido por Gartner desde 2021 que busca unificar AM, IGA, PAM e ITDR bajo un solo plano de control con políticas y observabilidad consistentes.
• Passkeys masivas: Apple, Google y Microsoft empujando passkeys como reemplazo de la contraseña. Adopción exponencial en CIAM.
• NHI security platforms: nueva categoría de empresas (Astrix, Token, Oasis) enfocadas exclusivamente en gobernar identidades de máquina.
• Gestión de identidades de agentes IA: aún sin estándar, pero todos los grandes players están construyendo capacidades.

Vendors representativos

El cambio narrativo

Hay una diferencia sutil pero importante entre la Ola 3 y la Ola 4. La Ola 3 era defensiva (“identidad es el perímetro que hay que proteger”). La Ola 4 añade un componente habilitador: identidad bien diseñada permite cosas que antes eran imposibles.

• Ofrecer banca embebida en una app de retail sin que el banco le dé al retail acceso a la base de datos de clientes — solo claims firmados.
• Lanzar agentes IA que actúen en nombre del cliente con scopes precisos y revocables.
• Crear ecosistemas multitenant donde cada organización mantiene control de sus datos pero comparte servicios.

Eso es lo que hoy se llama “Identity Security” (con I mayúscula, como concepto-paraguas) o también “Identity-First Security”.

Cómo se acumulan las olas

Una imagen útil para cerrar. Cada ola no reemplaza a la anterior — se monta encima. Como capas geológicas, los estratos más profundos siguen ahí, sosteniendo todo lo de arriba. El siguiente esquema muestra ese apilamiento tal y como lo encontrarías en una organización moderna.

Pantalla completa

Lectura del esquema: no tiene sentido hablar de Identity Security (Ola 4) si tu organización todavía no tiene MFA universal (Ola 3), ni hablar de MFA si los joiners y leavers no se procesan automáticamente (Ola 1). El orden importa.

Lo que esta ola todavía no resuelve

Es prematuro hacer balance porque seguimos en ella, pero ya se notan tensiones:

• La complejidad se acumula: organizaciones tienen herramientas IAM de las cuatro olas conviviendo, con integraciones frágiles.
• Identidad de agentes IA es un problema nuevo sin solución madura. Quien lo resuelva bien será probablemente el SailPoint u Okta de los próximos diez años.
• El talento es escaso: pocos profesionales entienden las cuatro olas a la vez. Es justamente lo que este programa intenta formar.

Cómo aplicar este conocimiento histórico

Más allá de la curiosidad, conocer las olas tiene tres usos prácticos concretos.

1. Diagnóstico rápido de organizaciones

Cuando entres a una organización nueva, observa estas señales:

2. Justificación de inversiones

Cuando tengas que defender un proyecto IAM frente a un comité ejecutivo, encadenar las olas te da una narrativa fuerte: “hemos resuelto X (ola anterior); ahora la presión competitiva/regulatoria/de seguridad nos exige resolver Y (ola siguiente)”. Es más persuasivo que listar features.

3. Anticipación

Pensar en olas te ayuda a anticipar la siguiente. Si la Ola 4 es Identity Security, ¿qué viene después? Las apuestas razonables incluyen: identidad descentralizada con wallets, criptografía post-cuántica generalizada, gobernanza federada de agentes IA. Quienes empiecen a diseñar para esa Ola 5 hoy van a tener ventaja en cinco años.

Recapitulación

Las cuatro olas de IAM cuentan una historia coherente: la disciplina nació para ahorrar costos (Ola 1), maduró para cumplir regulaciones (Ola 2), pivotó hacia seguridad cuando los breaches lo exigieron (Ola 3) y hoy se reorganiza para responder a un mundo donde la identidad — humana, de máquina y de agentes IA — es el plano de control de todo.

Si llevas la siguiente tabla en mente, vas a poder leer cualquier organización en pocas preguntas:

Tres preguntas para autoevaluarte

1. Trabajas como consultor IAM y entras a una empresa familiar grande con 2,000 empleados. Tienen Active Directory + reset de contraseña por preguntas + un script de provisioning. ¿En qué ola están y qué les recomendarías priorizar para los próximos 12 meses?
2. Tu CFO te dice “ya pagamos SailPoint hace 8 años, ¿por qué necesitamos más identity tools?”. ¿Cómo le explicas la diferencia entre IGA (Ola 2) e Identity Security (Ola 4) en menos de tres minutos?
3. Si tuvieras que apostar qué define la Ola 5 de IAM, ¿qué hipótesis manejarías y qué señales tempranas la confirmarían?