El 85% de las alertas ya no van a por el perímetro: van a por tu identidad, tu nube y tus credenciales

El perímetro corporativo no ha muerto. Simplemente ha dejado de ser el protagonista. Si el 85% de las alertas de seguridad ya están ligadas a identidades, entornos cloud y credenciales comprometidas, como sostiene SonicWall en su Cyber Protect Report 2026, lo que cambia no es solo la estadística: cambia la lógica entera de la defensa.

Durante años, muchas empresas siguieron comprando seguridad como quien refuerza una muralla. Más firewalls, más appliances, más reglas. Mientras tanto, los atacantes se colaban por una vía bastante menos épica y mucho más eficaz: una cuenta con privilegios, un token expuesto, una consola cloud mal protegida o un empleado que reutilizó una contraseña que ya estaba circulando por media internet. Menos cine, más contabilidad del desastre.

El dato del 85% encaja con una tendencia que llevan tiempo señalando grandes proveedores y organismos públicos: el acceso es el nuevo campo de batalla. Microsoft viene repitiendo desde hace años que la inmensa mayoría de los ataques exitosos contra cuentas podrían mitigarse con autenticación multifactor. CISA, en sus guías operativas, insiste en la reducción del riesgo de credenciales robadas y privilegios excesivos. Y Google, con su ecosistema cloud, lleva tiempo advirtiendo de un problema tan banal como peligroso: las claves persistentes y los secretos mal gestionados siguen haciendo el trabajo sucio a los atacantes.

La cuestión no es si el dato exacto es 85%, 80% o 90%. La cuestión es que la identidad se ha convertido en la llave maestra del negocio digital. Y cuando la llave maestra está en juego, todo lo demás —red, endpoint, aplicaciones, cadena de suministro cloud— queda subordinado.

Por qué este dato importa más de lo que parece

Hay titulares que describen una moda y otros que describen una transferencia de poder. Este pertenece a la segunda categoría. Cuando identidad, cloud y credenciales comprometidas concentran tal volumen de alertas, la conclusión práctica es bastante clara: el modelo de riesgo se ha desplazado desde la intrusión técnica pura hacia el abuso de confianza digital.

Eso tiene tres implicaciones inmediatas.

La primera: un incidente ya no exige necesariamente malware sofisticado. Un atacante con acceso válido puede moverse por sistemas corporativos con una discreción envidiable. Ni explota un zero-day, ni lanza un ransomware en los primeros diez minutos, ni deja una firma aparatosa. Entra con credenciales reales, consulta correo, revisa repositorios, accede a SaaS y se queda el tiempo suficiente para entender cómo monetizar el acceso.

La segunda: la nube ha multiplicado el impacto de un error de identidad. Antes, comprometer una cuenta podía abrir una puerta concreta. Ahora puede abrir una organización entera si esa cuenta tiene permisos sobre IAM, consola de administración, almacenamiento, automatizaciones, CI/CD o herramientas de soporte. El problema no es solo entrar. Es lo que esa identidad puede tocar una vez dentro.

La tercera: muchas empresas siguen midiendo madurez con controles visibles y no con controles decisivos. Tienen SOC, EDR y SIEM, pero no saben cuántas cuentas sin MFA siguen activas, cuántos usuarios conservan privilegios heredados, cuántos secretos hay embebidos en scripts o cuántas integraciones SaaS están autorizadas con permisos que nadie ha revisado en doce meses. Eso no es un matiz. Es el núcleo del problema.

Identidad: el activo que nadie trató como activo hasta que empezó a arder

La identidad digital siempre estuvo ahí, pero durante mucho tiempo se trató como un asunto de TI interna: altas, bajas, contraseñas, directorio activo, poco glamour. Ese enfoque ya no sirve. Hoy la identidad es infraestructura crítica.

