Identidades no humanas en ataques de identidad: el gran punto ciego

Hoy, en casi cualquier empresa mínimamente digitalizada, circulan miles de identidades no humanas que abren puertas, mueven datos y ejecutan procesos sin que nadie les preste demasiada atención. Mientras los equipos de seguridad siguen vigilando usuarios, contraseñas y MFA, el auténtico “ejército” que hace de pegamento entre aplicaciones y servicios son cuentas de servicio, claves API, tokens, bots y agentes de IA.

El problema es que estas identidades técnicas han crecido a un ritmo brutal, están mal inventariadas, apenas tienen gobernanza y suelen acumular privilegios que nadie revisa. Cuando una de ellas se ve comprometida, el atacante no solo hereda su acceso, sino que aprovecha una superficie donde no hay MFA, el monitoreo es limitado y casi nunca está claro quién es su responsable. Esa combinación las convierte en una pieza crítica en los ataques de identidad modernos.

Qué son las identidades no humanas y por qué son tan relevantes

En seguridad de la información, se considera identidad no humana (NHI) a cualquier credencial digital utilizada por máquinas, aplicaciones o procesos automatizados para autenticarse y acceder a recursos sin intervención directa de una persona. Entran aquí cuentas de servicio, claves API, secretos de aplicaciones, identidades gestionadas en la nube, tokens OAuth, certificados y, cada vez más, bots y agentes de inteligencia artificial.

Estas identidades cumplen, en esencia, la misma función que una cuenta de usuario tradicional: demostrar quién es “algo” ante un sistema y obtener permisos concretos. La diferencia es que no hay una persona tecleando usuario y contraseña, sino un proceso programático que se autentica con claves, tokens o certificados. Cuando el software de copias de seguridad se conecta a una base de datos a las dos de la mañana, lo hace gracias a una cuenta de servicio; cuando un CRM habla con un sistema de tickets, lo hace mediante una clave API.

En la práctica, en muchas organizaciones las identidades de máquina ya superan en número a las humanas por ratios que van de 10:1 hasta 45:1 o más, según distintos estudios de la industria. Cada recurso en la nube, cada pipeline de CI/CD, cada microservicio o integración entre SaaS genera nuevas credenciales técnicas. Y, pese a esa explosión, la mayoría de marcos de seguridad y procesos internos siguen diseñados pensando en usuarios humanos.

Este desfase crea un punto ciego evidente: las políticas y controles clásicos de IAM (contraseñas, MFA, SSO, revisiones de acceso) se adaptan mal a un entorno donde la autenticación es automática, las credenciales están incrustadas en código o almacenadas como secretos, y el ciclo de vida no lo marca Recursos Humanos sino los desarrolladores y los equipos de operaciones.

Diferencias clave entre identidades humanas y no humanas

Entender dónde chocan ambos mundos ayuda a ver por qué los ataques de identidad están girando cada vez más hacia las NHIs. Hay cuatro diferencias fundamentales en propiedad, autenticación, ciclo de vida y comportamiento.

En primer lugar, la propiedad: una identidad humana suele tener un dueño clarísimo (una persona concreta con un manager, un contrato y un rol). En cambio, las identidades no humanas suelen quedar “huérfanas” o con ownership difuso. Pueden ser responsabilidad parcial de un equipo de desarrollo, de operaciones, de un proveedor o de “alguien que montó esto hace años”. Cuando llega el momento de revisar permisos o desactivar algo, nadie levanta la mano.

En segundo lugar, el mecanismo de autenticación. Los humanos usan contraseñas, a menudo protegidas con MFA y, cada vez más, con SSO. Las NHIs se apoyan en tokens portadores, claves API, certificados, claves SSH o identidades gestionadas de los proveedores cloud. En casi todos los casos, no existe un segundo factor: si un atacante roba la credencial, tiene vía libre hasta donde lleguen esos permisos.

En cuanto al ciclo de vida, las identidades humanas se gobiernan a través de procesos relativamente maduros de alta, cambios de rol y baja, ligados a RR. HH. y a sistemas de onboarding/offboarding. Las identidades no humanas nacen, cambian y mueren (o, peor, no mueren) por decisión de desarrolladores, administradores o herramientas de automatización. Rara vez pasan por un flujo formal de aprobación, documentación y revisión periódica.

