Riesgo de acceso de terceros: Qué falló en la brecha danesa

El riesgo de acceso de terceros es la exposición que asume una organización cuando proveedores, contratistas o socios de integración tienen credenciales de sus sistemas o datos. Dinamarca reveló su magnitud en octubre de 2026: un atacante utilizó el acceso legítimo de una empresa de TI de dos personas al registro nacional de población y expuso datos de unos 8,8 millones de personas.

La causa raíz que se ha publicado es corriente. Al menos tres cuentas del proveedor, Pays ApS, están vinculadas a la brecha, sus administradores usaban supuestamente la contraseña «123456» y el acceso se prolongó durante 21 días y 17 horas antes de que los administradores del registro tuvieran conocimiento de ello.

Puntos clave

La brecha entró a través de las cuentas de un proveedor. Se vieron afectados unos 8,8 millones de los 11 millones de registros del padrón.
La plantilla del proveedor no limitó el daño. El alcance, la frecuencia de consultas y el número de cuentas de acceso determinan el radio de impacto.
Seis controles forman la comprobación del radio de impacto del acceso de proveedores: acceso acotado, límites de tiempo, credenciales únicas generadas, MFA en el perímetro que usted controla, supervisión de sesiones y una baja obligatoria al finalizar el contrato.
La referencia que hay que superar es de 21 días y 17 horas. Compruebe si su propia supervisión detectaría antes una actividad anómala en las cuentas de proveedores.

Qué ocurrió en Dinamarca y por qué es un caso de acceso de proveedores

En septiembre de 2026, un atacante utilizó el acceso legítimo al registro de Pays ApS, una empresa danesa de TI con dos empleados, para consultar el Registro Central de Personas (CPR) de Dinamarca. Se vieron afectados unos 8,8 millones de sus 11 millones de registros. El punto de entrada fueron las cuentas de un proveedor, no los sistemas del propio registro.

Cybernews informó de que al menos tres cuentas de Pays ApS están vinculadas a la brecha y de que, según se ha publicado, los administradores de la empresa usaban «123456» como contraseña. El director general de la empresa declaró a la cadena TV 2 que «se ha abusado de su acceso legal para buscar información en el sistema CPR». El Registro Central de Empresas de Dinamarca indicaba que la empresa tenía dos empleados en julio de 2026.

Un atacante anónimo contó al periódico danés Politiken que la intrusión comenzó con una contraseña filtrada de un antiguo empleado de una pequeña empresa danesa y que después dos programas extrajeron datos del registro. La Agencia Danesa de Protección de Datos afirmó que el ataque incluyó algún tipo de fuerza bruta para enumerar números CPR válidos, según BleepingComputer.

Fecha (2026)	Suceso	Fuente
10 de septiembre	Comienza el acceso, que dura 21 días y 17 horas en total	Cybernews
2 de octubre	La administración del CPR tiene conocimiento de la brecha	BleepingComputer
5 de octubre	Las autoridades anuncian la brecha, bloquean el acceso de la empresa y abren una investigación policial	BleepingComputer

Visto como causa y efecto: una contraseña débil o filtrada del proveedor dio al atacante el acceso del proveedor, ese acceso permitió tres semanas de enumeración y la enumeración devolvió registros de 8,8 millones de personas.

Un número CPR por sí solo no permite suplantar a un ciudadano, porque el segundo factor MitID de Dinamarca sigue siendo un obstáculo. Cybernews señala que los datos pueden hacer más eficaz el phishing y cruzarse con brechas anteriores.

Por qué el tamaño del proveedor no reduce el radio de impacto

La plantilla de un proveedor no influye en el daño que pueden causar sus credenciales. El radio de impacto depende de a qué puede llegar una cuenta, cuántos datos puede extraer por hora y cuántas cuentas de acceso existen. Una empresa de dos personas con acceso de búsqueda a un registro de 11 millones de entradas tiene la misma exposición que una grande.

