Cumplimiento de DORA: Por qué la seguridad de credenciales es ahora un imperativo legal para las instituciones financieras
La Ley de Resiliencia Operativa Digital (DORA) convierte la seguridad de credenciales en un control de riesgo financiero vinculante. Una contraseña comprometida puede generar amenazas sostenidas e invisibles, impactando directamente la continuidad operativa. Las instituciones financieras deben implementar controles robustos, incluyendo MFA resistente a phishing y gestión de acceso privilegiado, para cumplir con los requisitos de DORA y evitar consecuencias regulatorias.

*Autor: Eirik Salmi, Analista de Sistemas en **Passwork***
**Cuando un actor de amenazas ingresa a su red utilizando un nombre de usuario y contraseña legítimos, ¿qué control los detiene?**
Para la mayoría de las instituciones financieras, la respuesta honesta es: nada los detecta de inmediato. El atacante parece un usuario autorizado. Se mueven lateralmente, escalan privilegios y mapean sistemas críticos durante un promedio de 186 días antes de que la brecha sea identificada, y 55 días adicionales para contenerla, según el [Informe sobre el Costo de una Brecha de Datos](https://www.ibm.com/reports/data-breach) de **IBM** (2025).
Para entonces, el daño operativo está hecho y el reloj regulatorio ya ha comenzado.
El 17 de enero de 2025, la [Ley de Resiliencia Operativa Digital (DORA)](https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en) entró en vigor en toda la UE. El Artículo 9 del reglamento convierte la seguridad de credenciales en un control de riesgo financiero vinculante, con consecuencias supervisoras para las instituciones que no cumplan.
La pregunta ya no es si su postura de autenticación cumple con las mejores prácticas. Es si cumple con la ley, y si puede demostrarlo.
Este artículo rastrea los requisitos específicos del Artículo 9 que rigen la gestión de credenciales, explica por qué una contraseña comprometida es una falla en la resiliencia operativa bajo el marco de **DORA**, y describe los controles prácticos que cierran la brecha.
## La amenaza que DORA fue diseñada para contrarrestar
Las credenciales robadas son el vector de acceso inicial más grande en 2025, representando el 22% de todas las brechas de datos, según el [Informe de Investigaciones de Brechas de Datos](https://www.verizon.com/business/resources/reports/dbir/) de **Verizon**. Para las instituciones financieras, el costo sectorial de esa exposición promedia $5.56 millones por incidente, según el Informe sobre el Costo de una Brecha de Datos de **IBM**, una disminución respecto a los $6.08 millones en 2024, pero aún así el segundo más alto de cualquier industria a nivel mundial.
El lado de la oferta del robo de credenciales se ha industrializado por completo. Los Brokers de Acceso Inicial venden acceso verificado a redes corporativas por un promedio de $2,700, con el 71% de los listados incluyendo credenciales privilegiadas, acceso preempaquetado que no requiere habilidades técnicas para explotar, según investigación de **Rapid7**.
Infostealers como **Lumma**, **RisePro**, **StealC**, **Vidar** y **RedLine** automatizan la recolección de credenciales a escala. Los datos de **IBM** X-Force muestran que su entrega a través de phishing aumentó un 84% interanual en 2024, con datos de 2025 apuntando a una trayectoria aún más pronunciada.
El Artículo 9 de **DORA** existe precisamente para interrumpir esta cadena. El reglamento refleja una amenaza documentada y continua para la continuidad operativa de los mercados financieros europeos.
## Lo que realmente requiere el Artículo 9 de DORA
[El Artículo 9 de DORA](https://www.digital-operational-resilience-act.com/Article_9.html), titulado "Protección y Prevención", se encuentra dentro del marco de gestión de riesgos TIC exigido por el Artículo 6. Establece obligaciones técnicas y de procedimiento específicas que las entidades financieras deben implementar.
Dos disposiciones son directamente relevantes para la gestión de credenciales.
* **Artículo 9(4)(c)** exige que las entidades financieras "implementen políticas que limiten el acceso físico o lógico a los activos de información y activos TIC a lo que sea necesario solo para funciones y actividades legítimas y aprobadas". Este es el principio de mínimo privilegio, establecido como una obligación legal.
* **Artículo 9(4)(d)** va más allá, exigiendo a las entidades "implementar políticas y protocolos para mecanismos de autenticación sólida, basados en estándares relevantes y sistemas de control dedicados, y medidas de protección de claves criptográficas mediante las cuales los datos se cifran basándose en los resultados de procesos aprobados de clasificación de datos y evaluación de riesgos TIC".
Desglosando ese lenguaje en términos operativos: MFA es obligatorio. La referencia a "estándares relevantes" apunta directamente a FIDO2/WebAuthn, el estándar de autenticación más ampliamente desplegado actualmente resistente a kits de phishing Adversary-in-the-Middle (AiTM), que pueden eludir MFA basado en SMS y TOTP en tiempo real. La gestión de claves criptográficas es un requisito regulatorio.
Las herramientas de gestión de acceso privilegiado (PAM) no se nombran explícitamente en el reglamento, pero los controles que proporcionan se alinean directamente con los requisitos del Artículo 9. La grabación de sesiones, el aprovisionamiento de acceso justo a tiempo (JIT) y la bóveda de credenciales privilegiadas son precisamente los "sistemas de control dedicados" que describe el reglamento.
Las instituciones que no han implementado estos controles enfrentan una brecha de cumplimiento sobre la cual los supervisores pueden actuar.
La Autoridad Bancaria Europea (**EBA**) y las Normas Técnicas Regulatorias de **ESMA** bajo **DORA** proporcionan especificidad adicional sobre los requisitos de gestión de riesgos TIC, reforzando la base del Artículo 9 con orientación de implementación específica del sector.
## Compromiso de credenciales como falla de resiliencia operativa
El propósito declarado de **DORA** es garantizar que las entidades financieras puedan resistir, responder y recuperarse de las interrupciones TIC. Un compromiso de credenciales se ve completamente diferente a través de esa lente que a través de una lente de incidente de seguridad.
Con un tiempo de permanencia promedio de 186 días, una credencial comprometida no produce un evento de seguridad discreto. Produce una amenaza sostenida e invisible para la continuidad operativa: un atacante moviéndose lateralmente, escalando privilegios y mapeando sistemas críticos mientras aparece como un usuario legítimo. Es una amenaza directa a la continuidad operativa que **DORA** está diseñada para proteger.
La brecha del [registro nacional de bancos de Francia](https://www.bleepingcomputer.com/news/security/data-breach-at-french-bank-registry-impacts-12-million-accounts/) en enero de 2026 concretó la mecánica. Un actor de amenazas obtuvo las credenciales de un solo funcionario civil con acceso a Ficoba, la base de datos interministerial que contiene registros de cada cuenta bancaria abierta en Francia.
Usando solo esa cuenta, el atacante accedió y extrajo datos de 1.2 millones de cuentas bancarias, incluyendo IBANs, nombres y direcciones de titulares de cuentas, y números de identificación fiscal.
El sistema afectado se desconectó, las operaciones en el registro se interrumpieron y el incidente se informó a la autoridad de protección de datos de Francia, **CNIL**. El ataque no requirió sofisticación técnica.
Bajo **DORA**, un incidente de esa escala en una entidad financiera activaría obligaciones de notificación obligatoria bajo el Artículo 19: una notificación inicial dentro de las 4 horas posteriores a la clasificación (y no más de 24 horas después de la detección), un informe intermedio dentro de las 72 horas y un informe final dentro de un mes.
## La dimensión de terceros: las credenciales de proveedores son sus credenciales
El Capítulo V de **DORA** impone obligaciones explícitas a las entidades financieras con respecto al riesgo de terceros TIC. El perímetro de cumplimiento no se detiene en los sistemas propios de la institución.
La brecha de [Santander](https://www.bleepingcomputer.com/news/security/snowflake-account-hacks-linked-to-santander-ticketmaster-breaches/) en mayo de 2024 es el punto de referencia europeo. Los atacantes utilizaron credenciales robadas a empleados de **Snowflake** para acceder a una base de datos que contenía datos de clientes y empleados en España, Chile y Uruguay.
Las credenciales habían sido recolectadas meses antes por malware infostealer que infectó estaciones de trabajo de contratistas. Ninguna de las cuentas de **Snowflake** comprometidas tenía habilitada la autenticación multifactor.
El punto de entrada no estaba dentro de **Santander**. Era la postura de autenticación débil de un proveedor, y expuso datos pertenecientes a uno de los bancos más grandes de Europa sin que se escribiera un solo exploit.
Bajo **DORA**, una institución financiera cuyo proveedor TIC crítico sufra una brecha basada en credenciales enfrenta exposición regulatoria directa. Las instituciones deben exigir contractualmente estándares de autenticación equivalentes a sus proveedores y auditar el cumplimiento de esos requisitos.
Una brecha en la política de contraseñas de un proveedor no es solo problema del proveedor, es responsabilidad regulatoria de la entidad financiera.
## Construyendo una gestión de credenciales conforme a DORA
Cumplir con los requisitos del Artículo 9 exige un programa estructurado en cuatro áreas.
* **Implemente MFA resistente a phishing primero.** Autenticación basada en FIDO2/WebAuthn: llaves de seguridad de hardware, passkeys, autenticadores de plataforma. Las contraseñas de un solo uso basadas en SMS y TOTP no son adecuadas contra las técnicas de ataque actuales. Aplique MFA resistente a phishing para todos los usuarios, con particular rigor en cuentas privilegiadas y rutas de acceso remoto.
* **Aplique acceso de mínimo privilegio.** Aprovisionamiento JIT: otorgar acceso elevado solo durante la duración de una tarea específica elimina los privilegios permanentes que hacen que el robo de credenciales sea tan dañino. Desactive cuentas inmediatamente al darse de baja. Las cuentas inactivas se encuentran entre los vectores de ataque más comunes y evitables.
* **Almacene todas las credenciales en bóveda.** Las contraseñas de cuentas de servicio, las claves API y las credenciales privilegiadas deben almacenarse en una bóveda de credenciales cifrada y controlada por acceso. La gestión manual de credenciales a escala es operativamente inviable y no produce una pista de auditoría. Un gestor de contraseñas empresarial