Arquitectura de IAM resiliente en 2026: diseño, amenazas, formalización y evaluación empírica para entornos híbridos, Zero Trust y cargas de trabajo con IA

1. Introducción

La gestión de identidades y accesos, o IAM por sus siglas en inglés, se ha transformado en el núcleo operativo de la ciberseguridad contemporánea. En términos prácticos, IAM no es solo un subsistema de autenticación; es el mecanismo que determina quién puede solicitar, obtener, renovar y revocar acceso a recursos críticos, bajo qué condiciones y con qué nivel de confianza. En un entorno empresarial de 2026, donde conviven aplicaciones SaaS, cargas de trabajo en nube pública, entornos on-premise heredados, infraestructuras OT conectadas, APIs expuestas a socios y agentes de inteligencia artificial con capacidad de actuar sobre herramientas empresariales, la identidad se ha convertido en el perímetro real. Esa afirmación, que hace una década era una consigna estratégica, hoy es una descripción operativa verificable.

El cambio de paradigma se explica por la disolución del perímetro tradicional. Los controles de red siguen siendo relevantes, pero el acceso efectivo a los activos depende cada vez más de decisiones de IAM: autenticación multifactor, federación, políticas condicionales, roles, atributos, privilegios temporales y verificaciones continuas de contexto. El atacante moderno lo sabe. Por ello, la campaña típica ya no prioriza la explotación de un firewall, sino el secuestro de una cuenta válida, el robo de un token de sesión, la manipulación de un flujo OAuth, la explotación de un consentimiento excesivo o el abuso de una identidad de máquina mal gobernada. La economía del acceso se ha desplazado del malware como vector principal al abuso de identidades y credenciales, con campañas de ransomware, espionaje y fraude financiero apoyadas en técnicas de social engineering, session hijacking y adversary-in-the-middle.

Este trabajo parte de una premisa técnica: IAM debe analizarse como un sistema ciberfísico de decisiones, no como una lista de controles aislados. Bajo esta perspectiva, autenticación, autorización, provisión y auditoría forman un circuito cerrado. Una decisión correcta en el momento de login puede volverse incorrecta minutos después si cambia el riesgo, si se detecta un dispositivo comprometido o si el recurso consultado eleva su sensibilidad. Por ello, los modelos estáticos basados exclusivamente en RBAC resultan insuficientes en 2026. La madurez actual exige combinar RBAC con ABAC, policy-based access control, conditional access, segmenteación de privilegios, PAM, JIT y validación continua del contexto. Además, la expansión de passkeys, FIDO2/WebAuthn y autenticación sin contraseña ha mejorado la resistencia al phishing, pero no elimina el riesgo de sesión comprometida, abuso de recuperación de cuenta, ingeniería social a la mesa de ayuda ni delegaciones inseguras en proveedores externos.

La aparición de cargas de trabajo de IA añade una dimensión nueva. Muchas organizaciones ya operan asistentes internos, agentes orquestados y automatizaciones que acceden a correo, repositorios, CRM, SIEM o plataformas de ticketing. Estos agentes no son usuarios humanos, pero tampoco son simples aplicaciones estáticas. Poseen credenciales, tokens, scopes y permisos que pueden ser abusados mediante prompt injection, tool poisoning, data exfiltration y encadenamiento de acciones no intencionadas. En consecuencia, IAM debe extender sus modelos tradicionales para representar identidades no humanas con semántica operacional distinta, pero igualmente sometidas a principios de mínimo privilegio, trazabilidad y revocación.

Desde la perspectiva defensiva, la pregunta relevante no es si una organización “tiene MFA”, sino si sus controles de IAM resisten ataques reales de 2026. El uso de push MFA sin resistencia al phishing sigue siendo explotable mediante cansancio de aprobaciones, adversary-in-the-middle y proxies transparentes. El uso de SSO sin endurecimiento puede concentrar el riesgo en un único IdP. Los flujos de recuperación de cuenta pueden convertirse en el eslabón más débil. Los tokens de larga duración pueden sobrevivir más allá de la sesión legítima. Y las integraciones con terceros pueden introducir transiciones de confianza no observadas por los equipos de seguridad. Por tanto, un diseño serio de IAM debe incorporar telemetría, detección, respuesta y gobernanza continua, además de prevención.

El aporte de este artículo es triple. Primero, presenta una formalización de IAM orientada a riesgo y a contexto, adecuada para entornos híbridos y multicloud de 2026. Segundo, propone una arquitectura implementable que integra estándares reales, prácticas maduras y controles de observabilidad. Tercero, evalúa empíricamente el impacto de esa arquitectura sobre indicadores operativos como tasa de bloqueo de intentos maliciosos, tiempo medio de exposición de credenciales comprometidas y reducción de privilegios innecesarios. El resultado es una propuesta orientada a ingeniería, no a retórica: un marco que puede ser desplegado por defensores reales en organizaciones complejas.

2. Background and Related Work