Cybernews explica por qué una empresa de ese tamaño tenía ese acceso: las organizaciones pueden recibir acceso autorizado a determinados datos del registro para verificar las direcciones de sus clientes o mantener registros de socios. La consecuencia, en sus palabras, es que «la seguridad del registro depende, en parte, de las prácticas de seguridad de las organizaciones autorizadas a consultarlo».

La mayoría de las empresas tienen la misma estructura en su propia infraestructura: un proveedor de pagos con claves API para los registros de clientes, un proveedor de servicios gestionados con derechos de administrador de dominio, una agencia con acceso al CMS de producción. Dimensione cada caso según cuatro factores antes de conceder nada.

Factor	Pregunta clave
Alcance	¿A cuántos registros, sistemas o credenciales puede llegar esta cuenta?
Operación	¿Puede leer un registro, hacer consultas masivas o escribir?
Frecuencia	¿Hay un límite por cuenta y una alerta cuando el volumen se dispara?
Cuentas de acceso	¿Cuántas cuentas existen y pertenece cada una a una persona identificada?

«Somos demasiado pequeños para un programa de acceso de proveedores» es la objeción a la que responde este caso. El tamaño del programa debe corresponder al alcance del proveedor en sus datos, no a su plantilla ni a la del proveedor. Lo que sí cambia con el tamaño del proveedor es cuánta práctica de seguridad puede dar por supuesta: una empresa de dos personas rara vez tiene una función de seguridad dedicada, así que la verificación recae en usted.

Con qué rapidez crece el riesgo de acceso de terceros

El Data Breach Investigations Report 2026 de Verizon constató la implicación de terceros en el 48 % de las brechas, frente al 30 % un año antes, un salto del 60 %. Esa cifra anterior ya se había duplicado respecto a la edición de 2024. Dinamarca es un ejemplo de un patrón que ya afecta a casi la mitad de las más de 22 000 brechas que analizó el informe.

Verizon divide la exposición a terceros en tres arquetipos: un proveedor de su cadena de suministro de software, un proveedor que aloja sus datos y un proveedor conectado a su entorno. Pays ApS pertenece al tercer grupo. El mismo informe muestra con qué lentitud cierran los proveedores las brechas de seguridad que hay detrás del titular.

Hallazgo del informe 2026 de Verizon	Cifra
Brechas con implicación de un tercero	48 % (30 % en la edición anterior)
Terceros que corrigen por completo la MFA ausente o mal configurada en cuentas en la nube	23 %
Mediana de tiempo para resolver la mitad de los hallazgos de contraseñas débiles y permisos excesivos	Casi 8 meses
Organizaciones con al menos una cuenta de administrador IaaS con la MFA desactivada	37 %

La mitad de los hallazgos de contraseñas débiles y permisos excesivos siguen abiertos después de casi ocho meses. El acceso en Dinamarca duró tres semanas.

La factura también sigue subiendo. El Cost of a Data Breach Report 2026 de IBM sitúa la media mundial en 4,99 millones de dólares por filtración de datos, un récord y un aumento del 12 %.

Lecturas relacionadas

La vertiente normativa del riesgo de proveedores se trata en la guía de seguridad de la cadena de suministro .

Por qué exigir MFA no basta en las cuentas de proveedores

La MFA protege los puntos de inicio de sesión que usted controla. Las cuentas de proveedores suelen quedar fuera de su SSO, fuera de la aplicación de su MFA y fuera de los procesos de baja gestionados por recursos humanos, de modo que una política sólida en su lado dice poco de la contraseña en el lado del proveedor. En el acceso de proveedores, verifique la higiene de las cuentas en el perímetro en lugar de darla por supuesta.

Ni Cybernews ni BleepingComputer mencionan un segundo factor en las cuentas comprometidas. Los fallos publicados están una capa por debajo de la MFA: una contraseña trivial en cuentas de administrador y la contraseña filtrada de un antiguo empleado que, según el atacante, abrió la puerta de entrada.