Por último, el comportamiento: el acceso humano es interactivo, irregular y contextual. El acceso no humano es programático y repetitivo: un script lanza siempre las mismas consultas, un servicio hace la misma llamada a una API, un pipeline de CI/CD despliega siempre de la misma manera. Esto facilita definir líneas base de comportamiento, pero complica mucho la revisión manual a gran escala porque el volumen de eventos se dispara.

Métodos habituales de autenticación de identidades no humanas

Las NHIs no “inician sesión” en el sentido convencional, sino que se autentican de forma automática mediante diferentes tipos de credenciales. Los cuatro grandes enfoques que se ven en la mayoría de entornos son los siguientes.

El primero es la autenticación basada en token: claves API, tokens JWT y tokens portadores que se usan en integraciones de servicios, acceso a APIs y flujos OAuth. Estos tokens suelen viajar en cabeceras HTTP y, si se filtran, permiten suplantar la identidad de la aplicación o servicio.

En segundo lugar, la autenticación basada en claves, con especial protagonismo de claves SSH y claves asociadas a cuentas de servicio. Son típicas en conexiones a servidores, automatizaciones de administración de sistemas o despliegues. Cuando estas claves no rotan o se reutilizan en múltiples máquinas, el riesgo se multiplica.

El tercer enfoque son los certificados, habitualmente certificados X.509 y TLS mutuo (mTLS) para identificar máquinas y asegurar comunicaciones. Aquí, la identidad se ancla a un certificado emitido por una autoridad de confianza, que permite verificar que una máquina o servicio es quien dice ser.

Por último, encontramos la federación de identidad de carga de trabajo en nubes públicas: roles de AWS IAM, identidades gestionadas de Azure o cuentas de servicio de GCP. En este modelo, una aplicación que corre en la nube asume dinámicamente un rol con permisos definidos, sin necesidad de almacenar credenciales fijas, lo que reduce parte del riesgo… pero no elimina la necesidad de gobernanza y buen diseño de permisos.

El denominador común de todos estos métodos es que ninguno suele estar protegido por MFA ni por controles de login interactivo. Una vez comprometida la credencial, el atacante hereda todo el alcance de esa identidad técnica.

Principales tipos de identidades no humanas en la empresa

Para gestionar el problema con cierta seriedad, lo primero es clasificar las distintas familias de NHIs que existen en un entorno típico. Cada categoría tiene matices y retos de seguridad propios, pero comparten patrones de riesgo.

Una primera familia son las cuentas de servicio e identidades de aplicación. En entornos on-premise con Active Directory, las cuentas de servicio permiten que aplicaciones como el backup, el monitoreo o los servicios web accedan a bases de datos, sistemas de ficheros o recursos de red. Se identifican a menudo por el atributo ServicePrincipalName (SPN). El gran problema es que sus contraseñas se cambian poco o nada, y esas cuentas terminan acumulando privilegios con el paso del tiempo.

En el mundo Windows moderno, una buena práctica es migrar estas cuentas a Group Managed Service Accounts (gMSA), que permiten una gestión automática y segura de contraseñas desde Active Directory, sin que los administradores tengan que manipularlas directamente. En la nube, el equivalente conceptual serían las identidades de aplicación asignadas por los proveedores para acceder a APIs, bases de datos y servicios gestionados.

Otra categoría clave son las claves API y otros secretos de aplicaciones. Estos secretos permiten que un sistema se autentique frente a otro sin que intervenga un usuario. Se incrustan en integraciones internas, conexiones con herramientas SaaS, servicios de terceros, impresoras que reportan consumos al fabricante, equipos industriales que envían telemetría, etc. El riesgo aquí es doble: suelen ser credenciales estáticas, sin caducidad, y tienden a acabar repartidas en repositorios de código, variables de entorno, archivos de configuración o incluso en chats.

A esto se suman los secretos almacenados en bóvedas o ficheros (cadenas de conexión, contraseñas de bases de datos, claves de cifrado y similares). Aunque a menudo se les trate como “algo menos crítico”, en realidad proporcionan acceso directo a datos sensibles y sistemas núcleo. Una vez filtradas estas credenciales, el atacante puede pivotar con mucha facilidad entre servicios y, si afecta a integraciones con terceros, el impacto se extiende a la cadena de suministro digital, foco de marcos como NIS2 o DORA.

