Un estudio de 2026 de Orchid Security, especializada en seguridad de identidad, analizó el acceso de organizaciones de varios sectores y llegó a un número difícil de justificar: el 40% de las cuentas encontradas pertenecían a personas que ya no trabajan allí. En algunos entornos, ese porcentaje superaba el 60%.
El motivo no es falta de herramienta. Es que la lista de quién puede entrar a qué es, en la mayoría de las empresas, un ejercicio que ocurre una vez al año, hecho a mano, y que ya nace desactualizado al día siguiente. Un cargo cambia, un proyecto termina, un proveedor se va — y el acceso sigue ahí.
Para quien responde por seguridad y cumplimiento, el dato que importa no es solo "sobran cuentas". Es que nadie sabe, en el momento en que pregunta, cuántas de esas cuentas todavía pueden hacer algo.
El tamaño del problema, en números
El mismo estudio de Orchid Security encontró algo peor que la simple acumulación de cuentas: el 22% de las cuentas huérfanas todavía tenía privilegio elevado — es decir, quien ya se fue seguía con poder de administrador en algún sistema. Y una parte relevante de las cuentas de máquina y de integración — las que un sistema usa para comunicarse con otro — nunca pasó por el control central de identidad de la empresa, según el mismo informe.
Ese tipo de cuenta es el punto ciego más común. Una cuenta de aplicación se crea para un proyecto, una integración puntual, una prueba. El proyecto termina, la persona que la creó cambia de equipo o se va de la empresa, y la credencial queda ahí — casi siempre configurada para no expirar nunca, porque hacerla expirar "podría romper algo" que nadie tiene claro qué es.
El riesgo de una credencial válida no es hipotético. Según el informe de investigación de violaciones de datos de 2026 de Verizon, cubierto por Descope, el abuso de credenciales aparece en el 39% de las violaciones analizadas, en algún punto de la cadena del ataque, y el 28% de los casos tenía credenciales entre los datos comprometidos. Una credencial válida, de una cuenta que nadie está mirando, es exactamente el tipo de puerta que ese ataque busca.
Por qué la revisión anual no alcanza
La respuesta más común sigue siendo la planilla: una vez al año, alguien de TI exporta la lista de usuarios de cada sistema, la manda a los gerentes para que confirmen por correo, y espera la respuesta. Ese proceso tiene tres problemas a la vez.
El primero es el desfase. Entre una revisión y la siguiente, las personas cambian de función, los contratos terminan, los proyectos se cierran — y el acceso que tenía sentido en enero puede no tener ningún sentido en julio. El segundo es la cobertura. Las cuentas de aplicación, de integración y de proyectos cerrados casi nunca aparecen en esas planillas, porque no tienen un "dueño" humano obvio que confirme o niegue.
El tercer problema es lo que los auditores de cumplimiento llaman falta de rastro. No basta con que la revisión haya ocurrido: hay que mostrar quién revisó, cuándo y contra qué sistema real — no contra una copia de la lista de meses atrás. Según material sobre auditoría de acceso para la norma ISO 42001, que rige los sistemas de gestión de inteligencia artificial, el auditor verifica si las revisiones ocurren con un ritmo constante y si cada una muestra al revisor, la fecha y la decisión tomada — una revisión sin ese rastro no cuenta como evidencia, aunque se haya hecho de buena fe.
Lo que cambia cuando la revisión es continua
La norma ISO 27001, en su control sobre derechos de acceso, pide revisión en intervalos definidos, con el privilegio administrativo revisado con más frecuencia que el acceso común — la práctica recomendada suele ser trimestral para el acceso privilegiado y anual para el resto. La exigencia no es nueva; lo que cambia es cómo se cumple.
Cuando el acceso se revisa de forma continua, y no una vez al año, tres cosas dejan de depender de una planilla. La primera es el origen del acceso: si nace ligado a la identidad corporativa de la persona, salir de la empresa ya significa perder el acceso, sin esperar la próxima ronda de revisión. La segunda es la granularidad: revisar "la persona X tiene acceso al sistema Y" es más fácil de hacer mal que revisar "la persona X tiene el rol Z dentro del sistema Y" — y esa segunda pregunta es la que una revisión real necesita responder.
La tercera es la cuenta de aplicación. Las herramientas creadas para un proyecto, una integración o una prueba específica necesitan un dueño, un plazo y un motivo registrado — de lo contrario, se convierten exactamente en el tipo de cuenta huérfana que el estudio de Orchid Security encontró por miles.
Lo que tiene que existir en la práctica
Un entorno de acceso bien revisado se sostiene en mecanismos concretos, no en la buena voluntad de quien se acuerde de avisar a TI.
Entrada por identidad corporativa. El acceso a la IA y a las herramientas conectadas usa el mismo directorio de la empresa que la red — la misma credencial, por así decirlo. Cuando alguien sale del directorio de la empresa, el acceso cae junto, en el mismo instante, sin depender de una segunda acción manual.
Acceso según el rol, no según la persona. Cada función dentro de cada sistema se otorga de forma específica a quien ejerce ese rol — no un permiso amplio "porque así fue más rápido".
Plazo y dueño para el acceso temporal. Toda cuenta creada para un proyecto, una integración o una prueba tiene un responsable y una fecha prevista de cierre, en lugar de quedar activa por defecto hasta que alguien lo note.
Registro de auditoría de quién otorgó qué. Toda concesión, cambio o eliminación de acceso queda registrada con quién tomó la decisión y cuándo — el tipo de evidencia que pide una auditoría de cumplimiento y que una planilla de correos no entrega.
Así fue diseñada la plataforma Skyller: identidad que viene del directorio de la empresa, acceso según el rol de cada persona y registro de auditoría por defecto, no como un paso extra de fin de año.
La ganancia para quien responde por el cumplimiento
Para quien prepara una auditoría — de seguridad de la información, de controles financieros o, cada vez más, de uso de inteligencia artificial — el valor práctico de un acceso revisado de forma continua aparece al responder la pregunta más simple y más temida: "¿quién tiene acceso a esto, y por qué?"
Las normas que rigen los controles financieros exigen que la revisión de acceso siga el mismo ritmo que el informe trimestral, con alguien independiente confirmando que cada acceso sigue teniendo sentido — y con prueba de que lo señalado para eliminar fue realmente eliminado, no solo registrado en un ticket. Un entorno donde ese rastro ya existe por diseño convierte la preparación de una auditoría de un proyecto de semanas en una consulta de minutos.
También hay una ganancia menos comentada: el tiempo del propio equipo de TI. Cada hora dedicada a perseguir gerentes para que confirmen una planilla de acceso es una hora que no va hacia lo que realmente protege a la empresa.
Una guía para la próxima revisión de acceso
Antes de abrir una planilla anual más, vale la pena llevar estas preguntas a la conversación con seguridad de la información y cumplimiento:
- ¿Cuántas cuentas activas hoy pertenecen a personas que ya no trabajan en la empresa? Si responder exige un relevamiento manual, el número real probablemente sea mayor de lo que cualquiera imagina.
- ¿Las cuentas de aplicación y de proyectos cerrados tienen dueño y plazo registrados? Si no lo tienen, no aparecen en ninguna revisión — y son exactamente las que más se acumulan.
- ¿La última revisión de acceso muestra quién revisó, cuándo y contra qué sistema? Una revisión sin ese rastro no resiste una auditoría, aunque se haya hecho de buena fe.
- ¿El acceso está ligado a la identidad corporativa o a inicios de sesión sueltos por sistema? Sin ese vínculo, sacar a alguien de la nómina de la empresa no apaga automáticamente el acceso que esa persona acumuló en el camino.