Una vez que una credencial se filtra, la revocación es lenta. El State of Secrets Sprawl 2026 de GitGuardian hizo un seguimiento de secretos válidos encontrados en commits públicos de GitHub en 2022 y constató que el 64 % seguía sin revocarse en 2026. Una credencial filtrada de un proveedor sigue activa hasta que alguien asume la responsabilidad de revocarla.

«Nuestros proveedores están certificados» no cierra la brecha. Un certificado describe el programa de un proveedor. No puede decirle si la cuenta que un contratista abre hoy usa una contraseña única generada o un acceso compartido por toda la empresa. Los accesos compartidos también hacen ilegible el registro de auditoría: el log muestra la empresa, no la persona.

Si hoy los accesos de los proveedores están en hojas de cálculo y conversaciones de chat, trasládelos a una bóveda donde cada credencial se genera, se acota y queda registrada. Pruebe Passwork gratis y hágalo primero con un solo proveedor.

Comprobación del radio de impacto: Seis controles para el acceso de terceros

La comprobación del radio de impacto del acceso de proveedores es una rutina de seis controles para dimensionar y limitar a qué pueden llegar las credenciales de un proveedor: acotar el acceso a la tarea, limitarlo en el tiempo, emitir credenciales únicas, aplicar la MFA en su perímetro, supervisar las sesiones de los proveedores y condicionar el cierre del contrato a la baja. Aplíquela antes de conceder acceso y en cada revisión.

La Directiva NIS2 de la UE regula esta capa. La Directiva (UE) 2022/2555 (NIS2), en su artículo 21, apartado 2, letra d), incluye la seguridad de la cadena de suministro entre las medidas de gestión de riesgos que adoptan las entidades esenciales e importantes, incluidos los aspectos de seguridad de la relación con cada proveedor directo o prestador de servicios.

Acotar el acceso a la tarea. Aplique el principio de mínimo privilegio a cada proveedor: conceda las bóvedas, los sistemas o los ámbitos de API concretos que exige el contrato, dimensiónelos con los cuatro factores anteriores y mantenga separadas las cuentas de administrador y las de uso habitual. El acceso basado en roles hace que esto sea repetible, y la guía de RBAC muestra cómo vincular el alcance a la función laboral. En Dinamarca, un solo conjunto de credenciales podía enumerar millones de registros.
Limitar el acceso en el tiempo. Vincule cada cuenta de proveedor a la fecha de finalización del contrato o del proyecto, retire el acceso permanente cuando el trabajo se detenga y vuelva a aprobarlo en cada hito mediante una revisión de accesos programada. Una contraseña filtrada solo funciona mientras la cuenta funcione. Si la filtración danesa procedía de un antiguo empleado, la baja era el control que la habría neutralizado.
Emitir credenciales únicas y atribuibles a cada persona. Una cuenta por persona, nunca una por empresa. Genere las contraseñas en lugar de dejar que cada persona las elija y rechace al crearlas valores reconocidamente inseguros como «123456». Haga primero un inventario de las credenciales en poder de los proveedores; la guía de gestión de credenciales SaaS explica cómo.
Aplicar la MFA en el perímetro que usted controla. Coloque el segundo factor en el inicio de sesión de su pasarela, portal o bóveda, sea cual sea la postura de seguridad del proveedor. Así, una contraseña adivinada o filtrada no abre nada por sí sola. Las cuentas de proveedores dentro de sus sistemas siguen la misma regla que las cuentas de empleados.
Supervisar las sesiones de proveedores como las de empleados con privilegios. Registre cada sesión, genere alertas ante picos de volumen, accesos fuera de horario y consultas secuenciales, y revise la actividad de los proveedores con un calendario fijo. La gestión de accesos privilegiados abarca la grabación de sesiones y la elevación just-in-time (justo a tiempo). La siguiente sección ofrece una referencia de la rapidez con la que deben saltar esas alertas.
Convertir la baja del proveedor en requisito obligatorio al finalizar el contrato. El contrato no se cierra hasta que las cuentas del proveedor estén desactivadas, las credenciales compartidas se hayan rotado y se haya firmado una revisión final de accesos. Desactivar una cuenta no equivale a rotar lo que conocía, porque las contraseñas, claves API y tokens que el proveedor ya vio siguen siendo válidos hasta que se cambian. La guía de baja de empleados aplica la misma lógica a la plantilla, y se traslada directamente a los contratistas.

