Qué es IAM: gestión de identidades y accesos en empresa 2026

IAM (Identity and Access Management) es la disciplina que gestiona el ciclo de vida de las identidades digitales (usuarios humanos, máquinas, cargas de trabajo y agentes de IA) y los accesos que cada una tiene sobre los recursos de la organización. Es la base sobre la que se construye cualquier arquitectura Zero Trust, cualquier programa de cumplimiento serio (NIS2, ENS, ISO 27001, DORA, SOC 2) y cualquier defensa realista contra los ataques modernos, donde el robo y abuso de credenciales es el vector dominante en la mayoría de brechas.

Lo esencial sobre IAM

• IAM no es un producto, es una disciplina transversal que cubre autenticación, autorización, gobierno de accesos, identidades privilegiadas e identidades de máquina.
• Las grandes subdisciplinas son IAM operacional, IGA, PAM, CIAM y Machine Identity, y cada una resuelve un problema distinto.
• El modelo de autorización (RBAC, ABAC, PBAC, ReBAC) marca el techo de granularidad y mantenibilidad de tu política de accesos.
• El stack 2026 combina IdP empresarial, MFA resistente a phishing, gobierno de accesos y gestión de cuentas privilegiadas, con tendencia hacia identidad como nuevo perímetro.
• Encaja con NIS2 art. 21, ISO 27001 A.5.16 a A.5.18, ENS, GDPR art. 32 y SOC 2 CC6.

Los tres pilares clásicos: AAA

El acrónimo histórico AAA (Authentication, Authorization, Accounting) sigue siendo la mejor forma de explicar qué hace IAM.

Authentication (autenticación): quién eres. Una identidad demuestra que es quien dice ser. Los factores se agrupan en algo que sabes (contraseña, PIN), algo que tienes (clave FIDO2, TOTP, smartphone) y algo que eres (huella, rostro, voz). La autenticación moderna combina factores (MFA) y sustituye contraseñas por passkeys resistentes a phishing.

Authorization (autorización): qué puedes hacer. Una vez autenticada, la identidad necesita decisión sobre qué recursos puede ver, modificar o eliminar. Se materializa en políticas (roles, atributos, relaciones, listas). Es la pieza más compleja porque crece con cada aplicación, equipo y dato sensible.

Accounting (registro): qué hiciste. Toda acción autenticada y autorizada deja rastro auditado: quién, qué, sobre qué recurso, desde dónde, cuándo. Sin accounting no hay forensia, no hay cumplimiento y no hay forma de detectar abuso. Los logs IAM son uno de los inputs más valiosos del SIEM.

Algunas literaturas amplían a AAAA añadiendo Auditing, que separa la generación del log de su revisión periódica. La distinción importa: generar logs sin revisarlos es hallazgo habitual de auditoría.

Las subdisciplinas de IAM

IAM no es un único producto ni un único equipo. Es un conjunto de subdisciplinas con problemas, vendors y madurez distintos. Confundirlas es la causa más común de proyectos que se atascan.

IAM operacional. El día a día: alta y baja de cuentas, provisioning automatizado, sincronización con RRHH, gestión de grupos, restablecimiento de contraseñas, integración SSO. Su métrica de éxito es velocidad y consistencia: un empleado nuevo debe tener todos sus accesos el primer día y perderlos por completo el día de su baja.

IGA (Identity Governance and Administration). Va más allá del provisioning y se centra en el gobierno: certificaciones periódicas, revisión de derechos por managers, segregación de funciones, workflows de aprobación, modelado de roles. Es la capa que responde con evidencia trazable a la pregunta del auditor ¿por qué este usuario tiene este acceso?.

PAM (Privileged Access Management). Gestiona las cuentas privilegiadas: administradores de dominio, root en servidores, superusers de bases de datos, claves cloud. Incluye bóveda de credenciales, rotación automática, grabación de sesiones, just-in-time access y aprobación por flujo.

CIAM (Customer IAM). Gestiona identidades de usuarios externos: clientes, partners, ciudadanos. Requisitos distintos al IAM interno: escala de millones, registro social, branding, consentimiento GDPR, fricción mínima.

