Las identidades no humanas ya son el agujero favorito de los atacantes

Las cuentas que más riesgo generan en muchas empresas ya no tienen nombre y apellidos. Tienen tokens, secretos embebidos, permisos excesivos y una vida útil que nadie controla del todo. Hablamos de identidades no humanas: aplicaciones, cuentas de servicio, APIs, contenedores, funciones serverless, agentes CI/CD, robots RPA y workloads automatizados que piden acceso a sistemas críticos sin pasar por recepción. Y lo hacen a escala industrial.

La noticia no sorprende a quien lleve tiempo mirando arquitectura cloud con algo más que fe. Lo llamativo es otra cosa: durante años, las organizaciones han dedicado presupuestos enteros a la identidad humana —MFA, SSO, PAM para administradores, campañas contra el phishing— mientras dejaban que miles de credenciales de máquina crecieran como malas hierbas. El resultado es un desequilibrio bastante serio. Si el atacante encuentra una clave de API olvidada en un repositorio, una cuenta de servicio con privilegios permanentes o un token sin rotación, el discurso de “confianza cero” se queda en merchandising.

El punto ciego tiene nombre técnico, y cada vez más presencia en los informes de la industria: machine identities, non-human identities o NHI. La CISA lleva tiempo insistiendo en la mala gestión de credenciales, secretos y privilegios como factor recurrente en intrusiones. NIST, en su Cybersecurity Framework 2.0 publicado el 26 de febrero de 2024, ha reforzado el peso de la gobernanza y del control de identidades dentro de las funciones Govern y Protect. Y mientras tanto, en el mundo real, el volumen de identidades de máquina ya supera con holgura al de usuarios humanos en muchas organizaciones medianas y grandes. No hace falta una cifra universal para entender la gravedad: basta mirar cualquier entorno de Kubernetes, cualquier pipeline de despliegue o cualquier integración SaaS medianamente compleja.

Aquí está el quid: las identidades no humanas no son un problema accesorio de DevOps. Son un problema central de ciberseguridad, resiliencia operativa y cumplimiento. También de gobierno. Porque cuando una entidad no sabe cuántas credenciales de máquina tiene, qué permisos usan, dónde están los secretos, quién es su propietario y cuándo caducan, no tiene un incidente esperando ocurrir. Tiene varios.

No son usuarios, pero actúan como si lo fueran

El error más común es tratarlas como “credenciales técnicas” sin más. No lo son. Una identidad no humana autentica, accede, ejecuta acciones, llama a APIs, mueve datos, despliega código, consulta bases de datos y, en demasiados casos, hereda privilegios que ningún humano conseguiría sin pasar por cuatro comités y dos auditorías. La diferencia es que la máquina no se queja, no pide vacaciones y no abre tickets. Por eso mismo se queda fuera del radar.

Una cuenta de servicio en Active Directory, un rol de IAM en AWS, una managed identity en Azure, un service account en Kubernetes, un token de GitHub Actions, una clave SSH usada por automatismos o un secreto almacenado en variables de entorno son expresiones distintas del mismo fenómeno: software que necesita demostrar quién es para acceder a algo.

La complejidad se dispara por tres motivos muy concretos. Primero, escala. Cada microservicio, integración, pipeline o contenedor puede generar varias identidades asociadas. Segundo, efimeridad. En entornos cloud nativos, muchos workloads nacen y mueren en minutos, pero los privilegios que los respaldan pueden durar meses. Tercero, opacidad organizativa. El equipo de seguridad suele ver la política; el equipo de plataforma ve la implementación; el propietario de la aplicación ve la urgencia del negocio. Nadie ve el mapa completo.

Esa fractura organizativa explica por qué las identidades no humanas se han convertido en un vector tan atractivo. El atacante no necesita “hackear la IA” ni inventar nada futurista. Le basta con robar un token válido, explotar una mala configuración de permisos o encadenar una exposición de secretos desde repositorios, logs, artefactos CI/CD o imágenes de contenedor. Más barato, más silencioso y, a menudo, más eficaz que perseguir a un directivo por phishing durante semanas.

Por qué este problema se ha agravado ahora

El crecimiento de las identidades no humanas no es una moda terminológica. Es la consecuencia directa de tres cambios de arquitectura que ya no tienen vuelta atrás.