Con qué rapidez detectaría un acceso anómalo de un proveedor

En el caso danés, el acceso publicado duró 21 días y 17 horas antes de que la administración del registro tuviera conocimiento de la brecha el 2 de octubre. Utilice ese intervalo como referencia: si mañana una cuenta de proveedor empezara a enumerar registros en sus sistemas, ¿lo detectaría antes su supervisión?

El patrón publicado ofrece señales que puede poner a prueba. Una enumeración por fuerza bruta genera un gran volumen de consultas desde una sola cuenta, muchas de ellas de identificadores que no existen, y además el atacante trasladó datos a un almacenamiento fuera del registro.

Señal	En el patrón danés	Alerta que probar
Volumen	Consultas durante tres semanas	Número diario de consultas por cuenta de proveedor frente a su línea base
Enumeración	Fuerza bruta sobre números CPR válidos	Tasa elevada de consultas fallidas o secuenciales desde una cuenta
Horario y origen	No publicado	Inicios de sesión fuera del horario contratado o desde nuevas ubicaciones
Exfiltración	Datos almacenados fuera del registro	Lecturas o exportaciones masivas desde una cuenta de proveedor

El acceso permanente dificulta el ajuste de estas alertas, porque una cuenta sin fecha de finalización no tiene un marco de proyecto con el que comparar su actividad. El acceso limitado en el tiempo reduce lo que hay que vigilar. Realice un ejercicio de simulación (tabletop): elija la cuenta de proveedor con mayor alcance, simule el patrón de enumeración y mida cuánto tarda alguien en recibir una alerta.

Cómo ayuda Passwork a controlar el acceso de proveedores y terceros

Passwork permite a un equipo dar a cada proveedor exactamente las credenciales que exige su contrato y retirarlas en una sola acción. Los permisos por bóveda y por carpeta acotan el acceso, el control de acceso basado en roles separa a los administradores de los miembros y el registro de actividad deja constancia de quién abrió qué y cuándo. Passwork gobierna las credenciales almacenadas en la bóveda.

El modelo de gestión de accesos de Passwork se corresponde con los seis controles anteriores.

Control	Función de Passwork
1. Acotar a la tarea	Niveles de acceso por bóveda y carpeta (acceso completo, solo lectura, prohibido), tipos de bóveda personalizados por proyecto o nivel de acceso, y administradores corporativos asignados por política que el propietario de una bóveda no puede eliminar
2. Acceso limitado en el tiempo	Enlaces externos con límite de tiempo, opcionalmente de un solo uso, para credenciales que un proveedor necesita una vez, sin necesidad de cuenta; el acceso continuo del proveedor termina al desactivar su grupo
3. Credenciales únicas	Cuentas individuales por usuario y un generador de contraseñas integrado que aplica las reglas de complejidad definidas por la organización
4. MFA en su perímetro	Los administradores pueden exigir la autenticación de dos factores (TOTP, WebAuthn) en todas las cuentas; SAML SSO y LDAP/AD para la plantilla
5. Supervisión	Registro de actividad de las acciones de usuarios, administradores y sistema, exportable a Syslog o a un SIEM
6. Baja obligatoria	Desactivación del grupo de un proveedor sin eliminarlo; el panel de seguridad señala las credenciales que siguen al alcance de usuarios cuyo acceso se revocó, lo que proporciona la lista de rotación

