Explicación de la seguridad de la identidad no humana

Una identidad no humana (NHI) es un sujeto de software —como una cuenta de servicio, una carga de trabajo, una instanci cloud , un dispositivo o un agente automatizado— que puede autenticarse y al que se le pueden conceder permisos para acceder a recursos. No hay ninguna persona detrás de ella, y se crea mediante un evento de software en lugar de mediante una contratación. Fuera del ámbito de la ciberseguridad, la expresión tiene un significado bastante diferente, y el acrónimo NHI, por sí solo, aparece predominantemente en las búsquedas generales con un significado que no tiene nada que ver; por lo tanto, para que quede claro: esta página trata sobre las entidades de máquina dentro de los sistemas de identidad empresariales.

Estas identidades constituyen actualmente la mayor parte de los elementos de autenticación en un entorno moderno. Gozan de privilegios permanentes, funcionan de forma ininterrumpida, rara vez tienen un titular identificado y sus credenciales suelen sobrevivir a los sistemas que las emitieron. En esta página se define este conjunto de identidades, se delimitan sus fronteras con respecto a la identidad de máquina y a la gestión de identidades y accesos (IAM), se muestra cómo se ven realmente comprometidas estas identidades y se explica qué hace un equipo de seguridad cuando una de ellas activa una alerta.

¿Qué es una identidad no humana?

Una identidad no humana es cualquier entidad de software que pueda autenticarse y recibir autorización para acceder a recursos, sin que haya una persona detrás de ella. Las cuentas de servicio, las cargas de trabajo, las instancias de cloud , los dispositivos y los agentes automatizados entran dentro de esta categoría. Esta categoría existe porque la automatización necesita credenciales. Cada tarea programada, cada pipeline, cada integración y cada microservicio tiene que demostrar quién es antes de poder realizar cualquier acción útil.

La seguridad de identidades no humanas, a menudo abreviada como «seguridad NHI», consiste en identificar a ese conjunto de identidades, asignar a cada una de ellas un titular y un conjunto de permisos delimitados, acortar la vigencia de sus credenciales y detectar cuándo una de ellas empieza a comportarse de una forma que nunca antes había mostrado. Los programas de gestión de riesgos internos incorporan cada vez más estas identidades, ya que una cuenta de servicio sin titular y un empleado sin supervisión plantean un problema de gobernanza similar.

La prueba de los límites: qué cuenta y qué no

La Alianza para la Seguridad de la Identidad No Humana ( Cloud ) establece una definición muy estricta. En su documento de 2026 titulado «Definición de identidad no humana», una entidad se considera una NHI «solo cuando puede autenticarse (demostrar quién es) y recibir autorización (que se le concedan permisos), ya sea de forma directa o indirecta, para acceder a los recursos» (Cloud Security Alliance).

Esa prueba descarta varios elementos que la gente suele denominar «identidades no humanas». Un registro de configuración, como una entrada de la CMDB que describe un servidor, no es una identidad a menos que se utilice para autenticarse u obtener derechos. Tampoco lo son los objetos de metadatos, ni el código ni los scripts que nunca se autentican. Y lo que es más importante, los secretos, los tokens, las claves de API y los certificados tampoco son identidades, a menos que estén vinculados a una. Esta última exclusión cambia la forma en que se ejecuta un programa, y en la siguiente sección se explica por qué.

El Gobierno de EE. UU. tiene su propio término para referirse a este mismo concepto. El NIST define una entidad no humana (NPE) como «una entidad relacionada con las tecnologías de la información que cuenta con una identidad digital y actúa en el ciberespacio, pero que no es un agente humano», basándose en las normas CNSSI 4009-2015, NIST SP 800-162 y NIST SP 800-207 (NIST CSRC). Cuando un marco de control o un contrato federal menciona el término «NPE», se refiere a una identidad no humana.

Cuántas identidades no humanas tiene una organización