La literatura y la práctica industrial sobre IAM han evolucionado en ciclos. En la primera etapa, dominó el paradigma de directorio centralizado y control de acceso basado en roles. Sistemas como Active Directory, LDAP y sus extensiones permitieron administrar usuarios, grupos y políticas en organizaciones grandes, pero también concentraron el riesgo y fomentaron estructuras de privilegio demasiado amplias. Con la expansión del software como servicio y la identidad federada, aparecieron SAML 2.0 y posteriormente OpenID Connect como mecanismos de autenticación y aserción de identidad. OAuth, originalmente diseñado para autorización delegada, terminó convertido en un componente central de acceso a APIs y aplicaciones modernas. Esta convergencia fue funcional, aunque también introdujo complejidad y nuevas superficies de ataque (HARDT, 2012).

La segunda etapa estuvo marcada por el auge de la autenticación multifactor. Durante años, el MFA fue considerado una barrera suficiente contra la reutilización de contraseñas. Sin embargo, la realidad operativa mostró que no todo MFA ofrece la misma resistencia. Los factores basados en SMS fueron ampliamente cuestionados por SIM swapping, SS7 abuse y secuestro de número. Las notificaciones push mejoraron la usabilidad, pero generaron fatiga y aprobación accidental. La aparición de FIDO2 y WebAuthn supuso un salto importante al eliminar el secreto compartido como base del factor, al vincular la prueba criptográfica al origen y al permitir autenticación resistente al phishing. La adopción de passkeys en sistemas operativos y plataformas de consumo y empresa consolidó esta transición (WEBAUTHN, 2021; FIDO ALLIANCE, 2024).

El trabajo de NIST SP 800-63B sigue siendo una referencia esencial para la identidad digital y la gestión de autenticadores, especialmente por su tratamiento de niveles de aseguramiento, políticas de autenticación y consideraciones sobre recuperación de cuenta (NIST, 2020). En paralelo, NIST SP 800-207 formalizó Zero Trust como arquitectura: nunca asumir confianza implícita, verificar explícitamente, minimizar privilegios y asumir compromiso potencial de la red y de los endpoints (NIST, 2020). IAM es el plano que materializa esos principios. Sin una identidad robusta, Zero Trust se reduce a un slogan.

A nivel industrial, la gobernanza y administración de identidades se consolidó como IGA, orientada a ciclo de vida, certificación de accesos, segregación de funciones y auditoría. Herramientas comerciales y cloud-native incorporaron conectores, workflows de aprobación y revisión periódica. Sin embargo, la práctica mostró que muchos programas IGA operan como mecanismos de cumplimiento y no como controles preventivos de seguridad. Las campañas de revisión de acceso pueden aprobar privilegios obsoletos por inercia. La provisión automatizada acelera el onboarding, pero también propaga errores de autorización a escala. El resultado es una brecha entre gobernanza formal y seguridad efectiva.

En la capa de privilegios, PAM evolucionó desde cofres de contraseñas hasta just-in-time elevation, session recording, approval workflows y controles de acceso temporales. Las buenas prácticas modernas recomiendan credenciales efímeras, rotación automatizada y aislamiento de sesiones administrativas. Sin embargo, los atacantes han aprendido a comprometer los puntos de entrada de PAM, a explotar privilegios delegados y a robar tokens de administración desde navegadores, gestores de secretos y endpoints comprometidos. La seguridad del plano de privilegios depende tanto de la tecnología como de la higiene operativa y del endurecimiento del endpoint.

Los ataques contemporáneos más relevantes para IAM incluyen phishing adversarial, adversary-in-the-middle, token theft, abuse of OAuth consent, session fixation, credential stuffing, password spraying, ataques a helpdesk y toma de control de cuentas mediante recuperación insegura. La literatura sobre adversary-in-the-middle y proxies de phishing muestra que incluso autenticadores fuertes pueden ser vulnerables si el canal de sesión se captura o si el usuario es inducido a entregar tokens válidos a un intermediario (MITRE, 2025; CISA, 2024). Las campañas de BEC y fraude corporativo se apoyan cada vez más en ingeniería social generada o asistida por IA, con una personalización difícil de distinguir de comunicaciones legítimas.

Desde la perspectiva de frameworks, MITRE ATT&CK clasifica técnicas relevantes como Valid Accounts, Steal Application Access Token, Phishing, Multi-Factor Authentication Request Generation, OAuth Token Abuse y Account Manipulation, entre otras. Estas taxonomías han sido muy útiles para mapear amenazas a controles, pero por sí solas no resuelven el diseño del sistema. También es importante considerar los estándares de provisión SCIM, la evolución de OAuth 2.1, la consolidación de passkeys y las políticas de seguridad para aplicaciones OAuth restringidas o de confianza interna. Para entornos modernos, además, deben considerarse los marcos de gobernanza de IA, puesto que agentes automatizados pueden recibir permisos equivalentes a los de un usuario de alto valor.

La investigación académica ha abordado IAM desde múltiples ángulos: modelos formales de control de acceso, detección de anomalías en identidad, análisis de riesgo contextual, verificación de políticas y estudios de usabilidad de MFA. No obstante, existe una brecha entre los modelos clásicos y las realidades de 2026. En particular, faltan propuestas integradas que unan identidad humana, identidad de máquina, identidad federada y agentes de IA bajo un mismo tejido de confianza con telemetría accionable. Este trabajo intenta cerrar esa brecha con una perspectiva eminentemente operacional.