Agrupe a las personas de cada proveedor en un único grupo y vincule la desactivación del grupo a la fecha de finalización del contrato en su lista de verificación de bajas. Es un solo paso en lugar de una búsqueda cuenta por cuenta.

Una bóveda gobierna las credenciales que usted almacena y emite. No puede aplicar reglas de contraseñas dentro de los sistemas del propio proveedor ni en un registro gubernamental, por lo que esos controles siguen dependiendo de las cláusulas del contrato, los derechos de auditoría y la supervisión del control 5. Revocar el acceso tampoco borra lo que un contratista ya vio: rote todo lo que haya abierto.

Qué hacer este trimestre frente al riesgo de acceso de terceros

El registro danés quedó expuesto a través de los accesos de un proveedor, y el tamaño del proveedor no cambió en nada el resultado. Aborde el riesgo de acceso de terceros ante todo como un problema de dimensionamiento: enumere a qué puede llegar cada cuenta de proveedor, dé a cada persona una credencial generada propia y asigne a cada una una fecha de finalización y una alerta de supervisión.

Siguiente paso: esta semana, haga una lista de todas las cuentas de proveedores y contratistas con acceso permanente y, después, aplique la comprobación del radio de impacto a las tres con mayor alcance.

Si su equipo concede a proveedores o contratistas acceso a credenciales compartidas, pruebe Passwork gratis: acote ese acceso por bóveda, comparta credenciales puntuales mediante enlaces con límite de tiempo y revoque el grupo de un proveedor en un solo paso, con un registro de auditoría detrás de cada acción.

Preguntas frecuentes sobre el riesgo de acceso de terceros

¿Qué es el riesgo de acceso de terceros?

El riesgo de acceso de terceros es la exposición que asume una organización cuando proveedores, contratistas o socios de integración tienen acceso a sus sistemas o datos. El riesgo se sitúa fuera de su propio perímetro de seguridad, pero aun así puede exponer sus datos, como en la brecha del CPR de Dinamarca en 2026, en la que las cuentas comprometidas de un proveedor llegaron a 8,8 millones de registros.

¿En qué se diferencia el acceso de proveedores del de empleados?

Las cuentas de proveedores suelen quedar fuera de la MFA, el SSO y los procesos de baja gestionados por recursos humanos de la propia organización, por lo que necesitan su propia política de acceso, frecuencia de revisión y desencadenante de revocación. Vincúlelos al contrato, no al organigrama: el acceso empieza y termina con la declaración de trabajo, y un responsable designado firma cada revisión.

¿Cada cuánto revisar los permisos de acceso de proveedores?

Revise las cuentas de proveedores con privilegios cada trimestre, las cuentas estándar de proveedores al menos dos veces al año y todas las cuentas en los hitos del contrato, en los cambios de alcance y al finalizar el contrato. Trate la revisión final como un requisito obligatorio para cerrar el contrato. Estas frecuencias son una base práctica; ajústelas a su propia evaluación de riesgos.

¿Basta un gestor de contraseñas para resolver el riesgo de acceso de proveedores?

No. Un gestor de contraseñas controla las credenciales almacenadas en él: quién las tiene, cómo se generan, quién las abrió y cuándo. No puede aplicar reglas de contraseñas dentro de los sistemas del propio proveedor, así que las cláusulas del contrato, la MFA en su perímetro, la supervisión y la baja obligatoria siguen siendo importantes. Es la base sobre la que se construyen los demás controles.

¿Qué hacer con el acceso de proveedores cuando termina un contrato?

Desactive todas las cuentas del proveedor, rote cada credencial compartida y clave API que el proveedor pudiera leer, revise el registro de actividad del periodo del contrato y deje constancia de la aprobación antes de cerrarlo. Desactivar las cuentas no basta, porque las contraseñas y los tokens que el proveedor ya vio siguen siendo válidos, así que la rotación es un paso aparte.