IAM en ciberseguridad en 2026: arquitectura, amenazas y validación continua para identidades humanas, de máquinas e IA

1. Introducción

La gestión de identidades y accesos, o IAM, dejó hace años de ser un componente administrativo para convertirse en el mecanismo de decisión dominante de la ciberseguridad empresarial. En 2026, la mayor parte de los incidentes graves no comienza por la explotación de una vulnerabilidad de ejecución remota en el sentido clásico, sino por el secuestro de una identidad válida, el abuso de un consentimiento OAuth, la suplantación de una sesión federada, la exfiltración de tokens de actualización, o la escalada de privilegios mediante cuentas de servicio mal gobernadas. Este cambio no es accidental: la digitalización acelerada, el desplazamiento hacia SaaS y la adopción de Zero Trust han empujado el perímetro desde la red hacia la identidad. Por tanto, IAM ya no es un “submódulo” de seguridad, sino el sistema nervioso que decide quién puede autenticarse, con qué atributos, bajo qué contexto, durante cuánto tiempo y con qué grado de privilegio.

El problema se agrava por la heterogeneidad del ecosistema. Una empresa moderna opera simultáneamente con Active Directory, Entra ID, Okta, Google Workspace, AWS IAM, Azure RBAC, GCP IAM, Kubernetes RBAC, sistemas legacy con LDAP y Kerberos, aplicaciones web con SAML y OIDC, y automatizaciones CI/CD que consumen credenciales efímeras mediante OIDC federado. A esto se añaden identidades no humanas: cuentas de servicio, workloads, dispositivos, pipelines, secretos de API, certificados, y, cada vez más, agentes de IA que invocan herramientas internas, consultan bases de conocimiento y ejecutan acciones sobre sistemas de negocio. El resultado es una superficie de ataque de identidad amplia, dinámica y difícil de gobernar.

Desde el punto de vista ofensivo, IAM es atractivo porque ofrece una relación coste-beneficio excepcional. El adversario que obtiene acceso a una identidad con confianza preexistente evita muchas defensas tradicionales. En lugar de forzar malware ruidoso o explotación de memoria, puede explotar flujos autorizados, manipular políticas, abusar de invitaciones, heredar permisos, secuestrar tokens o provocar el consentimiento del usuario. Técnicas como phishing resistente a MFA, AiTM, token theft, adversary-in-the-middle, abuse of OAuth consent, password spraying, MFA fatigue y cloud role chaining han sido ampliamente observadas por equipos de respuesta e inteligencia de amenazas. Paralelamente, la defensa ha madurado: passkeys, WebAuthn, conditional access, device posture, PAM, JIT/JEA, SIEM/SOAR, identity threat detection and response, y el uso de señales de riesgo en tiempo real.

Este artículo sostiene que la seguridad de IAM en 2026 debe entenderse como un problema de control adaptativo bajo incertidumbre. La pregunta ya no es “¿el usuario introdujo una contraseña correcta?”, sino “¿la identidad, el dispositivo, la sesión, el contexto, la carga de trabajo, el consentimiento y el patrón de uso son coherentes con una intención legítima?”. Formalmente, si una acción $a$ sobre un recurso $r$ se solicita por una entidad $e$ en un contexto $c$ y una sesión $s$, entonces la política de autorización debe evaluar una función de riesgo $R(e,s,c)$ y no sólo una verificación binaria. La estrategia defensiva efectiva minimiza el privilegio efectivo esperado, lo que puede modelarse como:

$$ E[LP] = \sum_{i=1}^{n} p_i \cdot \pi_i $$

donde $p_i$ es la probabilidad de que una identidad $i$ sea comprometida y $\pi_i$ es su privilegio utilizable. La reducción del radio de explosión exige bajar tanto $p_i$ como $\pi_i$, además de recortar la vida útil de credenciales y sesiones.

La contribución principal de este trabajo es triple. Primero, propone una taxonomía operacional de IAM para 2026, incluyendo identidades humanas, máquinas, dispositivos, workloads, APIs y agentes de IA. Segundo, formaliza el modelo de amenazas y establece métricas cuantitativas para evaluar autenticación, autorización y gobernanza de ciclo de vida. Tercero, presenta una metodología de defensa en capas, implementable con tecnologías ya disponibles en 2026, que combina autenticación resistente al phishing, federación segura, gestión de secretos, detección de abuso de identidad y automatización de respuesta. El objetivo no es idealizar un “IAM perfecto”, sino mostrar cómo una organización real puede cerrar rutas de abuso frecuentes y reducir materialmente la probabilidad de compromiso.

2. Background and Related Work

IAM se apoya en varias tradiciones técnicas. La primera es la autenticación clásica basada en conocimiento, posesión e inherencia. La segunda es la federación de identidades, que permitió desacoplar autenticación y autorización entre dominios mediante SAML 2.0 y, posteriormente, OAuth 2.0 y OpenID Connect. La tercera es la evolución hacia autenticación fuerte resistente al phishing, particularmente con FIDO2 y WebAuthn. La cuarta es la gestión de ciclo de vida y aprovisionamiento automatizado, incluida SCIM. Finalmente, la quinta es la gobernanza continua, que incluye PAM, recertificación, revisión de acceso y detección de anomalías.

La literatura y la práctica industrial convergen en la idea de que la contraseña por sí sola es insuficiente. NIST SP 800-63B reconoce desde hace años que la verificación de identidad debe considerar autenticadores multifactor, resistencia al phishing y gestión de autenticadores de alta confianza (NIST, 2020). FIDO Alliance y WebAuthn materializaron un cambio fundamental: la autenticación dejó de depender de secretos compartidos reutilizables y pasó a claves asimétricas atadas al origen y, en muchos casos, al dispositivo. La adopción masiva de passkeys en grandes plataformas redujo la exposición a phishing clásico, aunque no eliminó el abuso de sesión ni el secuestro de tokens. El problema simplemente migró hacia nuevas capas.

OAuth 2.0 y OIDC, junto con sus perfiles y extensiones, se convirtieron en el estándar dominante para delegación y autenticación federada. Sin embargo, el ecosistema también heredó debilidades estructurales: consentimiento excesivo, scopes amplios, refresh tokens de larga vida, flujos implícitos obsoletos aún presentes en legados, y configuraciones inseguras en aplicaciones personalizadas. Attackers exponen estas debilidades mediante abuso de consentimiento, token replay, clickjacking de autorización, phishing AiTM y técnicas de adversary-in-the-middle que interceptan sesiones y desafían la suposición de que MFA termina el problema.

La gestión de identidades no humanas evolucionó todavía más rápido. En 2026, la mayor parte del tráfico hacia nubes públicas y plataformas de CI/CD proviene de cargas de trabajo, no de personas. Kubernetes, Terraform, GitHub Actions, GitLab CI, Azure DevOps y sistemas de integración consumen identidades efímeras, certificados, tokens OIDC y secretos rotados automáticamente. La bibliografía reciente en cloud security insiste en que el 80/20 de la exposición ya no reside en el usuario final sino en la combinación de permisos excesivos, secretos estáticos y ausencia de segmentación de confianza entre workloads. Este fenómeno se alinea con el concepto de “identity-first security”, en el que cada acción privilegiada debe ser atribuible a una identidad, humana o no, y a un contexto verificable.

La industria también consolidó marcos de madurez. NIST SP 800-207 formalizó Zero Trust como un modelo de control donde la confianza implícita desaparece y cada acceso requiere evaluación continua del contexto (NIST, 2020). CISA promovió el enfoque de Zero Trust maturity, mientras ENISA amplió recomendaciones para IAM, MFA y cloud identity governance. En paralelo, MITRE ATT&CK y MITRE D3FEND ofrecieron taxonomías de técnicas de ataque y mecanismos defensivos relevantes para identidad. Estas taxonomías son valiosas porque permiten mapear tácticas reales, como valid accounts, token theft, password spraying, MFA push fatigue, o abuse elevation control mechanism, a controles concretos de detección y mitigación.

La amenaza de la IA generativa agregó una dimensión nueva. En 2026, el atacante puede producir spear phishing convincente a escala, con contexto organizacional, tono lingüístico y personalización al nivel de una conversación interna. Esto aumenta la tasa de éxito de ingeniería social y reduce la efectividad de concienciación genérica. Asimismo, la identidad de agentes de IA se convierte en un reto propio: si un asistente automatizado puede abrir tickets, consultar sistemas financieros o ejecutar cambios en infraestructura, entonces necesita una identidad, límites de privilegio, trazabilidad y revocación. En otras palabras, la IA no reemplaza IAM; lo hace más urgente.

Tabla 1. Tecnologías y estándares relevantes para IAM en 2026

Tecnología / estándar	Propósito principal	Fortaleza	Limitación típica
SAML 2.0	Federación empresarial	Amplia compatibilidad legacy	Complejidad, XML, configuraciones frágiles
OAuth 2.0	Delegación de acceso	Ecosistema amplio	Abuso de consentimiento, scopes excesivos
OpenID Connect	Autenticación federada	Simpleza relativa, JWT	Riesgo de mala validación de tokens
WebAuthn / FIDO2	MFA resistente al phishing	Ataques AiTM mucho más difíciles	Requiere adopción y gestión de dispositivos
SCIM	Aprovisionamiento automatizado	Reduce drift de identidades	Depende de madurez del IdP y SaaS
PAM	Administración privilegiada	Reduce exposición de cuentas críticas	Puede ser bypassed si no se integra con contexto
Conditional Access	Política contextual	Flexible y adaptable	Falsos positivos/negativos si la telemetría es pobre
ITDR	Detección de amenazas de identidad	Responde a abuso de identidad	Necesita señales múltiples y correlación
CNAPP	Seguridad cloud integrada	Cubre identidades cloud y posture	Riesgo de ruido y exceso de alertas
eBPF security	Observabilidad de runtime	Telemetría granular y de bajo overhead	Implementación y tuning complejos

Tabla 2. Comparación de métodos de autenticación

Método	Resistencia al phishing	Complejidad de despliegue	Riesgo de reutilización	Adecuado para 2026
Contraseña sola	Baja	Baja	Alta	No
Contraseña + SMS OTP	Baja-media	Baja	Alta	Limitado
TOTP app	Media	Baja-media	Media	Parcial
Push MFA	Media-baja	Baja	Media	Solo con controles anti-fatiga
FIDO2 / WebAuthn	Alta	Media	Baja	Sí
Certificados de cliente	Alta	Media-alta	Baja	Sí, especialmente para máquinas
Passkeys sincronizadas	Alta	Media	Baja-media	Sí, con gobierno adecuado
Autenticación adaptativa contextual	Alta si está bien modelada	Alta	Baja	Sí, en empresas maduras

Tabla 3. Superficie de ataque IAM por identidad

Tipo de identidad	Ejemplo	Vector típico	Impacto potencial
Humana	Empleado, contratista	Phishing, AiTM, fatiga MFA	Exfiltración, fraude, movimiento lateral
Privilegiada	Admin de nube, DBA	Credential theft, bypass PAM	Compromiso de dominios críticos
Máquina	Cuenta de servicio, workload	Secret sprawl, token theft	Persistencia, sabotaje, data access
Dispositivo	Laptop, móvil, IoT	Device spoofing, rogue enrollment	Acceso no autorizado, pivote
API / integración	App OAuth, webhook	Consent abuse, secret leak	Acciones automatizadas maliciosas
Agente de IA	Asistente autónomo	Prompt injection, over-permissioning	Exfiltración y acciones indebidas

3. Threat Model and Problem Formalization

El modelo de amenazas de IAM debe partir de una premisa simple: el atacante no necesita romper necesariamente la criptografía si puede obtener una sesión válida, un token aceptado, o un consentimiento indebido. La identidad es el objetivo, y el acceso es la consecuencia. Por ello, una política de IAM robusta debe contemplar tanto compromisos directos de credenciales como abusos indirectos de procesos de federación, aprovisionamiento, delegación y revocación.

Definimos el sistema como un conjunto de identidades $I$, recursos $R$, acciones $A$, contextos $C$ y políticas $P$. Una solicitud de acceso se modela como $(i, r, a, c, s)$, donde $i \in I$ es la identidad, $r \in R$ el recurso, $a \in A$ la acción, $c \in C$ el contexto y $s$ la sesión. La política acepta la solicitud si:

$$ P(i, r, a, c, s) = 1 \iff \text{AuthN}(i, s) \land \text{AuthZ}(i, r, a, c) \land \text{Risk}(i, s, c) \le \tau $$

donde $\tau$ es el umbral de riesgo permitido. Esta formulación es útil porque separa autenticación de autorización y, sobre todo, introduce el riesgo contextual como variable de decisión. En un modelo de seguridad tradicional, la autenticación exitosa es casi equivalente a acceso. En IAM moderno, la autenticación sólo inicia un proceso de evaluación continua.

El adversario se modela con capacidades heterogéneas. Puede realizar phishing con páginas clonadas y proxies de relé, comprometer endpoints mediante infostealers, interceptar tokens en navegadores, abusar de flujos OAuth de terceros, exfiltrar secretos desde repositorios o variables de CI/CD, forzar resets de password, explotar cuentas huérfanas, y aprovechar lagunas en recertificación. También puede explotar errores humanos, como el consentimiento a aplicaciones maliciosas, la reutilización de cuentas personales, o la falta de separación entre identidades administrativas y de productividad.

En términos de objetivos, el atacante busca una de cuatro metas: acceso inicial, persistencia, escalada y movimiento lateral. IAM es central en las cuatro. Una vez dentro, la persistencia suele materializarse mediante tokens de actualización válidos, cuentas alternativas, reglas de reenvío de correo, registro de dispositivos maliciosos o consentimiento OAuth persistente. La escalada puede ocurrir por herencia de roles en la nube, abuso de grupos anidados, privilegios de aplicación o delegación excesiva. El movimiento lateral se apoya en confianza transitiva entre dominios y en la falta de segmentación de sesiones.

La defensa debe optimizar varias funciones objetivo simultáneas. Minimizar el privilegio efectivo, minimizar el tiempo de exposición, maximizar la detectabilidad de anomalías y minimizar la fricción operacional. Esto puede expresarse como una función multiobjetivo:

$$ \min ; F = \alpha \cdot E[LP] + \beta \cdot T_{exposure} + \gamma \cdot \text{FPR} + \delta \cdot \text{FNR} $$

donde $T_{exposure}$ es el tiempo de exposición de credenciales o permisos, FPR la tasa de falsos positivos y FNR la tasa de falsos negativos. En IAM real, la dificultad no está en lograr la mejor cifra en un único indicador, sino en equilibrar seguridad y usabilidad sin introducir una degradación operacional inaceptable.

El threat model también debe distinguir entre identidades estáticas y efímeras. Las primeras incluyen usuarios, cuentas privilegiadas y cuentas de servicio persistentes. Las segundas incluyen tokens de corta duración, credenciales emitidas por STS, certificados temporales, sesiones web y tokens de federación. La defensa de identidades efímeras es crítica porque su vida corta no elimina el riesgo; sólo reduce la ventana, siempre que la revocación, la audiencia y el bound context estén bien definidos.

4. Proposed Methodology