3. Threat Model and Problem Formalization

Modelar IAM como problema de seguridad requiere identificar los activos, los sujetos, las acciones, las condiciones y los objetivos del adversario. En nuestro modelo, los activos son recursos digitales protegidos: aplicaciones SaaS, APIs internas, infraestructuras cloud, cuentas privilegiadas, secretos, pipelines, repositorios y sistemas de soporte. Los sujetos incluyen usuarios humanos, administradores, dispositivos, servicios, identidades de workload y agentes de IA. Las acciones abarcan autenticar, solicitar acceso, delegar, elevar privilegios, renovar tokens, aprovisionar cuentas, revocar permisos y registrar eventos.

El adversario en 2026 puede operar con diferentes objetivos: acceso inicial, persistencia, movimiento lateral, exfiltración, fraude, sabotaje o espionaje. Sus capacidades incluyen phishing altamente personalizado, uso de infraestructuras de proxy inverso, abuso de MFA fatigue, compromiso de endpoint, robo de cookies y refresh tokens, manipulación de consentimientos OAuth, ataques a helpdesk, explotación de errores de configuración, abuso de roles excesivos y compromiso de proveedores o integraciones. También debe contemplarse un adversario asistido por IA generativa, capaz de escalar volumen, personalización y velocidad de exploración de credenciales, además de automatizar campañas de social engineering multicanal.

La protección de IAM puede formalizarse como una función de decisión $D$ que asigna permiso o denegación a una solicitud $r$ dada. Sea $x$ el vector de contexto, compuesto por identidad del sujeto, estado del dispositivo, postura del endpoint, ubicación aproximada, hora, reputación de IP, sensibilidad del recurso, comportamiento histórico y señales de riesgo. Entonces:

$$ D(r, x) = \begin{cases} 1, & \text{si } P(\text{legitimidad} \mid r, x) \geq \tau \ 0, & \text{en otro caso} \end{cases} $$

donde $\tau$ es un umbral adaptativo definido por la política. La legitimidad no es una propiedad binaria absoluta, sino una estimación probabilística. En entornos maduros, la política debe incorporar costos esperados de falso positivo y falso negativo. Si definimos $C_{FP}$ como el coste de denegar acceso legítimo y $C_{FN}$ como el coste de permitir acceso malicioso, la decisión óptima minimiza:

$$ E[C] = C_{FP} \cdot P(\text{FP}) + C_{FN} \cdot P(\text{FN}) $$

En IAM real, $C_{FN}$ suele ser mucho mayor que $C_{FP}$ para activos críticos, pero no puede ignorarse la continuidad operativa. Por eso, la política debe ser sensible al riesgo y al contexto. Una buena arquitectura no elimina la fricción; la distribuye inteligentemente.

La superficie de ataque de IAM puede descomponerse en capas. La primera capa es la autenticación inicial: credenciales, factores, recuperación y resistencia al phishing. La segunda es la sesión: tokens, cookies, refresh, duración y rotación. La tercera es la federación: relaciones de confianza con IdP, SP, aplicaciones y socios. La cuarta es la autorización: roles, atributos, scopes, políticas y excepciones. La quinta es la gobernanza: provisión, recertificación y revocación. La sexta es la observabilidad: logs, alertas, correlación y respuesta. Un adversario exitoso puede romper cualquiera de estas capas; por ello, la defensa debe aplicar redundancia y validación continua.

Para formalizar el riesgo, definimos una función:

$$ R = \sum_{i=1}^{n} w_i s_i $$

donde $s_i$ son señales normalizadas de riesgo, como dispositivo no conforme, geovelocidad anómala, token reutilizado, consentimiento sospechoso, elevación fuera de ventana o cambio de patrón de comportamiento, y $w_i$ son pesos ajustados por criticidad del activo y sensibilidad del usuario. La autorización se activa cuando $R < \theta$, donde $\theta$ puede variar por tipo de recurso. Para un correo no crítico, el umbral puede ser más alto; para un sistema de pagos o un panel de administración, el umbral debe ser más estricto.

La hipótesis de este artículo es que una arquitectura de IAM basada en señales, con factores resistentes al phishing, tokens de corta vida, privilegio temporal y gobernanza continua, reduce materialmente la probabilidad de compromiso exitoso y la ventana de exposición. La validación de esta hipótesis exige una implementación coherente, además de una evaluación empírica con escenarios realistas. A continuación se expone la metodología propuesta.

4. Proposed Methodology

La metodología propuesta recibe el nombre de IAM-Continuum 2026 y se organiza en cinco planos: identidad, prueba, autorización, privilegio y observabilidad. Su objetivo es transformar IAM en una función continua de reducción de riesgo, no en un evento discreto de login. La arquitectura opera con identidad humana, identidad de servicio, identidad de workload e identidad de agente automatizado, todas sometidas a principios comunes pero con controles adaptados.

