eIDAS2, la cartera europea de identidad digital y el RGPD (VI)

21 de Septiembre de 2026

El Reglamento eIDAS2 incorpora importantes retos en materia de protección de datos, especialmente en lo que se refiere a la implementación de las carteras de identidad digital. Estos desafíos se hacen más patentes al intentar conciliar aspectos como la funcionalidad, la privacidad y la seguridad.

Foto de Sasun Bughdaryan en Unsplash.

En esta publicación se analiza cómo podrían materializarse diferentes amenazas de detección, brecha de datos y divulgación en las carteras europeas de identidad digital. En el nuevo ecosistema eIDAS2 surgen las siguientes preguntas:

Incluso si no comparto mis datos personales, ¿puede mi proveedor de cartera o un observador externo saber que estoy realizando una acción específica o que poseo una credencial concreta simplemente mediante observación?
¿Dónde se almacenan realmente mis escaneos faciales, documentos de identidad y registros de transacciones, y qué ocurre con mi identidad digital si un proveedor que participa en el ecosistema de cartera sufre un ciberataque? ¿Podría un actor malintencionado robar mi identidad o clonar mi cartera?
¿Puede un proveedor o un intermediario recoger más datos personales de los necesarios a través de mi cartera, conservar mis datos de forma indefinida o cederlos a terceros sin mi conocimiento explícito?

La pregunta 1 está relacionada con la amenaza de Detección. Esta amenaza implica deducir la existencia de datos o la implicación del interesado en una actividad a través de la observación, incluso cuando el contenido real o los valores de los datos subyacentes permanecen ocultos. En el ecosistema de carteras, esta amenaza surge cuando un observador como una Relying Party (RP), un intermediario, un proveedor de carteras o alguien que intercepta las comunicaciones detecta características del usuario o comportamientos relativos a sus transacciones al monitorizar las reacciones de ciertos componentes, tráfico de red o salidas de API (Application Programming Interface).

Supongamos que una API de navegador o sistema operativo, como la Digital Credentials API, se comporta de manera diferente en función de si la cartera está instalada, de si una credencial específica está presente o de si un usuario deniega el permiso para presentar una credencial. La RP puede detectar esto fácilmente. Por ejemplo, un rastreador web malintencionado podría llamar a la API para detectar si el ciudadano posee una credencial altamente específica, como una credencial médica o un estatus de minoría, simplemente observando mensajes de error de la API, variaciones de tiempo o cambios en el estado del dispositivo.

Otro escenario es cuando una credencial sensible está protegida por una Política de Divulgación Incorporada (Embedded Disclosure Policy), como una que restrinja la compartición sólo a RPs de confianza autorizadas. Si un usuario navega a una RP no autorizada, la cartera evalúa esta política y deniega la solicitud de presentación. Si la cartera devuelve un error específico de “acceso denegado” a la RP en lugar de un error genérico de “credencial no encontrada”, la RP puede detectar de inmediato que el usuario sí posee la credencial sensible, aunque la presentación haya sido bloqueada.

Las comprobaciones de revocación y los protocolos de “llamada a casa” (phoning home, patrones de comunicación en los que un dispositivo cliente, aplicación o credencial se pone en contacto periódicamente o por eventos con un servidor remoto controlado por su emisor, proveedor u operador para transmitir datos y/o recibir instrucciones) también podrían ayudar a que diferentes actores materialicen la amenaza de detección, junto con un método obvio como puede ser el acceso parcial o total a los registros de transacciones (logs).

La amenaza de Brecha de datos implica la destrucción, pérdida, alteración, divulgación no autorizada o acceso a datos personales por error, personas de confianza maliciosas o ciberataques, y está relacionada con la pregunta 2. Aunque una brecha de datos es una amenaza genérica de protección de datos, su materialización en el ecosistema de carteras puede tener un impacto catastrófico debido a la alta sensibilidad de los datos tratados, como la identidad legal (PID), los atributos cualificados (QEAAs), los datos biométricos de incorporación al ecosistema y los historiales de transacciones de por vida.

La comprobación remota de identidad sin supervisión suele implicar la captura de imágenes faciales de alta resolución, transmisiones de vídeo en directo y escaneos de documentos. Si los Proveedores de Servicios de Comprobación de Identidad (IPSP) o los Proveedores de Servicios de Confianza (TSP) conservan estos flujos biométricos en bruto en bases de datos centralizadas, crean enormes “honeypots”. Un ciberataque o una brecha causada por un actor interno malintencionado en este tipo de base de datos generaría un riesgo permanente de robo de identidad y suplantación biométrica.