También debemos considerar las identidades gestionadas por los proveedores cloud, como las Managed Identities en Azure. Este modelo elimina la necesidad de almacenar claves o contraseñas, ya que el propio servicio en la nube proporciona un token de acceso seguro ligado al recurso. Es un avance claro, pero solo resuelve el problema dentro del perímetro de ese proveedor; las credenciales híbridas y las cuentas on-premise siguen requiriendo visibilidad y control.

Los tokens OAuth forman otra pieza importante del puzle. Son la base de muchas integraciones de terceros: sincronización de datos de RR. HH. con proveedores de identidad, herramientas de reporting que extraen información de un CRM SaaS, plataformas de marketing conectadas al correo corporativo, etc. Estos tokens de actualización pueden vivir mucho más tiempo del previsto, quedarse olvidados en integraciones antiguas y mantener un acceso mucho más amplio del que nadie recuerda.

En entornos cloud nativos también proliferan las identidades de carga de trabajo para contenedores, funciones serverless y máquinas virtuales. Kubernetes, las funciones Lambda, Azure Functions o pods en clústeres gestionados generan identidades que necesitan permisos para leer y escribir en almacenamiento, consumir APIs o publicar en colas de mensajes. Estas identidades son efímeras, se crean y destruyen constantemente, y su volumen crece muy por encima de la capacidad humana de seguimiento manual.

No hay que olvidar las identidades de máquinas y dispositivos físicos o virtuales: servidores, VMs, routers, dispositivos IoT, sensores, cámaras, componentes de red, etc. Suelen autenticarse mediante certificados o credenciales específicas y añaden una capa adicional al mapa de identidades no humanas, especialmente relevante a medida que crece el IoT industrial y el edge computing.

Por último, una categoría en plena expansión son los bots y agentes de IA. Desde asistentes como Microsoft Copilot que necesitan leer correos y documentos internos, hasta robots de RPA que automatizan procesos en aplicaciones legacy, pasando por agentes de IA que orquestan acciones entre múltiples sistemas, todos ellos operan como identidades no humanas con acceso, a menudo, muy amplio. Además, interactúan con repositorios de código y entornos de desarrollo, lo que puede provocar filtraciones inadvertidas de credenciales en logs, prompts o salidas de herramientas.

Por qué las NHIs se han disparado y complican los ataques de identidad

La explosión de identidades no humanas no es casualidad: responde a la combinación de microservicios, contenedores, automatización masiva y adopción de SaaS de terceros. Cada microservicio que habla con otro necesita credenciales; cada clúster Kubernetes crea cuentas de servicio; cada flujo de integración en la nube genera tokens y claves API.

Además, las empresas están empujando procesos críticos hacia la automatización: copias de seguridad, actualizaciones, orquestación de despliegues, sincronización de datos, autenticación de usuarios… Todo eso se hace ya casi siempre con identidades no humanas en segundo plano, precisamente para no interrumpir al usuario. Esa comodidad operativa viene acompañada de una complejidad de gobernanza enorme.

Los CISOs y responsables de seguridad empiezan a verlo con claridad. Encuestas a líderes de ciberseguridad muestran que las NHIs se perciben ya como uno de los principales puntos de dolor en seguridad de identidad. A la mayoría les preocupa que estos “actores invisibles” tengan privilegios especiales, actúen en nombre de administradores y desarrolladores y, sin embargo, queden fuera de procesos maduros de revisión y control.

A este cóctel se suma el auge de la arquitectura Zero Trust, impulsada por organismos como el NIST. Los documentos fundacionales de Zero Trust dejan claro que no se puede construir un modelo serio que ignore las identidades de máquina, sobre todo cuando se les conceden permisos potentes y se asume que son “de confianza” por defecto.

La magnitud del problema se ve en las cifras: en muchas compañías, las identidades de máquina se han multiplicado por decenas y ya superan con creces a las humanas. En ciertos sectores, se habla incluso de ratios de 144:1. Mientras tanto, un porcentaje muy elevado de organizaciones confiesa no tener inventariado ni protegido este universo de credenciales, almacenar secretos en múltiples sitios dispersos y otorgar a los desarrolladores más privilegios de los necesarios.

Cómo las NHIs alimentan los ataques de identidad modernos