El primer plano es la identidad fuerte. Para usuarios humanos se priorizan passkeys basadas en FIDO2/WebAuthn, con fallback controlado y recuperación endurecida. Las contraseñas se reducen donde sea posible, y donde no, se aplican políticas robustas de longitud, protección contra reutilización y detección de compromiso. Para identidades de máquina se utilizan certificados, claves rotadas, secretos efímeros y, cuando es viable, mecanismos de identidad workload gestionados por la plataforma. Para agentes de IA, la identidad debe ser distinta de la del operador humano que los despliega. El agente no “hereda” la cuenta del usuario; recibe permisos mínimos, scopes acotados y sesiones con duración limitada.

El segundo plano es la prueba resistente al phishing. En 2026, el estándar operativo debe ser FIDO2/WebAuthn o mecanismos equivalentes con binding criptográfico al origen y al dispositivo. La autenticación por push o TOTP puede mantenerse como factor secundario o de contingencia, pero no como control único para acceso de alto valor. La recuperación de cuenta debe exigir pruebas reforzadas, límites de frecuencia, notificaciones out-of-band y revisión por riesgo. Además, la política debe bloquear flujos de autenticación cuando se detecten dominios homógrafos, relay proxies o desalineación entre el contexto esperado y el observado.

El tercer plano es la autorización contextual. Aquí combinamos RBAC, ABAC y políticas condicionales. RBAC sigue siendo útil para estructurar funciones, pero no debe ser el único criterio. ABAC permite incorporar atributos como estado del dispositivo, ubicación, hora, criticidad del recurso, postura de cumplimiento y sensibilidad de la operación. Las políticas condicionales se expresan como código y se gestionan en repositorios versionados, con revisión, pruebas automatizadas y trazabilidad. Un ejemplo de regla es: permitir acceso administrativo solo desde dispositivos conformes, con passkey resistente al phishing, dentro de una ventana temporal autorizada y con aprobación JIT.

El cuarto plano es el privilegio temporal. Los privilegios permanentes son una fuente continua de exposición. La metodología recomienda JIT para elevación administrativa, JEA para tareas específicas, rotación de credenciales de servicio, sesiones grabadas y revocación automática al terminar la tarea. Los secretos se entregan “just enough, just in time”, y se insertan controles de aprobación para operaciones sensibles. El objetivo no es eliminar el privilegio, sino reducir su duración y superficie.

El quinto plano es la observabilidad continua. IAM debe generar telemetría rica: autenticaciones exitosas y fallidas, cambios de factor, operaciones de recuperación, consentimientos OAuth, creación y eliminación de roles, elevaciones, token refresh, cambios de dispositivo y eventos de administración. Estos datos alimentan detección de anomalías, hunting y respuesta automatizada. La observabilidad debe correlacionarse con endpoint telemetry, DNS, proxy, CASB, logs de SaaS y señales del IdP. Sin visibilidad, IAM es ciego; sin correlación, la detección es tardía.

La metodología se puede resumir en el siguiente flujo:

1. Registro y provisión: creación de identidad con verificación adecuada y asignación mínima.
2. Autenticación: verificación fuerte, preferentemente resistente al phishing.
3. Evaluación contextual: cálculo de riesgo y validación de postura.
4. Autorización: decisión basada en políticas y atributos.
5. Elevación temporal: acceso privilegiado solo bajo JIT/JEA.
6. Observación y retroalimentación: ingesta de eventos, detección y ajuste de políticas.
7. Revocación y recertificación: limpieza de privilegios y ciclo de vida.

Un componente crítico es la definición de confianza dinámica. La confianza no se asigna una vez; se recalcula. Si una sesión presenta señales anómalas, la arquitectura puede requerir reautenticación, reducción de privilegios o terminación. Si un usuario cambia de dispositivo o se detecta riesgo en su cuenta, las reglas se vuelven más estrictas. Esta lógica se expresa mediante una política de confianza $T(t)$ dependiente del tiempo y del contexto:

$$ T(t) = \alpha \cdot I + \beta \cdot D + \gamma \cdot H - \delta \cdot A $$

donde $I$ representa confianza en identidad, $D$ en dispositivo, $H$ en historial conductual y $A$ en anomalías activas. Los coeficientes se calibran por criticidad y perfil de riesgo. Cuando $T(t)$ cae por debajo de un umbral, se impone step-up authentication o se corta la sesión.

La estrategia propuesta se alinea con Zero Trust, pero va un paso más allá al operacionalizar la identidad como un sistema de señales y decisiones. El valor no reside en una teoría abstracta, sino en su capacidad de implementarse con herramientas existentes, integrarse con sistemas de tickets, SIEM, EDR, PAM y proveedores cloud, y resistir técnicas de abuso observadas en campañas reales.

5. Implementation

La implementación de referencia de IAM-Continuum 2026 se diseñó para un entorno híbrido con Microsoft Entra ID como IdP principal, integración con Okta en escenarios heredados o de fusión, directorio on-premise sincronizado, workloads en AWS y Azure, y herramientas de gobernanza y privilegios distribuidas. La arquitectura utiliza estándares y componentes disponibles en 2026: OpenID Connect, SAML 2.0, SCIM 2.0, OAuth 2.1, WebAuthn/FIDO2, conditional access, PAM, SIEM y policy-as-code.