Machine Identity. Identidades no humanas: workloads cloud, contenedores, service accounts, dispositivos IoT, agentes de IA. Su volumen crece más rápido que el de humanos y su gestión tradicional ha sido pobre (claves estáticas, secretos en código, certificados sin rotación). Foco 2026 en SPIFFE/SPIRE, identidades efímeras y gestión de secretos integrada.

Componentes técnicos del stack IAM

Por debajo del lenguaje de negocio, un stack IAM se compone de piezas técnicas con responsabilidades claras.

Identity Provider (IdP). Sistema autoritativo que custodia la identidad y emite aserciones. Microsoft Entra ID, Okta, Ping Identity, ForgeRock, Auth0 y Keycloak son los nombres habituales. Es el centro neurálgico: si cae o se compromete, cae el acceso a todo lo que delega en él.

Service Provider (SP). Aplicación o servicio que confía en el IdP para autenticar. En SSO bien diseñado el SP nunca ve la contraseña, solo recibe una aserción firmada.

Directorio. Almacén estructurado de cuentas, grupos y atributos. Active Directory sigue dominante on-premise tras dos décadas. Microsoft Entra ID (antes Azure AD) es su contraparte cloud, complementaria, no idéntica. Otras opciones: OpenLDAP, JumpCloud, directorio nativo de Okta o Google Workspace.

Federation. Permite que un usuario autenticado en un dominio acceda a recursos de otro sin reautenticarse. Protocolos dominantes: SAML 2.0 (empresarial clásico), OpenID Connect (OIDC) sobre OAuth 2.0 (estándar moderno) y SCIM para provisioning.

Factores de autenticación. Desde contraseñas (el más débil y aun así el más extendido) hasta passkeys FIDO2/WebAuthn y claves físicas, pasando por TOTP, push (con riesgo de MFA fatigue) y biometría (siempre como factor local).

Adaptive authentication. Capa que ajusta la fricción según riesgo de sesión: ubicación, dispositivo, hora, comportamiento. Sesión de bajo riesgo pasa con un factor, sesión sospechosa exige reverificación o se bloquea.

RBAC vs ABAC vs PBAC vs ReBAC

El modelo de autorización que elijas determina cuánta granularidad podrás expresar y cuánto coste de mantenimiento asumirás. No hay un ganador absoluto, hay encajes según caso.

Regla práctica para empresas medianas. Empezar con RBAC para los casos claros (acceso a aplicaciones SaaS, grupos de departamento) y añadir ABAC o PBAC para los casos donde el contexto importa (acceso a datos por clasificación, restricciones por ubicación, ventanas horarias). ReBAC encaja en productos SaaS multi-tenant más que en IT corporativo clásico.

Vendor landscape 2026

El ecosistema IAM en 2026 está fragmentado por subdisciplina. Esta sección describe capacidades sin endorsar comercialmente: la elección depende del punto de partida, del stack existente y de las prioridades.

IAM empresarial e IdP. Okta como independiente de referencia, Microsoft Entra ID con integración nativa en Microsoft 365, Ping Identity con tracción en banca y telcos, OneLogin como alternativa más ligera, ForgeRock fuerte en CIAM, Auth0 (parte de Okta) con foco developer.

PAM. CyberArk como referente histórico, Delinea (fusión Thycotic y Centrify) con propuesta modular, BeyondTrust con foco en endpoint privilegiado, HashiCorp Vault centrado en secretos y machine identity.

IGA. SailPoint como líder consolidado, Saviynt con enfoque cloud y moderno, IBM Verify Governance, Omada con tracción EMEA. Es el segmento donde el coste de licencia e implementación pesa más.

CIAM. Auth0 y Okta CIAM (mismo grupo), Microsoft Entra External ID, AWS Cognito nativo para stacks AWS, Google Cloud Identity para Workspace. ForgeRock y Ping también compiten aquí.

Open source. Keycloak (Red Hat) como referente para IdP self-hosted, Authentik con UX moderna, Authelia ligero, Casbin como librería de autorización embebible, OpenFGA y SpiceDB como implementaciones abiertas inspiradas en Zanzibar para ReBAC.

Machine identity y secretos. HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, CyberArk Conjur, Akeyless. Para workloads, SPIFFE/SPIRE como estándar abierto.

La regla práctica: consolidar primero IdP y MFA, después PAM si hay administración crítica significativa, después IGA cuando aplicaciones y presión de auditoría lo justifiquen, y trabajar machine identity en paralelo desde el inicio.