No existe consenso en el sector sobre en qué medida las identidades no humanas superan en número a las humanas, y las cifras publicadas no son compatibles entre sí. Abarcan poblaciones diferentes: todas las empresas en un estudio, las fincas de origen « cloud » en otro, y solo las grandes organizaciones en un tercero. Utilizan denominadores distintos, contando las identidades de máquina por empleado en un caso y las identidades no humanas por identidad humana en otro. Además, proceden de métodos diferentes, que abarcan desde la telemetría de autenticación hasta el escaneo de repositorios y los datos autoinformados de encuestas. Considera cualquier ratio que aparezca en los titulares como orientativo y limitado a su contexto, nunca como un punto de referencia para tu caso.

Lo que sí se puede afirmar con certeza es la tendencia. Las identidades no humanas superan ahora con creces a las humanas en la mayoría de los entornos, y la brecha sigue aumentando a medida que se extienden la automatización y los flujos de trabajo basados en agentes.

Un dato accesible, con fecha concreta y que no es una proporción sirve de referencia para ello. Un informe de 2026 reveló que el 91 % de las identidades activas en producción no eran humanas, según datos extraídos de los entornos de AWS y Google Cloud que supervisa dicho proveedor (Help Net Security). Se trata de un porcentaje de las identidades activas observadas en el entorno supervisado por un proveedor. No es una proporción, y convertirlo en una supondría inventar una cifra que el estudio no respalda.

¿Cuáles son los tipos de identidades no humanas?

Las identidades no humanas se clasifican en cinco tipos, agrupadas en función de aquello a lo que está vinculada la identidad, y no en función de la credencial que presente.

Cinco temas relacionados con la identidad

Tabla: Los cinco tipos de identidad no humana de la taxonomía de la Alianza de Seguridad « Cloud », a qué está vinculada cada identidad y un ejemplo concreto de cada una.

La columna central es la que realmente hace el trabajo. Una cuenta de servicio se vincula a un sujeto de aplicación, por lo que perdura tras un nuevo despliegue. Una identidad de carga de trabajo se vincula a un pod, servicio o función en ejecución, por lo que puede existir durante unos segundos. Las identidades de infraestructura se asocian a instancias y nodos; las identidades de dispositivos, al hardware y al firmware, incluidos los sensores de IoT; y las identidades de agente, a un actor autónomo. Las identidades de carga de trabajo son el grupo que más rápido crece en los entornos contenedorizados, razón por la cual el trabajo de seguridad de Kubernetes y el trabajo relacionado con identidades no humanas se solapan tanto en la práctica.

El sujeto de identidad no es el mecanismo de autenticación.

Las organizaciones suelen confundir la identidad con el elemento que se utiliza para acreditarla, tratando una clave API, un token o un certificado como si la credencial fuera la identidad. Pero no lo es. Se trata de mecanismos de autenticación, y la taxonomía los clasifica en cinco categorías: secretos estáticos, como contraseñas, claves API y claves SSH; tokens firmados, como JWT, OIDC y aserciones SAML; certificados, incluidos X.509 y SPIFFE SVID; credenciales respaldadas por hardware o por certificación almacenadas en un TPM, un HSM o un elemento seguro; y credenciales de sesión nativas de « cloud » de tipo temporal y de corta duración.

La norma de gobernanza se deriva directamente de esta separación. Vincula la titularidad, el ciclo de vida y los derechos al sujeto, que es la cuenta de servicio o la carga de trabajo que persiste. Adapta la solidez de las credenciales, la frecuencia de rotación y la renovación al mecanismo, que puede sustituirse sin alterar quién es la identidad. Los programas que invierten este principio acaban rotando los secretos de forma rigurosa, mientras que nadie puede determinar a quién pertenece la cuenta a la que pertenecen dichos secretos. Por eso, además, un inventario de claves API no es un inventario de identidades.

¿Son los agentes de IA identidades no humanas?

Sí, con una salvedad. La taxonomía de la Alianza de Seguridad de la Infraestructura de la Información ( Cloud Security Alliance) incluye las «identidades de agente (actor autónomo, incluida la IA)» como uno de sus cinco tipos; por lo tanto, un agente de IA es una identidad no humana y hereda todos los modos de fallo descritos en esta página: privilegio permanente, credenciales no renovadas y ausencia de propietario identificado. La salvedad es que la autorización de agente a herramienta cuenta ahora con su propio modelo normativo. La especificación del Protocolo de Contexto de Modelo (MCP), con fecha del 28 de julio de 2026, convierte a los servidores MCP en servidores de recursos OAuth 2.1 que «DEBEN validar que los tokens de acceso se hayan emitido específicamente para ellos como destinatarios previstos» (Protocolo de Contexto de Modelo). Las cuestiones de gobernanza, ciclo de vida y control específicas de los agentes pertenecen al ámbito de la seguridad de la IA agentiva.