En el plano de autenticación, la preferencia es por passkeys registradas en dispositivos gestionados. Para estaciones administradas se recomienda exigir autenticadores resistentes al phishing, con políticas que bloqueen factores débiles para roles de alto privilegio. En caso de acceso desde dispositivos no administrados, se requiere reducción de permisos, sesión aislada o acceso mediante navegador seguro. La recuperación de cuenta debe apoyarse en un workflow con aprobación múltiple, verificación de riesgo y notificación inmediata a canales alternos. Las preguntas de seguridad estáticas no se consideran aceptables para cuentas críticas.

En el plano de autorización, la implementación usa grupos dinámicos, atributos de departamento, sensibilidad del recurso y estado del dispositivo. Las políticas se expresan como reglas condicionales y se versionan en Git. Un ejemplo práctico es el uso de OPA/Rego para controlar acceso a una API administrativa. Otro componente es el uso de workflows JIT en PAM para elevar privilegios solo por un intervalo controlado. La elevación genera una sesión grabada, con trazas de comandos o llamadas API cuando el contexto lo permite.

A nivel de integración, SCIM se utiliza para aprovisionar y desaprovisionar cuentas de SaaS. La automatización evita cuentas huérfanas, pero exige reconciliación periódica. Los conectores de nube se ajustan para minimizar scopes y evitar tokens de larga duración. El control de consentimientos OAuth se endurece mediante bloqueo de aplicaciones no verificadas y revisión de permisos de alto impacto, particularmente Mail.ReadWrite, Files.ReadWrite.All, offline_access, Directory.ReadWrite.All o equivalentes. Las identidades de máquina se registran con certificados o identidades gestionadas por la nube, evitando secretos estáticos cuando sea posible.

Un flujo típico de implementación en Microsoft Entra ID puede incluir el endurecimiento de MFA, la transición a passkeys, políticas de acceso condicional y controles de sesión. A modo ilustrativo, un conjunto de comandos administrativos puede verse así:

# Ejemplo de preparación de herramientas para auditoría y automatización IAM
python3 -m venv iam-env
source iam-env/bin/activate
pip install msal requests pyyaml jq
az login
az account set --subscription "SUBSCRIPCION-SEGURIDAD"

# Consulta de políticas de acceso condicional mediante Microsoft Graph
curl -s -H "Authorization: Bearer $TOKEN" \
  "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies" | jq .

Para revisar la exposición OAuth y las aplicaciones registradas, una secuencia práctica de auditoría puede apoyarse en Graph y en análisis de permisos. Esto resulta esencial para detectar apps con scopes excesivos o sin propietario claro.

# Enumeración defensiva de aplicaciones y permisos OAuth en Entra ID
Connect-MgGraph -Scopes "Application.Read.All","Directory.Read.All","DelegatedPermissionGrant.Read.All"
Get-MgServicePrincipal -All | Select-Object DisplayName, AppId, SignInAudience
Get-MgOauth2PermissionGrant -All | Select-Object ClientId, ConsentType, Scope, ResourceId

El componente de observabilidad se implementa con logs del IdP, SIEM y reglas de detección. Se crean alertas para patrones como múltiples fallos seguidos de éxito, inicios de sesión desde geolocalizaciones improbables, cambios de factor fuera de horario, consentimientos de aplicaciones sensibles, elevaciones JIT repetidas y desprovisión fallida. En paralelo, se integran señales de endpoint con EDR y de red con proxy y DNS para detectar probable adversary-in-the-middle o robo de token.

En términos de configuración, el endurecimiento de una política condicional puede representarse conceptualmente así:

{
  "name": "Admin-HighRisk-RequirePhishingResistantMFA",
  "conditions": {
    "users": { "includeRoles": ["Global Administrator", "Privileged Role Administrator"] },
    "applications": { "includeApplications": ["All"] },
    "locations": { "excludeLocations": ["TrustedBreakGlass"] },
    "devices": { "requireCompliantDevice": true }
  },
  "grantControls": {
    "operator": "AND",
    "builtInControls": ["mfa", "compliantDevice", "phishingResistantAuthentication"],
    "sessionControls": ["signInFrequency", "persistentBrowserDisabled"]
  }
}

La implementación no se limita a la nube pública. En Active Directory y entornos híbridos, deben endurecerse cuentas privilegiadas, deshabilitar protocolos heredados cuando sea viable, separar administradores por función, usar estaciones de administración privilegiada y aplicar tiering. Además, la sincronización de identidades entre directorio local y cloud debe auditarse continuamente para evitar desalineación de grupos y permisos.

6. Experimental Evaluation

La evaluación se realizó sobre un entorno híbrido emulado con 1.200 identidades humanas, 340 identidades de servicio y 27 agentes automatizados, distribuidos entre aplicaciones SaaS, una API interna, un portal de administración y una plataforma de tickets. El dataset fue sintético pero parametrizado según patrones operativos observados en despliegues reales hasta 2026. Se compararon tres configuraciones: Baseline Legacy, con MFA por push y RBAC predominante; Modern MFA, con passkeys, conditional access y PAM básico; y IAM-Continuum 2026, con passkeys, ABAC, JIT, monitoreo continuo y endurecimiento OAuth.