Zero Trust y IAM: identidad como nuevo perímetro

En la arquitectura Zero Trust, la identidad ocupa el lugar que antes ocupaba la red como plano de control principal. Identity is the new perimeter resume el cambio. Tres conceptos lo concretan.

Just-In-Time access (JIT). El acceso privilegiado no es permanente. Un administrador solicita el rol cuando lo necesita, recibe aprobación, ejecuta la tarea, y el rol expira automáticamente. Reduce drásticamente la ventana de exposición de cuentas privilegiadas robadas.

Just Enough Access (JEA). Cuando se concede acceso, es el mínimo necesario para la tarea. No "administrador del sistema" sino "puedo reiniciar este servicio en estos dos servidores". Se materializa con PowerShell JEA en Windows, sudo granular en Linux, scopes finos en cloud.

Continuous verification. La sesión no se da por buena indefinidamente. Postura del dispositivo, comportamiento del usuario y señales de threat intelligence se evalúan en continuo. Si algo cambia, la sesión se reevalúa y puede revocarse.

Para profundizar en este modelo, consulta la guía de Zero Trust: arquitectura, principios e implementación.

Riesgos comunes en IAM

Las brechas asociadas a IAM no suelen venir de fallos del IdP en sí, sino de patrones de mala higiene y de ataques específicos contra el plano de identidad.

Shadow accounts. Cuentas creadas fuera del proceso oficial (un equipo crea cuenta local en una SaaS, un técnico crea cuenta de servicio sin documentar). Invisibles a IGA y deprovisioning. Mitigación: discovery activo y disciplina de SSO obligatorio.

Orphaned accounts. Cuentas de usuarios que ya no están en la organización pero cuyo acceso sigue activo. Hallazgo recurrente en auditorías y favorito de atacantes que compran credenciales en mercados oscuros. Mitigación: automatización del offboarding y certificaciones periódicas.

Service accounts sobreprivilegiadas. Cuentas técnicas que arrancaron con permisos amplios "por si acaso" y nunca se revisaron. En muchas brechas el atacante encuentra una y hereda sus permisos. Mitigación: modelado por necesidad, rotación y monitorización específica.

MFA bypass. Ataques que sortean MFA: MFA fatigue (bombardeo de push hasta que el usuario acepta), SIM swapping contra SMS OTP, phishing en tiempo real con kits tipo Evilginx, robo de cookies de sesión post-MFA. Mitigación: MFA resistente a phishing (FIDO2/passkey) y número en pantalla en notificaciones.

OAuth token theft. Robo de tokens OAuth válidos que dan acceso sin credencial. Mitigaciones: tokens cortos, refresh tokens rotatorios, binding a dispositivo, detección de uso anómalo.

Session hijacking. Robo de cookies de sesión activas mediante malware o XSS. Mitigaciones: tokens vinculados a dispositivo, reautenticación periódica, detección de cambios de huella de cliente.

Auditoría de IAM

Una práctica IAM sin auditoría regular degenera con rapidez. Tres procesos mínimos:

Certificaciones de acceso. Trimestral o semestral según criticidad: los managers revisan los accesos de su equipo y confirman o retiran. Los privilegiados se revisan con mayor frecuencia. Debe dejar evidencia auditable de quién revisó, qué decidió y cuándo.

Segregación de funciones (SoD). Reglas que prohíben combinaciones tóxicas. Ejemplo clásico: la misma persona no debería poder crear un proveedor y aprobar el pago al mismo. Se modela como políticas de violación y se reporta a comité de auditoría.

Entitlement review. Revisión de derechos finos (no solo "acceso a SAP" sino "transacción XYZ"). Más detallada que la certificación general, aplicada a sistemas críticos. Las herramientas IGA modernas integran entitlement catalogs que la facilitan.

Encaje con NIS2, ISO 27001, ENS, GDPR, SOC 2

IAM es uno de los dominios donde más directamente se materializan los controles normativos. Tener un IAM sólido reduce significativamente el coste de cumplimiento en múltiples marcos a la vez.

Para preparación de auditoría, consulta la guía paso a paso de auditoría NIS2 y la guía completa de ISO 27001.