Pero este es solo un ejemplo. Como ya se explicó en entradas anteriores, los formatos de credencial actuales en el ARF (ISO mDL y SD-JWT) se basan en hashes de atributos con salting y firmas estáticas del emisor. Si varias RP sufren brechas de datos, un atacante (o actores que confabulan) que posea registros de presentación de credenciales filtrados puede comparar huellas criptográficas estáticas (valores de salt, claves públicas o firmas) para vincular transacciones de usuarios en diferentes servicios ex post. Esto convierte, retroactivamente, una brecha de datos, en principio localizada, en vigilancia y perfilado a nivel sistémico.

Además, según eIDAS2 y el Reglamento (UE) 2024/2979, las carteras deben permitir a los usuarios exportar un Objeto de Migración que contenga metadatos y registros de transacciones a un almacenamiento en la nube para la recuperación del dispositivo. Si este Objeto de Migración o los registros de transacciones remotos se almacenan sin cifrar o con claves gestionadas por el proveedor débiles, una brecha en el proveedor de almacenamiento en la nube podría exponer el historial completo de interacciones digitales y uso de servicios del usuario. Las formas en que puede materializarse una amenaza de brecha de datos son virtualmente ilimitadas, y el impacto en este contexto es casi siempre grave.

Por último, en relación con la pregunta 3, debemos considerar las amenazas de Divulgación, que implican la recogida, almacenamiento, tratamiento, compartición o transferencia de datos personales en exceso. A diferencia de una brecha de datos (que con frecuencia suele implicar acceso no autorizado o malintencionado), la divulgación de datos puede producirse a través de operaciones autorizadas, legítimas o rutinarias cuando las decisiones de diseño dan lugar a sobreidentificación, compartición excesiva, desvío de finalidad o retención de datos no justificada, por ejemplo.

Las RP pueden intentar “acumular datos” o realizar solicitudes de atributos “por si acaso”. Supongamos que una RP solicita el PID completo de un usuario (nombre legal completo, fecha de nacimiento, número de identificación nacional, dirección o fotografía) para transacciones en las que funcionalmente solo se requiere un único atributo o una prueba booleana (“mayor de 18 años” o “residente del municipio X”). Además, los datos de la credencial o los atributos de identidad divulgados para una transacción inicial específica podrían reutilizarse, cruzarse con bases de datos comerciales externas o compartirse con terceros (como redes publicitarias) sin una base legal válida o autorización explícita del usuario.

Otros actores también pueden materializar esta amenaza. Por ejemplo, los proveedores de cartera o los de credenciales, firmas y sellos podrían recoger métricas de uso, observar detalles de las transacciones o rastrear cuándo y dónde un usuario presenta sus credenciales. O bien, los Proveedores de Servicios de Comprobación de Identidad (IPSP) podrían recopilar pruebas complementarias excesivas (por ejemplo, extractos bancarios completos, registros de servicios públicos o atributos de documentos innecesarios) o conservar de forma indefinida grabaciones de vídeo en bruto, escaneos de documentos de alta resolución e imágenes faciales durante la comprobación remota de identidad, ya sea sin supervisión o con asistencia (regulada por el estándar ETSI TS 119 461).

Como ya se ha explicado en entradas anteriores de esta serie, mitigar estas amenazas requiere diferentes medidas y salvaguardas, combinando un enfoque de protección de datos desde el diseño y por defecto con una aplicación de la norma que alcance también aspectos técnicos. Por ejemplo, las amenazas de detección se contrarrestan aplicando una estricta inobservabilidad mediante el almacenamiento local de registros de transacciones únicamente en el dispositivo del usuario, comprobaciones de revocación asíncronas que impidan a los emisores rastrear presentaciones en tiempo real, y respuestas de API y errores simétricos que eviten que los observadores detecten atributos de diferentes interesados.

Las amenazas de brecha de datos se mitigan eliminando “honeypots” centralizados, como bases de datos biométricas, mediante el tratamiento local, la eliminación inmediata de flujos de vídeo en bruto y escaneos faciales tras la vinculación de identidad, el mantenimiento de la segregación lógica y física de los datos de la cartera respecto a otros servicios del proveedor, el cifrado de copias de seguridad en el lado del cliente y el despliegue de Pruebas de Conocimiento Cero (Zero Knowledge Proof o ZKP) o credenciales anónimas para garantizar que los registros de presentación filtrados no puedan cruzarse entre diferentes partes.

Finalmente, las amenazas de divulgación se mitigan aplicando una divulgación selectiva a nivel de atributo, restringiendo técnicamente a las RP a su ámbito registrado mediante Certificados de Registro (Wallet Relying Party Registration Certificates o WRPRC) legibles por máquina, aplicando seudónimos por defecto siempre que la identificación no esté obligada por ley, y limitando de manera estricta la recolección de datos durante la incorporación al ecosistema a los atributos esenciales mínimos. Una próxima entrada analizará e ilustrará las amenazas de protección de datos que faltan por analizar.

Esta entrada está relacionada con otros materiales publicados por la División de Innovación y Tecnología de la AEPD, tales como: