Aplicaciones expuestas y accesos robados: así entra hoy el 80% de los atacantes, y por qué eso complica DORA y NIS2

La parte incómoda del último dato de Kaspersky no es que el 43,7% de los ciberataques analizados en 2025 arrancara por aplicaciones expuestas a Internet, ni que otro 25,4% empezara con cuentas válidas comprometidas, ni siquiera que las relaciones de confianza sumaran un 12,7%. La parte incómoda es otra: casi nada de eso suena nuevo. Y, sin embargo, sigue funcionando.

Si sumas esas tres vías, tienes más del 80% de los casos. No hablamos de un vector exótico, de una cadena de explotación digna de una conferencia técnica en Las Vegas o de una vulnerabilidad de laboratorio con nombre ingenioso. Hablamos de lo de siempre: servicios accesibles desde fuera, credenciales legítimas en manos ajenas y conexiones entre sistemas que un atacante aprovecha como si fueran una autopista sin peaje.

Ese dato importa por una razón muy concreta. La conversación pública sobre ciberseguridad sigue fascinada por el zero-day de la semana, por el ransomware con marca propia o por la última campaña atribuida a un actor estatal. Pero cuando se revisan intrusiones reales, lo que aparece con una frecuencia casi ofensiva es una higiene básica mal resuelta: una VPN sin MFA robusto, un portal olvidado, un RDP aún visible, una cuenta de proveedor con permisos de más, un servidor web sin parchear, una identidad de servicio que nadie recuerda pero que mantiene medio negocio en pie. El glamour del cibercrimen suele entrar por una puerta bastante cutre.

Para las empresas europeas, y en especial para las entidades reguladas, esto tiene una derivada seria. DORA no se escribió para castigar presentaciones bonitas de resiliencia, sino para obligar a demostrar control operativo real. NIS2 tampoco está para premiar políticas de 80 páginas que nadie ejecuta. Si el grueso de los ataques sigue entrando por exposición externa, identidades comprometidas y confianza mal gobernada, entonces la pregunta regulatoria ya no es si existe una política, sino si la organización puede probar que reduce de verdad esas tres superficies.

Aquí está el quid: el informe sirve como fotografía de amenaza, sí, pero sobre todo como espejo incómodo de prioridades. Muchas compañías han invertido millones en capacidades de detección y respuesta y siguen sin saber, con precisión, qué aplicaciones tienen publicadas en Internet, qué cuentas de servicio no rotan credenciales desde hace meses o qué proveedor conserva acceso persistente a entornos críticos. Luego llega el incidente y todo el mundo descubre que el inventario era más aspiración que realidad.

Lo que realmente dicen esos tres vectores

Conviene mirar las cifras despacio. Las aplicaciones expuestas a Internet, con un 43,7%, no son simplemente “servidores vulnerables”. Ahí entran portales web, appliances perimetrales, servicios de acceso remoto, herramientas de colaboración, paneles de administración, APIs y software empresarial que alguien decidió publicar porque el negocio necesitaba rapidez y la revisión de seguridad se quedó para después. O para nunca.

Este vector se ha vuelto especialmente rentable para los atacantes por una combinación muy prosaica: proliferación de activos, ciclos de parcheo lentos y dependencia creciente de software de terceros. Basta ver lo ocurrido en los últimos años con productos de transferencia de archivos, appliances VPN o plataformas de virtualización. Progress MOVEit marcó 2023 por una vulnerabilidad de SQL injection, CVE-2023-34362, explotada a gran escala por Cl0p. Citrix Bleed, CVE-2023-4966, convirtió sesiones robadas en acceso efectivo. En 2024 y 2025 la historia no ha cambiado de género: sigue siendo una carrera entre exposición, explotación y parcheo, con demasiadas organizaciones perdiendo por minutos que acaban costando meses.

El segundo vector, las cuentas válidas comprometidas, con un 25,4%, merece menos romanticismo del que suele recibir. No siempre significa phishing clásico. Puede ser infostealer en el portátil de un empleado, token robado en el navegador, reutilización de contraseñas, fatiga MFA, credenciales filtradas por un proveedor o secretos embebidos en scripts y repositorios. La identidad se ha convertido en el perímetro operativo real. Quien la trata como una capa más del stack va tarde.