Los atacantes han entendido rápido que las NHIs son un blanco jugoso. Los ataques basados en identidad ya dominan buena parte del panorama, y el abuso de cuentas de servicio, tokens y claves API se está convirtiendo en un vector emergente recurrente en los informes de tendencias.

Uno de los fallos más habituales es la proliferación de secretos en código y artefactos de despliegue. Bajo la presión de entregar rápido, muchos equipos incrustan claves API, contraseñas o tokens directamente en el repositorio, en archivos de configuración o en imágenes de contenedores. De ahí pasan, con mucha facilidad, a repos públicos, documentación compartida o conjuntos de datos indexados en la web.

Investigaciones recientes han encontrado miles de credenciales activas enterradas en grandes repositorios de datos web que luego se usan para entrenar modelos de IA. Eso significa que estos secretos no solo están expuestos, sino que además se convierten en parte del material de entrenamiento de sistemas que, a su vez, pueden ayudar a descubrir o explotar vulnerabilidades similares. Es un círculo vicioso peligroso: la IA se alimenta de datos que contienen fugas de credenciales y puede terminar amplificando el problema.

Otro foco crítico son los problemas de gestión del ciclo de vida. Las cuentas de servicio creadas para un proyecto temporal rara vez se desactivan cuando el proyecto termina. Siguen ahí, con permisos vigentes y sin nadie pendiente de ellas. Las aplicaciones obsoletas dejan detrás identidades fantasma que conservan accesos a datos y sistemas sensibles.

La dinámica de la nube y los contenedores empeora aún más la situación: instancias efímeras, autoescalado, funciones que aparecen y desaparecen, todo ello tirando de identidades creadas sobre la marcha. Sin una capa de descubrimiento y gobernanza sólida, es imposible saber cuántas credenciales de este tipo hay activas, qué pueden hacer y quién las creó.

A esto hay que añadir el efecto de la IA generativa y los agentes autónomos. Estos sistemas son capaces de crear, modificar y usar credenciales por sí mismos, encadenar herramientas entre dominios de confianza y ejecutar acciones con amplios permisos para cumplir objetivos de negocio. El margen para cometer errores de configuración, sobreexponer secretos o autorizar comportamientos no previstos es enorme.

El cambio silencioso: por qué casi nadie lo está midiendo bien

Las identidades humanas, con todos sus problemas, tienen algo a favor: fricción natural y trazabilidad. Se les da de alta con un proceso, piden permisos, se les aplican políticas, sus credenciales caducan, eventualmente abandonan la organización. Hay ciclos reconocibles y puntos de control.

Las identidades no humanas, en cambio, se caracterizan por tres rasgos que las hacen especialmente peligrosas: persisten en el tiempo, escalan permisos por inercia y carecen de dueño claro. Si nadie las busca, se quedan; si algo falla, se les da “un poquito más de permiso” para que no se rompa nada; si preguntas de quién son, la respuesta suele ser vaga.

Cuando se combina permanencia, privilegios crecientes y falta de responsabilidad, el resultado es una bomba de relojería a nivel de seguridad y operación. Cualquier incidente se vuelve difícil de investigar, porque ni siquiera se sabe qué identidades existen, qué datos tocan, qué sistemas pueden modificar o qué depende de ellas.

En muchas empresas, el modelo clásico de IAM se intenta estirar para cubrir estas necesidades, pero el problema no es solo de control técnico, sino de gobernanza. La pregunta adecuada no es “¿tienen MFA?”, porque casi nunca lo van a tener; la pregunta clave es “¿quién es dueño de esta identidad técnica y con qué intención se creó?”.

La realidad es que casi todas estas identidades nacen de decisiones legítimas para hacer avanzar el negocio: integrar el CRM con el soporte, dar acceso temporal a un proveedor, automatizar la copia de datos de un sistema a otro, montar un script para evitar que un equipo se ahogue en trabajo manual, aceptar los roles por defecto que propone un servicio cloud. No hay mala fe, hay prisa.

De la teoría a la práctica: cómo fallan las NHIs en una empresa real

En la mayoría de organizaciones, el problema no estalla como un sofisticado ataque de película. Se manifiesta en situaciones mucho más mundanas pero igual de dañinas. Por ejemplo, un token que se filtra en un repositorio público o en una herramienta de colaboración externa; una cuenta de servicio que sigue viva años después de que el proyecto terminara; una integración SaaS que, tras una actualización, pasa a leer mucha más información de la prevista.

