El reporte 2026 marca un cambio estructural en cómo ocurren las brechas, pero el problema de fondo sigue siendo el acceso que nadie revoca.
El informe anual de Verizon sobre brechas de datos acaba de documentar un cambio que llevaba años gestándose: la explotación de vulnerabilidades técnicas pasó a ser el método más frecuente de intrusión en 2026, representando el 31% de todas las brechas confirmadas. El abuso de credenciales — el líder histórico de la última década — cayó al 13%. Es un dato que reordena prioridades en los equipos de seguridad, pero que no resuelve el problema de fondo: qué puede hacer un atacante una vez adentro depende de cuántos permisos acumuló la cuenta comprometida a lo largo de meses o años sin que nadie los revisara.
El patrón es conocido en cualquier organización: cuando un empleado cambia de equipo, los nuevos accesos llegan en menos de un día — hay un responsable, hay un plazo, hay presión para que la persona sea productiva cuanto antes. Los accesos del rol anterior se quedan ahí, porque revocarlos no tiene dueño ni urgencia. Según las prácticas documentadas en múltiples procesos de revisión de acceso corporativo, los derechos antiguos solo se eliminan cuando alguien lo pide explícitamente. Nadie abre un ticket para reportar que un permiso dejó de ser necesario, porque la única persona que lo notaría — el propio usuario — no tiene incentivo para hacerlo. El costo de mantener ese permiso es alto, pero invisible y diferido en el tiempo.
Cómo funciona el ciclo de acumulación de permisos sin freno
El proceso de otorgamiento tiene estructura: un manager solicita, un aprobador confirma, el acceso se activa en horas. La revocación no tiene ninguna de esas dos cosas — ni responsable ni fecha límite. Cuando llega el momento de la revisión anual de accesos, el revisor ve una lista con cientos de nombres junto a permisos, pero el tablero no muestra si ese acceso se usó la semana pasada o hace un año. La pregunta que aparece en pantalla es siempre la misma: «¿Todavía lo necesita?» Decir que no implica el riesgo de romper algo. Decir que sí no genera consecuencias inmediatas. La respuesta predecible es sí, y el ciclo se repite.
El control de acceso basado en roles ayuda en parte, pero el problema es que cuando un usuario cambia de rol, su rol formal se actualiza en el sistema, pero no los accesos directos, grupos y carpetas que acumuló durante el tiempo en el puesto anterior. Esos permisos quedan huérfanos: nadie los reclama, nadie los revisa, nadie los elimina. Y cuando ocurre una brecha — ya sea por vulnerabilidad explotada o por credencial comprometida — el atacante hereda todo ese inventario sin dueño.
El dato que nadie mide: cuánto acceso sobrevive a los cambios de puesto
Una encuesta de PasswordManager.com realizada en marzo de 2023 entre 1,000 trabajadores estadounidenses encontró que el 58% de quienes dejaron sus empleos admitieron haber usado contraseñas de empleadores anteriores sin actualizarlas después de partir. Es una muestra limitada y declarativa, pero señala el patrón: las salidas pasan por checklists de recursos humanos, pero no por auditorías de los permisos y certificados creados por cientos de personas a lo largo de años. Los traslados internos son peores, porque ni siquiera disparan un proceso de offboarding — simplemente no pasa nada.
El estándar NIST SP 800-53 Rev. 5 — catálogo de controles de seguridad y privacidad usado en organizaciones reguladas — incluye los controles AC-2 y AC-6, que exigen revisión de cuentas, procesamiento de traslados y terminaciones, y otorgamiento exclusivo de privilegios requeridos por el rol del individuo. Pero cumplir con el estándar en papel no es lo mismo que implementarlo en la práctica: la mayoría de las organizaciones revisan accesos una vez al año con una pregunta genérica, no cada vez que alguien cambia de equipo con una lista concreta de qué ya no necesita.
Por qué América Latina replica el mismo patrón sin las herramientas para auditarlo
El problema no es exclusivo de Estados Unidos. En Brasil y México — los dos mercados con mayor adopción de controles de acceso empresariales en la región — las organizaciones financieras y de retail implementan los mismos sistemas de gestión de identidades que sus matrices globales, pero sin los equipos de auditoría interna dimensionados para revisarlos. Un banco regional en São Paulo puede tener el mismo software de revisión de accesos que su contraparte en Nueva York, pero con un tercio del personal dedicado a procesar las certificaciones trimestrales. El resultado es que la pregunta «¿Todavía lo necesita?» se responde con sí por defecto, porque investigar cada permiso individual tomaría más tiempo del que el equipo tiene asignado.
No hay datos públicos sobre cuántos permisos huérfanos acumulan las cuentas corporativas en LATAM, pero el patrón estructural es el mismo: otorgar acceso tiene dueño y urgencia, revocarlo no tiene ninguna de las dos. Y cuando una brecha ocurre — ya sea por phishing, por vulnerabilidad sin parchear o por credencial filtrada — el atacante hereda todo ese inventario sin supervisión.
Tres cambios de política que no requieren tecnología nueva
La solución no pasa por comprar otra herramienta de gestión de identidades. Pasa por redefinir quién es responsable de eliminar accesos y cuándo tiene que hacerlo. Primero: tratar cada cambio de puesto como un evento de eliminación. Cuando el sistema de recursos humanos registra un traslado, se genera automáticamente una tarea para el manager saliente y el entrante con una sola pregunta: qué ya no va a necesitar esta persona. Se le entrega la lista de accesos actuales y diez minutos para responder. Todo el acceso que la persona acumuló durante ese período tiene que tener un dueño explícito.
Segundo: cada permiso tiene que tener su propio dueño y fecha de vencimiento. Los accesos a carpetas de proyecto, permisos especiales o acceso a sistemas de producción tienen que expirar en una fecha concreta — ya sea la fecha de cierre del proyecto o, por defecto, tres meses después de su emisión, a menos que el dueño — una persona con nombre, no una dirección de correo genérica — lo renueve explícitamente. Tercero: las revisiones de acceso tienen que mostrar cuándo se usó por última vez cada permiso. Si el tablero no puede responder esa pregunta, el revisor no tiene información suficiente para tomar la decisión.
Nuestro análisis
El cambio que documenta Verizon — vulnerabilidades explotadas superando al abuso de credenciales como método de intrusión — es real y requiere ajustes en prioridades de parcheo y gestión de superficie de ataque. Pero el impacto de una brecha sigue dependiendo de cuánto acceso acumuló la cuenta comprometida sin que nadie lo revisara. El patrón se repite en cada auditoría post-incidente: el atacante no necesitó escalar privilegios porque la cuenta ya tenía permisos de tres roles anteriores que nadie revocó. Y ese problema no se resuelve con mejor detección de vulnerabilidades — se resuelve con políticas de revocación tan estructuradas como las de otorgamiento.
Lo que falta en la mayoría de las organizaciones no es tecnología: es decisión de asignar responsabilidad y plazo a la eliminación de accesos. Los tres cambios propuestos — tratar traslados como eventos de eliminación, asignar dueño y vencimiento a cada permiso, mostrar fecha de último uso en las revisiones — no requieren presupuesto nuevo. Requieren redefinir el proceso para que revocar sea tan inevitable como otorgar. ¿Cuántas brechas del próximo informe de Verizon podrían haberse contenido si el atacante hubiera heredado solo los permisos del rol actual, no los de los tres anteriores?