El tercer vector, las relaciones de confianza, con un 12,7%, es probablemente el más subestimado por los comités de dirección y uno de los más explosivos desde el punto de vista regulatorio. Una relación de confianza no es una abstracción: es una conexión entre dominios, una integración API entre cliente y proveedor, una cuenta federada, una herramienta de administración remota, una conexión de soporte privilegiado, una dependencia SaaS con acceso a datos o procesos críticos. Cuando esa confianza no está segmentada ni vigilada, el atacante no necesita romper todas las puertas; le basta con una llave prestada.

Si esto te suena a “supply chain”, sí, pero con un matiz. La cadena de suministro digital no solo falla cuando un proveedor sufre una intrusión masiva con repercusión global. Falla también en silencios mucho más cotidianos: accesos que no caducan, contratos que no exigen logging suficiente, entornos de soporte con privilegios amplios, interconexiones heredadas que nadie revisa porque “siempre han estado ahí”. La confianza, en muchas organizaciones, sigue documentándose mejor de lo que se gobierna.

Por qué seguimos fallando en algo tan conocido

La explicación fácil sería hablar de falta de presupuesto. A veces es cierto. Pero no explica todo. Hay empresas con presupuesto holgado que siguen descubriendo activos públicos por Shodan antes que por su propio inventario. Hay organizaciones con centros de operaciones sofisticados que detectan una intrusión días después porque el acceso inicial fue una cuenta de proveedor fuera de los casos de uso habituales. Hay equipos de seguridad que despliegan EDR en miles de endpoints y no consiguen que el negocio retire un portal obsoleto “porque lo usa un área pequeña, pero crítica”.

El problema real suele estar en la gobernanza operativa. Seguridad sabe algo. Infraestructura sabe otra cosa. Desarrollo publica una API nueva. Compras firma un proveedor con acceso remoto. Negocio necesita inmediatez. Cumplimiento revisa el papel. Y nadie tiene una visión unificada, casi en tiempo real, de qué está expuesto, quién puede entrar y qué confianza se ha concedido a terceros. Luego llega el auditor o el atacante, y ambos descubren lo mismo con métodos distintos.

También influye un sesgo corporativo bastante humano: se financia mejor lo visible que lo básico. Un programa de threat hunting suena bien en una reunión. Un proyecto para retirar 200 activos expuestos heredados, rotar credenciales de servicio y reconfigurar federaciones con proveedores suena menos heroico. Pero adivina cuál reduce más riesgo medible.

La inflación tecnológica tampoco ayuda. Muchas organizaciones han multiplicado herramientas sin resolver el dato base. Tener CSPM, ASM, EDR, SIEM, SOAR, PAM e IAM no garantiza control si cada plataforma ve un trozo distinto y ninguna se alimenta de un inventario fiable. El resultado es una paradoja bastante moderna: empresas con más visibilidad declarada que certeza real.

Hay, además, una razón estructural que rara vez se dice en voz alta. Corregir exposición externa y accesos comprometidos duele políticamente dentro de la empresa. Cerrar un servicio afecta a usuarios. Reforzar MFA crea fricción. Limitar privilegios incomoda a administradores y proveedores. Segmentar confianza rompe automatizaciones hechas deprisa. Es mucho más fácil anunciar una nueva solución de ciberseguridad que discutir con cinco áreas de negocio por qué un acceso ya no puede seguir “como siempre”.

El ángulo europeo: esto ya no es solo un problema técnico

En Europa, seguir fallando en estos tres frentes ya no se puede despachar como una cuestión interna de TI. Ahora tiene lectura regulatoria, contractual y de supervisión.

NIS2, la Directiva (UE) 2022/2555, obliga a las entidades esenciales e importantes a aplicar medidas técnicas, operativas y organizativas apropiadas y proporcionadas. El artículo 21 no se queda en vaguedades amables: menciona gestión de riesgos, tratamiento de incidentes, continuidad de negocio, seguridad de la cadena de suministro, seguridad en la adquisición, desarrollo y mantenimiento de redes y sistemas, políticas para evaluar la eficacia de las medidas y prácticas básicas de ciberhigiene, incluyendo autenticación multifactor o autenticación continua, comunicaciones seguras y gestión de accesos. Si una organización sigue acumulando exposición innecesaria a Internet y accesos débiles, no está ante una recomendación blanda; está rozando un incumplimiento material de control.

La fecha no es menor. Los Estados miembros debían transponer NIS2 antes del 17 de octubre de 2024. La implementación nacional no ha sido homogénea, pero el mensaje regulatorio sí lo es: la “ciberhigiene” dejó de ser un término de concienciación para convertirse en una expectativa exigible. Y cuando los vectores más explotados son precisamente los más básicos, la defensa de “teníamos una estrategia” empieza a sonar a excusa de PowerPoint.