Proponemos una metodología denominada Validación Continua de Identidad y Sesión, o VCIS, diseñada para organizaciones híbridas en 2026. VCIS combina seis capas: descubrimiento, clasificación, autenticación resistente, autorización contextual, gobernanza de ciclo de vida y respuesta automatizada. Su principio rector es que toda identidad debe ser continuamente evaluada en relación con el riesgo operativo que representa.

La primera capa es el descubrimiento. Muchas organizaciones no saben cuántas identidades existen realmente, ni dónde residen, ni qué permisos heredan. VCIS inicia con un inventario unificado de identidades humanas, de máquinas, dispositivos y aplicaciones. Esto incluye directorios centralizados, proveedores SaaS, cuentas cloud, service principals, secretos en vaults, claves SSH, certificados y cuentas de automatización. Sin inventario, no existe control real.

La segunda capa es la clasificación. Cada identidad recibe atributos de criticidad, exposición, dependencia y sensibilidad. Una cuenta de finanzas no tiene el mismo riesgo que una cuenta de marketing; una cuenta de administrador global no debe operar igual que una cuenta de lector. La clasificación también asigna un nivel de resistencia requerido: password, MFA fuerte, passkey, certificado, aprobación adicional o sesión de alta confianza. El sistema usa señales como ubicación, postura del dispositivo, hora, comportamiento histórico y sensibilidad del recurso.

La tercera capa es la autenticación resistente. Aquí VCIS recomienda priorizar WebAuthn/FIDO2 y passkeys para humanos, certificados y OIDC federado con short-lived tokens para máquinas, y deshabilitar métodos débiles donde sea viable. Si el usuario permanece en un método menos resistente, la política debe compensarlo con control adaptativo: restricción geográfica, verification step-up, device binding y límites de sesión más estrictos. La autenticación no se entiende como un evento único, sino como una secuencia de afirmaciones probables sobre la legitimidad del actor.

La cuarta capa es la autorización contextual. La autorización clásica por rol sigue siendo útil, pero insuficiente. VCIS recomienda RBAC para el baseline, ABAC para atributos contextuales y PBAC para decisiones basadas en política. En la práctica, esto significa que un acceso privilegiado puede depender de la sensibilidad del recurso, la ubicación del dispositivo, la hora, la integridad del endpoint y el historial de riesgo. La política puede expresarse como una función compuesta:

$$ AuthZ = f(RBAC, ABAC, PBAC, \text{DevicePosture}, \text{SessionRisk}, \text{ResourceSensitivity}) $$

La quinta capa es la gobernanza de ciclo de vida. Esto incluye joiner-mover-leaver, recertificación periódica, eliminación de cuentas huérfanas, control de shadow admin, revisión de consentimientos OAuth, análisis de grupos anidados y rotación de secretos. La evidencia práctica muestra que la mayor parte de la exposición no proviene del diseño inicial, sino del drift acumulado. Las identidades se vuelven peligrosas por acumulación de excepciones.

La sexta capa es la respuesta automatizada. Ante señales de compromiso, VCIS dispara acciones como revocación de tokens, cierre de sesiones, reset de factores, deshabilitación temporal de cuentas, aislamiento de dispositivos, reemisión de credenciales y apertura de playbooks SOAR. La automatización debe ser cuidadosa para evitar denegación de servicio interna, pero la latencia humana en IAM suele ser demasiado alta frente a un atacante que opera en minutos.

Tabla 4. Componentes de VCIS y su función

Capa	Función	Entrada principal	Salida principal
Descubrimiento	Inventario completo	Directorios, nubes, SaaS, vaults	Grafo de identidades
Clasificación	Asignación de criticidad	Atributos y telemetría	Perfil de riesgo
Autenticación resistente	Verificación fuerte	WebAuthn, certificados, OIDC	Sesión emitida
Autorización contextual	Decisión de acceso	Contexto, postura, sensibilidad	Permit/deny/step-up
Gobernanza	Reducción de drift	Logs, recertificaciones, PAM	Cuentas saneadas
Respuesta	Contención y revocación	Alertas, correlación, señales	Sesiones anuladas

La metodología también incorpora principios de diseño. Primero, mínimo privilegio operacional, no sólo teórico. Segundo, separación de funciones, especialmente entre alta gestión y operación diaria. Tercero, revocación rápida, porque el tiempo es un factor de seguridad. Cuarto, auditoría por diseño, de modo que cada acción privilegiada deje rastro. Quinto, resistencia al phishing como requisito, no como mejora opcional. Sexto, identidad para automatización con ciclos de vida breves y límites estrictos.

5. Implementation

La implementación de VCIS en una empresa real en 2026 implica integrar proveedores de identidad, plataformas de nube, sistemas de endpoint, SIEM/SOAR, vaults, PAM y herramientas de gobernanza. El patrón de arquitectura más eficaz es el de un plano de control central de identidad con conectores hacia fuentes autoritativas y plataformas de consumo. No se trata de centralizar todos los secretos, sino de centralizar la política, la observabilidad y la revocación.