Piensa en el recorrido típico de una empresa mediana o grande. Tiene Microsoft 365 o Google Workspace, varias aplicaciones SaaS, una o dos nubes públicas, acceso remoto, proveedores externos, desarrollo interno, herramientas de atención al cliente y automatizaciones con cuentas de servicio. Cada una de esas piezas genera usuarios, roles, claves, tokens, certificados o secretos de acceso. El resultado no es una arquitectura limpia. Es un ecosistema de identidades humanas y no humanas que crece más rápido de lo que se gobierna.

Ahí aparece una de las mayores asimetrías del mercado: desplegar nuevas identidades es muy fácil; retirarlas o controlarlas bien es bastante menos popular. Los equipos de negocio piden acceso inmediato. Los equipos de seguridad intentan no ser el departamento que bloquea ventas, integraciones o despliegues. Así se acumulan privilegios, se eternizan cuentas de servicio y sobreviven usuarios huérfanos de proyectos que nadie recuerda. Los atacantes agradecen la falta de orden. Y mucho.

La identidad no humana merece un apartado propio porque suele pasar por debajo del radar ejecutivo. Cuentas de servicio, secretos de API, tokens OAuth, claves SSH, certificados de automatización, credenciales embebidas en pipelines: todo eso permite operar sistemas críticos sin intervención humana. También permite comprometerlos sin hacer ruido si esas credenciales quedan expuestas en repositorios, wikis internas, tickets o herramientas de colaboración. El atacante no necesita convencer a nadie con phishing si encuentra una llave ya dejada en la alfombra.

La nube agrava el problema por diseño, no por accidente

La nube no es insegura por naturaleza. Lo que sí hace es acelerar consecuencias. En un entorno on-prem, el daño de una identidad comprometida solía depender bastante de la segmentación de red y de barreras técnicas relativamente estáticas. En cloud, la propia capa de gestión concentra un poder enorme. Desde una consola administrativa o una API bien autorizada se puede crear infraestructura, copiar datos, modificar políticas, desactivar registros, alterar copias de seguridad o abrir servicios a internet en minutos.

Eso explica por qué los errores de configuración cloud y el abuso de privilegios aparecen de forma recurrente en incidentes públicos. No porque la nube sea peor, sino porque traduce permisos lógicos en impacto operativo inmediato.

Hay un patrón conocido. Una cuenta con privilegios excesivos queda expuesta por phishing, credential stuffing, reutilización de contraseñas o robo de tokens de sesión. El atacante accede a la consola, enumera recursos, revisa buckets, instantáneas, roles e integraciones, y busca una vía para persistir. Si encuentra automatizaciones o cuentas de servicio mal vigiladas, el problema escala rápido. A veces roba datos. A veces prepara fraude. A veces se lleva secretos que permiten atacar a terceros. Todo ello con herramientas legítimas del propio entorno.

Y aquí aparece una ironía regulatoria interesante: muchas organizaciones presumen de cifrado, DLP y retención, pero siguen sin poder responder con precisión a preguntas básicas. ¿Qué cuentas tienen acceso administrativo sobre la nube? ¿Cuántas credenciales de larga duración siguen activas? ¿Qué identidades de proveedor externo tienen acceso persistente? ¿Quién revisó los permisos efectivos el último trimestre? Si no puedes responder eso en menos de una semana, tienes un problema de control, no de visibilidad estética.

Credenciales comprometidas: el viejo problema que nunca se fue

Las credenciales robadas son uno de los vectores más aburridos del sector. Y precisamente por eso siguen funcionando. Hay pocas historias más deprimentes en seguridad que ver caer una organización compleja por una contraseña reutilizada, una sesión secuestrada o un correo de phishing suficientemente convincente.

El problema se ha sofisticado sin dejar de ser básico. Ya no hablamos solo de usuario y contraseña. Hablamos de robo de cookies de sesión, secuestro de tokens OAuth, abuso de credenciales de acceso remoto, recolección de secretos expuestos en código y explotación de MFA mal implementado o mal resistido frente a ataques de fatiga. El atacante moderno no siempre intenta romper el sistema. Prefiere entrar por la puerta con una chapa aparentemente válida.