El primero es la adopción masiva de cloud e infraestructuras híbridas. Cuando una empresa desplaza parte de su operación a AWS, Azure o Google Cloud, no traslada simplemente servidores; traslada relaciones de confianza. Cada servicio gestionado, cada función, cada integración con almacenamiento, mensajería o base de datos introduce permisos máquina a máquina. En AWS, por ejemplo, eso suele traducirse en roles y políticas IAM; en Azure, en service principals y identidades gestionadas; en Kubernetes, en service accounts y tokens asociados. La superficie crece aunque la plantilla no crezca un solo empleado.

El segundo cambio es la automatización agresiva. CI/CD, infraestructura como código, RPA, scripts de operación, bots internos, orquestación SOAR: todo eso reduce fricción y acelera despliegues, pero también multiplica credenciales con privilegios. Cuando funciona, nadie pregunta. Cuando una de esas credenciales se filtra, medio entorno queda expuesto con una elegancia casi insultante.

El tercero es el ecosistema API. Las empresas ya no operan como castillos con foso, sino como centrales de intercambio. Se conectan con proveedores, fintechs, clientes, marketplaces, herramientas de marketing, plataformas de datos, ERP y servicios de analítica. Cada conexión exige autenticación. OAuth, tokens estáticos, certificados, claves de firma, secretos compartidos. El problema no es usar APIs; el problema es desplegar miles sin un inventario fiable, sin clasificación de criticidad y sin rotación disciplinada.

Por eso el riesgo ha dejado de ser teórico. Los secretos expuestos en repositorios públicos siguen apareciendo con una regularidad deprimente. GitGuardian, proveedor especializado en detección de secretos, lleva años documentando la escala del problema en código expuesto y colaborativo. No hace falta asumir cada cifra como verdad universal para extraer la lección correcta: los secretos se filtran más de lo que las organizaciones admiten, y una parte sustancial de esos secretos no pertenece a personas, sino a sistemas.

Cuando una credencial de máquina cae, el impacto puede ser peor que con un usuario

Hay una razón sencilla. Muchas identidades no humanas nacen para “que las cosas funcionen”, no para cumplir el principio de mínimo privilegio. Eso se traduce en permisos amplios, persistentes y difíciles de revisar. Un usuario humano puede tener MFA, revisiones trimestrales, segregación de funciones y caducidad de accesos. Una cuenta de servicio, no siempre.

El patrón se repite. Un equipo crea una cuenta técnica para conectar una aplicación con una base de datos. Le concede permisos de lectura y escritura “por si acaso”. Más tarde esa misma cuenta se reutiliza para otra integración. Nadie documenta el propietario real. La contraseña no rota porque rompería producción. Años después, esa cuenta sigue viva, con privilegios que superan a los de varios empleados y con trazabilidad dudosa. Si el atacante la roba, el movimiento lateral resulta bastante cómodo.

Eso explica por qué la gestión deficiente de identidades de máquina suele estar vinculada a tres escenarios de impacto alto:

Exfiltración de datos. Un token de aplicación con acceso a almacenamiento, CRM o lago de datos permite sacar información sin disparar las mismas alarmas que un acceso humano anómalo.

Persistencia. Una identidad técnica comprometida puede mantenerse activa durante meses si carece de rotación, revisión de uso o propietario claro.

Escalada y pivotaje. Los atacantes buscan roles con permisos transitivos: una función que puede asumir otro rol, un pipeline con permisos de despliegue o un secreto que abre la puerta al gestor de claves.

La ironía amarga es que muchas organizaciones creen haber avanzado mucho porque implantaron SSO corporativo y MFA para empleados. Bien. Eso era obligatorio. Pero si luego los pipelines despliegan con tokens permanentes, los contenedores arrastran secretos en texto claro y las APIs internas aceptan credenciales sin caducidad, la casa sigue teniendo la puerta trasera abierta. Y el ladrón, por supuesto, ya la ha visto.

Lo que dicen los marcos serios, sin maquillaje comercial

No existe una ley europea dedicada exclusivamente a las identidades no humanas. Lo que existe es algo más incómodo: varias normas y marcos que, combinados, hacen muy difícil justificar una gestión laxa de credenciales técnicas.

NIST CSF 2.0, publicado por el National Institute of Standards and Technology el 26 de febrero de 2024, no entra a resolver por sí solo el problema, pero sí deja claro el enfoque. En la función Protect, la categoría PR.AA aborda gestión de identidades, credenciales y control de acceso para usuarios, servicios y activos autenticados. No es un capricho semántico: servicios y activos autenticados están dentro de la conversación. En una auditoría madura, decir “eso era una cuenta de máquina” ya no exonera a nadie.