Preguntas frecuentes

¿Empiezo por IAM operacional o por IGA?

Por IAM operacional. Sin IdP consolidado, MFA generalizado y procesos básicos de alta y baja, montar IGA encima es construir tejado sin paredes. IGA aporta valor cuando ya hay control de identidades, decenas de aplicaciones conectadas y presión real de auditoría que exige certificaciones. Una secuencia razonable es 6 a 12 meses de IAM operacional sólido antes de abordar IGA.

¿Entra ID reemplaza Active Directory?

No del todo. Entra ID es excelente para identidad cloud, SSO con SaaS y autenticación de aplicaciones modernas, pero no implementa todos los servicios de Active Directory clásico (GPO completas, Kerberos a recursos on-premise, esquema LDAP profundo). En 2026 lo habitual es coexistencia: AD para lo on-premise legacy con Entra Connect sincronizando hacia Entra ID. Migraciones puras solo encajan en organizaciones cloud-first.

¿Con MFA es suficiente, o necesito PAM además?

MFA es necesario pero no suficiente para cuentas privilegiadas. Una cuenta de administrador con MFA sigue siendo una cuenta con poder permanente que vive en un puesto que puede comprometerse. PAM añade bóveda, rotación, JIT, grabación de sesión y aprobación por flujo. La regla: MFA es base para todos, PAM es obligatorio para el subconjunto privilegiado.

¿Las passkeys eliminan las contraseñas?

Tienden a hacerlo, pero la transición dura varios años. Las passkeys (WebAuthn) ofrecen seguridad muy superior (resistentes a phishing, vinculadas a dispositivo, sin secreto compartido) y mejor experiencia. En 2026 la adopción crece rápido en consumer y avanza en empresa, pero las contraseñas conviven por inercia de aplicaciones legacy y casos de recuperación. Roadmap razonable: passkey first donde se pueda, password fallback solo donde no haya alternativa.

¿La identidad de máquina es más importante que la humana?

Importan ambas, pero el volumen y crecimiento de identidades de máquina superan al de humanas. Una organización mediana puede tener miles de service accounts, certificados, claves API y workloads frente a cientos de humanos. Su gestión tradicional ha sido peor (secretos en código, claves sin rotación), lo que las convierte en vector favorito. Tratarlas con la misma seriedad (inventario, ciclo de vida, rotación, mínimo privilegio) es foco de madurez en 2026.

¿IAM open source es serio para empresa?

Sí, en escenarios concretos. Keycloak es opción sólida para IdP self-hosted con SAML y OIDC maduros. Authentik y Authelia encajan en casos pequeños. Casbin, OpenFGA y SpiceDB cubren autorización embebible. El trade-off frente a vendors no es calidad técnica sino coste operativo: open source exige equipo capaz de operar, parchar y escalar. Para organizaciones con plataforma fuerte es viable; para el resto, vendors suelen salir más baratos en coste total.

Recursos relacionados

• Qué es Zero Trust: arquitectura, principios e implementación
• Qué es PKI: infraestructura de clave pública
• Qué es SAML: federación de identidad y SSO empresarial
• Qué es JWT: seguridad de tokens y errores comunes
• Pentesting Active Directory: tier model y caminos de ataque
• Qué es credential stuffing: ataque y defensa

Estrategia IAM con Secra

En Secra acompañamos a organizaciones B2B en el diseño y consolidación de su programa IAM. En 4 semanas entregamos un diagnóstico y roadmap con:

• Assessment del stack actual (identidades humanas y de máquina, IdP, MFA, PAM, IGA) comparado con tu marco normativo objetivo (NIS2, ENS, ISO 27001, DORA, SOC 2).
• Modelo objetivo de identidad, autenticación y autorización adaptado a tu stack (Microsoft, Google, AWS, Azure, híbrido).
• Plan por fases con quick wins (MFA resistente a phishing, eliminación de cuentas huérfanas, jubilación de protocolos legacy) y proyectos estructurales (IdP único, PAM, IGA).
• Soporte de ejecución opcional en fases sensibles (migración a passkeys, despliegue PAM, certificaciones de accesos).

Si tu organización evalúa un proyecto IAM, una consolidación de IdP o un despliegue PAM, contacta con Secra y agendamos una sesión inicial sin compromiso.