También es frecuente encontrar proveedores con accesos residuales “por si acaso” o automatizaciones a las que se les dieron permisos de escritura totales cuando solo necesitaban leer. Cada una de estas pequeñas decisiones acumula deuda de ciberseguridad y operativa.

Cuando sucede un incidente y hay que investigar, el verdadero dolor aflora: no existe un inventario fiable de identidades no humanas. Nadie puede decir con rapidez qué credencial estaba en juego, qué alcance tenía, qué sistemas tocaba o qué dependencias podía romper si se desactivaba.

El resultado es un miedo muy concreto: nadie se atreve a apagar nada “por si rompe producción”. Esa parálisis es la prueba de que la organización no controla su propia capa de automatización y que la dependencia de identidades no humanas mal gobernadas es crítica.

Cómo descubrir identidades no humanas en tu entorno

Antes de poder controlar algo, hay que encontrarlo. El descubrimiento de NHIs no puede quedar en un ejercicio puntual en Excel; tiene que convertirse en un proceso continuo y, en la medida de lo posible, automatizado.

El primer paso lógico es arrancar desde tu proveedor de identidad. En entornos con Active Directory, conviene listar cuentas con ServicePrincipalName, cuentas de servicio gestionadas y gMSAs. En la nube, hay que obtener inventarios de service principals, registros de aplicaciones e identidades gestionadas desde las consolas de administración o APIs correspondientes.

Para cada identidad encontrada, es clave capturar al menos cuatro atributos: qué aplicación la usa, qué tipo de credenciales tiene, a qué recursos puede acceder y quién es su propietario. Esa base de datos simplificada es ya un salto enorme frente a la opacidad habitual.

Después, hay que bajar a la capa de código y automatización. Trabajando con los equipos de DevOps es posible localizar credenciales almacenadas en pipelines de CI/CD, plantillas de infraestructura como código y variables de entorno. Las herramientas de escaneo de repositorios ayudan a detectar claves API incrustadas y secretos que nunca deberían haber salido del gestor de secretos.

El tercer frente son las integraciones SaaS. Muchas empresas descubren, al revisarlas, docenas de tokens OAuth activos ligados a integraciones antiguas configuradas por personas que ya ni siquiera trabajan allí. Cada uno de esos tokens es una identidad no humana con permisos que casi nadie recuerda.

Por último, todo lo que se descubra debe documentarse con cabeza: propietario nominal (una persona, no un grupo), justificación de negocio, tipo de credencial, política de rotación y fecha de última revisión. Sin esos datos, el inventario es solo una lista estática imposible de operar.

Eso sí, hay una advertencia importante: el descubrimiento manual solo da una foto fija. Los entornos cambian a diario; una exportación trimestral no captura la cuenta de servicio creada el martes ni el token que un equipo generó deprisa para una prueba de concepto. El descubrimiento continuo es lo único que separa a las organizaciones que realmente conocen su población NHI de las que solo creen conocerla.

Criterios para gobernar y asegurar las identidades no humanas

La gestión de identidades no humanas (a menudo llamada NHIM) consiste en descubrir, gobernar y proteger identidades de máquina que IAM y PAM clásicos no cubren bien. Se trata de aplicar disciplina de seguridad donde no hay un actor humano, las credenciales no usan MFA y la creación de identidades no pasa por RR. HH., sino por scripts, pipelines y herramientas.

El primer principio operativo es que ninguna identidad no humana debe existir sin un propietario claramente asignado desde el minuto cero. Esa propiedad debe ser de una persona concreta, no de un alias genérico ni de un “equipo X”. El atributo de dueño tiene que ser obligatorio en cualquier flujo de aprovisionamiento, ya sea manual o automatizado.

El segundo pilar es aplicar el principio de mínimo privilegio desde el diseño. Cada NHI debe recibir solo los permisos estrictamente necesarios, acotados al recurso más específico posible. Las cuentas de servicio con acceso a nivel de suscripción completa o dominio, cuando solo necesitan tocar una base de datos concreta, son un clásico que conviene eliminar.