Cómo se relaciona la identidad no humana con la identidad de las máquinas y la gestión de identidades y accesos (IAM)

La seguridad de la identidad no humana consiste en la aplicación de la gestión de identidades y accesos (IAM) a entidades que nunca han pasado por los procesos de incorporación, traslado o baja. La tabla distingue los tres términos, que suelen utilizarse indistintamente.

Tabla: Diferencias entre las identidades humanas, las identidades no humanas y las identidades de las máquinas en cuanto a origen, credenciales, titularidad y fin de vida útil.

Identidades humanas frente a identidades no humanas

La diferencia que importa es el origen de la identidad. Las identidades humanas pasan por procesos de incorporación, traslado y baja gestionados por RR. HH., por lo que su ciclo de vida cuenta con un sistema de registro y una persona responsable del mismo. Las identidades no humanas, en cambio, se originan a partir de eventos del ciclo de vida del software: una implementación, una operación de aprovisionamiento, el inicio de una carga de trabajo, la ejecución de un proceso, un evento de autoescalado o la invocación de un agente. Ningún sistema de RR. HH. tiene constancia de que haya ocurrido nada de eso. Por eso, los modelos de gobernanza basados en las incorporaciones, los traslados y las bajas no se aplican de forma natural a esta población.

La identidad de la máquina y la estructura del certificado

Estos términos se solapan, pero no son sinónimos. La gestión de identidades de máquinas se inscribe en la tradición de la PKI y se centra en los certificados, las claves y la renovación antes de su caducidad. La gestión de identidades no humanas se centra en las cuentas de servicio, los tokens OAuth, las claves API y la autorización entre aplicaciones. La distinción entre «sujeto» y «mecanismo» explica la diferencia: un certificado es un mecanismo, no un tipo de identidad.

El plazo de validez de los certificados se va reduciendo según su propio calendario. El CA/Browser Forum aprobó la votación SC-081v3 el 11 de abril de 2025, con la que se reducirá progresivamente el periodo máximo de validez de los certificados TLS de confianza pública de 398 días a 47 días, y se propone que estas reducciones «comiencen en marzo de 2026 y concluyan en marzo de 2029» (CA/Browser Forum). Ese calendario se aplica únicamente a los certificados TLS de confianza pública. No afecta a la PKI interna, ni a los tokens OAuth y las claves API que predominan en esta página.

Dónde se sitúa la seguridad del NHI en relación con la gestión de identidades y accesos (IAM)

La gestión de identidades y accesos (IAM) es una disciplina de ciberseguridad, y la seguridad de las identidades no humanas es la parte de la misma que abarca a los sujetos de identidad que no corresponden a personas. Se trata de una distinción más operativa que académica, ya que las herramientas de IAM tradicionales se diseñaron en torno a los eventos del ciclo de vida humano. En una encuesta de la Cloud Security Alliance patrocinada por un proveedor y realizada en 2026 a 383 profesionales —llevada a cabo en línea en agosto y septiembre de 2025—, el 92 % de los encuestados afirmó no confiar en que sus soluciones de IAM tradicionales pudieran gestionar eficazmente los riesgos asociados a la IA y a las identidades no humanas (Cloud Security Alliance). El análisis de identidades es donde ambas poblaciones se encuentran en la práctica, aplicando modelos de comportamiento a ambas.

Cómo se ven comprometidas las identidades no humanas

Las identidades no humanas se ven comprometidas debido a procesos de baja que nunca revocan las credenciales, integraciones de terceros que conservan tokens activos y secretos que nunca se han renovado. Lo que las hace atractivas es más una cuestión estructural que algo excepcional. Cuentan con privilegios permanentes, funcionan de forma continua, rara vez tienen un responsable en condiciones de detectar que algo va mal y su actividad se asemeja exactamente a la automatización legítima de la que se hacen pasar.