La guía de CISA sobre phishing-resistant MFA y el énfasis creciente en FIDO2/WebAuthn no son casuales. Los métodos clásicos de MFA reducen riesgo, sí, pero no todos resisten igual. SMS y códigos TOTP siguen siendo mejores que nada, pero el mercado ya conoce sus limitaciones frente a phishing kits adversary-in-the-middle y técnicas de robo de sesión. La diferencia entre “tenemos MFA” y “tenemos MFA resistente al phishing en accesos críticos” es justo el tipo de matiz que separa el cumplimiento superficial de la resiliencia real.

No es solo ciberseguridad: también es gobernanza, riesgo y cumplimiento

Si esta noticia se leyera únicamente como una alerta técnica, se quedaría corta. Identidad, nube y credenciales comprometidas ya son un asunto de gobierno corporativo. Y eso tiene una traducción regulatoria bastante directa en Europa.

En DORA, el Reglamento (UE) 2022/2554, la gestión del riesgo TIC no se limita a comprar herramientas; exige un marco interno para proteger, detectar, responder y recuperar. El artículo 6 obliga a mantener un marco sólido, exhaustivo y bien documentado de gestión del riesgo TIC. El artículo 9 aterriza medidas de protección y prevención, incluyendo políticas de control de acceso, gestión de identidades y medidas para limitar el riesgo de exposición. Si una entidad financiera no sabe quién accede a qué sistemas críticos, con qué privilegios y bajo qué control de autenticación, no tiene un problema periférico: tiene un hueco en el corazón de DORA.

El artículo 17 de DORA, sobre clasificación y notificación de incidentes relacionados con las TIC, también entra en juego. Una intrusión basada en credenciales comprometidas puede derivar en un incidente mayor aunque no haya habido malware visible. Eso obliga a las entidades a detectar antes, clasificar mejor y preservar evidencia. El adversario que accede con identidad válida no hace ruido por cortesía; hace ruido cuando ya es tarde.

La cosa no acaba ahí. NIS2, Directiva (UE) 2022/2555, exige en su artículo 21 medidas técnicas, operativas y organizativas adecuadas y proporcionadas para gestionar riesgos de seguridad. Entre ellas aparecen el análisis de riesgos, la gestión de incidentes, la continuidad y seguridad de la cadena de suministro, pero también la seguridad en la adquisición, desarrollo y mantenimiento de redes y sistemas, incluida la gestión y divulgación de vulnerabilidades. Aunque NIS2 no enumera “MFA en todos los accesos privilegiados” como frase mágica universal, sería una lectura creativamente negligente pensar que la protección de identidades y accesos no está en el centro de ese deber de diligencia.

Si hay datos personales de por medio —y en entornos de identidad casi siempre los hay— entra además GDPR. El artículo 32 exige medidas técnicas y organizativas apropiadas para garantizar un nivel de seguridad adecuado al riesgo. El artículo 33 fija la notificación a la autoridad de control en 72 horas cuando haya violación de seguridad de los datos personales, salvo que sea improbable que entrañe riesgo para los derechos y libertades de las personas físicas. Un acceso indebido a correo corporativo, CRM, HR o repositorios cloud con datos personales puede activar esa obligación con bastante rapidez. Y sí, “el atacante usó una cuenta legítima” no desactiva el problema, solo lo vuelve más incómodo de explicar.

Qué le dice realmente esta noticia a un CISO

Un CISO sensato no debería leer el 85% como un eslogan, sino como una prioridad presupuestaria. Si la mayoría de las alertas están donde están, el esfuerzo defensivo debe moverse ahí. No por moda. Por economía del riesgo.

La primera pregunta es incómoda: ¿mi organización protege mejor sus dispositivos que sus identidades? En muchísimas empresas, la respuesta honesta es sí. Tienen inventarios de equipos relativamente maduros, despliegues EDR razonables y cierta disciplina de parcheo, pero conviven con MFA desigual, cuentas privilegiadas permanentes, service accounts sin rotación, federaciones mal documentadas y autorizaciones SaaS que nadie revisa.