NIST SP 800-207 sobre Zero Trust Architecture también es útil aquí. Aunque su foco no sea regulatorio, insiste en autenticación continua, acceso contextual y eliminación de confianza implícita. Trasládelo a machine identities y la traducción es obvia: credenciales efímeras, privilegios mínimos, fuerte atestación de workload y supervisión constante. Lo contrario de dejar secretos estáticos en variables de entorno y esperar lo mejor.

En Europa, NIS2 aprieta por el lado de la gobernanza y de la gestión del riesgo. El artículo 21 de la Directiva (UE) 2022/2555 obliga a las entidades esenciales e importantes a adoptar medidas técnicas, operativas y organizativas adecuadas y proporcionadas. Entre ellas figuran políticas de análisis de riesgos y seguridad de los sistemas de información, gestión de incidentes, seguridad de la cadena de suministro, seguridad en la adquisición, desarrollo y mantenimiento de redes y sistemas, y evaluación de la eficacia de las medidas. Si una organización depende de APIs, automatismos y cuentas de servicio para operar, las identidades no humanas quedan atrapadas de lleno en ese perímetro. Ignorarlas ya no es una omisión técnica; puede convertirse en una deficiencia de gobierno.

DORA eleva aún más la presión en el sector financiero. El Reglamento (UE) 2022/2554 exige un marco interno sólido de gestión del riesgo TIC. El artículo 6 obliga a contar con un marco integral de gestión de riesgo de las TIC. El artículo 8 entra en la identificación, clasificación y documentación de las funciones empresariales, activos de información y dependencias TIC. El artículo 9 trata la protección y prevención, incluyendo políticas, procedimientos, protocolos y herramientas para minimizar el impacto de incidentes TIC. Y el artículo 28, clave para terceros proveedores de servicios TIC, obliga a gestionar riesgos derivados de dependencias externas. Si una entidad financiera no sabe qué identidades de máquina usan sus proveedores, qué accesos conservan y cómo se revocan, tiene un problema operativo y regulatorio a la vez.

GDPR tampoco se queda al margen cuando estas identidades acceden a datos personales. El artículo 5.1.f exige integridad y confidencialidad. El artículo 24 impone responsabilidad proactiva del responsable del tratamiento. El artículo 32 obliga a aplicar medidas técnicas y organizativas apropiadas para garantizar un nivel de seguridad adecuado al riesgo. Una cuenta de servicio con acceso desproporcionado a datos personales y sin controles de rotación o monitorización no encaja bien con ese mandato, por decirlo con suavidad.

No hace falta forzar el análisis. Ninguna de estas normas te dirá “implante una plataforma de machine identity security antes del viernes”. Lo que sí hacen es cerrar el espacio para la dejadez. Si el acceso automatizado sostiene procesos críticos, debe estar gobernado, trazado y controlado. Punto.

La relación incómoda entre DevOps, seguridad y cumplimiento

El choque cultural es conocido. DevOps quiere velocidad, reutilización y despliegues sin fricción. Seguridad quiere trazabilidad, rotación, revisión de privilegios y límites estrictos. Cumplimiento quiere evidencia. Las identidades no humanas se sitúan justo en la intersección donde todos tienen parte de razón y nadie quiere asumir todo el trabajo.

El problema aparece cuando el diseño del control se hace tarde. Si la seguridad de identidades de máquina se introduce al final del ciclo, el equipo técnico la percibe como un freno y busca atajos. Aparecen entonces secretos codificados en scripts, excepciones permanentes, cuentas compartidas entre aplicaciones, certificados sin inventario central y permisos inflados para “desatascar” una integración. Nadie lo documenta como mala práctica. Se documenta como urgencia del negocio. Luego llega una revisión interna o un incidente y el atajo adquiere, de repente, su nombre real.

La solución no pasa por moralizar a los equipos de ingeniería. Pasa por diseñar controles que encajen en la automatización. Secret managers integrados en pipelines, identidades efímeras, emisión dinámica de credenciales, certificados con ciclos de vida automáticos, políticas de acceso basadas en atributos, y detección de secretos en repositorios antes de hacer merge. Si el control exige burocracia manual para cada despliegue, perderá. Siempre.