El privilegio de la inmunidad y la proliferación de los secretos

Cada identidad no humana que posea permisos que no necesite en ese momento amplía la superficie de ataque, ya que la credencial sigue siendo válida independientemente de si alguien la está utilizando o no. Las credenciales no humanas robadas también constituyen una vía directa para el movimiento lateral, ya que una cuenta de servicio que ya se comunica con cinco sistemas es una ruta ya establecida entre ellos. Estas cuentas se concentran allí donde la supervisión directa es más escasa, razón por la cual los programas de seguridad de «cloud » y de identidades no humanas siguen convergiendo.

La proliferación de secretos es la parte cuantificable del problema. La quinta edición del informe «State of Secrets Sprawl», publicada el 17 de marzo de 2026, detectó 28 649 024 secretos nuevos en las confirmaciones públicas de GitHub durante 2025, lo que supone un aumento interanual del 34 %, incluidos 1 275 105 secretos pertenecientes a servicios relacionados con la IA, con un incremento interanual del 81 % (GitGuardian). Se trata de credenciales de identidades que alguien ha creado y que nadie ha supervisado, y el robo de credenciales que se inicia en un repositorio público no requiere ningún tipo de intrusión.

La implicación de terceros agrava aún más la situación. Verizon señala que la participación de terceros en las infracciones ha aumentado un 60 % con respecto a los datos del año pasado, y que las infracciones en las que interviene un tercero representan ahora el 48 % del total (sala de prensa de Verizon). Su resumen ejecutivo de 2026 añade que el aprovechamiento de vulnerabilidades «ha aumentado hasta el 31 % en los datos de este año» como el vector de acceso inicial más común (resumen ejecutivo del DBIR 2026 de Verizon). El informe completo sitúa el periodo de los incidentes analizados entre el 1 de noviembre de 2024 y el 31 de octubre de 2025. Un ataque a la cadena de suministro que alcance los tokens de una integración afecta a todo aquello a lo que dichos tokens puedan acceder.

Lo que revelan tres incidentes confirmados

Tabla: Tres incidentes contrastados, cada uno de los cuales ilustra una forma diferente en la que falla una identidad no humana, junto con la causa principal y la lección que se desprende de ellos.

Relación entre el «Top 10 de identidades no humanas» de OWASP y los incidentes reales

La lista «Top 10 de identidades no humanas» de OWASP consta exactamente de diez entradas, desde NHI1 hasta NHI10. Al relacionarlas con incidentes verificados, se distingue entre los riesgos teóricos y aquellos que ya han tenido consecuencias.

Tabla: Cinco entradas del «Top 10 de identidades no humanas» de OWASP (2025), cada una de ellas asociada a un incidente verificado que la ilustra.

Las cinco entradas que no aparecen en la tabla anterior son: NHI4:2025 «Autenticación insegura», NHI6:2025 «Configuraciones de implementación inseguras de Cloud », NHI8:2025 «Aislamiento del entorno», NHI9:2025 «Reutilización de NHI» y NHI10:2025 «Uso humano de NHI» (OWASP). Esta última entrada es la que con mayor frecuencia se omite en los resúmenes de la lista.

En términos de « MITRE ATT&CK », las claves API robadas, los tokens OAuth y las claves de firma se obtienen mediante 0006 Acceso con credenciales. Una nota sobre la nomenclatura para quienes estén actualizando la lógica de detección más antigua: la matriz Enterprise de la versión 19.2 incluye 15 tácticas, y «Evasión de defensa» ya no figura entre ellas, ya que se retiró en la versión 19 y fue sustituida por 0005 Discreción y 0112 Deterioro de la capacidad de defensa.

Este mismo patrón se observa en los registros de vulnerabilidades. CVE-2026-12564, publicado el 18 de agosto de 2026, describe un complemento de credenciales en el que un atacante autenticado que posea privilegios para crear credenciales puede provocar que el token de la cuenta de servicio de Kubernetes de un pod controlador sea leído y enviado a una URL controlada por el atacante. La CNA le otorgó una puntuación de 9,6 (crítica), y la NVD aún no había publicado su propia puntuación en el momento de redactar este artículo (NVD).