La segunda pregunta va de detección: ¿mi SOC distingue entre actividad legítima y abuso de identidad? Porque buena parte del juego se decide ahí. Detectar malware es una cosa. Detectar una secuencia sospechosa de autenticación, elevación de privilegios, acceso a recursos inusuales y exfiltración por canales permitidos es otra bastante más exigente. Requiere telemetría de identidad, registros cloud de calidad, enriquecimiento contextual y reglas menos decorativas.

La tercera es de resiliencia operativa: ¿puedo revocar rápido el acceso comprometido sin colapsar el negocio? Parece simple. No lo es. Muchas organizaciones no tienen claro qué dependencias se rompen si desactivan una cuenta de servicio, rotan una clave de API o restringen un rol con permisos heredados. Y así es como un control obvio se convierte en una discusión de dos semanas entre seguridad, operaciones y negocio. El atacante, por supuesto, no espera al comité.

Qué le dice esta noticia a compliance y al consejo

Que dejar la identidad en manos exclusivas de TI ya no es defendible. Si el riesgo de compromiso de credenciales afecta continuidad, datos, fraude, terceros y reporting regulatorio, entonces el órgano de dirección tiene que verlo como un riesgo transversal.

DORA es explícita al atribuir al órgano de dirección la responsabilidad última sobre la gestión del riesgo TIC, y eso incluye aprobar, supervisar y responder por el marco de control. No basta con recibir un tablero trimestral de “incidentes cerrados”. El consejo debería pedir métricas más reveladoras: porcentaje de cuentas privilegiadas con MFA resistente al phishing, número de cuentas inactivas aún habilitadas, tiempo medio de revocación de accesos al producirse una baja, volumen de secretos de larga duración sin rotación, exposición de identidades de terceros y cobertura de logging en planos de control cloud.

La conversación madura no es “¿tenemos IAM?”. La conversación madura es “¿qué fallaría mañana si alguien roba una sesión de administrador cloud o compromete una cuenta de soporte con acceso a clientes?”. La diferencia entre ambas preguntas se mide en millones, sanciones y noches sin dormir.

La gran zona ciega: identidades de terceros y cadena de suministro

Hay un detalle que muchas empresas siguen subestimando: parte del problema de identidad no pertenece del todo a la plantilla propia. Proveedores de soporte, desarrolladores externos, MSSP, integradores, plataformas SaaS y partners técnicos acumulan accesos persistentes a entornos críticos. A veces están justificados. A veces llevan años ahí porque nadie se atrevió a retirarlos por miedo a romper algo.

En DORA, los terceros TIC están sometidos a una atención especial. El artículo 28 y siguientes obligan a gestionar el riesgo derivado de proveedores de servicios TIC, incluyendo elementos contractuales, monitorización y estrategia sobre dependencias. Aunque la noticia de SonicWall no hable de DORA, el vínculo operativo es obvio: una identidad de tercero mal gobernada puede ser el atajo más rápido hacia un incidente material.

En la práctica, el control de terceros suele fallar por tres motivos. Uno, no existe un inventario fiable de accesos concedidos fuera de RRHH. Dos, esos accesos no siguen el mismo estándar de MFA y revisión que los internos. Tres, la retirada al cierre de contrato o al cambiar el alcance del servicio es sorprendentemente caótica. Resultado: puertas abiertas que nadie siente como propias. Y ya sabemos cómo acaba eso.

Por qué “zero trust” sirve poco si se queda en póster

El mercado lleva años vendiendo zero trust. La idea base sigue siendo sólida: no confiar por defecto, verificar de forma continua y conceder el mínimo acceso necesario. El problema es que, en demasiadas organizaciones, zero trust se ha convertido en un idioma de presentación más que en una disciplina operativa.

Si de verdad te tomas en serio el cambio de escenario que sugiere ese 85%, zero trust deja de ser una etiqueta y pasa a exigir decisiones concretas. MFA resistente al phishing para administradores y accesos críticos. Acceso privilegiado just-in-time en lugar de privilegio permanente. Segmentación basada en identidad y contexto. Revisión periódica de permisos efectivos, no de organigramas teóricos. Telemetría unificada de autenticación, autorización y actividad cloud. Gestión de secretos con rotación y trazabilidad. Revocación automatizada en bajas y cambios de rol. Sin eso, zero trust es merchandising.

