Vinculación al titular en la cartera EUDI: qué prueba realmente una presentación
El problema de la posesión desde el texto primario: qué prueba una presentación de cartera, qué dice el ARF v3.0.0 sobre User binding y el retrato, una tabla de amenazas y un diseño de refuerzo por riesgo para equipos regulados.
En resumen
La vinculación al titular de la cartera europea de identidad digital (EUDI Wallet) es el vínculo entre la persona que presenta una cartera y la persona a la que se expidieron los datos de identidad. El Architecture and Reference Framework (ARF) lo denomina vinculación al usuario (User binding), y en la mayoría de las presentaciones la parte usuaria confía en él en lugar de comprobarlo.[2]
- Una presentación verificada y vinculada al dispositivo demuestra que los datos son auténticos y no se han modificado, y que la cartera contiene la clave vinculada.[2]
- No demuestra quién tiene el teléfono en su próximo inicio de sesión, pago o restablecimiento de contraseña.
- El nivel de seguridad alto es una garantía real. Mantenga la cartera como opción por defecto y añada comprobaciones faciales solo donde el riesgo lo justifique.
Este es el problema de la posesión. Una firma de la cartera muestra que se ha usado una clave. Hace falta una cadena de confianza para pasar de esa clave a un ser humano, y el último eslabón está en un teléfono que usted no controla.
Nada de esto hace que la cartera sea débil. Se expide en el marco de un sistema con nivel de seguridad alto, y un equipo que la trata como sospechosa la desaprovecha. Esta guía explica qué responde, qué deja abierto y cómo cerrar la brecha.
Para el registro y los certificados, consulte nuestra guía para partes usuarias. Para elegir la vía de integración, consulte cómo elegir una plataforma de integración de la cartera EUDI.
Qué demuestra realmente una presentación de la cartera
Una presentación remota ejecuta varias comprobaciones en secuencia. Algunas le corresponden a usted y otras se producen dentro de la cartera, donde usted no puede verlas.
Usted nunca ve el paso 3
Comprobar firma y estado
Comprobar vinculación al dispositivo
Presentación remota simplificada, basada en la sección 6.6.3 del ARF v3.0.0. Los pasos 1, 2 y 4 son visibles para usted o para la persona. El paso 3 no lo es.[2]
| Capa | Qué acredita | Quién comprueba | Situación para usted | Límite |
|---|---|---|---|---|
| Firma del emisor | Los datos proceden de un proveedor auténtico y no se han modificado[2] | Usted | El artículo 5b(9) lo atribuye a las partes usuarias, para los PID y las declaraciones[1] | No dice nada sobre quién realiza la presentación |
| Estado de revocación | El proveedor de los datos no los ha revocado[2] | Usted | Recomendado, no obligatorio[3] | Solo tan actualizado como la fuente de estado |
| Vinculación al dispositivo | Los datos están en la unidad de cartera a la que se expidieron, no en una copia[2] | Usted | Recomendado, pero obligatorio si confía en la autenticación propia de la cartera[2] | Demuestra una clave, no una persona |
| Integridad de la cartera | La unidad de cartera y su hardware seguro eran válidos en el momento de la emisión[2] | El proveedor de los datos, durante la emisión[2] | Usted confía en esto de forma indirecta[2] | No tiene forma directa de verificarlo[2] |
| Autenticación del usuario | La cartera autenticó a su usuario antes de liberar los datos[2][6] | La cartera | Usted confía en esto de forma indirecta[2] | No le llega ningún resultado |
El ARF v3.0.0 divide la atestación de la unidad de cartera del reglamento en una Wallet Instance Attestation, sobre la integridad de la aplicación y su estado de revocación, y una Key Attestation, sobre el almacenamiento seguro que guarda las claves.[2] Sobre su posición: "La instancia de la parte usuaria no tiene forma de verificar directamente la autenticidad de la unidad de cartera y del proveedor de la cartera."[2]
Figura 12 de la ARF: el usuario accede a la unidad de cartera mediante un enlace de autenticación que la parte usuaria nunca ve. Fuente: EUDI Wallet Architecture and Reference Framework, Comisión Europea, CC BY 4.0. Sin adaptar.
Cubra la brecha que deja la cartera
Aplique prueba de vida y comparación facial en las acciones que conllevan un riesgo real, en el flujo que ya usa hoy para la verificación. Empiece gratis o hable con nosotros.
Vinculación al dispositivo, vinculación al titular y la brecha que queda después
Bajo "vinculación al titular" se mezclan tres vínculos distintos. Los dos primeros son conceptos de la ARF. El tercero es una etiqueta nuestra.
De la clave a la cartera
Vinculación al dispositivo
- Los datos están vinculados a una clave en hardware seguro[2]
- También llamada prueba de posesión[2]
- Impide la copia y la reutilización[2]
Lo comprueba usted
De la cartera a la persona
Vinculación al usuario
- Quien presenta los datos es la persona a la que se expidieron[2]
- Depende de la vinculación al dispositivo[2]
- Normalmente se da por buena, no se verifica[2]
La realiza la cartera
De la persona a la acción
Vinculación a la acción
- Esta persona realizó esta acción posterior
- Queda fuera de la presentación
- Reside en su sesión y en sus controles
Solo suya (término nuestro)
La vinculación al dispositivo (device binding) y la vinculación al usuario (User binding) son términos del ARF. La vinculación a la acción es una etiqueta de Didit, no un término de ninguna norma.
El documento de debate del ARF sobre declaraciones vinculadas al dispositivo expone la distinción en una sola línea: «Una declaración puede estar vinculada a un dispositivo pero no a un usuario».[11] La definición que importa es esta.
Sección 6.6.3.9ARF v3.0.0
«La vinculación al usuario (a veces también llamada “vinculación al titular”) es la propiedad de que la persona que presenta el PID o la declaración ante la parte usuaria es, de hecho, el usuario al que se expidieron el PID o la declaración».
Fuente: ARF v3.0.0, capítulo 6[2]
A nivel de protocolo, la propiedad que usted controla es require_cryptographic_holder_binding en OpenID4VP. Su valor por defecto es true, y fijarla en false indica a la cartera que usted acepta una credencial sin esa prueba.[12] El protocolo dice holder binding donde el ARF dice device binding.[12][2] Déjela activada. Nuestra guía del verificador OpenID4VP explica las comprobaciones.
Lo que dicen la ley y el ARF, con sus propias palabras
Estas disposiciones regulan la expedición y la presentación en la cartera, no las acciones posteriores en su cuenta.
| Norma | Texto | Qué significa para usted |
|---|---|---|
| Art. 5a(4)(a), Reglamento 910/2014 | Las carteras deben permitir a los usuarios presentar datos «bajo el control exclusivo del usuario»[1] | Nuestra lectura: un requisito sobre cómo se construyen las carteras, no una conclusión sobre ninguna sesión |
| Art. 5a(5)(d) y 5a(11) | Las carteras cumplen los requisitos del nivel de seguridad alto y se proporcionan en el marco de un sistema de nivel de seguridad alto[1] | Base sólida, sin necesidad de prueba adicional para esa afirmación |
| Art. 5b(9) | Las partes usuarias son responsables de "autenticar y validar" los datos[1] | Las comprobaciones de firma y validez son responsabilidad suya |
| Art. 3(5), Reglamento 2024/2977 | Los proveedores de PID "deben garantizar" que los PID que expidan "estén vinculados criptográficamente a la unidad de cartera a la que se expidan"[4] | Los proveedores de PID deben vincular el PID a la unidad de cartera; usted verifica el resultado |
| Art. 3(1), Reglamento 2024/2979 | Ninguna funcionalidad básica "hasta que la unidad de cartera haya autenticado correctamente al usuario de la cartera"[6] | La cartera autentica antes de actuar |
| Anexo, punto 2.2.1, Reglamento de Ejecución 2015/1502 | Para el nivel de seguridad alto, "El medio de identificación electrónica está diseñado para que pueda ser protegido de manera fiable por la persona a quien pertenece contra su uso por otros."[7] | Protección frente a terceros, al alcance del titular |
| WIAM_14, anexo 2 del ARF | El hardware seguro para el PID autentica al usuario con nivel de seguridad alto antes de las operaciones criptográficas sobre sus activos críticos[3] | Una segunda capa de autenticación dentro de la cartera |
La sección 6.5.3.3.1 del ARF dice: "Durante la activación de la unidad de cartera, la unidad de cartera garantiza que el usuario configure dos mecanismos de autenticación de usuario." Uno funciona a nivel del sistema operativo y otro en el hardware criptográfico seguro que se usa cuando se expide, presenta o elimina un PID.[2] El usuario tiene que superar ambos para presentar el PID.[2]
La sección 6.6.3.9 sobre la confianza en esa autenticación: "Esta confianza no se basa en el resultado de ninguna verificación realizada por la propia parte usuaria", sino en "una confianza a priori en la unidad de cartera certificada y (para los PID y las atestaciones con nivel de seguridad alto) en el WSCA/WSCD certificado."[2] (WSCA y WSCD: la aplicación y el dispositivo criptográficos seguros de la cartera.) El ARF añade que confiar en este método "implica que las partes usuarias deben verificar la vinculación al dispositivo".[2]
Así, el ARF establece tres vías para la vinculación al usuario. Confiar en la autenticación de la cartera, que siempre se ejecuta. Comparar un retrato incluido en el PID con el rostro en vivo. O comparar los atributos del PID con un documento de identidad que pueda verificar que pertenece realmente a la persona.[2]
Por qué el nivel de seguridad alto es una garantía real
El nivel de seguridad alto exige protección "frente a atacantes con un alto potencial de ataque".[7] La certificación pone a prueba esa resistencia.[8] Un PID falsificado, una cartera clonada o una respuesta reproducida deberían fallar. Nuestra lectura: el nivel de seguridad alto describe el medio y no dice nada de un titular real que decide prestar o vender su uso.
El documento de trabajo Topic R del ARF de 14 de octubre de 2025 recoge que "a día de hoy, los dispositivos móviles no tienen medios ni base para certificar ante las partes usuarias de la cartera que se ha realizado la autenticación del usuario", y que, en opinión de algunos expertos, la biometría del dispositivo "no es plenamente fiable".[10] Es un documento de debate, no un requisito.
- 11 de agosto de 2026Normas de confirmación del retratoReglamento 2026/1731 en vigor: avisos y confirmación explícita.
- 24 de diciembre de 2026Plazo de las carterasCálculo propio: 24 meses desde los actos.
- 10 de julio de 2027Aplicación del AMLREl artículo 22(6) vincula a los sujetos obligados.
- 24 de diciembre de 2027AceptaciónCálculo propio: artículo 5f(2). Partes privadas obligadas por ley o contrato a usar autenticación reforzada de usuario, a petición del usuario; microempresas y pequeñas empresas exentas.
- 11 de agosto de 2028Retrato en el PIDAtributo obligatorio del PID desde esta fecha, salvo exclusiones voluntarias.
Las fechas de diciembre son un cálculo propio a partir de los artículos 5a(1) y 5f(2), contadas desde la entrada en vigor de los actos de ejecución mencionados en los artículos 5a(23) y 5c(6) (Reglamentos 2024/2977 a 2024/2982, en vigor desde el 24 de diciembre de 2024).[1][4][5][13] Consulte nuestra guía de plazos de la cartera EUDI.
El retrato: útil, opcional y estrictamente regulado
El retrato es la forma evidente de comprobar a la persona. El Reglamento de Ejecución (UE) 2026/1731, adoptado el 15 de julio de 2026 y publicado en el Diario Oficial el 22 de julio de 2026, modificó sus normas.
- Calendario. "el retrato del usuario de la cartera podrá formar parte de los datos de identificación de la persona obligatorios para la persona física únicamente a partir del 11 de agosto de 2028".[5] Con arreglo a la tabla PID actual, el retrato se incluye "salvo que el usuario lo rechace expresamente, cuando proceda".[5]
- Se mantiene la exclusión voluntaria. Los Estados miembros "podrán disponer que el usuario tenga la opción de rechazar la inclusión del retrato", y en ese caso el valor queda vacío.[5]
- Aviso de la cartera. La cartera advierte de que la solicitud implica datos biométricos, y el usuario debe "confirmar de forma explícita y específica la presentación del retrato".[4] El requisito RPA_07c del ARF añade: "El silencio o una casilla premarcada NO DEBERÁN considerarse suficientes."[3]
- No es una base jurídica. El considerando 2 del Reglamento 2026/1731 dice: "La confirmación explícita del usuario de la cartera debe ser una salvaguarda técnica y no constituir por sí misma una base jurídica para el tratamiento."[5] El considerando remite a los artículos 6 y 9 del RGPD para la base jurídica.[5]
- Conservación. El retrato "no será conservado por las partes usuarias de la cartera salvo que su tratamiento sea necesario a efectos de identificación y autenticación" con arreglo a la normativa de protección de datos, o que el Derecho de la Unión o nacional lo prevea.[4][5]
- Registro. Según el artículo 5b(3), no puede solicitar datos más allá de los que registró, así que el retrato debe figurar en el uso registrado.[1]
Para la comparación a distancia, el ARF exige buena iluminación, instrucciones claras y "un mecanismo aprobado de detección de vida compatible con la detección de ataques de presentación", "así como mecanismos de detección de ataques de inyección, en particular la detección de deepfakes".[2] ENISA describe en detalle los ataques de presentación facial.[21] ETSI TS 119 461 define un ataque de inyección como un "ataque consistente en inyectar contenido controlado por el atacante en el proceso de captura de datos".[23]
Una comprobación facial en un teléfono: el paso de captura es la superficie de ataque. Ilustración de mikemacmarketing, Wikimedia Commons, CC BY 2.0. Sin adaptar.
La verificación uno a uno cuya única finalidad es confirmar una identidad declarada queda excluida de la entrada del anexo III del AI Act sobre identificación biométrica remota.[16] Los datos biométricos utilizados para identificar de forma unívoca a una persona siguen siendo categorías especiales de datos según el artículo 9 del RGPD, así que prevea una base jurídica y una evaluación de impacto.[15]
Amenaza por amenaza: qué detiene la cartera y qué queda en sus manos
El reglamento de certificación contiene un registro de riesgos para las carteras. Los identificadores de amenaza que figuran a continuación son los oficiales. Las dos últimas columnas son nuestra valoración.[8]
| Amenaza | Registro | Efecto de la cartera | Qué queda | Su control |
|---|---|---|---|---|
| Datos de la cartera copiados o duplicados | TR60 | Alto: vinculación al dispositivo[2] | Poco, si lo verifica | Mantenga activa la prueba de vinculación |
| Presentación reproducida | Tipo 5.3 | Alto: firma nueva sobre sus datos[2] | Poco | Nonce único por solicitud |
| Teléfono robado, bloqueado | TR98 | Alto: dos capas de autenticación[2] | Robo del factor de conocimiento (TR35) | Comprobar el estado de revocación |
| Dispositivo compartido en el hogar | TR35, TR98 | Parcial | Alguien que conoce el PIN o el código[22] | Verificación reforzada en acciones de alto riesgo |
| Usuario coaccionado o manipulado | TR28, TR99 | Débil: el usuario legítimo aprueba | Casi todo | Seguimiento de transacciones, periodo de reflexión, verificación reforzada con contexto |
| Retransmisión entre dispositivos | TR103 | Parcial: comprobación de proximidad[24] | Phishing de la sesión del navegador | Usar el mismo dispositivo siempre que se pueda e indicar la acción |
| Autenticación local vulnerada | TR113 | Depende de la certificación[8] | Riesgo de dispositivo comprometido | Comprobación de revocación, señales del dispositivo |
| Toma de control de la cuenta tras el alta | Fuera de la cartera | Ninguna salvo que se vuelva a presentar | Contraseñas, sesiones, flujos de recuperación | Verificación reforzada en cambios sensibles |
| Mula con una cartera real | Fuera de la cartera | Nada: se superan todas las comprobaciones | Todo | Monitorización del comportamiento, vínculos de red |
El usuario legítimo que aprueba
TR99 dice: "Un atacante puede convencer a un usuario para que se autentique y apruebe transacciones con un atacante o un tercero no autorizado."[8] Todos los factores se superan. La autenticación reforzada de clientes "sigue siendo eficaz frente a los tipos de fraude que estaba diseñada para mitigar", según el BCE, y el fraude total notificado en el Espacio Económico Europeo fue de €4.2 billion en 2024.[19][20] En las transferencias, el fraude por manipulación del ordenante creció "del 65% al 74% en valor y del 55% al 71% en volumen, de 2023 a 2024".[19]
Dos personas, dos dispositivos
TR103: "El usuario detrás de la conexión entre la parte usuaria y el navegador puede ser distinto del usuario detrás de la conexión entre la parte usuaria y la cartera."[8] La sección 4.4.3.2 del ARF señala que "los flujos entre dispositivos son vulnerables a ataques de phishing y de retransmisión", y la sección 4.4.3 hace obligatoria para ellos la comprobación de proximidad.[24] Su sesión web sigue estando separada de la aprobación en la cartera.
Figura 5 del ARF: en un flujo entre dispositivos, su servicio se comunica con un navegador y la cartera está en un segundo dispositivo. Fuente: EUDI Wallet Architecture and Reference Framework, Comisión Europea, CC BY 4.0. Sin adaptar.
La mula con una cartera real
Una persona que vende el acceso a una cuenta, o que abre una para otra persona, supera honestamente todas las comprobaciones de la cartera, porque esa persona es la titular. El control es el que ya establece el Reglamento contra el blanqueo de capitales (AMLR): el "seguimiento continuo de las relaciones de negocios".[13] Los vínculos entre cuentas, los dispositivos compartidos y las caras repetidas son las señales que ponen al descubierto las redes.
Un diseño de verificación reforzada que mantiene la cartera como opción por defecto
Ningún texto que hayamos leído exige prueba de vida además de una cartera. El artículo 22(6)(b) del AMLR enumera, como una de sus opciones, "el uso de medios de identificación electrónica que cumplan los requisitos del Reglamento (UE) n.º 910/2014 en lo que respecta a los niveles de seguridad 'sustancial' o 'alto'".[13] Los proyectos finales de normas de la Autoridad de Lucha contra el Blanqueo de Capitales (AMLA) indican que esto "incluye las carteras europeas de identidad digital", y esas normas siguen siendo un proyecto, no derecho vigente.[14] Consulte nuestra guía del AMLR sobre la aceptación de carteras.
El artículo 20(2) del AMLR deja el alcance de las medidas a "un análisis individual de los riesgos".[13] En nuestra opinión, un selfie en cada presentación es difícil de justificar con arreglo al principio de minimización de datos del RGPD.[15] Estos niveles son una sugerencia nuestra, no categorías jurídicas.
1Clasificar el evento
Alta, inicio de sesión o una acción concreta, con su riesgo.
Cuánto daño puede causar la persona equivocada
Solo con la cartera
Comprobaciones criptográficas completas. Sin biometría.
Añadir prueba de vida y comparación facial
Con el retrato, o con una cara que conserve de forma lícita.
Volver a verificar en la acción
Nueva comprobación vinculada a esta acción y, después, revisión.
2Registrar la evidencia
Qué se ejecutó, el resultado, la fecha. Por defecto, no el retrato.
Un flujo de decisión de ejemplo. Fije sus propios umbrales en su evaluación de riesgos.
| Nivel | Eventos habituales | Controles | Por qué |
|---|---|---|---|
| La cartera por sí sola | Comprobaciones de edad o de atributos, apertura de cuenta estándar, inicio de sesión de bajo riesgo | Firma, vinculación al dispositivo, estado, nonce | El nivel de seguridad alto hace el trabajo; cuantos menos datos, mejor |
| Cartera más rostro | Cliente de mayor riesgo, dispositivo o ubicación inusual, primer uso tras un largo periodo sin actividad | Lo anterior, más prueba de vida y comparación facial | Responde directamente a la vinculación al usuario (User binding), tal como la describe el ARF[2] |
| Reverificación por acción | Nuevo beneficiario, pago elevado, cambio de datos bancarios, recuperación, alta de un dispositivo | Nueva comprobación facial o aprobación vinculada a la operación, más revisión | Vincula a la persona con esa acción |
| Sin cartera o sin retrato | Cliente sin cartera, país con implantación tardía, retrato excluido por el usuario | Documento, lectura del chip, prueba de vida, comparación facial | El uso de la cartera es voluntario[1] |
El PID no puede aprobar una acción por usted: "Las unidades de cartera NO DEBERÁN utilizar una clave privada del PID para firmar datos de transacción recibidos de una parte usuaria en una solicitud de presentación."[9] La aprobación de operaciones corresponde a las declaraciones de autenticación reforzada del usuario (SUA), que contienen datos de transacción y se encuadran en el tema del ARF sobre pagos electrónicos.[3] La normativa de pagos funciona igual: el código debe ser "específico para el importe de la operación de pago y el beneficiario".[18] La fórmula de PSD2 "cualquier acción a través de un canal remoto que pueda entrañar un riesgo de fraude en el pago u otros abusos" es un modelo útil de activación.[17]
Opción
Cartera de nuevo
- Nueva presentación del PID
- Confirma de nuevo la cartera
- Sin vínculo con la acción
Adecuada para el inicio de sesión
Opción
Comprobación facial
- Prueba de vida y comparación facial
- Comprueba a la persona presente
- Necesita una referencia lícita
Adecuada para cambios de riesgo
Opción
Declaración de la transacción
- Firma los datos de la acción
- Muestra al usuario lo que se aprueba
- Depende del soporte del emisor
Adecuada para pagos
Atención
No use la clave del PID como identificador del dispositivo. Los proveedores pueden emitir declaraciones que se presentan una sola vez, para "mitigar el riesgo de vinculabilidad por las partes usuarias".[2] Identifique a los clientes recurrentes por sus atributos, como explica nuestra guía de aceptación transfronteriza.
Lista de comprobación: qué hacer este mes
La política interna en la que se basan estos pasos está en nuestra guía de políticas y controles de la cartera EUDI, y la decisión sobre la vía de integración está en la guía de plataformas de integración.
Cumplimiento y riesgos
- Documente qué eventos dependen solo de la cartera.
- Defina los desencadenantes de la verificación reforzada para pagos salientes, cambios de beneficiario y recuperación de cuentas.
- Determine la base jurídica de cualquier comparación facial.[5][15]
- Actualice su evaluación de impacto relativa a la protección de datos para el uso del retrato.[15]
Ingeniería
- Siga exigiendo la prueba de vinculación al titular en cada solicitud.[12]
- Verifique la firma de vinculación al dispositivo en cada respuesta.[2]
- Compruebe el estado de revocación aunque sea opcional.[3]
- Vincule cada presentación a una única sesión con un nonce nuevo.
- Diseñe el flujo del retrato de modo que gestione un valor vacío.[5]
Producto y soporte
- Solicite el retrato solo cuando sus finalidades registradas lo incluyan.[1]
- Mantenga una vía basada en documentos para quienes no tengan cartera.[1]
- Redacte el texto de cada verificación reforzada de modo que indique la acción.
- Informe a los clientes de que pueden pedir al proveedor de la cartera que revoque una cartera robada.[6]
Cómo ayuda Didit con el problema de la posesión
La documentación de Didit indica la aceptación de la cartera EUDI con el estado «Próximamente».[28] Nuestra página sobre la cartera EUDI dice "Todavía no existe una API de Didit específica para EUDI" e "Integre hoy y consérvelo cuando llegue la cartera". Esta sección trata de lo que funciona hoy. Biometric Authentication ejecuta verificaciones reforzadas de prueba de vida y comparación facial.
- Reverificación. Biometric Authentication verifica a los usuarios recurrentes solo con prueba de vida, o con prueba de vida más comparación facial con un retrato almacenado, como una sesión dentro de un flujo de trabajo.[25][27]
- Presencia. Liveness comprueba que hay una persona real delante de la cámara, con métodos pasivos, de acción 3D o de destellos.[26]
- Verificación reforzada. La documentación del producto Authentication de Didit describe una llamada que aplica sus reglas de verificación reforzada antes de una acción sensible y devuelve si se requiere verificación. Es nueva y se activa por aplicación.[31]
- Redes. Face Search detecta cuentas duplicadas, y Networks agrupa a los solicitantes que comparten señales de dispositivo, IP, biométricas, de documento o de contacto.[29][30]
- Seguimiento. Transaction Monitoring analiza las transacciones en tiempo real con un motor de reglas configurable e incluye gestión de casos.[32]
- Alternativa. ID Verification y las eID nacionales operativas atienden a los clientes que no tienen cartera.[28]
Didit proporciona
- Prueba de vida y comparación facial bajo demanda
- Rutas de documento y de eID nacional
- Señales de duplicados y de redes
- El registro de cada comprobación
Sigue siendo suyo
- La evaluación de riesgos y la política de verificación reforzada
- Su base jurídica y su evaluación de impacto
- El registro como parte usuaria
- Cada decisión de alta y de transacción
Los planes y las tarifas están en nuestra página de precios. Los datos almacenados siguen el plazo de conservación que usted configure, y Didit actúa como su encargado del tratamiento.[33]
Diseñe con nosotros su verificación reforzada
Indíquenos qué acciones conllevan más riesgo y empiece con la prueba de vida y la comparación facial en su flujo.
Puntos clave
- La vinculación al dispositivo demuestra una clave. La vinculación al usuario enlaza esa clave con una persona, y normalmente se confía en ella en lugar de comprobarla.
- El nivel de seguridad alto ofrece una garantía sólida sobre la cartera, y no cubre a una mula que colabora voluntariamente ni a un usuario manipulado.
- El retrato se incorpora a los datos obligatorios del PID a partir del 11 de agosto de 2028, con sujeción a las exclusiones voluntarias, y la confirmación del usuario no es una base jurídica.
- El PID no puede firmar datos de transacción, por lo que las acciones de alto riesgo necesitan otra aprobación.
Preguntas frecuentes
¿Qué es la vinculación al titular (holder binding) en la cartera EUDI?
La vinculación al titular es la propiedad de que la persona que presenta los datos es la persona a la que se expidieron. El ARF la denomina vinculación al usuario (User binding) e indica que a veces también se denomina holder binding.[2]
¿Qué diferencia hay entre la vinculación al dispositivo y la vinculación al titular?
La vinculación al dispositivo une los datos a una clave guardada en el hardware seguro de la cartera, e impide la copia y la reproducción. La vinculación al titular une los datos a una persona. El ARF trata la vinculación al dispositivo como requisito previo de la vinculación al usuario (User binding).[2]
¿Es obligatoria la vinculación al dispositivo para el PID?
Sí, para los proveedores. El Reglamento de Ejecución 2024/2977 exige a los proveedores de PID que garanticen que el PID que expiden está vinculado criptográficamente a la unidad de cartera.[4] Verificar la firma se recomienda a las partes usuarias, y es obligatorio si usted se basa en la autenticación propia de la cartera.[2]
¿Puedo hacer una comparación facial con el retrato de la cartera?
Solo si el PID lo incluye, usted ha registrado ese uso, el usuario lo confirma y dispone de una base jurídica. El retrato se incorpora a los datos obligatorios del PID a partir del 11 de agosto de 2028, y los Estados miembros pueden permitir que los usuarios opten por no incluirlo.[5]
¿Puedo conservar el retrato de una presentación de la cartera?
No por defecto. Solo puede conservarse si el tratamiento es necesario para la identificación y la autenticación conforme al Derecho de la Unión en materia de protección de datos, o cuando el Derecho de la Unión o nacional lo prevea.[4][5]
¿Exige el AMLR una prueba de vida además de la cartera EUDI?
Ningún texto que hayamos leído lo exige. El artículo 22(6)(b) recoge, como una opción, los medios de identificación electrónica que cumplen los requisitos del Reglamento 910/2014 con nivel de seguridad sustancial o alto, y el alcance de las medidas depende de su análisis de riesgos individual.[13] Los proyectos finales de normas de AMLA indican que esto incluye las carteras, y todavía no tienen fuerza de ley.[14]
¿Puede una presentación de la cartera aprobar un pago?
No con el PID. El PID Rulebook prohíbe usar la clave privada del PID para firmar datos de transacciones.[9] El ARF prevé que la aprobación de transacciones concretas se base en declaraciones de autenticación reforzada del usuario, que contienen los datos de la transacción.[3]
¿Impide el nivel de seguridad alto la apropiación de cuentas?
Protege la cartera, no su cuenta. Tras el alta, sus contraseñas, sesiones y procesos de recuperación quedan fuera de la cartera, salvo que solicite una nueva presentación u otra comprobación en los momentos sensibles.
¿Puede una mula superar los controles de la cartera EUDI?
Sí. Un titular real que usa una cartera real supera todos los controles, porque lo que comprueban es cierto. El control es el seguimiento continuo conforme al artículo 26 del AMLR, junto con los vínculos entre cuentas.[13]
¿Acepta Didit la cartera EUDI?
La documentación de Didit recoge la aceptación de la cartera EUDI con el estado «Próximamente», y la página de soluciones indica que todavía no existe una API de Didit específica para EUDI.[28] Las identidades electrónicas (eID) nacionales, la verificación de documentos, la prueba de vida y la comparación facial funcionan hoy, y la página de soluciones describe el plan.
Fuentes
- Reglamento (UE) n.º 910/2014, modificado por el Reglamento (UE) 2024/1183, texto consolidado de 18 de octubre de 2024, EUR-Lex.
- Architecture and Reference Framework v3.0.0, capítulo 6, Trust model, Comisión Europea, 23 de julio de 2026.
- Architecture and Reference Framework v3.0.0, anexo 2, High-Level Requirements, Comisión Europea.
- Reglamento de Ejecución (UE) 2024/2977, texto consolidado de 11 de agosto de 2026, EUR-Lex.
- Reglamento de Ejecución (UE) 2026/1731, EUR-Lex, Diario Oficial de 22 de julio de 2026.
- Reglamento de Ejecución (UE) 2024/2979, texto consolidado de 11 de agosto de 2026, EUR-Lex.
- Reglamento de Ejecución (UE) 2015/1502 sobre los niveles de seguridad, EUR-Lex.
- Reglamento de Ejecución (UE) 2024/2981 sobre la certificación de carteras, anexo I, registro de riesgos, EUR-Lex.
- PID Rulebook v1.7, Comisión Europea, 17 de julio de 2026.
- Topic R, Authentication of the User to the device, v1.0, documento de debate del ARF, 14 de octubre de 2025.
- Topic Z, Device-bound Attestations, v1.0, documento de debate del ARF, 29 de septiembre de 2025.
- OpenID for Verifiable Presentations 1.0, OpenID Foundation.
- Reglamento (UE) 2024/1624 (AMLR), EUR-Lex, Diario Oficial de 19 de junio de 2024.
- Informe final, proyecto de RTS conforme al artículo 28(1) del AMLR, AMLA, 30 de septiembre de 2026 (proyecto final, sin fuerza de ley).
- Reglamento (UE) 2016/679 (GDPR), EUR-Lex.
- Reglamento (UE) 2024/1689 (AI Act), EUR-Lex.
- Directiva (UE) 2015/2366 (PSD2), EUR-Lex.
- Reglamento Delegado (UE) 2018/389, EUR-Lex.
- Informe de 2025 sobre el fraude en los pagos, EBA y ECB, diciembre de 2025.
- Informe conjunto EBA-ECB sobre el fraude en los pagos, nota de prensa, ECB, 15 de diciembre de 2025.
- Remote Identity Proofing: Attacks and Countermeasures, ENISA.
- TechDispatch on Digital Identity Wallets, European Data Protection Supervisor, diciembre de 2025.
- ETSI TS 119 461 v2.1.1, verificación de la identidad de los sujetos de servicios de confianza, ETSI.
- Architecture and Reference Framework v3.0.0, capítulo 4, High-level architecture, European Commission.
- Biometric Authentication, documentación de Didit.
- Detección de vida, documentación de Didit.
- Face Match 1:1, documentación de Didit.
- Carteras de identidad digital, documentación de Didit.
- Face Search, documentación de Didit.
- Networks, documentación de Didit.
- Crear una verificación reforzada, documentación de Didit.
- Monitorización de transacciones, documentación de Didit.
- Conservación de datos, documentación de Didit.
Una cartera responde a quién pertenece una credencial, y su análisis de riesgo empieza a partir de esa respuesta. Para los momentos que exigen a una persona, consulte Biometric Authentication. Para la preparación de la cartera, consulte nuestra página sobre la cartera EUDI y verificación de eID.
Verifique a la persona, no solo la clave
Añada prueba de vida y comparación facial donde su evaluación de riesgos indique que corresponden.
Artículos relacionados
- Aceptación transfronteriza de la cartera EUDI: una sola integración en toda la UE
- Preparación para la cartera EUDI: políticas y controles para entidades reguladas
- Vinculación al titular en la cartera EUDI: qué prueba realmente una presentación
- Integración de la cartera EUDI: cómo elegir su vía (guía 2026)
- Verificación de identidad FINTRAC en 2026: métodos, normas y C-12
- Ley 25 de Quebec y biometría: guía de verificación de identidad (2026)