Cómo detectar y contener la filtración de identidades no humanas

Detectar una violación de la identidad no humana implica establecer una línea de referencia de lo que cada entidad de máquina suele hacer y alertar ante cualquier desviación, ya que la credencial es válida y la autenticación en sí misma no presenta ningún indicio de anomalía. La contención implica, por tanto, revocar primero y resolver las dependencias de producción en segundo lugar, una decisión que la mayoría de los equipos no han tomado de antemano. Esto convierte el problema tanto en una cuestión de operaciones del SOC como de gobernanza de identidades.

Conviene definir esta laguna con precisión, en lugar de hacerlo de forma general. Existen directrices sobre las capacidades de identificación de entidades no humanas y sobre el orden de los pasos de respuesta, y en esta página se citan a continuación. Lo que ninguna página de clasificación ofrece, y lo que ni siquiera proporciona el propio organismo de normalización de la categoría, son criterios de triaje orientados al SOC o un manual de contención específico y secuenciado. Esa es la aportación que hace esta sección.

Por qué las señales de detección centradas en las personas no se activan ante identidades no humanas

Los usuarios humanos acceden a los sistemas de forma predecible, desde ubicaciones concretas o en momentos específicos del día, y gran parte de la detección de identidades se basa en esa previsibilidad. Las identidades no humanas no muestran esos patrones de comportamiento físico, razón por la cual el «desplazamiento imposible», el ejemplo por excelencia, es descrito por la Alianza para la Seguridad en el Cloud como un patrón «centrado en los humanos, pero no aplicable a una NHI» (Alianza para la Seguridad en elCloud ). Los métodos de detección heredados de la población humana fallan aquí de forma silenciosa. No fallan en su funcionamiento, sino que nunca se activan.

Hay cinco capacidades que las sustituyen. La detección y el descubrimiento continuos identifican identidades que nadie ha registrado. Los gráficos de identidad representan las cadenas de roles asumidos y la confianza delegada, lo que crea rutas transitivas de escalada de privilegios. El establecimiento de valores de referencia de comportamiento define lo que se considera normal para cada identidad. La detección en tiempo real abarca el primer acceso a los datos de los clientes, las actualizaciones sospechosas y las descargas masivas de información confidencial. La respuesta ante incidentes cierra el ciclo. La función en sí misma es la detección y respuesta ante amenazas de identidad, y el análisis del comportamiento de las identidades proporciona el modelo subyacente.

Criterios de clasificación para una alerta de identidad no humana

Analiza la alerta basándote en estas ocho preguntas, ordenadas según el peso que tiene cada una a la hora de determinar el veredicto.

1. ¿Tiene esa identidad un propietario humano identificado? Nadie puede confirmar que esa actividad fuera la esperada.
2. ¿Se sale este comportamiento de la línea de referencia establecida para la identidad? Una carga de trabajo que realiza una sexta tarea tras dos años en los que solo realizaba cinco es la señal.
3. ¿Se trata del primer acceso a un almacén de datos sensibles? La desviación de mayor valor disponible en una identidad de larga duración.
4. ¿La credencial tiene una vigencia prolongada o ha superado su intervalo de rotación? La deuda de rotación amplía el margen de tiempo durante el cual una credencial robada sigue siendo válida.
5. ¿Tiene la identidad un privilegio de acceso que va más allá de su función? Un permiso excesivo convierte una pequeña concesión en un gran radio de impacto.
6. ¿Se puede acceder a la identidad desde una integración de terceros? Los tokens de terceros suponen una exposición de primera mano, tal y como demostró Salesloft Drift.
7. ¿Muestra el gráfico de identidades una ruta transitiva hacia un mayor privilegio? Las cadenas de roles asumidos permiten que identidades anodinas alcancen lugares destacados.
8. ¿Hay indicios de una recuperación masiva de información secreta? Las lecturas masivas de una cámara acorazada rara vez forman parte de un proceso automatizado habitual.

‍

‍

Una secuencia de contención y la decisión entre «revocar» y «interrumpir la producción»