DORA va aún más lejos para el sector financiero. El Reglamento (UE) 2022/2554 es aplicable desde el 17 de enero de 2025. No pide una perfección imposible, pero sí algo mucho más molesto: capacidad de demostrar gobernanza, pruebas, respuesta, reporting y control de terceros ICT. El artículo 5 sitúa la responsabilidad del marco de gestión del riesgo TIC en el órgano de dirección. El artículo 8 exige identificación, clasificación y documentación de todas las funciones, roles, activos de información y activos TIC que soportan funciones de negocio. El artículo 9 aborda protección y prevención, incluyendo políticas sobre control de acceso, gestión de cambios, parches y seguridad de redes. Los artículos 28 a 30 aprietan sobre riesgo de terceros TIC. Si la intrusión entra por una aplicación publicada sin control, una cuenta comprometida o una relación de confianza mal gestionada, DORA no ve “mala suerte”: ve un fallo en el marco.

Y luego está GDPR, que sigue apareciendo en escena cuando el incidente ya ha causado daño. Si el acceso comprometido acaba afectando a datos personales, el artículo 33 obliga a notificar la violación de seguridad a la autoridad de control en un plazo de 72 horas desde que se tiene constancia, salvo que sea improbable que constituya un riesgo para los derechos y libertades de las personas físicas. El artículo 32 exige medidas técnicas y organizativas apropiadas. Cuando un atacante entra con credenciales válidas y se mueve durante días porque no había MFA fuerte ni monitorización suficiente, no es difícil imaginar la conversación posterior con el DPO y con la autoridad competente. Nadie disfruta de esa llamada.

La lección aquí es sencilla. La misma debilidad operativa puede activar varias obligaciones a la vez: gestión de riesgos y supervisión sectorial bajo DORA, medidas de ciberseguridad y gobernanza bajo NIS2, y notificación de brechas y seguridad del tratamiento bajo GDPR. Para una entidad financiera, una aseguradora o un proveedor crítico, ya no existen compartimentos estancos cómodos entre ciberseguridad, riesgo operativo, legal y compliance. El atacante tampoco distingue.

Aplicaciones expuestas: el viejo pecado mortal del perímetro moderno

La categoría “aplicaciones expuestas” parece trivial hasta que se aterriza en lo que suele incluir. No son solo páginas web corporativas. Son consolas de administración, VPN, firewalls con interfaz pública, plataformas de transferencia de ficheros, herramientas ITSM, software de acceso remoto, APIs de partners, escritorios virtuales, gateways de correo y un largo etcétera. Cada uno trae una mezcla distinta de superficie, urgencia de parcheo y dependencia del negocio.

En los últimos años, los atacantes han afinado un patrón extremadamente rentable: escaneo masivo, explotación rápida de vulnerabilidades ya divulgadas y automatización de la fase de acceso inicial. Cuando una CVE afecta a un producto ampliamente desplegado en perímetro, el reloj empieza antes de que muchas organizaciones hayan convocado la primera reunión interna. Lo vimos con MOVEit en junio de 2023. Lo vimos con Citrix NetScaler. Lo hemos visto repetirse con firewalls y VPN de distintos fabricantes. El ciclo es despiadado: exposición visible, exploit disponible, actividad oportunista, y más tarde, muy tarde, inventario urgente.

La pregunta útil para una empresa no es “tenemos un programa de vulnerabilidades?”, sino “cuánto tardamos en saber con certeza qué activos expuestos usan el producto afectado, qué versión ejecutan, quién es su dueño, si está detrás de WAF o segmentación adicional, y cuánto tardamos en parchear o aislar?”. Si la respuesta real es más de 24-48 horas para la identificación y varios días para la contención en activos críticos expuestos, el problema no es solo la vulnerabilidad; es el modelo operativo.

Esto conecta con DORA de forma directa. El artículo 8 sobre identificación de activos no es un requisito ornamental. Sin inventario fiable de activos TIC y dependencias, no hay gestión de exposición seria. Y sin eso, el discurso de resiliencia se viene abajo en la primera crisis. Muchas entidades han aprendido a golpes que su CMDB dice una cosa, su nube otra y su superficie real en Internet otra bastante más embarazosa.