Esto explica por qué la discusión ya no pertenece solo al CISO. También es de plataforma, arquitectura, ingeniería y riesgo operacional. La identidad no humana es infraestructura crítica disfrazada de detalle técnico.

Los cinco fallos operativos que se repiten en casi todas partes

Conviene aterrizar el problema. No en teoría, sino en los errores concretos que aparecen una y otra vez.

1. No existe inventario fiable

La organización sabe cuántos empleados tiene. No sabe cuántas cuentas de servicio activas, tokens API, certificados de cliente, secretos de despliegue o roles de workload existen en producción. Sin inventario no hay propietario, sin propietario no hay revisión y sin revisión el privilegio se vuelve permanente por inercia.

La prueba de madurez aquí es sencilla: si preguntas quién es dueño de una identidad técnica concreta, cuándo se usó por última vez y qué proceso de negocio soporta, alguien debería responder en minutos, no tras dos semanas de arqueología interna.

2. Permisos excesivos por diseño

Las políticas “comodín” siguen siendo demasiado frecuentes. En cloud público, conceder más permisos de los necesarios para evitar errores de integración es tentador. Luego llega el olvido. El mínimo privilegio exige revisar permisos efectivos, no solo permisos declarados. Y en entornos con decenas de cuentas y roles encadenados, esa revisión es cualquier cosa menos trivial.

3. Secretos de larga duración

Tokens y claves que duran meses o años. Certificados renovados manualmente. Credenciales incrustadas en código, imágenes o ficheros de configuración. Cada secreto persistente es una invitación a que alguien lo reutilice donde no debe o a que termine en un log, un ticket o un repositorio. La existencia de gestores de secretos maduros hace que esta práctica sea menos defendible cada año.

4. Falta de telemetría útil

Muchas empresas registran eventos, sí. Otra cosa es que puedan responder preguntas valiosas: qué identidad de máquina accedió a qué recurso, desde qué contexto, con qué frecuencia, y si ese patrón se desvía del comportamiento esperado. Sin esa visibilidad, la detección llega tarde o no llega.

5. Revocación torpe o inexistente

Cuando un proveedor termina contrato, una aplicación se retira o un pipeline cambia, las identidades asociadas deberían desaparecer o perder acceso. En la práctica, sobreviven. Algunas porque nadie recuerda que existen. Otras porque quitarlas “podría romper algo”. Es decir: permanecen activas precisamente porque son peligrosas y opacas.

Qué deberían hacer de verdad los CISOs, no lo que pone en las diapositivas

La respuesta útil no es comprar una herramienta y dar el asunto por resuelto. La respuesta empieza por una decisión de gobierno: tratar las identidades no humanas como una clase de activo de riesgo con ciclo de vida propio. Si eso no está reconocido formalmente, todo lo demás será parcial.

El primer paso serio es clasificar. No todas las identidades de máquina merecen el mismo tratamiento. Una cuenta de monitorización interna no tiene el mismo riesgo que un rol con acceso a pagos, datos de clientes o despliegue en producción. Clasifique por criticidad del proceso, sensibilidad del dato, privilegio efectivo y alcance lateral posible. Esa taxonomía permite priorizar sin perderse en el volumen.

El segundo paso es asignar propiedad inequívoca. Cada identidad no humana debe tener un propietario técnico y un propietario de negocio, aunque sea el mismo equipo. Si no hay nombre de responsable, hay abandono organizado.

El tercero es reducir la persistencia. Donde sea posible, use credenciales efímeras, federación, emisión dinámica de secretos y certificados de corta duración. En Kubernetes y cloud nativo esto no es ciencia ficción; es la dirección natural. Lo que sobra es tolerancia a seguir con secretos permanentes.

El cuarto paso es revisar el privilegio en uso, no solo el concedido. Esto exige telemetría y análisis. Si una identidad usa de forma habitual el 10% de los permisos concedidos, el 90% restante es superficie de ataque financiada por la propia empresa.

El quinto paso es integrar seguridad en el flujo de desarrollo. Escaneo de secretos en repositorios, bloqueo de commits con claves expuestas, políticas de infraestructura como código revisables, y aprobación automatizada para cambios de permisos sensibles. Si estos controles viven fuera del pipeline, llegarán tarde.