La Alianza de Seguridad « Cloud » establece el procedimiento a seguir, y este es sólido. En caso de detección, se deben revocar en primer lugar los tokens y las claves de acceso comprometidos para bloquear el acceso del atacante. A continuación, se deben aislar las cargas de trabajo afectadas y delimitar el alcance del incidente mediante el recorrido del grafo de identidades. Por último, se debe automatizar la recuperación —incluida la sustitución de credenciales— solo después de que se haya verificado que el entorno está limpio, manteniendo la validación humana para incidentes de alta gravedad o ambiguos, de modo que no se emitan nuevas claves secretas en un contexto que aún esté comprometido.

Lo que ese orden da por sentado, y no proporciona, es el nivel de toma de decisiones que subyace a él. Hay tres preguntas que deben responderse antes de que se produzca un incidente, y no durante el mismo. ¿Quién es responsable de la decisión de revocación cuando la identidad no tiene un titular designado? ¿Cuál es la solución alternativa cuando la revocación rompe una dependencia de producción? ¿Cómo se lleva a cabo la revocación de una cuenta de servicio cuyos usuarios son desconocidos?

Esta disyuntiva no es hipotética. En la encuesta «SANS State of Identity Threats and Defenses» de 2026, realizada a más de 500 profesionales de la seguridad de todo el mundo, el 92 % no renueva las credenciales de los equipos cada 90 días por temor a que ello pueda provocar fallos en las cuentas de servicio (Infosecurity Magazine). Una solución práctica por etapas reduce el alcance antes de restringir el acceso: primero se retiran los permisos, se observa qué deja de funcionar mientras la credencial sigue activa y, a continuación, se revoca.

La revocación también debe llegar a la capa de tokens. El aviso del FBI sobre aplicaciones conectadas maliciosas señala que autorizar una de ellas elude defensas como la autenticación multifactorial, los restablecimientos de contraseña y la supervisión de inicios de sesión, y que, dado que los tokens OAuth los emite la propia plataforma, la actividad de la aplicación maliciosa puede parecer una integración de confianza. En el caso de la filtración de Drift, la contención adoptó esa forma: el 20 de agosto de 2025 se revocaron todos los tokens de acceso y de actualización activos de la aplicación (FBI FLASH).

¿A qué velocidad es suficiente?

Una editorial proporciona tanto un objetivo como una medida, en la misma unidad y para la misma acción, lo que hace que la correspondencia sea excepcionalmente clara. Su grupo de trabajo sobre IAM ofrece un objetivo ilustrativo: «menos de 24 horas para que las medidas correctivas contengan las identidades comprometidas antes de que los adversarios logren el movimiento lateral». Se trata de un objetivo para un programa maduro, no de un punto de referencia observado.

En comparación con estos datos, según la encuesta de 2026 patrocinada por un proveedor y realizada a 383 profesionales, casi una cuarta parte (24 %) de las organizaciones tarda más de 24 horas en rotar o revocar una credencial tras una posible exposición, y el 30 % tarda más de un día en evaluar una fuga de credenciales de alta gravedad (Cloud Security Alliance). Lee atentamente esa segunda cifra. Mide la rapidez con la que los equipos evalúan la gravedad, no en qué se basan para hacerlo.

Qué pruebas hay que conservar

Hay que considerar la telemetría de identidades no humanas como un control que se conserva y supervisa, y no como un elemento secundario. El caso de Coupang es el mejor ejemplo disponible. Las autoridades reguladoras ordenaron la conservación de los registros de acceso y, seis días después, la empresa eliminó manualmente aproximadamente seis meses de registros de acceso a la web. Se perdió aproximadamente el 13 % de los registros correspondientes al periodo del ataque, «lo que hizo imposible identificar a todas las víctimas afectadas», y la comisión remitió el caso de la empresa para su enjuiciamiento penal por destrucción de pruebas (The Record).

Cómo gestionar el ciclo de vida de las identidades no humanas

La gestión de identidades no humanas consiste en identificarlas, asignar a cada una un titular humano y acortar la vigencia de cada credencial. Las etapas se llevan a cabo en orden.