No hace falta adoptar una ortodoxia doctrinal para mejorar mucho. Hace falta dejar de tratar identidad como burocracia de soporte. Esa es la pieza que demasiadas organizaciones aún no han interiorizado.

Seis decisiones operativas que sí cambian el riesgo

Conviene aterrizar. Si una empresa quiere responder a esta tendencia con algo más útil que una reunión de PowerPoint, hay varias decisiones que tienen impacto medible.

1. Diferenciar entre MFA “presente” y MFA “resistente”

Contar accesos con MFA no basta. Hay que separar usuarios críticos, administradores, soporte, finanzas, recursos humanos y acceso a consola cloud. En esos casos, la prioridad debería ser FIDO2/WebAuthn o mecanismos equivalentes resistentes al phishing. No todos los factores valen lo mismo, y fingir que sí solo sirve para adornar cuadros de mando.

2. Reducir privilegios permanentes

El enemigo real no es solo la cuenta comprometida; es la cuenta comprometida con demasiado poder. El acceso privilegiado temporal, aprobado y registrado reduce la superficie de abuso. Si una identidad solo puede elevarse durante una ventana concreta y para una tarea concreta, el daño potencial baja de forma clara.

3. Mapear identidades no humanas

Muchas empresas no tienen un inventario decente de cuentas de servicio, claves API, secretos en CI/CD y automatizaciones. Eso es como no saber cuántas llaves maestras hay en el edificio. El inventario no resuelve el problema por sí solo, pero sin inventario no hay control, ni rotación, ni monitorización útil.

4. Vigilar la capa de control cloud

Los registros del plano de gestión —por ejemplo, actividad administrativa, cambios IAM, creación de tokens, modificación de políticas, nuevas federaciones o aperturas de almacenamiento— son esenciales. Si el SOC no los prioriza, se pierde justo la película que explica cómo se materializa un compromiso de identidad en la nube.

5. Revisar accesos de terceros con fecha de caducidad real

No basta con “revisar periódicamente”. Hace falta que cada acceso de proveedor tenga propietario interno, propósito documentado, método de autenticación exigido y fecha de expiración técnica. Lo contrario no es gobernanza; es esperanza administrativa.

6. Ensayar la revocación

Las organizaciones hacen simulacros de ransomware y caída de CPD, pero pocas prueban qué ocurre si deben invalidar de golpe una identidad privilegiada, rotar un secreto crítico o cerrar accesos de un tercero comprometido. Ese ensayo revela dependencias ocultas. También ahorra pánico cuando el incidente no es un ejercicio.

Lo que el dato no dice, pero conviene no olvidar

Sería un error leer esta tendencia como si todo lo demás dejara de importar. Vulnerabilidades explotables, exposición de servicios, falta de parcheo, ransomware y errores de desarrollo siguen ahí. En 2024 y 2025, CISA continuó actualizando su catálogo KEV con vulnerabilidades activamente explotadas, y ese catálogo sigue recordando una verdad incómoda: el acceso inicial puede llegar por muchas vías.

La diferencia es que identidad y credenciales suelen actuar como amplificador. Un atacante puede aprovechar una vulnerabilidad para conseguir un punto de apoyo, pero una vez obtiene credenciales válidas o roba tokens, el movimiento lateral y la persistencia se vuelven mucho más sencillos. Por eso la defensa eficaz no debería enfrentar “vulnerabilidades” contra “identidad”, como si hubiera que elegir bando. Hay que entender cómo se encadenan.

Tampoco conviene convertir cualquier estadística de proveedor en dogma. SonicWall tiene intereses comerciales, como los tienen todos los actores del sector cuando publican informes. Eso no invalida el dato, pero sí obliga a situarlo. La pregunta útil no es si la cifra exacta encaja al decimal con otras fuentes. La pregunta útil es si coincide con lo que ya muestran incidentes, auditorías y prioridades regulatorias. Y ahí la respuesta es bastante clara: sí, coincide.