Hay además una trampa frecuente: pensar que publicar un servicio detrás de un proveedor cloud o de una CDN reduce por sí mismo el riesgo material. A veces lo mitiga. Otras veces solo añade capas hasta que nadie sabe quién ve qué logs, quién aplica qué parche y quién tiene autoridad para cortar el acceso. La nube no elimina el perímetro; lo multiplica y lo hace más difícil de cartografiar.

Credenciales válidas: cuando el atacante no necesita forzar la puerta

Las cuentas válidas comprometidas son el sueño del atacante y la pesadilla del defensor, porque convierten una intrusión en algo que se parece demasiado a actividad legítima. Esa es la razón por la que tantos programas de seguridad aparentan madurez y luego sufren tanto para detectar movimientos tempranos. Si la identidad es correcta, el endpoint parece normal y el acceso se produce desde una infraestructura plausible, la señal se vuelve difusa.

El problema ha crecido con la economía del robo de credenciales. Los infostealers extraen contraseñas guardadas, cookies de sesión, tokens, wallets y otra información de navegadores y aplicaciones. Esos datos acaban en mercados criminales, canales cerrados o manos de operadores de acceso inicial. El ransomware ya no necesita siempre irrumpir por la fuerza; a menudo compra una entrada ya abierta. Y si además la organización mantiene cuentas sin MFA fuerte, accesos heredados o privilegios excesivos, el resto del trabajo se simplifica de forma casi insultante.

Desde el punto de vista regulatorio, esto empieza a ser difícil de justificar. NIS2 art. 21 menciona expresamente autenticación multifactor o continua y gestión de accesos. DORA art. 9 exige mecanismos de protección y prevención adecuados, incluyendo políticas de control de acceso. Si una entidad crítica o financiera sigue tratando MFA como un proyecto parcial, circunscrito al acceso remoto de empleados pero no a administradores, proveedores, cuentas privilegiadas y aplicaciones de alto impacto, está defendiendo una frontera de 2019 en un escenario de 2025.

También hay una diferencia clave entre tener MFA y tener MFA resistente al phishing. No es lo mismo un código SMS o una aprobación push que un método basado en FIDO2/WebAuthn o certificados bien gobernados para determinados perfiles. La fatiga MFA, los proxys adversario-en-medio y el secuestro de sesión han demostrado que muchas implantaciones “cumplen” en papel pero no aguantan ataques medianamente preparados. Cumplir y resistir no son sinónimos. A veces ni se saludan.

Otro punto poco glamuroso y muy relevante: las cuentas no humanas. Identidades de servicio, secretos en pipelines, claves API, certificados de máquina a máquina, credenciales embebidas en scripts o herramientas de automatización. Son el lado oscuro del IAM corporativo porque suelen pertenecer a todos y a nadie. DORA no usa el término de moda “machine identities”, pero sus exigencias sobre activos, protección y controles de terceros empujan claramente hacia su gobernanza. Si no sabes qué procesos dependen de qué secretos, no puedes ni rotarlos con seguridad ni detectar su abuso con rapidez.

Relaciones de confianza: la cadena de suministro que nadie quiere mapear del todo

El 12,7% vinculado a relaciones de confianza parece menor hasta que se entiende su potencia. Una sola relación mal gobernada puede dar acceso lateral a entornos que, de otro modo, serían muy difíciles de alcanzar. El atacante compromete un proveedor, una cuenta federada, un canal de soporte o una herramienta de administración, y de pronto entra por la parte de atrás con permisos que la organización otorgó voluntariamente.

Este vector debería hacer sonar alarmas en cualquier consejo de administración sujeto a DORA. Los artículos 28, 29 y 30 no se limitan a decir “vigile a sus proveedores”. Exigen una gestión sólida del riesgo de terceros TIC, incluyendo estrategia, registros de acuerdos contractuales, evaluación previa, cláusulas mínimas y supervisión continuada. Si un tercero mantiene acceso privilegiado, procesa datos críticos o soporta funciones esenciales, la entidad necesita saber exactamente qué puede hacer, cómo se monitoriza, cómo se revoca el acceso y qué pasa si el proveedor falla o es comprometido.

La ironía es que muchas empresas han mejorado mucho la due diligence contractual y siguen flojas en el control técnico cotidiano. Tienen cuestionarios, anexos y matrices de riesgo, pero no una revisión mensual de accesos efectivos, no una segmentación real de sesiones de soporte, no un vault centralizado para credenciales de terceros, no logs suficientemente detallados para reconstruir qué hizo el proveedor en un momento concreto. Mucho papel. Poca telemetría.