1. Descubre todas las identidades no humanas en cloud, en modelos SaaS y en entornos locales
2. Asignar un responsable concreto a cada identidad detectada
3. Limitar los derechos de ámbito a lo que la identidad utiliza realmente
4. Almacenar las credenciales de forma segura y automatizar su rotación
5. Certificar el inventario en un ciclo de revisión periódico
6. Retirar la identidad cuando haya cumplido su finalidad

Identificación, titularidad e inventario

La identificación es lo primero, porque nada más funciona en una población que no se haya censado, y debe abarcar entornos de « cloud », SaaS y locales, en lugar de limitarse a uno de los tres. La responsabilidad es lo segundo, y es el paso que la mayoría de los programas se saltan. En la misma encuesta de 2026, patrocinada por un proveedor y realizada a 383 profesionales, el 51 % de las organizaciones señaló la falta de una responsabilidad o rendición de cuentas claras como su principal problema (Cloud Security Alliance). De esos dos aspectos se deriva un inventario certificable. El privilegio permanente es también el punto de encuentro entre la supervisión del acceso privilegiado y el trabajo con identidades no humanas, y zero trust es el modelo rector, ya que no concede nada en función de la ubicación o de una autenticación previa.

Gestión de la rotación y de los secretos

Tres mediciones independientes apuntan en la misma dirección desde tres puntos de partida distintos. Nunca deben promediarse, combinarse ni restarse entre sí, ya que ninguna de ellas comparte un denominador común.

Tabla: Tres mediciones independientes de la rotación de credenciales, obtenidas a partir de un objetivo ilustrativo, un autoinforme y datos de telemetría del proveedor. Cada fila tiene un denominador diferente, por lo que estas cifras nunca deben promediarse, combinarse ni restarse entre sí.

La fila de telemetría corresponde a la edición de 2025 y está quedando obsoleta; además, refleja la base de clientes de un único proveedor, en lugar de reflejar el mercado en su conjunto. Aun así, la convergencia entre un objetivo, una autoevaluación y la telemetría constituye una prueba más sólida que cualquiera de estos tres elementos por separado.

Identidad de carga de trabajo de corta duración con SPIFFE y SPIRE

La solución basada en estándares para los secretos de larga duración consiste en dejar de utilizarlos. El «Secure Production Identity Framework for Everyone» (SPIFFE) es un conjunto de especificaciones de código abierto para la inicialización y la emisión de identidades a servicios en entornos dinámicos y heterogéneos, mediante documentos de identidad de corta duración obtenidos a través de una sencilla API. SPIRE es la implementación de dichas especificaciones por parte del proyecto SPIFFE.

Cuatro conceptos sustentan el modelo. Un «SPIFFE ID» es un nombre con formato URI para una carga de trabajo. Un «SVID», o «Documento de identidad verificable SPIFFE», es la credencial que lo acredita, en formato X.509 o JWT. La API de carga de trabajo es la forma en que una carga de trabajo obtiene su propio SVID sin necesidad de mantener un secreto estático. Un dominio de confianza es el límite dentro del cual se emiten y se consideran fiables dichas identidades. La documentación se encuentra actualmente en la versión v1.15.2 (SPIFFE). La gobernanza está establecida: SPIFFE fue aceptado en la Fundación para la Informática Nativa ( Cloud , CNCF) el 29 de marzo de 2018, pasó a la fase de incubación el 22 de junio de 2020 y se graduó el 23 de agosto de 2022 (CNCF).

Esto encaja aquí porque una identidad de carga de trabajo de corta duración y contrastada elimina por completo las credenciales permanentes, lo que constituye la respuesta estructural al documento NHI7:2025 «Secretos de larga duración». Sin embargo, las estructuras de identidad tienen sus propios fallos. CVE-2026-18677, publicada el 12 de agosto de 2026, describe una malla de servicios en la que un plano de datos que presenta un token vinculado a etiquetas podría registrarse con una etiqueta de carga de trabajo arbitraria y obtener la identidad SPIFFE de otra carga de trabajo; recibió una puntuación de 6,0 (medio) por parte de la CNA y no fue puntuada por la NVD en el momento de redactar este artículo (NVD).

Indicadores que muestran la reducción del riesgo