El choque con la realidad presupuestaria

La mala noticia para muchas empresas es que reforzar identidad no siempre produce el mismo efecto visual que comprar una nueva plataforma deslumbrante. A menudo implica trabajo ingrato: limpiar privilegios, rediseñar procesos de alta y baja, integrar sistemas heredados, revisar federaciones, retirar cuentas antiguas, corregir automatizaciones frágiles, convencer a usuarios privilegiados de usar llaves físicas, imponer controles a terceros que preferirían operar “como siempre”.

Eso genera resistencia porque toca fricciones cotidianas. Justamente por eso suele postergarse. Y justo por eso el riesgo persiste. La seguridad de identidad rara vez se rompe por falta de conceptos; se rompe por acumulación de excepciones que el negocio normaliza.

Hay además un problema clásico de incentivos. Si mejoras EDR o compras una solución de detección reluce más en el presupuesto. Si reduces privilegios permanentes o haces inventario de secretos, el resultado es decisivo pero menos vistoso. La resiliencia real suele ser bastante menos glamourosa que el marketing de ciberseguridad. Qué sorpresa.

Qué deberían hacer ahora las empresas sin perderse en teoría

No necesitan rehacer toda la arquitectura en una semana. Sí necesitan priorizar con brutal honestidad.

Primero, identificar los diez accesos y roles cuya pérdida de control tendría mayor impacto: administración cloud, correo de alta dirección, finanzas, soporte con acceso a clientes, CI/CD, repositorios de código, gestión de identidades, copias de seguridad y herramientas de administración remota. Si eso no está delimitado, cualquier estrategia posterior se dispersa.

Segundo, verificar método de autenticación, privilegio, titularidad, logging y capacidad de revocación para cada uno de esos accesos. No en un diagrama ideal. En producción.

Tercero, revisar qué identidades de terceros y no humanas están ligadas a esos procesos críticos. Esta parte suele revelar más deuda de la que los comités quieren escuchar, pero precisamente por eso merece prioridad.

Cuarto, conectar esta revisión con obligaciones regulatorias y contractuales. Si eres entidad financiera o proveedor crítico, el debate ya no es meramente técnico. DORA, NIS2 y GDPR convierten la higiene de identidad en materia de control, supervisión y, llegado el caso, responsabilidad.

Quinto, medir progreso con indicadores que describan riesgo residual de verdad. No “número de políticas emitidas”, sino reducción de cuentas privilegiadas permanentes, cobertura de MFA resistente, tiempo de cierre de accesos tras baja, rotación de secretos críticos, revisión efectiva de permisos de terceros y capacidad de detección de actividad anómala en plano de control cloud.

La lectura final: el ataque sigue entrando por donde más confías

La noticia de SonicWall no anuncia una revolución súbita. Confirma algo más incómodo: muchas organizaciones siguen protegiendo mejor lo que se ve que lo que otorga poder. Y hoy el poder digital está concentrado en identidades, permisos, sesiones, tokens y configuraciones cloud.

Si el 85% de las alertas orbitan alrededor de ese triángulo —identidad, nube y credenciales comprometidas— la discusión seria ya no es si hace falta “más seguridad” en abstracto. La discusión es si tu empresa está preparada para defender y gobernar su sistema nervioso: quién accede, con qué legitimidad, durante cuánto tiempo y con qué capacidad de daño.

Porque ese es el giro real del mercado. El atacante ya no necesita tumbar la puerta principal si puede entrar con una credencial correcta, moverse por la nube como un usuario más y abusar de la confianza que la organización regaló por comodidad, prisa o simple desorden. Y ese tipo de incidente es especialmente cruel: no solo demuestra un fallo técnico. Demuestra un fallo de gobierno.

A estas alturas, seguir tratando la identidad como un problema secundario ya no es conservadurismo. Es imprudencia con presupuesto.