En tercer lugar, hay que automatizar la rotación de credenciales y la caducidad de accesos siempre que se pueda. En entornos AD, las gMSA solucionan gran parte del problema. En la nube y con claves API, la rotación debe integrarse en los pipelines de despliegue o delegarse en gestores de secretos capaces de renovar credenciales sin impactar en la producción. No existe un periodo de rotación mágico aplicable a todo, pero los marcos de referencia (NIST, CIS, PCI DSS, etc.) apuntan todos a la necesidad de políticas claras basadas en riesgo.

El cuarto elemento es el monitoreo orientado a anomalías de comportamiento. En lugar de revisar cada evento de autenticación, lo importante es detectar cuando una cuenta de servicio empieza a acceder a recursos fuera de su patrón, o cuando una clave API se usa desde ubicaciones geográficas inesperadas. Las líneas base de comportamiento son especialmente útiles en identidades de máquina por lo repetitivo de sus acciones normales.

Quinto, hay que ser agresivos en el descomisionado. Las identidades no humanas obsoletas son uno de los puntos de entrada más explotables. Un buen enfoque es marcar para revisión cualquier NHI que no se haya autenticado en un periodo (por ejemplo, 90 días); si el propietario no justifica su necesidad, desactivarla y, si nadie se queja en otro intervalo razonable, eliminarla.

Por último, resulta imprescindible certificar periódicamente los accesos de las NHIs. Igual que se hacen campañas de recertificación de permisos para usuarios privilegiados, los dueños de las identidades técnicas deben validar, en una cadencia razonable (anual como mínimo, trimestral para cuentas sensibles), que cada identidad sigue siendo necesaria y con el nivel de privilegios adecuado.

Todo esto encaja bien con los grandes marcos regulatorios ya vigentes: CMMC exige control de acceso y gestión de cuentas para todas las identidades, SOC 2 requiere controles de acceso extensivos, HIPAA demanda trazabilidad para todo acceso a información sanitaria (incluidas cuentas de servicio), y normas europeas como NIS2 o DORA ponen el foco en el riesgo de la cadena de suministro digital y en las identidades gestionadas por terceros que acceden a tu entorno. Construir gobernanza de NHIs es, en la práctica, construir evidencia de cumplimiento.

El papel de plataformas especializadas en visibilidad y control

Llegados a este punto, muchas organizaciones descubren que intentar cubrir todo este terreno a mano, con scripts y hojas de cálculo, no es sostenible. Es aquí donde entran en juego plataformas específicas que dan visibilidad continua sobre identidades y sus actividades en directorios y nubes.

Algunas soluciones se centran en ofrecer inventarios vivos de cuentas de servicio, identidades de aplicación y configuraciones de acceso, señalando aquellas con permisos excesivos, inactividad prolongada o configuraciones que violan la política interna. El valor no está solo en la foto actual, sino en poder ver cómo cambia el paisaje a medida que se crean, modifican o eliminan identidades.

Para entornos como Active Directory, herramientas de auditoría avanzada permiten seguir en detalle la creación de cuentas de servicio, los cambios de pertenencia a grupos, los intentos de uso interactivo de identidades técnicas y los cambios en políticas de grupo. Esta trazabilidad facilita responder a auditorías y reconstruir incidentes.

En el caso de identidades privilegiadas no humanas, se impone cada vez más el modelo de privilegios just-in-time, donde el acceso elevado solo se concede durante el tiempo estrictamente necesario y se retira después, incluso para cuentas de servicio. Unido a grabaciones de sesión y registros detallados de actividad, este enfoque reduce el riesgo de credenciales con poder ilimitado y siempre activo.

Al final, el objetivo de todas estas herramientas es sencillo: cerrar la brecha de visibilidad sobre las identidades no humanas, de forma que la seguridad de identidad deje de ser una batalla centrada solo en las personas y pase a cubrir también a la “fuerza de trabajo invisible” que realmente sostiene los flujos digitales modernos.

Todo este recorrido muestra que las identidades no humanas han pasado de ser un detalle técnico a convertirse en la columna vertebral silenciosa y, a la vez, el talón de Aquiles de muchas estrategias de seguridad. Gobernarlas bien implica saber cuántas hay, qué hacen, quién responde por ellas y qué ocurriría si mañana desaparecieran; las organizaciones que consigan responder con claridad a estas preguntas tendrán mucha menos superficie de ataque disponible para campañas basadas en el abuso de credenciales y podrán avanzar en automatización sin seguir acumulando deuda de ciberseguridad.