En este ámbito, casi nadie publica resultados de pruebas de rendimiento medidos, por lo que conviene considerar los objetivos del programa como metas y no como un rendimiento real.

Tabla: Objetivos del programa publicados por la Alianza para la Seguridad de la Información Nacional ( Cloud ), con un valor de referencia medido que solo se proporciona cuando la unidad y la acción coinciden. Advertencia de la propia fuente: «Los objetivos que aquí se presentan son metas ilustrativas para programas maduros de seguridad del NHI y deben ajustarse en función del riesgo de la organización, la criticidad del NHI y los requisitos operativos». No se trata de valores de referencia observados.

Seguridad y cumplimiento normativo en materia de identidad no humana

NIS2 y DORA abordan la identidad no humana a través del control de acceso y el riesgo de las TIC de terceros, en lugar de nombrarla.

Tabla: Cómo se aborda la identidad no humana en los dos principales instrumentos de la UE, y el texto exacto del artículo en el que se basa cada referencia.

El artículo 21, apartado 2, de la NIS2 enumera diez medidas, de la (a) a la (j), pero la cláusula marco es más importante que el número en sí. Las medidas «se basarán en un enfoque que abarque todos los riesgos [...] e incluirán, como mínimo, las siguientes», lo que convierte a las diez medidas en un mínimo y no en una lista cerrada. Cabe señalar también lo que no establece el artículo 21, apartado 2, letra j). Dado que termina con la expresión «cuando proceda», la Directiva NIS2 no exige de forma incondicional la autenticación multifactorial. Los Estados miembros tenían hasta el 17 de octubre de 2024 para adoptar y publicar las medidas de transposición, y debían aplicarlas a partir del 18 de octubre de 2024 (Comisión Europea).

El apéndice G del documento de la Alianza de Seguridad de la Red de Cuentas de Usuarios ( Cloud ) establece una correspondencia independiente entre las prácticas de identidad no humana y las normas SOC 2, ISO 27001:2022, NIST SP 800-53 y NIST CSF, el RGPD, la HIPAA, la PCI-DSS v4.0, la DORA y la NIS2, situando la aplicación del principio de «privilegio mínimo» en el artículo 21, apartado 2, letra i). Hay que tener en cuenta su advertencia: «Las correspondencias indican alineación, pero no garantizan la certificación». Los programas de cumplimiento más amplios tratan cada vez más a la población no humana como parte de su ámbito de aplicación por defecto.

Enfoques modernos sobre la seguridad de la identidad no humana

El panorama de las herramientas se ha estructurado en cinco categorías independientes de los proveedores: detección e inventario, gestión y almacenamiento de secretos, gestión de derechos y gobernanza del acceso, estructuras de identidad de cargas de trabajo y detección de comportamientos para entidades de máquina. La mayoría de los programas combinan dos o tres de estas categorías, en lugar de adquirir una sola solución.

Evalúa en función de criterios, no de candidatos. Pregunta hasta qué punto llega la detección en entornos de « cloud », SaaS y locales, y si la herramienta asigna la titularidad en lugar de limitarse a enumerar identidades. Compruebe la variedad de tipos de credenciales que se cubren y si la automatización de la rotación tiene en cuenta las dependencias de producción en lugar de dar por hecho que no existen. Pregunte si la detección de comportamientos está ajustada para entidades de máquina o si se hereda de modelos humanos, y confirme que los datos de evidencia generados estén listos para auditorías, ya que tanto la detección y respuesta ante amenazas de identidad como las pruebas de cumplimiento normativo se basan en la misma telemetría. La tendencia es clara: las claves secretas permanentes están dando paso a identidades de cargas de trabajo de corta duración y verificadas.

Cómo enfoca « Vectra AI » la seguridad de la identidad no humana

Vectra AI parte de la premisa de que se da por hecho que existe una vulnerabilidad. Si una identidad no humana puede autenticarse, puede ser objeto de abuso, y la verdadera pregunta es si alguien se daría cuenta. La metodología es conductual: los sujetos de seguridad de las máquinas necesitan valores de referencia diseñados para máquinas, no métodos de detección heredados de los humanos.

‍