NIS2 también aprieta aquí. El artículo 21 incluye la seguridad de la cadena de suministro y la relación entre cada entidad y sus proveedores o prestadores de servicios directos. El mensaje del legislador europeo es claro: no vale externalizar el riesgo y luego fingir sorpresa cuando vuelve por la puerta principal. La dependencia digital ya forma parte del perímetro regulado.

Para entidades financieras españolas y europeas, esta dimensión se vuelve aún más delicada si confluyen outsourcers de TI, proveedores cloud, servicios de pagos, BPO y fintechs integradas por API. Una interrupción o intrusión en un tercero puede convertirse en incidente operativo, incumplimiento de servicio, afectación de datos personales y, en determinados casos, incidente grave reportable bajo DORA. No es una teoría académica; es el tipo de cascada que los supervisores llevan años viendo venir.

Lo que un CISO debería revisar mañana por la mañana, no el próximo trimestre

Si el dato de Kaspersky vale para algo, es para ordenar prioridades con una honestidad que a veces escasea. No hace falta inventar un programa nuevo; hace falta comprobar si lo básico funciona de verdad.

Primero, superficie expuesta. No un inventario estático sacado de una CMDB bonita, sino una reconciliación continua entre lo que la organización cree tener, lo que realmente responde en Internet y lo que terceros de exposición externa son capaces de ver. Si un activo crítico público no tiene dueño claro, clasificación, nivel de criticidad, ventana de parcheo definida y capacidad de aislamiento rápido, ese activo no está gestionado. Está esperando turno.

Segundo, identidades privilegiadas y de terceros. Aquí conviene dejarse de métricas cosméticas y mirar casos concretos: cuántas cuentas administrativas no usan MFA resistente al phishing, cuántos proveedores mantienen acceso persistente, cuántas cuentas de servicio tienen privilegios elevados sin rotación frecuente, cuántos secretos están fuera de un gestor central y cuántas excepciones “temporales” llevan meses vivas. Suele ser un ejercicio deprimente. Precisamente por eso conviene hacerlo.

Tercero, telemetría y detección sobre uso anómalo de cuentas válidas. Muchas organizaciones monitorizan malware mejor que comportamiento. Necesitan casos de uso para detectar viajes imposibles, acceso fuera de patrón, tokens reutilizados, cambios sospechosos en métodos MFA, abuso de cuentas de servicio, escalado de privilegios tras autenticación aparentemente normal y actividad administrativa desde canales no habituales. Cuando el acceso inicial se produce con credenciales legítimas, el valor está en la desviación, no en la firma.

Cuarto, confianza técnica con terceros. No basta con saber que existe un contrato. Hay que revisar federaciones, túneles, VPN de soporte, herramientas RMM, accesos jump server, integraciones API y permisos sobre datos y sistemas. La pregunta operativa no es “tenemos proveedor X?”, sino “si mañana proveedor X fuera comprometido, qué podría tocar exactamente, durante cuánto tiempo y cómo lo sabríamos?”. Si la respuesta requiere una reunión de tres semanas, mal asunto.

Quinto, capacidad de notificación y escalado. Si un incidente entra por una aplicación expuesta o una cuenta comprometida y termina afectando a servicios esenciales o datos personales, los relojes regulatorios empiezan rápido. DORA art. 17 y siguientes articulan la gestión, clasificación y notificación de incidentes relacionados con TIC para entidades financieras, desarrollado después por normativa técnica secundaria. GDPR art. 33 mantiene sus 72 horas para brechas de datos personales. La coordinación entre seguridad, legal, privacidad, continuidad y comunicación no puede improvisarse cuando ya tienes al atacante dentro.

Lo que compliance no debería dejar solo en manos de seguridad

Hay una tentación recurrente en muchas organizaciones: tratar estas cifras como una lección técnica para el CISO y su equipo. Error. Si el 80% de los ataques relevantes se concentra en tres fallos de control bastante identificables, entonces compliance, auditoría interna y gestión de riesgos tienen materia clara para preguntar con más precisión y menos formalismo.

Por ejemplo: ¿el inventario de activos expuestos se contrasta con fuentes externas independientes? ¿Existe trazabilidad entre activo expuesto, propietario, criticidad y tiempo de remediación? ¿Se revisan accesos de proveedores con periodicidad definida y evidencia técnica? ¿Se han reducido privilegios heredados tras integraciones o migraciones? ¿Qué controles compensatorios existen cuando un parche crítico no puede aplicarse de inmediato? ¿Qué porcentaje de cuentas privilegiadas usa MFA resistente al phishing frente a MFA básico? ¿Cómo se detecta el uso anómalo de cuentas válidas? Ahí empiezan las preguntas útiles. Todo lo demás es liturgia.