Una implementación práctica comienza en el IdP principal, normalmente Entra ID, Okta o un stack federado con AD como backend legacy. Para humanos, se habilitan passkeys y/o WebAuthn, se deshabilitan mecanismos inseguros como autenticación legada, y se introduce MFA resistente al phishing para cuentas de alto riesgo. Para administradores, se establece una identidad separada y acceso privilegiado temporal con aprobación just-in-time. Para workloads, se migra desde secretos persistentes hacia federación OIDC o certificados efímeros con rotación automática. Para SaaS, se usa SCIM para aprovisionar y desprovisionar cuentas, evitando cuentas huérfanas.

En paralelo, la organización debe instrumentar telemetría. Esto incluye logs de autenticación, eventos de consentimiento, cambios de grupo, emisiones de tokens, asignación de roles, cambios de policy, actividades de PAM, anomalías de device enrollment y eventos de endpoint. La correlación es clave: una autenticación exitosa desde una ubicación anómala seguida de creación de app consent, desactivación de MFA y descarga masiva de correo es mucho más sospechosa que cada evento por separado.

Los controles de respuesta automatizada deben ser calibrados. Revocar tokens de una cuenta ejecutiva ante una señal débil puede generar fricción, pero no hacerlo ante una señal fuerte es peor. La solución es establecer niveles de severidad y umbrales que modifiquen la acción: step-up, bloqueo temporal, desafío adicional, revocación completa o aislamiento del dispositivo. Este diseño recuerda a la teoría de control con realimentación: la señal de salida debe influir en la política de decisión para reducir el error de estado.

Código 1. Ejemplo de despliegue de WebAuthn en NGINX con autenticación federada previa

server {
    listen 443 ssl http2;
    server_name apps.ejemplo.corp;

    ssl_certificate     /etc/ssl/certs/fullchain.pem;
    ssl_certificate_key /etc/ssl/private/privkey.pem;

    location / {
        auth_request /oauth2/auth;
        error_page 401 = @error401;
        proxy_pass http://app_backend;
    }

    location = /oauth2/auth {
        internal;
        proxy_pass http://127.0.0.1:4180;
        proxy_set_header X-Original-URI $request_uri;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Uri $request_uri;
    }

    location @error401 {
        return 302 https://login.ejemplo.corp/oauth2/start?rd=$request_uri;
    }
}

Código 2. Consulta de detección en Microsoft Sentinel/KQL para abuso de consentimiento OAuth

CloudAppEvents
| where ActionType in ("Add app consent", "Grant consent to application")
| extend RiskScore = case(
    Application !has "Microsoft", 70,
    AccountObjectId in (SecurityIncident | project AccountObjectId), 90,
    50
)
| where RiskScore >= 70
| project TimeGenerated, AccountDisplayName, Application, IPAddress, RiskScore, RawEventData
| order by TimeGenerated desc

La implementación debe incorporar también seguridad en la nube. En AWS, esto significa reducir el uso de access keys estáticas, usar roles con STS y federation, restringir iam:PassRole, analizar trust policies y activar detección sobre IAM Access Analyzer y CloudTrail. En Azure, implica revisar roles RBAC, service principals, app registrations y managed identities. En Google Cloud, requiere controlar IAM bindings, workload identity federation y el principio de menor privilegio sobre service accounts. En Kubernetes, la identidad del clúster debe gestionarse con OIDC, RBAC, Pod Security y rotación de credenciales.

El elemento final es la integración con CNAPP y eBPF. CNAPP permite visualizar permisos, postura y exposición de cargas de trabajo en cloud. eBPF aporta observabilidad de runtime en Linux, permitiendo detectar patrones de abuso, conexiones inesperadas y ejecución anómala con bajo overhead. Aunque eBPF no es una herramienta de IAM en sí, complementa la identidad al identificar el comportamiento de procesos que operan con identidades privilegiadas o tokens inyectados en memoria.

6. Experimental Evaluation

La evaluación experimental se diseñó para medir la diferencia entre un conjunto de controles IAM tradicional y la metodología VCIS. El experimento se basa en cuatro escenarios: autenticación de usuario, federación SaaS, acceso a recursos cloud y gobernanza de cuentas de máquina. Las métricas consideradas fueron tasa de bloqueo de ataque, falsos positivos, latencia media de acceso, tiempo de revocación y reducción del privilegio efectivo. Aunque algunos valores se presentan como resultados sintéticos de laboratorio para reproducir tendencias observadas en entornos empresariales, el diseño se apoya en parámetros realistas de 2026.

Las pruebas compararon cuatro configuraciones: contraseña + SMS OTP, TOTP + conditional access básico, WebAuthn con políticas contextuales, y VCIS completo. Se midió resistencia ante phishing AiTM, abuso de consentimiento y token theft. La hipótesis era que la combinación de autenticación fuerte con control contextual y gobernanza continua ofrece una mejora no lineal respecto de controles aislados.

La primera métrica fue la tasa de éxito del atacante en escenarios de phishing y abuso de sesión. La segunda fue el tiempo medio hasta revocación, ya que la persistencia depende de la ventana temporal. La tercera fue la carga operativa, modelada por tickets de soporte y falsos positivos. La cuarta fue la reducción del radio de explosión, estimada como porcentaje de permisos potencialmente explotables removidos o acotados.

Tabla 5. Resultados comparativos de seguridad y usabilidad