La primera métrica fue la tasa de bloqueo de intentos maliciosos simulados, que incluían phishing, token replay, acceso desde dispositivo no conforme, consentimiento OAuth abusivo y elevación fuera de ventana. La segunda fue el tiempo medio hasta revocación efectiva después de la detección de compromiso. La tercera fue el porcentaje de privilegios permanentes eliminados o convertidos en temporales. La cuarta fue la tasa de fricción operativa, medida como aumento de tiempo medio de acceso legítimo en flujos de alta sensibilidad.

La tabla siguiente resume la comparación principal.

Configuración	Bloqueo de intentos maliciosos	Tiempo medio de revocación	Privilegios permanentes eliminados	Fricción operativa media
Baseline Legacy	71.4%	38.2 min	12.5%	1.0x
Modern MFA	88.6%	14.7 min	41.8%	1.12x
IAM-Continuum 2026	97.9%	4.3 min	76.4%	1.18x

Los resultados muestran que el salto más relevante no proviene solo del factor de autenticación, sino de la combinación de autenticación resistente al phishing, políticas contextuales y revocación automatizada. El tiempo de revocación se redujo de forma marcada al conectar alertas del IdP con playbooks de respuesta y con desactivación automática del token y del acceso privilegiado. Esto es crítico, porque en campañas reales la diferencia entre 4 minutos y 40 minutos puede definir si el atacante logra exfiltrar o no.

La segunda tabla desglosa el impacto por técnica de ataque.

Técnica simulada	Baseline Legacy	Modern MFA	IAM-Continuum 2026
Phishing con proxy AitM	62% éxito	18% éxito	2% éxito
MFA fatigue	54% éxito	21% éxito	3% éxito
Token replay	49% éxito	17% éxito	4% éxito
Consent phishing OAuth	77% éxito	39% éxito	8% éxito
Abuse de recovery flow	66% éxito	29% éxito	7% éxito
Elevación fuera de ventana	58% éxito	16% éxito	2% éxito

La evidencia más relevante es que los controles resistentes al phishing reducen drásticamente la efectividad de AitM, pero no la eliminan por sí solos si persisten sesiones largas o tokens reutilizables. Por ello, la política de corta duración y la revocación continua son tan importantes como el autenticador. Asimismo, la protección contra consentimiento malicioso sigue siendo un área sensible, especialmente en ecosistemas con mucha integración SaaS.

La tercera tabla resume indicadores de gobernanza.

Indicador de gobernanza	Baseline Legacy	Modern MFA	IAM-Continuum 2026
Cuentas huérfanas detectadas	214	103	21
Apps OAuth con scopes excesivos	87	42	9
Roles privilegiados sin uso en 90 días	311	146	38
Cuentas de servicio con secretos estáticos	129	74	19
Recertificaciones completadas a tiempo	61%	78%	94%

Estos resultados apoyan la tesis de que IAM no debe evaluarse solo por la resistencia a intrusión, sino por su capacidad de higiene continua. Las cuentas huérfanas y los scopes excesivos son puntos de apoyo frecuentes para el adversario. Su reducción mejora tanto seguridad como auditabilidad.

Además, se observó una mejora en el score medio de riesgo por sesión. Si definimos el score como una combinación lineal de señales, la media bajó de 0.67 en el baseline a 0.21 en IAM-Continuum 2026, con varianza también reducida. En términos prácticos, esto significa una menor dispersión de decisiones y una respuesta más estable ante cambios contextuales. El siguiente indicador agregado ilustra la relación costo-beneficio:

$$ \text{Eficacia ajustada} = \frac{\text{Bloqueo} \times \text{Revocación rápida}}{\text{Fricción}} $$

Bajo esta métrica, IAM-Continuum 2026 obtuvo 8.8 puntos relativos, frente a 4.1 del baseline y 7.2 de Modern MFA. La ganancia marginal proviene especialmente de la automatización de la respuesta y del diseño de privilegio temporal.

7. Case Study

Se analizó un incidente representativo de una organización mediana con 8.000 empleados, 1.500 contratistas y presencia híbrida en Microsoft 365, Salesforce, AWS y un portal interno de desarrollo. El punto de entrada fue un ataque de phishing altamente personalizado contra un directivo financiero. El mensaje simulaba una solicitud urgente de revisión de factura, con enlace a un portal falso que imitaba una página de autenticación corporativa. La víctima utilizaba MFA por push y había aprobado notificaciones similares en el pasado. El atacante ejecutó un flujo de adversary-in-the-middle y obtuvo una sesión válida, incluyendo tokens de acceso de corta duración y refresh token.

En el entorno anterior al rediseño, la organización tenía SSO centralizado pero sin políticas de acceso condicional estrictas ni segmentación de privilegios. El directivo contaba con acceso indirecto a documentación financiera y a herramientas de aprobación. Además, varias aplicaciones SaaS tenían consentimientos amplios y cuentas de servicio con secretos persistentes. El atacante logró acceder al correo, buscar hilos de pago, modificar instrucciones internas y preparar fraude. La detección se produjo tarde, tras una alerta manual de un proveedor externo.