Y el sexto, que demasiadas veces se deja para “fase dos”, es la revocación. Cree procedimientos probados para desactivar identidades comprometidas o innecesarias sin improvisar en plena crisis. Porque el día del incidente, descubrir que nadie sabe qué rompe una cuenta de servicio al deshabilitarla es una experiencia poco edificante.

Qué deben preguntar los consejos y los comités de riesgo

Si el consejo solo recibe métricas sobre phishing, parches y formación, está viendo una parte cada vez menos representativa del problema. Las identidades no humanas son lo bastante críticas como para entrar en el nivel de supervisión adecuado, sobre todo en sectores regulados.

Las preguntas útiles no son técnicas en exceso, pero sí incómodas:

¿Tenemos inventario actualizado de identidades no humanas en procesos críticos?

¿Qué porcentaje usa credenciales de larga duración frente a mecanismos efímeros o federados?

¿Cuántas carecen de propietario asignado?

¿Con qué frecuencia revisamos permisos efectivos y revocamos accesos no usados?

¿Cómo detectamos exposición de secretos en repositorios, tickets, artefactos y logs?

¿Qué dependencias de terceros conservan acceso máquina a máquina a nuestros sistemas?

Esas preguntas enlazan directamente con DORA, NIS2 y con cualquier marco interno de apetito de riesgo. También sirven para separar a las organizaciones que gobiernan su superficie de identidad de las que simplemente acumulan herramientas.

Implicaciones para entidades financieras españolas

Aquí la cuestión deja de ser abstracta. Bancos, aseguradoras, entidades de pago, EAF, gestoras y proveedores tecnológicos que caigan dentro de DORA operan con una densidad de integraciones y automatismos especialmente alta. APIs con terceros, motores de fraude, pipelines de despliegue, herramientas de observabilidad, plataformas SaaS, servicios de firma, modelos analíticos, robots de back office. Todo eso vive de identidades no humanas.

DORA empezó a aplicar el 17 de enero de 2025. A partir de esa fecha, la conversación ya no es si la entidad conoce el riesgo, sino si puede demostrar control suficiente. El artículo 8 obliga a identificar y documentar activos TIC y sus interdependencias. Si las identidades de máquina que conectan esos activos no están inventariadas y asociadas a funciones de negocio, esa documentación nace incompleta. El artículo 9 exige medidas de protección y prevención. Mantener secretos estáticos sin rotación ni monitoreo en procesos críticos casa mal con ese deber. Y el artículo 28 sobre gestión de riesgos de terceros TIC mete presión adicional: accesos técnicos de proveedores, integradores y servicios cloud deben estar delimitados, documentados y revisados.

Para entidades sujetas también a supervisión del Banco de España, CNMV o Dirección General de Seguros según el caso, el asunto encaja además con expectativas tradicionales de control interno, segregación de funciones y trazabilidad. No hace falta que el supervisor publique una circular con el título “identidades no humanas” para que termine preguntando por ellas durante una inspección de resiliencia o de outsourcing.

Hay otro ángulo relevante: notificación de incidentes. Si una credencial de máquina comprometida afecta disponibilidad, autenticidad, integridad o confidencialidad de servicios críticos, la entidad puede verse empujada a sus procesos de clasificación y reporte de incidentes bajo DORA, y eventualmente a análisis de impacto sobre datos personales bajo GDPR, incluidos los plazos del artículo 33 si existe violación de seguridad de datos personales notificable en 72 horas. Una sola identidad técnica mal controlada puede activar varias obligaciones a la vez. Eficiencia regulatoria, lo llaman algunos. Los equipos de respuesta lo describirían con palabras menos elegantes.

La seguridad de APIs y la de identidades no humanas ya son la misma conversación

Separarlas es un error. Cada vez que una API confía en un secreto estático, en un token sin límites o en una identidad de cliente demasiado privilegiada, la seguridad de la interfaz depende de la seguridad de la identidad no humana que la consume. Y viceversa.

OWASP lleva años advirtiendo de fallos recurrentes en APIs, desde control de autorización roto hasta gestión deficiente de autenticación y exposición excesiva de datos. En la práctica, muchas de esas debilidades se agravan porque el cliente autenticado no es una persona, sino otro sistema. Los equipos asumen entonces que “si la llamada viene de una aplicación conocida”, el riesgo es menor. Grave error. Si esa aplicación guarda mal sus secretos o su identidad ha sido comprometida, la API no está hablando con un socio fiable, sino con un intruso bien disfrazado.