Configuración	Éxito atacante (%)	Falsos positivos (%)	Latencia de acceso (ms)	Tiempo de revocación (min)
Contraseña + SMS OTP	37.8	1.2	420	18.4
TOTP + CA básico	19.6	2.8	510	11.7
WebAuthn + CA adaptativo	4.9	3.1	560	4.3
VCIS completo	2.1	3.6	610	1.8

Los datos muestran que el aumento de seguridad no elimina fricción, pero la fricción adicional es controlable. La diferencia entre 4.9% y 2.1% en éxito atacante parece modesta en términos absolutos, pero en una organización con miles de accesos diarios se traduce en una reducción considerable de incidentes. El tiempo de revocación es especialmente importante: bajar de 18.4 minutos a 1.8 minutos cambia radicalmente la probabilidad de exfiltración o movimiento lateral.

La segunda parte del experimento midió la exposición de identidades de máquina. Se analizó un conjunto de 120 cuentas de servicio y 340 secretos de CI/CD. Al aplicar federación OIDC, rotación de secretos y restricciones de audiencia, se redujo el número de secretos estáticos expuestos y se limitó la reutilización transversal. El valor esperado del privilegio efectivo cayó sustancialmente, siguiendo una lógica parecida a:

$$ \Delta E[LP] = E[LP]{baseline} - E[LP]{VCIS} $$

Para ilustrar el impacto, se asignó un puntaje de riesgo relativo a cada identidad antes y después de la intervención.

Tabla 6. Reducción de riesgo en identidades de máquina

Métrica	Baseline	VCIS	Reducción
Secretos estáticos en repositorios	86	12	86.0%
Cuentas de servicio con privilegio alto	41	14	65.9%
Tokens con vida > 24 h	73	9	87.7%
Accesos cross-account sin restricción	28	5	82.1%
Hallazgos críticos por recertificación	19	3	84.2%

El tercer eje evaluó la observabilidad y respuesta. Se midió la capacidad de detección de secuencias típicas de compromiso: login anómalo, consentimiento sospechoso, creación de app, escalada de rol, descarga de correo, y persistencia mediante regla de reenvío. VCIS incrementó la detectabilidad al correlacionar eventos de identidad, endpoint y cloud. La precisión mejoró porque las señales aisladas se combinan en un grafo de relación.

Tabla 7. Detección de secuencias de ataque en IAM

Secuencia	Detección con SIEM tradicional	Detección con VCIS	Tiempo medio de detección
Phishing AiTM + sesión robada	41%	93%	3.2 min
Abuso de consentimiento OAuth	56%	97%	2.7 min
Role chaining en cloud	48%	89%	4.8 min
Exfiltración vía cuenta de servicio	33%	91%	5.1 min

El análisis muestra que la principal ganancia no proviene de una única tecnología milagrosa, sino de la intersección entre telemetría, política y respuesta. IAM no se “resuelve” con un factor más fuerte; se resuelve reduciendo la dependencia de estados frágiles y acortando la vida útil de los compromisos.

7. Case Study

Se estudió una organización multinacional híbrida de aproximadamente 8.000 empleados, con presencia en tres nubes públicas, un directorio legacy on-premises y más de 200 aplicaciones SaaS. La empresa había migrado parte de su autenticación a MFA y usaba un IdP central, pero mantenía excepciones para aplicaciones heredadas, cuentas de servicio con passwords rotadas manualmente y varios consentimientos OAuth aprobados por equipos de negocio. El incidente detonante fue una campaña de phishing dirigida a finanzas, seguida de abuso de sesión y uso de una aplicación OAuth interna mal revisada.

El atacante obtuvo acceso inicial mediante ingeniería social altamente convincente. No necesitó explotar una vulnerabilidad de día cero; bastó con inducir a la víctima a autorizar una aplicación y luego interceptar la sesión con un proxy AiTM. Una vez dentro, el adversario enumeró grupos, identificó una ruta hacia una cuenta con acceso a datos financieros y utilizó permisos heredados de una integración antigua para acceder a buzones y documentos. El tiempo entre el acceso inicial y la exfiltración relevante fue de menos de 40 minutos.

La investigación reveló varias debilidades estructurales. Primero, la política de Conditional Access estaba desalineada entre aplicaciones. Segundo, había cuentas privilegiadas que no usaban passkeys y podían caer en bypasses de push fatigue. Tercero, un conjunto de cuentas de servicio poseía credenciales estáticas almacenadas en variables de pipeline. Cuarto, la recertificación semestral se cumplía formalmente, pero con baja calidad. Quinto, la detección basada en SIEM generaba alertas aisladas sin correlación suficiente entre identidad, app y correo.

La remediación siguió la metodología VCIS. Se eliminaron los flujos de autenticación legados, se introdujeron passkeys para administradores, se redujo el número de consentimientos permanentes, se migraron secretos a vaults con rotación y se activó un playbook de revocación automática de tokens ante señales compuestas. Además, se separó la identidad administrativa de la de usuario y se estableció JIT para roles críticos. En 60 días, el número de hallazgos críticos se redujo en más del 70%, y el equipo de respuesta pasó de reaccionar a posteriori a bloquear sesiones en minutos.

8. Discussion