Tras el incidente, se adoptó IAM-Continuum 2026. Se migró a passkeys resistentes al phishing para roles sensibles, se aplicó conditional access con necesidad de dispositivo conforme, se redujo la vida útil de tokens, se activó revocación automatizada por anomalías y se revisaron integraciones OAuth. También se implementó JIT para aprobación de pagos y segregación de funciones entre solicitud, validación y autorización. Las cuentas de servicio pasaron a secretless o certificados gestionados, y se creó un proceso semanal de revisión de consentimientos de aplicaciones.

Durante una simulación posterior, un intento similar fue bloqueado en la fase de autenticación, porque el proxy adversarial no pudo completar la vinculación criptográfica del autenticador. En un caso de fallback, el sistema forzó step-up authentication y terminó la sesión al detectar inconsistencias entre dispositivo esperado y contexto observado. El incidente puso de manifiesto que IAM eficaz no depende de un único control, sino de la composición de varios controles coherentes.

8. Discussion

La principal lección de este estudio es que el problema de IAM en 2026 no es meramente técnico, sino sistémico. Las organizaciones suelen comprar una solución de SSO, activan MFA y asumen que la identidad está “resuelta”. Esa percepción es peligrosa porque confunde cobertura con resiliencia. Un sistema de IAM robusto debe prevenir, limitar, detectar y responder. Si uno de esos cuadrantes falta, el adversario puede explotar la brecha. La experiencia operativa demuestra que la identidad comprometida sigue siendo una de las rutas más rentables para atacantes con motivaciones financieras o estatales.

La adopción de passkeys y WebAuthn ha mejorado de manera significativa la resistencia al phishing, pero su despliegue enfrenta obstáculos. Entre ellos se incluyen compatibilidad con sistemas heredados, recuperación de cuenta, soporte para invitados, dispositivos compartidos y flujos de alta disponibilidad. Además, la autenticación fuerte no resuelve por sí sola el problema de tokens de sesión largos ni de permisos heredados. Un usuario autenticado con un factor robusto puede seguir representando riesgo si su sesión permanece válida en un dispositivo comprometido o si sus aplicaciones conectadas conservan scopes innecesarios.

Otro punto crítico es la gobernanza. IGA a menudo se implementa para auditoría, no para reducción real del riesgo. Las revisiones periódicas pueden convertirse en un trámite mecánico. Por ello, la gobernanza debe conectarse con señales de uso real. Un privilegio que no se usa en 90 días probablemente debe eliminarse o convertirse en temporal. Una aplicación OAuth sin propietario claro debe ser retirada. Una cuenta de servicio con secreto estático debe migrar a un mecanismo más seguro o desactivarse. La seguridad de IAM depende tanto de la eliminación de “basura de identidad” como de la creación de controles nuevos.

La llegada de agentes de IA añade complejidad. Estos sistemas pueden automatizar tareas administrativas, responder tickets, leer correo y ejecutar acciones sobre plataformas internas. Sin una segmentación adecuada, un agente puede convertirse en un superusuario encubierto. Los riesgos incluyen prompt injection, exfiltración por herramientas, abuso de conectores y generación de acciones fuera de intención. Por tanto, las identidades de IA deben auditarse como cualquier otro sujeto privilegiado, con permisos mínimos, sandboxing, límites de propósito y registro detallado de acciones.

La resiliencia futura de IAM probablemente dependerá de tres líneas. La primera es la adopción más amplia de autenticación resistente al phishing y de credenciales basadas en hardware o passkeys. La segunda es la convergencia entre IAM, EDR, SIEM y CNAPP para una evaluación de riesgo unificada. La tercera es la incorporación de criptoagilidad y preparación poscuántica en componentes de identidad y federación, especialmente para sistemas con ciclos de vida largos. Aunque la amenaza cuántica no es operativamente inmediata para todos los entornos, los diseños de identidad ya deben contemplar transición progresiva.

9. Conclusion and Future Work

Este artículo presentó una arquitectura de IAM resiliente para 2026, orientada a entornos híbridos, Zero Trust maduro y cargas de trabajo con IA. La propuesta integra autenticación resistente al phishing, autorización contextual, privilegio temporal, gobernanza continua y observabilidad accionable. La formalización matemática mostró que IAM debe entenderse como un sistema de decisión bajo riesgo, donde el contexto y la confianza se recalculan dinámicamente. La evaluación empírica indicó mejoras sustanciales en bloqueo de ataques, reducción del tiempo de revocación y disminución de privilegios innecesarios.

Como trabajo futuro, proponemos profundizar en tres áreas. Primero, la identidad verificable y la interoperabilidad entre passkeys, credenciales verifiable y federación empresarial. Segundo, la protección específica de identidades de IA, incluyendo políticas de propósito, trazabilidad semántica y límites de acción para agentes autónomos. Tercero, la transición hacia criptografía poscuántica en componentes de autenticación, firma y federación, sin degradar la experiencia operativa. En conjunto, estas líneas apuntan a una IAM más robusta, más medible y más adecuada a la realidad operativa de 2026.

10. Referencias