Eso obliga a revisar patrones concretos: tokens acotados por audiencia y duración, mutual TLS donde proceda, segregación de clientes por privilegio, revocación granular, análisis de comportamiento y validación fuerte del contexto de ejecución. Todo esto suena menos glamuroso que hablar de “IA defensiva”, pero reduce riesgo real. Mucho.

Lo que el mercado está vendiendo, y lo que de verdad hace falta

Como era de esperar, el mercado ya ha olido la sangre. Han proliferado plataformas de machine identity security, secrets management, workload identity, CNAPP, DSPM y otras siglas con talento comercial. Algunas resuelven problemas muy reales. Otras simplemente empaquetan visibilidad parcial con un nombre más fresco.

La pregunta correcta no es “qué herramienta compro”, sino “qué capacidad necesito”. Si una empresa carece de inventario, propiedad, telemetría y proceso de revocación, la tecnología debe apoyar esas cuatro capacidades. No sustituirlas con promesas de descubrimiento mágico. Una herramienta excelente no arregla un modelo operativo en el que nadie acepta ser dueño de una cuenta técnica crítica.

También conviene desconfiar del espejismo del escaneo puntual. Descubrir secretos expuestos una vez está bien. Controlar el ciclo de vida completo de las identidades no humanas está bastante mejor. Lo primero detecta síntomas. Lo segundo trata la enfermedad.

La objeción habitual: “esto siempre ha existido”

Correcto. Las cuentas de servicio no nacieron ayer. Las credenciales técnicas tampoco. La objeción falla en otro punto: el volumen, la velocidad y la criticidad han cambiado de escala. Una cuenta técnica en un CPD tradicional no equivale a miles de identidades efímeras y persistentes dispersas entre cloud, SaaS, contenedores, pipelines y proveedores.

También ha cambiado el coste del error. Con arquitecturas más interconectadas, una sola identidad comprometida puede tocar más sistemas, más datos y más procesos críticos que hace diez años. Y puede hacerlo con menos fricción. Antes, el atacante debía atravesar varios controles. Ahora, si roba el secreto correcto, a veces entra por la puerta de servicio con acreditación completa.

Negar la gravedad porque “esto ya existía” es como restar importancia a una fuga porque el agua lleva siglos inventada. El detalle relevante no es la antigüedad del elemento. Es la magnitud de la grieta.

Qué vigilar en los próximos 12 meses

Hay cuatro movimientos que merece la pena seguir de cerca.

Primero, una integración más fuerte entre gestión de secretos, seguridad cloud y gobierno de identidades. La fragmentación actual es insostenible en organizaciones grandes.

Segundo, más presión regulatoria indirecta. NIS2 y DORA no van a citar cada patrón técnico, pero sí van a empujar a evidenciar control, especialmente sobre activos críticos y terceros.

Tercero, mejor instrumentación en pipelines y plataformas de desarrollo. Las organizaciones maduras dejarán de perseguir secretos solo en producción y moverán el control mucho antes, al punto de creación.

Cuarto, un cambio de métricas. Veremos menos obsesión exclusiva por cuentas humanas privilegiadas y más foco en credenciales de máquina sin propietario, secretos de larga duración, privilegios no usados y accesos de terceros automatizados.

Ese cambio de métricas importa porque cambia la conversación presupuestaria. Cuando una empresa descubre que la mayor parte de sus identidades con acceso a procesos críticos no son humanas, ya no puede seguir asignando recursos como si el problema principal fuese solo el empleado que cae en un phishing.

La conclusión incómoda

Las identidades no humanas se han beneficiado durante años de un privilegio extraordinario: ser esenciales para operar y demasiado aburridas para el consejo. Ese tiempo se ha terminado. No porque un medio lo diga, sino porque la arquitectura tecnológica actual ha convertido esas identidades en la capa de confianza que sostiene buena parte del negocio digital.

Si esa capa está mal gobernada, el resto del discurso de seguridad se resiente. Da igual cuántas veces se repita “zero trust”, cuántos simulacros de phishing se lancen o cuántos dashboards verdes enseñe el proveedor de turno. Si una organización no puede responder con precisión cuántas identidades no humanas tiene, cuáles son críticas, qué permisos usan realmente, cómo rotan sus credenciales y cómo se revocan cuando sobra confianza, tiene una brecha estructural.

Y las brechas estructurales tienen una mala costumbre: no avisan antes de hacerse noticia.