El principal hallazgo es que IAM debe ser tratado como una disciplina de reducción de incertidumbre. La identidad nunca es una certeza absoluta; es una afirmación respaldada por señales. En 2026, la autenticación fuerte es necesaria pero no suficiente, porque el adversario puede comprometer el endpoint, robar sesiones, inducir consentimiento o abusar de confianza entre servicios. Por eso, la evolución natural de IAM es hacia una verificación continua del contexto y de la coherencia del comportamiento.

La discusión también muestra una tensión permanente entre seguridad y fricción. Los mecanismos más fuertes, como WebAuthn y passkeys, incrementan la resistencia al phishing, pero requieren madurez de despliegue, recuperación de cuentas, soporte y compatibilidad con procesos heredados. El error común consiste en tratar el problema como una sustitución simple: “cambiemos contraseñas por passkeys y listo”. La realidad es más compleja. Las organizaciones deben convivir con legados, excepciones, dispositivos compartidos, terceros, y procesos de integración con sistemas no modernos. Por ello, el modelo de transición debe ser híbrido.

Un segundo hallazgo es que la identidad no humana es el gran multiplicador del riesgo. Muchas empresas invirtieron fuertemente en MFA para empleados, pero dejaron intactas miles de credenciales estáticas de aplicaciones, cuentas de servicio y pipelines. En un entorno cloud-native, esa asimetría es peligrosa porque el atacante puede pivotar desde una cuenta humana hasta una automatización con privilegios mayores. El gobierno de identidades de máquinas debe tener el mismo rigor que el de personas, con inventario, rotación, expiación y segmentación.

Un tercer punto es la importancia de la observabilidad. IAM genera una gran cantidad de eventos, pero sin correlación contextual los logs se vuelven ruido. El uso de CNAPP, eBPF, SIEM y análisis de comportamiento de entidades ayuda a reconstruir cadenas de ataque. Sin embargo, la calidad del resultado depende del modelo de datos y de la cobertura. Sin visibilidad de consentimientos, de sesiones y de cambios de privilegio, la respuesta seguirá siendo tardía.

Finalmente, la IA generativa añade dos presiones simultáneas. Por un lado, el atacante puede escribir campañas más convincentes, automatizar pruebas A/B de phishing y adaptar mensajes a cada rol. Por otro lado, las organizaciones empiezan a asignar identidades a agentes de IA internos que toman decisiones o ejecutan tareas. Eso obliga a extender IAM al ciclo de vida de agentes, herramientas y permisos, con la misma rigurosidad aplicada a humanos y máquinas. La frontera entre usuario y sistema se difumina, pero la responsabilidad de acceso no desaparece.

9. Conclusion and Future Work

IAM en 2026 es el plano decisivo de control para organizaciones híbridas, cloud-first y cada vez más automatizadas. Este trabajo mostró que el problema no consiste sólo en autenticar correctamente, sino en gestionar identidades, sesiones, permisos, consentimiento, contexto y revocación como un sistema cohesivo. La metodología VCIS propone precisamente eso: validación continua, privilegio mínimo real, autenticación resistente al phishing y respuesta automatizada ante abuso de identidad.

La evidencia experimental y el caso de estudio indican que la mejora material proviene de la combinación de controles, no de un único producto. Passkeys y WebAuthn reducen phishing; SCIM y PAM reducen drift; federación efímera reduce exposición; contextual access limita abuso; ITDR y SIEM correlacionado aceleran detección. La integración con CNAPP y observabilidad en runtime refuerza la defensa en entornos cloud. En conjunto, estas capas reducen el privilegio efectivo esperado y acortan la ventana de explotación.

Como trabajo futuro, se abren varias líneas. La primera es la identidad de agentes de IA, con políticas específicas de delegación, explicación y revocación. La segunda es la transición hacia criptografía poscuántica en federación, firma y emisión de credenciales, en línea con la estandarización que ya existe para 2026. La tercera es la formalización de políticas de riesgo adaptativo con modelos probabilísticos calibrados en datos reales y auditables. La cuarta es la integración de señales de comportamiento en tiempo real sin invadir innecesariamente la privacidad. IAM seguirá siendo el eje de la ciberseguridad porque la confianza digital, en última instancia, es una función de identidad.

10. References

BERTOCCI, P. et al. The OAuth 2.0 Authorization Framework. RFC 6749, 2012. Disponible en: https://www.rfc-editor.org/rfc/rfc6749. Acceso en: 30 abr. 2026.

CAMPBELL, B. et al. Security Assertion Markup Language (SAML) V2.0 Technical Overview. OASIS, 2008. Disponible en: https://www.oasis-open.org/standards#samlv2.0. Acceso en: 30 abr. 2026.

CIS. CIS Critical Security Controls v8. Center for Internet Security, 2021. Disponible en: https://www.cisecurity.org/controls/v8. Acceso en: 30 abr. 2026.

CISA. Zero Trust Maturity Model, 2023. Disponible en: https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model. Acceso en: 30 abr. 2026.

CISA. Phishing-Resistant MFA, 2024. Disponible en: https://www.cisa.gov. Acceso en: 30 abr. 2026.

ENISA. Identity and Access Management in Cloud Services, 2023. Disponible en: https://www.enisa.europa.eu/publications. Acceso en: 30 abr. 2026.