En una entidad financiera bajo DORA, además, estas preguntas no son accesorias. El órgano de dirección debe aprobar, supervisar y ser responsable del marco de gestión del riesgo TIC conforme al artículo 5. Traducido al castellano llano: el consejo no puede limitarse a escuchar métricas verdes sin comprender si los tres principales vectores de intrusión están bajo control razonable. Si no puede obtener una respuesta clara, el problema no es técnico, es de gobierno.

Auditoría interna también tiene un papel incómodo pero necesario. Las revisiones tradicionales de políticas y muestras limitadas sirven de poco si no se testea la realidad operativa. En 2025 ya no basta con verificar que existe una política de gestión de vulnerabilidades o de accesos. Hay que comprobar si los activos expuestos críticos se descubren a tiempo, si los plazos de parcheo se cumplen en Internet-facing assets, si las altas y bajas de terceros funcionan, si los logs permiten reconstruir sesiones privilegiadas y si las excepciones tienen fecha de caducidad real. Suena menos elegante que una auditoría de madurez, pero es bastante más útil.

La contradicción de 2025: más herramientas, mismos agujeros

Quizá la parte más reveladora del informe de Kaspersky no sea el peso de cada vector, sino el desajuste entre inversión y resultado. Nunca ha habido tantas plataformas de seguridad, tanta inteligencia de amenazas, tanta capacidad de correlación y tanta retórica de resiliencia. Y aun así, los atacantes siguen entrando por aplicaciones expuestas, cuentas válidas y relaciones de confianza.

Eso sugiere una conclusión poco cómoda: el problema de muchas organizaciones no es la falta de tecnología, sino la incapacidad para convertirla en disciplina operativa. Pueden detectar más, sí, pero no necesariamente gobiernan mejor. Pueden comprar ASM sin retirar activos. Pueden tener IAM sin gobernar identidades no humanas. Pueden desplegar PAM y seguir concediendo accesos de proveedor demasiado amplios “por urgencia”. Pueden firmar cláusulas DORA impecables y no revisar una federación heredada desde hace un año. Todo esto pasa más de lo que a muchos les gustaría admitir.

Hay también una lección para el mercado regulatorio. DORA y NIS2 corren el riesgo de convertirse en ejercicios de documentación si supervisores y entidades no los aterrizan contra vectores concretos de ataque. La buena noticia es que ambas normas contienen materia suficiente para hacerlo bien: gestión de activos, controles de acceso, cadena de suministro, notificación, continuidad, pruebas y gobernanza. La mala es que traducir eso a operación diaria exige decisiones menos vistosas y bastante más ingratas.

La ironía final es brutal. El ecosistema ha pasado años hablando de inteligencia artificial defensiva, automatización avanzada y ciberresiliencia a escala, mientras una parte enorme del riesgo sigue concentrada en tres problemas que un comité de riesgos puede entender sin necesidad de ingeniería inversa: qué publicas, quién entra y en quién confías. No parece un enigma irresoluble. Parece, más bien, una cuestión de disciplina que muchas empresas todavía no han querido pagarse del todo.

Lo que viene ahora

Estos datos no predicen todo 2025, pero sí fijan una prioridad sensata. La organización que quiera reducir riesgo real en los próximos doce meses debería asumir que el acceso inicial seguirá explotando exposición externa, identidad comprometida y confianza delegada. Lo demás —ransomware, exfiltración, sabotaje, fraude, persistencia— vendrá después.

Para el sector financiero europeo, la lectura es aún más directa. DORA ya está en aplicación. NIS2 ya ha endurecido expectativas sobre ciberhigiene y cadena de suministro. GDPR sigue imponiendo plazos dolorosamente concretos cuando hay datos personales en juego. Si tu entidad aún no puede demostrar control razonable sobre estas tres puertas de entrada, no tiene un problema abstracto de madurez. Tiene un problema actual de riesgo operativo, de supervisión y, potencialmente, de responsabilidad del órgano de dirección.

Los atacantes no necesitan que una empresa lo haga todo mal. Les basta con que una aplicación siga expuesta, una cuenta siga siendo válida o una confianza siga concedida por inercia. Viendo las cifras, esa apuesta les sigue saliendo demasiado rentable.