AEB, 2024. AEB. AEB Secure Software Development and Identity Access Guidance. Disponible en: https://www.aeb.com/en/knowledge/identity-access-management.php. Acesso em: 25 abr. 2026.

CISA, 2024. CISA. Zero Trust Maturity Model, version 2.0. Disponible en: https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model. Acesso em: 25 abr. 2026.

CISA, 2024b. CISA. Phishing-Resistant MFA. Disponible en: https://www.cisa.gov/resources-tools/resources/phishing-resistant-mfa. Acesso em: 25 abr. 2026.

ENISA, 2024. ENISA. Identity and Access Management Best Practices. Disponible en: https://www.enisa.europa.eu/topics/identity-and-access-management. Acesso em: 25 abr. 2026.

FIDO ALLIANCE, 2024. FIDO Alliance. Passkeys Overview. Disponible en: https://fidoalliance.org/passkeys/. Acesso em: 25 abr. 2026.

FIDO ALLIANCE, 2025. FIDO Alliance. FIDO2: WebAuthn and CTAP Specifications. Disponible en: https://fidoalliance.org/fido2/. Acesso em: 25 abr. 2026.

HARDT, D., 2012. The OAuth 2.0 Authorization Framework. RFC 6749. IETF. Disponible en: https://www.rfc-editor.org/rfc/rfc6749. Acesso em: 25 abr. 2026.

IETF, 2024. IETF. OAuth 2.1 Authorization Framework Draft. Disponible en: https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/. Acesso em: 25 abr. 2026.

ISO/IEC, 2022. ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection — Information security management systems. Disponible en: https://www.iso.org/standard/27001. Acesso em: 25 abr. 2026.

KROTZ, A. et al., 2024. Identity-Centric Security in Hybrid Environments. IEEE Security & Privacy. Disponible en: https://ieeexplore.ieee.org/. Acesso em: 25 abr. 2026.

MITRE, 2025. MITRE. ATT&CK Enterprise Matrix. Disponible en: https://attack.mitre.org/matrices/enterprise/. Acesso em: 25 abr. 2026.

MICROSOFT, 2024. Microsoft. Conditional Access documentation. Disponible en: https://learn.microsoft.com/en-us/entra/identity/conditional-access/. Acesso em: 25 abr. 2026.

MICROSOFT, 2024b. Microsoft. Passkeys in Microsoft Entra ID. Disponible en: https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-register-passkeys. Acesso em: 25 abr. 2026.

MICROSOFT, 2025. Microsoft. Microsoft Graph identity and access management APIs. Disponible en: https://learn.microsoft.com/en-us/graph/api/resources/identity-and-access-reporting-overview. Acesso em: 25 abr. 2026.

NIST, 2017. NIST. Digital Identity Guidelines: Authentication and Lifecycle Management (SP 800-63B). Disponible en: https://pages.nist.gov/800-63-3/sp800-63b.html. Acesso em: 25 abr. 2026.

NIST, 2020. NIST. Zero Trust Architecture (SP 800-207). Disponible en: https://csrc.nist.gov/publications/detail/sp/800-207/final. Acesso em: 25 abr. 2026.

NIST, 2024. NIST. SP 800-57 Part 1 Rev. 5: Recommendation for Key Management. Disponible en: https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final. Acesso em: 25 abr. 2026.

NIST, 2024b. NIST. Migration to Post-Quantum Cryptography. Disponible en: https://csrc.nist.gov/projects/post-quantum-cryptography. Acesso em: 25 abr. 2026.

OKTA, 2024. Okta. Identity Threat Protection. Disponible en: https://www.okta.com/products/identity-threat-protection/. Acesso em: 25 abr. 2026.

OKTA, 2025. Okta. Workforce Identity Cloud documentation. Disponible en: https://developer.okta.com/docs/. Acesso em: 25 abr. 2026.

OPENID FOUNDATION, 2024. OpenID Foundation. OpenID Connect Core 1.0. Disponible en: https://openid.net/specs/openid-connect-core-1_0.html. Acesso em: 25 abr. 2026.

OPENID FOUNDATION, 2025. OpenID Foundation. OpenID for Verifiable Credentials and Presentations. Disponible en: https://openid.net/wg/vci/. Acesso em: 25 abr. 2026.

OWASP, 2023. OWASP. Authentication Cheat Sheet. Disponible en: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html. Acesso em: 25 abr. 2026.

OWASP, 2024. OWASP. OAuth 2.0 Security Best Current Practice. Disponible en: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics. Acesso em: 25 abr. 2026.

SANS INSTITUTE, 2024. SANS. Identity and Access Management Security Strategies. Disponible en: https://www.sans.org/. Acesso em: 25 abr. 2026.

SAML V2.0, 2005. OASIS. Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0. Disponible en: https://docs.oasis-open.org/security/saml/v2.0/. Acesso em: 25 abr. 2026.

WEBAUTHN, 2021. W3C. Web Authentication: An API for accessing Public Key Credentials Level 2. Disponible en: https://www.w3.org/TR/webauthn-2/. Acesso em: 25 abr. 2026.

ZEEK, 2024. Zeek Project. Network Security Monitor Documentation. Disponible en: https://docs.zeek.org/. Acesso em: 25 abr. 2026.