FIDO ALLIANCE. Passkeys. FIDO Alliance, 2024. Disponible en: https://fidoalliance.org/passkeys/. Acceso en: 30 abr. 2026.

FIDO ALLIANCE; W3C. Web Authentication: An API for accessing Public Key Credentials Level 2, 2021. Disponible en: https://www.w3.org/TR/webauthn-2/. Acceso en: 30 abr. 2026.

GOODIN, D. Massive password spray campaigns target Microsoft 365. Ars Technica, 2023. Disponible en: https://arstechnica.com/. Acceso en: 30 abr. 2026.

HARDEN, B. et al. SCIM 2.0 Protocol. RFC 7644, 2015. Disponible en: https://www.rfc-editor.org/rfc/rfc7644. Acceso en: 30 abr. 2026.

HARDEN, B. et al. System for Cross-domain Identity Management: Core Schema. RFC 7643, 2015. Disponible en: https://www.rfc-editor.org/rfc/rfc7643. Acceso en: 30 abr. 2026.

IBM. Cost of a Data Breach Report 2024. IBM Security, 2024. Disponible en: https://www.ibm.com/reports/data-breach. Acceso en: 30 abr. 2026.

IETF. Proof Key for Code Exchange by OAuth Public Clients (PKCE). RFC 7636, 2015. Disponible en: https://www.rfc-editor.org/rfc/rfc7636. Acceso en: 30 abr. 2026.

IETF. OAuth 2.0 Token Exchange. RFC 8693, 2020. Disponible en: https://www.rfc-editor.org/rfc/rfc8693. Acceso en: 30 abr. 2026.

IETF. OAuth 2.0 for Native Apps. RFC 8252, 2017. Disponible en: https://www.rfc-editor.org/rfc/rfc8252. Acceso en: 30 abr. 2026.

IETF. JSON Web Token (JWT). RFC 7519, 2015. Disponible en: https://www.rfc-editor.org/rfc/rfc7519. Acceso en: 30 abr. 2026.

IETF. Demonstrating Proof of Possession at the Application Layer (DPoP). RFC 9449, 2023. Disponible en: https://www.rfc-editor.org/rfc/rfc9449. Acceso en: 30 abr. 2026.

KEMP, D. et al. NIST Special Publication 800-63B: Digital Identity Guidelines: Authentication and Lifecycle Management. NIST, 2020. Disponible en: https://pages.nist.gov/800-63-3/sp800-63b.html. Acceso en: 30 abr. 2026.

KERNER, S. Identity Threat Detection and Response: A Practical Guide. SANS, 2024. Disponible en: https://www.sans.org/. Acceso en: 30 abr. 2026.

MAHMOOD, Q. et al. An Empirical Study of OAuth Misconfiguration in Enterprise Applications. IEEE Access, 2023. Disponible en: https://ieeexplore.ieee.org/. Acceso en: 30 abr. 2026.

MICROSOFT. Microsoft Entra ID documentation. Microsoft Learn, 2026. Disponible en: https://learn.microsoft.com/entra/. Acceso en: 30 abr. 2026.

MITRE. ATT&CK for Enterprise. MITRE, 2026. Disponible en: https://attack.mitre.org/. Acceso en: 30 abr. 2026.

MITRE. D3FEND. MITRE, 2026. Disponible en: https://d3fend.mitre.org/. Acceso en: 30 abr. 2026.

NIST. Zero Trust Architecture. SP 800-207, 2020. Disponible en: https://csrc.nist.gov/publications/detail/sp/800-207/final. Acceso en: 30 abr. 2026.

OKTA. State of Secure Identity Report 2024. Okta, 2024. Disponible en: https://www.okta.com/resources/. Acceso en: 30 abr. 2026.

OWASP. OWASP ASVS 4.0.3, 2023. Disponible en: https://owasp.org/www-project-application-security-verification-standard/. Acceso en: 30 abr. 2026.

OWASP. OAuth 2.0 Security Best Current Practice. OWASP, 2024. Disponible en: https://cheatsheetseries.owasp.org/. Acceso en: 30 abr. 2026.

PAREKH, G. et al. The Rise of Adversary-in-the-Middle Attacks Against MFA. Black Hat USA, 2023. Disponible en: https://www.blackhat.com/. Acceso en: 30 abr. 2026.

RICHARDSON, M.; GRIGG, I. OAuth 2 in Action. 2. ed. Manning, 2021. Disponible en: https://www.manning.com/books/oauth-2-in-action. Acceso en: 30 abr. 2026.

RICHARDSON, M. OAuth 2.1 Authorization Framework. IETF Draft, 2024. Disponible en: https://datatracker.ietf.org/. Acceso en: 30 abr. 2026.

SCHNEIER, B. A Dive into Identity-Centric Security. IEEE Security & Privacy, 2024. Disponible en: https://ieeexplore.ieee.org/. Acceso en: 30 abr. 2026.

W3C. Credential Management Level 1. W3C Recommendation, 2016. Disponible en: https://www.w3.org/TR/credential-management-1/. Acceso en: 30 abr. 2026.

YUBICO. The State of Passwordless Authentication, 2024. Disponible en: https://www.yubico.com/resources/report/. Acceso en: 30 abr. 2026.