La entrada La estrategia clave para migrar a la seguridad Post-Cuántica (PQC) sin detener el negocio se publicó primero en EADTrust.
]]>Ante la llegada inminente de los estándares post-cuánticos (FIPS 203, 204 y 205), la cripto-agilidad deja de ser una ventaja teórica para convertirse en un requisito operativo indispensable para evitar la obsolescencia tecnológica y el incumplimiento normativo.
El fin de la criptografía estática: por qué el modelo actual es insostenible
Históricamente, la criptografía se ha implementado de forma «estática» o rígida. Muchos desarrollos de software tienen algoritmos (como RSA o SHA-256) «hardcodeados» (incrustados) directamente en el código fuente de las aplicaciones.
El problema de la deuda técnica criptográfica
Este enfoque rígido genera una deuda técnica masiva ante la amenaza cuántica:
- Dependencia profunda: cambiar un algoritmo implica reescribir, recompilar y redesplegar aplicaciones enteras.
- Visibilidad nula: las empresas a menudo desconocen cuántas claves o certificados tienen, dónde están ubicados y qué algoritmo utilizan.
- Tiempos de reacción lentos: si se descubre una vulnerabilidad crítica (como ocurrió con Heartbleed o la debilidad futura de RSA), el tiempo de parcheo puede ser de meses, dejando una ventana de exposición inaceptable.
La cripto-agilidad propone una arquitectura donde la criptografía es un módulo intercambiable, permitiendo una transición fluida hacia los nuevos estándares PQC del NIST.
Los 3 pilares de una arquitectura cripto-ágil
Para implementar una estrategia de cripto-agilidad efectiva, las empresas deben actuar sobre tres ejes fundamentales: visibilidad, desacoplamiento y automatización.
1. Visibilidad y descubrimiento (Inventory)
No se puede proteger ni migrar lo que no se conoce. El primer paso es el descubrimiento automatizado de activos criptográficos.
- Escaneo de red: identificar todos los certificados SSL/TLS, claves SSH y firmas digitales en uso.
- Mapeo de algoritmos: clasificar cada activo según su algoritmo (RSA, ECC, AES) y su longitud de clave.
- Detección de Shadow IT: localizar servicios criptográficos no autorizados que podrían ser puntos ciegos durante la migración PQC.
2. Desacoplamiento y abstracción
El objetivo es eliminar el «hardcoding». Las aplicaciones no deben llamar a un algoritmo específico (ej: «Usar RSA-2048»), sino solicitar un servicio criptográfico genérico (ej: «Firmar documento»).
- Uso de librerías y APIs: implementar capas de abstracción o middleware que gestionen la criptografía.
- Políticas centralizadas: la decisión de qué algoritmo usar se toma en un archivo de configuración central o en un gestor de políticas, no en el código de la aplicación. Esto permite cambiar de RSA a CRYSTALS-Dilithium (FIPS 204) globalmente con una simple actualización de política.
3. Automatización del ciclo de vida
La gestión manual de miles de certificados y claves es humanamente imposible en entornos híbridos (clásicos + post-cuánticos).
- Rotación automática: sistemas que renuevan claves y certificados automáticamente antes de su caducidad.
- Despliegue instantáneo: capacidad para empujar nuevos algoritmos o revocar claves comprometidas en toda la infraestructura en cuestión de minutos, no días.
Cripto-agilidad y cumplimiento normativo (eIDAS / RGPD)
La agilidad criptográfica tiene implicaciones directas en la responsabilidad legal de la empresa.
RGPD y el «Estado de la técnica»
El RGPD exige medidas de seguridad acordes al estado de la técnica. Una organización que tarda meses en reemplazar un algoritmo vulnerado por falta de agilidad podría enfrentarse a sanciones por negligencia en la protección de datos desde el diseño.
eIDAS 2.0 y la identidad digital
Con la evolución del reglamento eIDAS y la futura Cartera de Identidad Digital Europea (EUDI Wallet), como Prestador de Servicios de Confianza seremos capaces de adaptarnos a nuevos requisitos de seguridad sin interrumpir el servicio.
La cripto-agilidad permite integrar nuevos esquemas de firma o autenticación exigidos por la UE (como los basados en PQC) sin refundar la plataforma tecnológica.
Roadmap sobre cómo implementar la cripto-agilidad hoy
Para los CISO y arquitectos de sistemas, la migración a un entorno ágil debe ser progresiva y paralela a la preparación para la era post-cuántica.
- Fase de auditoría: utilizar herramientas de escaneo para crear un inventario criptográfico dinámico. Identificar los puntos críticos donde la criptografía está «quemada» en el código. O lo que es más fácil, contratar la auditoría de EADTrust.
- Fase de saneamiento: comenzar a reemplazar llamadas directas a algoritmos por llamadas a librerías criptográficas modernas (como OpenSSL 3.0+ o Bouncy Castle) que soportan proveedores intercambiables.
- Adopción de certificados híbridos: implementar certificados que contengan tanto claves clásicas como post-cuánticas. Esto permite que los sistemas antiguos sigan funcionando mientras los sistemas modernos aprovechan la seguridad PQC, todo gestionado por la misma infraestructura ágil.
Pruebas de estrés: simular la revocación masiva de una autoridad de certificación o la obsolescencia súbita de un algoritmo para medir el tiempo de recuperación (MTTR) de la organización.
Preguntas Frecuentes (FAQ) sobre Cripto-agilidad
No necesariamente todo, pero sí los componentes críticos. Muchos HSM (Módulos de Seguridad de Hardware) antiguos no admiten actualización de firmware para nuevos algoritmos. La cripto-agilidad implica tener un inventario de hardware que permita actualizaciones de software o su sustitución rápida.
La criptografía híbrida es una táctica (usar dos algoritmos a la vez para seguridad redundante), mientras que la cripto-agilidad es una estrategia arquitectónica (la capacidad de cambiar esos algoritmos fácilmente). La agilidad facilita la implementación de esquemas híbridos.
Si se implementa correctamente, el impacto es despreciable. Aunque las capas de abstracción añaden una latencia mínima, la ventaja operativa de poder responder a amenazas en tiempo real y evitar paradas de servicio compensa sobradamente cualquier microsegundo de retraso en el procesamiento.
No. Cualquier empresa que gestione datos sensibles o cumpla normativas estrictas necesita agilidad. Las PYMES tecnológicas son a menudo más vulnerables al «hardcoding» por desarrollos rápidos y falta de estandarización, lo que las hace candidatas ideales para adoptar prácticas de desarrollo ágil y seguro (DevSecOps).
Conclusión
La cripto-agilidad no es un producto que se compra, sino una metodología que se adopta. En un mundo donde los estándares del NIST evolucionan y la computación cuántica amenaza los cimientos de la seguridad actual, la rigidez es el mayor riesgo empresarial.
Adoptar una postura cripto-ágil hoy garantiza que su organización pueda navegar la transición post-cuántica mañana sin interrupciones, costes desorbitados o brechas de cumplimiento.
También te puede interesar…
La entrada La estrategia clave para migrar a la seguridad Post-Cuántica (PQC) sin detener el negocio se publicó primero en EADTrust.
]]>La entrada Diciembre 2026: el plazo que tu empresa no puede ignorar se publicó primero en EADTrust.
]]>Si eres responsable de IT, legal, compliance o transformación digital en una empresa de banca, telecomunicaciones, energía, transporte, sanidad, seguros o educación en España, estos dos plazos ya deberían estar en tu planificación. No como una fecha futura a evaluar, sino como una fecha concreta con obligaciones técnicas y jurídicas que requieren tiempo de preparación. Menos del que parece.
Términos sobre plazos EUDI Wallet
Acto de ejecución
Reglamento adoptado por la Comisión Europea que establece las especificaciones técnicas concretas de implementación del Reglamento general. Los actos de ejecución de eIDAS 2.0 definen los protocolos, formatos e interfaces que deben cumplir todos los actores del ecosistema EUDI.
Parte usuaria de la cartera
Organización pública o privada que solicita y verifica atributos de usuarios que presentan su EUDI Wallet. Debe estar registrada en el sistema nacional de partes usuarias y disponer del certificado de acceso correspondiente.
Certificado de acceso de parte usuaria
Certificado emitido por un proveedor autorizado que autentica y valida a una parte usuaria ante las carteras de los usuarios. Requisito técnico imprescindible para poder recibir datos de la EUDI Wallet.
Registro de partes usuarias
Sistema nacional que recoge las organizaciones autorizadas para solicitar atributos de usuarios de la EUDI Wallet. Regulado por el Reglamento de Ejecución (UE) 2025/848. Antes de poder operar, la organización debe haber completado su registro.
Autenticación reforzada
Nivel de autenticación que requiere más de un factor de verificación. En sectores bajo PSD2, MiFID II u otras normas que exigen identificación robusta del cliente, la obligación de aceptar la EUDI Wallet se activa cuando el proceso requiere autenticación reforzada.
usercentric.id
Directorio de partes informadas e informantes para la Cartera IDUE, construido por EADTrust. Punto de entrada para organizaciones que quieren integrarse en el ecosistema EUDI como emisoras o verificadoras de credenciales.
Por qué el plazo de diciembre de 2026 es el primero que importa
El artículo 5 bis del Reglamento (UE) 2024/1183 establece que los Estados miembros proporcionarán al menos una cartera europea de identidad digital en los veinticuatro meses siguientes a la entrada en vigor de los actos de ejecución previstos en el propio artículo. Los primeros actos de ejecución relevantes fueron adoptados el 28 de noviembre de 2024 (los Reglamentos de Ejecución (UE) 2024/2977, 2024/2978, 2024/2979, 2024/2981 y 2024/2982). Con ese punto de partida, el plazo de veinticuatro meses lleva al 24 de diciembre de 2026 como fecha límite para la disponibilidad de la wallet.
Eso tiene tres consecuencias simultáneas que ocurren en esa fecha:
- Primera: todos los ciudadanos de los Estados miembros tienen el derecho de solicitar y recibir su EUDI Wallet. El Estado no puede negar ese derecho. En España, eso significa que la Cartera IDUE (la denominación española de la wallet europea) debe estar disponible y emitible para cualquier ciudadano que la solicite.
- Segunda: las administraciones públicas deben aceptar la EUDI Wallet como método de identificación electrónica para sus servicios. Las sedes electrónicas, los portales de tramitación, los sistemas de gestión que hoy admiten Cl@ve o certificado digital tendrán que poder recibir también la EUDI Wallet.
- Tercera: todos los sistemas que van a aceptar la wallet necesitan haber completado su proceso de registro como parte usuaria en el sistema nacional correspondiente. Ese registro no es instantáneo: requiere análisis jurídico de los datos que se van a solicitar, configuración técnica de los protocolos, integración con los sistemas existentes y tiempo de verificación.
Diciembre de 2026 no es la fecha en que «habrá que adaptarse». Es la fecha en que el sistema ya debe estar funcionando. La preparación ocurre antes, no después.
Los actos de ejecución que fijan el marco técnico concreto
Para entender qué hay que tener listo, hay que conocer los actos de ejecución que han ido definiendo las especificaciones técnicas del ecosistema. No son documentos de política: son estándares técnicos vinculantes que determinan cómo tiene que funcionar cada pieza del sistema.
En noviembre de 2024, la Comisión Europea adoptó los primeros cinco Reglamentos de Ejecución sobre las funcionalidades básicas de la cartera:
- 2024/2977: especificaciones técnicas para la arquitectura de referencia.
- 2024/2978: protocolos e interfaces para la presentación de atributos.
- 2024/2979: especificaciones para el identificador de la cartera.
- 2024/2981: registro de partes usuarias de la cartera.
- 2024/2982: mecanismos de verificación y validación.
En mayo de 2025, se adoptó el Reglamento de Ejecución (UE) 2025/848 sobre el registro de partes usuarias, el sistema que determina qué organizaciones pueden solicitar y recibir datos de la wallet de un usuario.
Y en 2025 se publicó la segunda oleada de actos técnicos de eIDAS 2.0, incluyendo los que regulan el archivo electrónico cualificado (2025/2532), la validación cualificada (2025/1942), los certificados (2025/1943) y los QTSPs (2025/2530), que completan el marco de los servicios de confianza que el ecosistema EUDI necesita para funcionar.
El mensaje práctico de esta acumulación de estándares técnicos es concreto: las empresas que quieren estar listas para diciembre de 2026 tienen que haber analizado ya estos documentos, o tener un asesor que lo haya hecho por ellas, y haber empezado la integración técnica.
El plazo de diciembre de 2027: obligación del sector privado regulado
Doce meses después del plazo de las administraciones públicas, el artículo 5 ter del Reglamento establece la obligación para el sector privado regulado. El plazo exacto es de treinta y seis meses desde la entrada en vigor de los actos de ejecución adoptados en noviembre de 2024, lo que sitúa la fecha en el 24 de diciembre de 2027.
El artículo 5 ter del Reglamento establece que las partes usuarias privadas que presten servicios en los siguientes sectores deben aceptar el uso de las carteras europeas de identidad digital:
- Transporte - operadores de transporte aéreo, ferroviario, marítimo y por carretera.
- Energía - distribuidores y suministradores de energía eléctrica y gas.
- Banca - entidades de crédito, entidades de pago y entidades de dinero electrónico.
- Servicios financieros - empresas de inversión, gestoras de fondos, aseguradoras.
- Seguridad social - entidades gestoras de prestaciones sociales.
- Salud - proveedores de servicios de salud.
- Agua potable - proveedores de servicios de suministro de agua.
- Servicios postales - proveedores de servicios postales.
- Infraestructura digital - proveedores de servicios de internet, computación en la nube, centros de datos.
- Telecomunicaciones - operadores de redes públicas de comunicaciones electrónicas.
- Educación - instituciones educativas reconocidas.
La obligación se activa cuando el Derecho de la Unión, nacional o una obligación contractual exija autenticación reforzada para la identificación en línea. Eso significa que las entidades financieras bajo PSD2, que ya exigen autenticación reforzada de sus clientes, no pueden elegir no aceptar la EUDI Wallet cuando un cliente quiera usarla para ese propósito.
Adicionalmente, las grandes plataformas en línea designadas bajo el Reglamento de Servicios Digitales (las llamadas «plataformas de muy gran tamaño») tienen la obligación de aceptar la EUDI Wallet para autenticación voluntaria de sus usuarios.
Qué significa «aceptar la EUDI Wallet» en la práctica
La obligación de «aceptar» la wallet no significa sustituir todos los sistemas de identificación existentes. Significa que cuando un usuario quiera usar la wallet para identificarse o autenticarse, la empresa debe poder procesarlo. En la práctica, eso requiere cuatro cosas:
Primero, el registro como parte usuaria
Para poder solicitar y recibir atributos de la wallet de un usuario, la organización debe registrarse como parte usuaria de la cartera en el registro nacional del Estado miembro donde esté establecida. El Reglamento de Ejecución (UE) 2025/848 define el proceso: la organización tiene que declarar qué datos va a solicitar, para qué fines y bajo qué base jurídica. Sin ese registro, la wallet del usuario no confiará en la solicitud de datos.
Segundo, el certificado de acceso de parte usuaria
Para que la wallet del usuario pueda verificar que quien solicita sus datos es quien dice ser, la organización necesita un certificado de acceso de parte usuaria de la cartera emitido por un proveedor autorizado. Sin ese certificado, no hay autenticación mutua y el proceso no funciona.
Tercero, la integración técnica
Los sistemas de autenticación, onboarding o verificación de identidad de la organización tienen que ser capaces de procesar la presentación de atributos conforme a los protocolos definidos en los actos de ejecución. No es necesariamente una integración desde cero: en muchos casos es añadir un módulo o adaptar un componente existente. Pero requiere tiempo de desarrollo y pruebas.
Cuarto, la política de datos mínimos
El Reglamento es explícito: la organización no puede solicitar más datos de los estrictamente necesarios para el servicio concreto. Diseñar esa política de datos mínimos, qué atributo exacto se solicita para cada caso de uso, cómo se gestiona y cuánto tiempo se conserva, es trabajo jurídico y técnico que no puede improvisarse.
El riesgo del que nadie habla: la ventana de influencia
Hay algo que los plazos regulatorios no capturan bien y que es decisivo en la implementación de un estándar como la EUDI Wallet: la ventana de influencia se cierra mucho antes de que llegue el plazo de obligatoriedad.
Los estándares técnicos de interoperabilidad: los protocolos, los formatos de credenciales, los mecanismos de verificación, están siendo definidos ahora por los grupos de trabajo técnicos europeos. Las organizaciones que participan en esos grupos, o que trabajan con actores que participan, tienen la posibilidad de influir en cómo se implementan esas decisiones técnicas. Las que llegan al proceso cuando los estándares ya están cerrados solo pueden adaptarse.
Julián Inza, presidente de EADTrust, ha participado activamente en las discusiones técnicas y regulatorias del ecosistema EUDI desde sus primeras fases, incluida la conferencia sobre implementación y transformación de la gestión de la identidad digital organizada por la Universidad Pontificia Comillas, donde se abordaron precisamente los retos de la implementación para el sector privado. Esa participación no es solo para mantenernos informados: es para que nuestros clientes tengan acceso a esa perspectiva en el momento en que la necesitan.
En EADTrust, hemos construido el Directorio de Partes Informadas e Informantes visible en usercentric.id: el punto de entrada para organizaciones que quieren entender su posición en el ecosistema EUDI y empezar el proceso de integración antes de que el plazo obligue.
El impacto estimado por la Comisión Europea
Los números que la Comisión Europea asocia a la EUDI Wallet no son pequeños. El análisis de impacto del Reglamento estima que, una vez desplegada la wallet a escala:
- Para el sector financiero: ahorro estimado de 1.020 millones de euros anuales derivado de la eliminación de fricciones en el proceso de identificación y KYC de clientes.
- Para el conjunto de la economía digital: entre el 52% y el 85% de los ciudadanos de la UE usarán la EUDI Wallet antes de 2030.
- Para la eliminación de la dependencia de terceros: la wallet reduce la dependencia de los sistemas de autenticación de grandes plataformas privadas, el «iniciar sesión con Google» o «continuar con Facebook», que actualmente concentran el 85% de los inicios de sesión en la web europea.
- Para el sector turístico español: la verificación de identidad en hoteles, alquiler de vehículos y servicios de movilidad tiene un impacto directo en la experiencia del turista europeo en España, donde la wallet simplifica procesos que hoy requieren presentación física de documentos.
Dos fechas, dos velocidades, una preparación
La diferencia entre diciembre de 2026 y diciembre de 2027 no es solo de doce meses. Es de alcance y de urgencia.
- Diciembre de 2026 afecta principalmente a la administración pública y a las infraestructuras de identidad digital del Estado. Pero las empresas que tienen relaciones con la administración (proveedores de servicios digitales, plataformas de tramitación, gestores de servicios públicos) necesitan que sus sistemas sean compatibles con la wallet en esa misma fecha para que sus usuarios puedan usarla en el contexto de esos servicios.
- Diciembre de 2027 afecta directamente al sector privado regulado. Pero prepararse en doce meses es insuficiente en muchos casos. La integración técnica, el registro como parte usuaria, el análisis jurídico de los datos que se solicitan y la formación de los equipos que van a gestionar el nuevo modelo de identidad requieren entre doce y veinticuatro meses de trabajo previo en organizaciones de tamaño mediano y grande.
Las empresas que empiezan a prepararse en 2026 llegan a diciembre de 2027 con los sistemas listos. Las que empiezan en 2027 llegan al plazo en modo emergencia, con los costes, los riesgos y las prisas que eso implica.
Calendario EUDI Wallet 2024-2030: las fechas que importan
| Fecha | Hito | Quién se ve afectado |
| 20 mayo 2024 | eIDAS 2.0 en vigor. | Marco regulatorio activado |
| 28 noviembre 2024 | Primeros 5 actos de ejecución adoptados. | Inicio del cómputo de plazos |
| 6 mayo 2025 | Regl. Ej. 2025/848 sobre registro de partes usuarias. | Organizaciones que quieren integrarse |
| Diciembre 2025 | EUDI Wallet Launchpad en Bruselas. Presentación de Cartera IDUE. | España entre los 5 países piloto líderes |
| 24 diciembre 2026 | Wallet operativa en todos los Estados miembros. AAPP obligadas a aceptarla. | Administraciones públicas y ciudadanos |
| 24 diciembre 2027 | Sector privado regulado obligado a aceptarla. | Banca, telecos, energía, salud, seguros, transporte, educación |
| 2028–2030 | Despliegue de QEAA sectoriales. Integración DPP. | Sectores con credenciales verificables específicas |
| 2030 | Objetivo: 52-85% ciudadanos UE con wallet activa. | Mercado interior digital transformado |
Preguntas frecuentes sobre Los plazos de la EUDI Wallet
El Reglamento no establece directamente un régimen sancionador europeo uniforme por incumplimiento de la obligación de aceptar la wallet, ese desarrollo corresponde a los Estados miembros. Sin embargo, operar en sectores regulados sin cumplir la obligación puede generar exposición ante el regulador sectorial competente (Banco de España, CNMC, CNMV) que puede considerar el incumplimiento como una infracción de las obligaciones de identificación electrónica. Adicionalmente, si un cliente quiere usar la wallet y la empresa se niega a aceptarla, hay riesgo de reclamación y de daño reputacional.
No. Diciembre de 2026 afecta principalmente a administraciones públicas y requiere que sus sedes electrónicas acepten la wallet. Para las empresas privadas, el plazo relevante es diciembre de 2027, pero la preparación técnica y jurídica necesaria para estar listas en esa fecha requiere haber empezado al menos dieciocho meses antes.
El proceso de registro incluye la declaración de qué datos se solicitan, para qué fines y bajo qué base jurídica; la evaluación de esa declaración por el organismo competente; la obtención del certificado de acceso; y la integración técnica con los protocolos de la wallet. El tiempo total depende del sector y la complejidad de la organización, pero suele requerir entre tres y doce meses desde el inicio del proceso.
Las microempresas y pequeñas empresas están expresamente excluidas de la obligación del artículo 5 ter. La obligación aplica a empresas medianas y grandes que operen en los sectores regulados listados. Pueden elegir aceptar la wallet voluntariamente si les genera valor operativo.
Sí. Como QTSP participante en el ecosistema EUDI desde sus primeras fases, con presencia en los pilotos europeos y con el Directorio de Partes Informadas e Informantes de usercentric.id, EADTrust puede acompañar a tu organización en el análisis del impacto, el diseño de la estrategia de integración, el proceso de registro como parte usuaria y la obtención de los certificados de acceso necesarios.
¿Tu organización ya sabe qué tiene que hacer antes de diciembre de 2026?
El reloj ya está corriendo. Los actos de ejecución están publicados, los plazos están fijados y los primeros pilotos ya son funcionales. La diferencia entre las organizaciones que van a llegar a diciembre de 2026 y diciembre de 2027 con los sistemas listos y las que van a llegar en modo emergencia es lo que hagan (o no hagan) en los próximos doce meses.
En EADTrust podemos ayudarte a entender exactamente qué te afecta, qué tienes que hacer y en qué orden. Desde el análisis de impacto inicial hasta el registro como parte usuaria, pasando por la obtención de los certificados de acceso y la integración técnica con tus sistemas.
También te puede interesar…
La entrada Diciembre 2026: el plazo que tu empresa no puede ignorar se publicó primero en EADTrust.
]]>La entrada Cómo preparar tu empresa para el DPP se publicó primero en EADTrust.
]]>Esa lectura es incorrecta. No porque las fechas sean diferentes, son las que son, sino porque el DPP no es un documento que se genera en el momento de la venta. Es un sistema de datos que requiere arquitectura de información, contratos con proveedores, decisiones de diseño IT, infraestructura de autenticación e integración con el Registro Central de la Comisión Europea. La CWA 18186:2025 (las directrices técnicas del CEN publicadas en mayo de 2025) identifica quince decisiones de diseño distintas que el responsable de implementar el DPP en una empresa debe tomar antes de que el sistema esté operativo. Esas decisiones no se ejecutan en semanas. Se ejecutan en meses o años.
Este artículo es la guía de dónde empezar: qué decisiones hay que tomar, en qué orden, qué infraestructura técnica necesitas y cómo encaja todo con los plazos reales que el ecosistema regulatorio establece.
Definiciones sobre como preparar tu empresa para el DPP
CWA 18186:2025
Directrices del CEN (CEN Workshop Agreement) publicadas el 5 de mayo de 2025, que proporcionan orientación práctica para diseñar e implementar Pasaportes Digitales de Producto. Es el primer estándar europeo sobre el DPP y la referencia técnica principal para empresas que inician el proceso de preparación.
Sistema de gestión del DPP
Sistema IT que aloja los datos del DPP, gestiona los derechos de acceso diferenciados, proporciona el portal de información en línea y conecta con el Registro Central de la Comisión Europea. Puede ser interno, externalizado o híbrido.
El rol que tu empresa necesita crear: el DPP designer
La CWA 18186:2025 introduce un rol que todavía no existe formalmente en la mayoría de las empresas europeas: el DPP designer, o responsable del DPP. Es la persona encargada de decidir sobre la implementación IT del DPP o de preparar el encargo a un proveedor externo para que lo implemente.
El término puede sonar técnico, pero la función es estratégica. El DPP designer no es necesariamente un ingeniero de software: es quien tiene que articular qué datos necesita recoger el DPP, cómo se gestionan esos datos a lo largo del ciclo de vida del producto, qué actores de la cadena de suministro tienen que contribuir a ellos, y qué arquitectura IT puede sustentar todo eso.
La CWA señala que aunque el término DPP designer es el que usa el documento, cada empresa puede darle el nombre que quiera: DPP manager, DPP executive u otro. Lo que importa no es el título sino que exista una persona o equipo con responsabilidad clara sobre el diseño e implementación del DPP.
En empresas pequeñas, ese rol puede recaer sobre el responsable de calidad o el responsable de IT. En empresas medianas y grandes, puede requerir un equipo transversal que combine personas de operaciones, IT, legal y sostenibilidad. Lo que no funciona es asumir que el DPP se resolverá sólo cuando llegue el acto delegado.
La primera decisión que tu empresa necesita tomar sobre el DPP es quién lo va a diseñar. Sin esa persona o equipo, las demás decisiones no se toman. Y sin esas decisiones, no hay sistema listo cuando el plazo llegue.
Las quince decisiones que el DPP designer tiene que tomar
La CWA 18186:2025 organiza las decisiones de diseño del DPP en quince contextos bien definidos. No todas son del mismo peso ni del mismo horizonte temporal, pero todas deben ser resueltas antes de que el sistema esté operativo. Las explicamos agrupadas por naturaleza para facilitar la priorización.
Decisiones sobre el tipo de pasaporte y los identificadores
Decisión 1 – Tipo de pasaporte: modelo, lote o artículo
Esta es probablemente la decisión con mayor impacto en toda la arquitectura técnica del DPP. Un DPP a nivel de modelo es el más cercano al sistema de etiquetado actual: todos los productos de una misma serie comparten el mismo pasaporte. Es el mínimo exigible para muchos grupos. Un DPP a nivel de lote permite trazabilidad entre actores B2B. Un DPP a nivel de artículo es el más granular: cada unidad física tiene su propio identificador único, lo que permite capturar eventos durante todo el ciclo de vida, reparaciones, reacondicionamiento, cambio de estado.
El nivel que se exige lo determina el acto delegado de cada grupo de producto. Pero decidir el nivel que quieres implementar, que puede ser más ambicioso que el mínimo exigido, es una decisión estratégica que afecta al coste, la complejidad y el valor que el DPP puede generar más allá del cumplimiento regulatorio.
Decisión 2 – Identificadores
El DPP debe tener cuatro identificadores únicos obligatorios: el identificador del producto, el identificador del operador, el identificador de la instalación donde se fabrica el producto y el identificador de registro del DPP en el Registro Central. La CWA identifica ejemplos de identificadores comúnmente usados: el Manufacturer Part Number (MPN), identificador interno del fabricante, útil para uso interno pero con interoperabilidad limitada, el Global Trade Item Number (GTIN) de GS1, utilizado en retail, moda, alimentación y logística, y los Universally Unique Identifiers (UUIDs).
El estándar de identificadores para el sistema DPP europeo está siendo desarrollado por el grupo de trabajo 2 del JTC24 de CEN/CENELEC, con entrega prevista para marzo de 2026. El DPP designer debe asegurarse de que los identificadores elegidos cumplirán ese estándar cuando esté disponible.
Decisiones sobre el soporte físico y el etiquetado
Decisión 3 – Soporte de datos
El DPP debe ser accesible mediante un soporte de datos físico en el producto: código QR, código de barras bidimensional, RFID u otro medio. El soporte de datos debe estar presente en el propio producto, en su envase o en la documentación que lo acompañe, según lo que especifique el acto delegado. La elección del soporte tiene implicaciones directas en el proceso de producción, cómo se incorpora físicamente al producto o al embalaje, y en la experiencia del consumidor.
Decisión 4 – Etiquetado del producto
Cómo se integra el soporte de datos en el etiquetado físico existente: si se añade al etiquetado actual, si sustituye algún elemento, y cómo garantizar que es visible, legible y duradero durante toda la vida útil prevista del producto. En textil, por ejemplo, esto puede implicar rediseñar la etiqueta de composición para integrar el código QR del DPP.
Decisiones sobre el portal de información y la arquitectura IT
Decisión 5 – Acceso al portal de información del DPP
El DPP no es solo datos: es un portal accesible en línea que muestra esa información a distintos usuarios con distintos niveles de autorización. El DPP designer debe definir cómo los consumidores, distribuidores, reparadores y autoridades accederán a la información, qué información es pública y qué requiere autenticación.
Decisión 6 – Cambio de idioma
El ESPR establece que los consumidores deben poder acceder a la información del DPP en todos los idiomas oficiales de la UE. La gestión de las versiones lingüísticas del DPP, tanto del contenido del portal como de los documentos que pueda incluir, es una decisión de arquitectura con implicaciones de coste y gestión.
Decisión 7 – Arquitectura IT: interna o externalizada
Esta es la decisión con mayor impacto presupuestario. El ESPR establece que el sistema de datos del DPP es descentralizado: los datos los gestiona el operador económico o un prestador de servicios de DPP contratado externamente. Hay dos caminos: desarrollar y gestionar la infraestructura internamente, o contratar un proveedor de servicios de DPP que gestione el alojamiento, el acceso y la copia de seguridad obligatoria. Para la mayoría de las pymes y muchas empresas medianas, la externalización a un proveedor certificado es más eficiente. Para grandes fabricantes con productos complejos y cadenas de suministro extensas, puede tener sentido una solución interna o híbrida.
Decisiones sobre el contenido y la gestión de la información
Decisión 8 – Cálculo y adquisición de la información del DPP
Esta es la decisión más compleja en términos de cadena de suministro. La información que el DPP debe incluir: composición de materiales, huella de carbono, contenido reciclado, parámetros de durabilidad… no suele estar disponible en un formato estándar en los sistemas actuales de los fabricantes.
Para la huella de carbono, hay que calcularla con metodologías reconocidas. Para el contenido reciclado, hay que recogerlo de los proveedores de materiales. Para los parámetros de durabilidad, hay que tener los datos de los ensayos. La CWA advierte que en muchos casos la información no puede simplemente «recuperarse» de sistemas existentes: hay que diseñar los procesos de recogida de datos antes de que el DPP sea obligatorio.
Decisión 9 – Búsqueda de la información del DPP
Cómo se organiza la información dentro del DPP para que sea encontrable y comparable por distintos actores: consumidores que buscan por parámetro de sostenibilidad, autoridades que verifican el cumplimiento, reparadores que necesitan especificaciones técnicas.
Decisión 10 – Gestión del intercambio de información
El DPP debe ser totalmente interoperable con otros DPPs en los aspectos técnicos, semánticos y organizativos. Esto implica decidir qué estándares de intercambio de datos se van a usar y cómo el DPP de la empresa se integrará con los sistemas de otros actores de la cadena de valor que también tendrán DPPs: proveedores de materiales, fabricantes de componentes.
Decisiones sobre trazabilidad, longevidad y seguridad
Decisión 11 – Trazabilidad
Qué eventos del ciclo de vida del producto se capturarán en el DPP: si se registrarán eventos de fabricación, de distribución, de reparación, de reacondicionamiento, de fin de vida. Esto determina si el DPP es un documento estático, con información del momento de la introducción en el mercado, o un registro dinámico que se actualiza a lo largo de la vida del producto.
Decisión 12 – Longevidad del acceso a los datos
El ESPR exige que el DPP permanezca disponible durante el período especificado en el acto delegado, incluso después de insolvencia, liquidación o cese de actividad del operador económico responsable. El DPP designer debe decidir cómo se garantiza esa disponibilidad a largo plazo, típicamente, a través de la copia de seguridad obligatoria con un tercero independiente.
Decisión 13 – Disponibilidad de la copia de seguridad
El artículo 10 del ESPR establece la obligación de poner a disposición una copia de seguridad del DPP a través de un prestador de servicios de DPP que sea un tercero independiente desde el momento de introducción del producto en el mercado. Quién gestiona esa copia de seguridad, cómo se gestiona técnicamente y bajo qué condiciones tomaría el relevo si el sistema principal falla son decisiones que hay que tomar antes de la primera comercialización.
Decisión 14 – Seguridad del DPP
El artículo 11 del ESPR exige que el diseño técnico del DPP garantice la autenticación, la fiabilidad y la integridad de los datos, con un elevado nivel de seguridad y privacidad y evitando el fraude. La CWA identifica cinco niveles donde debe abordarse la seguridad: el sistema de gestión del DPP del fabricante, la autenticidad del soporte de datos, el acceso al DPP para información restringida, el proceso de emisión de derechos de acceso, y la seguridad del acceso al portal de información.
Decisión 15 – Confianza en la información del DPP
Cómo garantizar que la información que figura en el DPP es auténtica, precisa y no ha sido manipulada. La CWA advierte que la exactitud de la información puede variar significativamente dependiendo de la calidad de los procesos del fabricante, y que no está prevista ninguna verificación independiente obligatoria bajo el ESPR, aunque los actos delegados podrán incluirla. El DPP designer debe decidir si incorporar procesos voluntarios de verificación por terceros para mejorar la confiabilidad de la información.
La cadena de suministro: el problema más infraestimado del DPP
Hay una diferencia fundamental entre el DPP y otros requisitos regulatorios de producto que muchas empresas todavía no han asimilado: el DPP no puede construirse solo con información interna. Requiere datos de la cadena de suministro que actualmente no fluyen de forma estructurada hacia el fabricante.
La CWA 18186:2025 describe el caso de un fabricante complejo que puede recibir información de DPP de miles de proveedores de fabricación. Para una marca de moda que fabrica en varios países, la composición de fibras, los porcentajes de contenido reciclado, las sustancias presentes en las tinturas y la huella de carbono de cada etapa de producción son datos que están en manos de los proveedores, no del fabricante final.
Para recoger esa información de forma estructurada, las empresas necesitan:
Primero, modificar los contratos con proveedores para incluir obligaciones de entrega de datos en formatos interoperables. Segundo, definir qué formatos y estándares de datos van a usar para que la información de distintos proveedores sea comparable y consolidable. Tercero, construir o contratar sistemas que integren esa información en el DPP de forma automatizada.
Este proceso, desde la negociación de contratos hasta la integración técnica, no se hace en semanas. En sectores con cadenas de suministro globales y complejas, como el textil o el mueble, puede llevar entre uno y tres años construir los flujos de datos que el DPP va a necesitar. Esperar a que el acto delegado esté publicado para empezar es asumir que dieciocho meses son suficientes para hacer todo eso. En la mayoría de los casos, no lo son.
La infraestructura técnica mínima: lo que necesitas tener antes del plazo
Con independencia del sector y del tipo de DPP que requiera tu grupo de producto, hay una infraestructura técnica mínima que cualquier empresa que vaya a tener un DPP necesitará tener operativa antes de la fecha de aplicación del acto delegado:
Registro en el Registro Central del DPP
El Registro Central de la Comisión Europea será operativo a partir del 19 de julio de 2026. Desde esa fecha, los identificadores únicos de los DPPs pueden comenzar a registrarse. La conexión con el Registro Central y el proceso de registro de identificadores debe estar integrado en el sistema del DPP. Para el despacho aduanero de productos regulados, el identificador único de registro en este sistema será obligatorio.
Sistema de gestión del DPP
El sistema que aloja los datos del DPP, gestiona los derechos de acceso diferenciados, proporciona el portal de información y conecta con el Registro Central. Puede ser interno, externalizado a un proveedor de servicios de DPP, o híbrido. El artículo 11 del ESPR establece que el sistema debe ser interoperable, abierto, legible por máquina, estructurado y accesible a través de una red de intercambio de datos sin dependencia de un proveedor.
Copia de seguridad obligatoria
Un tercero independiente que custodie una copia del DPP y garantice su disponibilidad incluso después de insolvencia o cese de actividad del operador responsable. Este tercero no puede usar, vender ni reutilizar los datos más allá del servicio de almacenamiento contratado.
Servicios de confianza para la autenticación
El artículo 11 del ESPR exige que el diseño técnico del DPP garantice la autenticación, la fiabilidad y la integridad de los datos, con un elevado nivel de seguridad y privacidad. Esto requiere mecanismos de autenticación para los actores que introducen o actualizan datos en el DPP: fabricantes, importadores, reparadores, reacondicionadores. Los servicios de confianza cualificados bajo el marco eIDAS: sellos electrónicos cualificados, firmas electrónicas cualificadas, marcas de tiempo cualificadas… son el mecanismo regulatorio previsto para cumplir esas garantías de autenticidad e integridad.
Soporte de datos en el producto
El código QR u otro soporte de datos debe estar integrado en el proceso de producción o etiquetado antes de que el producto salga a la venta. Si requiere modificaciones en la línea de producción, en el diseño del embalaje o en el proceso de etiquetado, esos cambios necesitan tiempo de implementación.
El calendario de preparación: qué hacer cuándo
No todas las acciones tienen el mismo horizonte temporal. Esta secuencia orientativa puede servir como punto de partida para construir el plan de preparación para el DPP de tu empresa.
Ahora (2026):
- Identificar el grupo de producto y su fecha estimada de acto delegado conforme al Plan de Trabajo ESPR 2025-2030.
- Nombrar al DPP designer o equipo responsable.
- Revisar los estudios preparatorios del JRC que alimentarán el acto delegado de tu sector, son públicos y orientativos del contenido probable del DPP.
- Evaluar qué datos de la cadena de suministro se necesitarán y si los proveedores actuales pueden suministrarlos en formato estructurado.
- Decidir si el DPP se gestionará internamente o con un proveedor externo.
6-12 meses antes del acto delegado:
- Negociar con proveedores de materiales y componentes los requisitos de entrega de datos para el DPP.
- Elegir e integrar el sistema de gestión del DPP.
- Diseñar el soporte de datos físico e integrarlo en el proceso de producción o etiquetado.
- Contratar el servicio de copia de seguridad obligatoria con un tercero independiente.
- Configurar la infraestructura de autenticación para los actores que introduzcan datos en el DPP.
Al publicarse el acto delegado:
- Revisar el contenido obligatorio del DPP conforme al acto delegado específico y ajustar el sistema.
- Registrar los primeros identificadores en el Registro Central de la Comisión, si ya está operativo.
- Completar la integración del soporte de datos en los productos de la primera serie regulada.
18 meses después del acto delegado (fecha de aplicación):
- El DPP debe estar operativo para todos los modelos del grupo de producto que se introduzcan en el mercado desde esa fecha.
El caso especial de las empresas que ya están en EPREL
Para los fabricantes e importadores que ya tienen modelos registrados en EPREL con verificación de proveedor activa, el punto de partida para el DPP es más favorable. EPREL les ha introducido ya en la lógica de los registros digitales europeos, en el uso de identificadores únicos de modelo, en la gestión de documentación técnica estructurada y en la autenticación mediante servicios de confianza cualificados.
Cuando lleguen los actos delegados del ESPR para grupos de productos con etiqueta energética, lo más probable es que la Comisión exima a esos productos de un DPP adicional, dado que EPREL ya actúa como sistema equivalente. Pero esa exención no es automática: requiere que la Comisión lo declare expresamente en el acto delegado correspondiente. Y aunque se declare, los requisitos de ecodiseño adicionales del ESPR: durabilidad, contenido reciclado, huella de carbono… pueden requerir información que EPREL actualmente no recoge.
En cualquier caso, las empresas que ya operan en EPREL con sello cualificado NTR tienen resuelto el eslabón más crítico: la infraestructura de autenticación e identidad digital que el DPP va a necesitar es la misma. El paso siguiente es ampliarla al ciclo de vida completo del producto.
Preguntas frecuentes sobre como preparar tu empresa para el DPP
Por el Plan de Trabajo ESPR 2025-2030 y el artículo del sector correspondiente en este cluster de contenidos. Una vez identificada la fecha estimada del acto delegado, el plazo de dieciocho meses posterior es la fecha de aplicación del DPP. A partir de ahí, calcula hacia atrás cuánto tiempo necesita tu empresa para implementar los sistemas y negociar los flujos de datos con proveedores.
Sí. El ESPR permite que el DPP sea gestionado por un prestador de servicios de DPP externo, incluyendo el alojamiento, la gestión de accesos y la copia de seguridad obligatoria. Para la mayoría de las pymes, la externalización es la opción más eficiente. Lo que no puede externalizarse es la responsabilidad de que los datos sean exactos, completos y estén actualizados: esa responsabilidad siempre recae sobre el operador económico que introduce el producto en el mercado.
No sin consentimiento expreso. El artículo 10 del ESPR establece que los datos personales relativos a clientes no se almacenarán en el DPP sin su consentimiento expreso conforme al Reglamento General de Protección de Datos.
El artículo 9 del ESPR establece que los datos que figuren en el DPP serán exactos, completos y estarán actualizados. Si las autoridades de vigilancia del mercado detectan información incorrecta, pueden actuar contra el operador económico responsable. La confianza en el sistema DPP, y su utilidad para consumidores y reparadores, depende directamente de la precisión de los datos.
No necesariamente, pero puede contenerlos. El Anexo III del ESPR establece que el DPP puede incluir manuales de usuario, instrucciones, advertencias e información sobre seguridad. El DPP debe complementarse, cuando sea necesario, con medios de transmisión de información no digitales (como etiquetas físicas) para garantizar el acceso a la información a todos los usuarios.
El DPP no es un problema futuro: es una decisión que se toma hoy
Las empresas que empiezan a trabajar en el DPP ahora, antes de que el acto delegado de su sector esté publicado, tienen ventaja en tres frentes: pueden negociar los flujos de datos con proveedores sin presión de plazo, pueden evaluar y elegir proveedores de servicios DPP sin urgencia, y pueden diseñar la arquitectura IT con calma y sin improvisaciones.
Las que esperan al acto delegado para empezar tendrán dieciocho meses para hacer todo eso. En la mayoría de los sectores, no es suficiente.
En EADTrust somos prestador cualificado de servicios de confianza incluido en la EU Trusted List. Los mismos certificados que hoy permiten verificarse en EPREL son la base de la infraestructura de autenticación que el DPP va a necesitar: sellos electrónicos cualificados para autenticar quién introduce datos, marcas de tiempo cualificadas para la trazabilidad de eventos, y servicios de archivo cualificado para la disponibilidad a largo plazo que el Reglamento exige.
También te puede interesar…
La entrada Cómo preparar tu empresa para el DPP se publicó primero en EADTrust.
]]>La entrada Nube soberana europea vs CLOUD Act americano: por qué importa dónde están tus datos se publicó primero en EADTrust.
]]>Si tu proveedor es una empresa americana: Amazon Web Services, Microsoft Azure, Google Cloud, DocuSign, Adobe… la respuesta es incómoda: puede estar obligado a entregar esos datos aunque estén alojados físicamente en un servidor en Frankfurt, Dublín o Madrid. No por mala fe. Por ley. La ley que lo hace posible se llama CLOUD Act (Clarifying Lawful Overseas Use of Data Act) y entró en vigor en Estados Unidos en 2018.
La nube soberana europea es exactamente lo contrario de eso. Este artículo explica qué es el CLOUD Act, por qué una filial europea de una empresa americana no rompe el problema, qué obliga la ley española a las empresas que trabajan con la administración pública, y cómo funciona la infraestructura que garantiza la soberanía real de los datos.
Nube soberana ¿Sabes realmente bajo qué jurisdicción están los datos de tu empresa? →Conceptos
CLOUD Act (Clarifying Lawful Overseas Use of Data Act)
Ley federal americana de 2018 que permite a las autoridades de EEUU solicitar datos almacenados por empresas americanas independientemente de dónde estén físicamente ubicados esos datos. Aplica a cualquier empresa con sede en EEUU, incluyendo sus filiales europeas.
Nube soberana europea
Infraestructura de computación en la nube diseñada para garantizar que los datos permanezcan bajo jurisdicción exclusivamente europea, con acceso restringido a personal residente en la UE, arquitectura de aislamiento que impide la salida de datos fuera de la región y protocolos contractuales de impugnación ante solicitudes gubernamentales externas.
Oracle EU Sovereign Cloud
Infraestructura de nube sobre la que EADTrust despliega sus servicios, Signature Manager, eArchiving, EAD Enterprise Suite. Regiones aisladas física y lógicamente, operadas exclusivamente por personal residente en la UE, con copias de seguridad dentro de la UE y CDN deshabilitadas.
RGPD (Reglamento General de Protección de Datos, Reglamento (UE) 2016/679)
Marco europeo de protección de datos personales. Prohíbe transferir datos personales a terceros países sin garantías adecuadas. La sentencia Schrems II invalidó el Privacy Shield por no ofrecer garantías equivalentes al RGPD frente a los programas de vigilancia americanos.
Real Decreto-ley 14/2019
Norma española que establece la obligatoriedad de que los recursos técnicos para la identificación y firma en la administración pública se encuentren ubicados en territorio de la Unión Europea, y las categorías especiales de datos en territorio español.
Transferencia internacional de datos
Cualquier comunicación o cesión de datos personales a un destinatario establecido en un tercer país fuera de la UE. El RGPD la prohíbe salvo que el país destino haya sido declarado adecuado por la Comisión Europea o se utilicen garantías adecuadas.
El CLOUD Act: qué dice y por qué alcanza a servidores en Europa
El CLOUD Act (Clarifying Lawful Overseas Use of Data Act) es una ley federal americana de 2018 que modifica la Ley de Almacenamiento de Comunicaciones de EEUU. Su disposición más relevante para las empresas europeas es esta: las empresas americanas pueden ser obligadas por orden judicial o administrativa a proporcionar datos almacenados en sus servidores, independientemente de dónde estén físicamente ubicados esos servidores.
Eso significa que si contratas AWS, Azure, Google Cloud, Salesforce, DocuSign, Adobe Sign u otro servicio de una empresa con sede en Estados Unidos, esa empresa puede ser requerida por las autoridades americanas para proporcionar el contenido de tus carpetas, tus contratos, tus comunicaciones o cualquier dato que hayas almacenado en su plataforma, aunque el servidor esté en Frankfurt y aunque el contrato incluya cláusulas de residencia de datos en Europa.
La distinción clave es entre la localización física del dato y la jurisdicción corporativa de quien lo custodia. El CLOUD Act no alcanza directamente a la empresa europea que tiene sus datos en ese servidor: alcanza al proveedor americano que gestiona ese servidor. El proveedor tiene que obedecer la orden, o impugnarla judicialmente, con los costes y resultados inciertos que eso implica.
¿Puede el proveedor resistirse? En teoría, sí: puede impugnar la orden si considera que viola las leyes del país donde están los datos. En la práctica, las grandes empresas tecnológicas americanas han cedido datos de usuarios europeos a las autoridades americanas en múltiples ocasiones, y los casos donde han impugnado con éxito son la excepción, no la norma.
Que el servidor esté en Europa no es suficiente. Lo que importa es quién es el propietario del servidor y bajo qué ley está constituida esa empresa. Una filial europea de Amazon sigue siendo Amazon. Una orden a Amazon es una orden a todos sus servidores, donde quiera que estén.
El problema del Schrems II y la invalidación del Privacy Shield
La tensión entre la protección de datos europea y la extraterritorialidad americana no es nueva. El Tribunal de Justicia de la Unión Europea la ha abordado en dos ocasiones, con resultados que el sector tecnológico todavía está procesando.
En julio de 2020, la sentencia Schrems II declaró inválido el Privacy Shield (el acuerdo que permitía transferir datos personales de ciudadanos europeos a EEUU) precisamente porque los programas de vigilancia americanos, incluyendo el acceso por vía del CLOUD Act, no ofrecen garantías equivalentes a las del RGPD europeo.
El Data Privacy Framework que sustituyó al Privacy Shield en 2023 reduce parte de esa tensión para transferencias de datos personales, pero no elimina el problema estructural: el CLOUD Act sigue vigente, sigue siendo aplicable a empresas americanas con servidores en Europa, y no tiene un marco de impugnación sistemática que garantice la protección de datos europeos.
Para datos que no son «personales» en el sentido del RGPD, contratos corporativos, propiedad intelectual, secretos comerciales, estrategia empresarial, el Data Privacy Framework no ofrece ninguna protección adicional. El CLOUD Act puede alcanzar esos datos con independencia de que sean o no datos personales.
Lo que dice la ley española: dónde tienen que estar los datos de la administración
El legislador español ya respondió a este problema antes de que el debate sobre el CLOUD Act llegara a los medios de comunicación. El Real Decreto-ley 14/2019, de 31 de octubre, establece obligaciones muy concretas sobre la ubicación de los sistemas de información de la administración pública española.
El artículo que modifica la Ley 39/2015 establece que en relación con los sistemas de identificación y firma previstos en la Ley, se establece la obligatoriedad de que los recursos técnicos necesarios para la recogida, almacenamiento, tratamiento y gestión de dichos sistemas se encuentren situados en territorio de la Unión Europea, y en caso de tratarse de categorías especiales de datos, en territorio español.
Y el nuevo artículo 46 bis de la Ley 40/2015, introducido por el mismo Real Decreto-ley, es aún más directo: los sistemas de información y comunicaciones para la recogida, almacenamiento, procesamiento y gestión del censo electoral, los padrones municipales, los datos fiscales y los datos de usuarios del sistema nacional de salud deberán ubicarse y prestarse dentro del territorio de la Unión Europea, y los datos a que se refiere no podrán ser objeto de transferencia a un tercer país u organización internacional.
La Ley de Contratos del Sector Público (9/2017) añade una obligación que afecta directamente a los proveedores tecnológicos de la administración española: la empresa adjudicataria de contratos públicos que impliquen tratamiento de datos personales debe presentar, antes de la formalización del contrato, una declaración en la que ponga de manifiesto dónde van a estar ubicados los servidores y desde dónde se van a prestar los servicios asociados.
Eso significa que si quieres vender servicios tecnológicos a la administración pública española o a cualquier entidad que gestione datos regulados, tienes que poder demostrar que tus servidores están en la UE. Una empresa cuya infraestructura principal está en EEUU no puede cumplir ese requisito con garantías reales, aunque tenga una filial europea.
Qué es exactamente la nube soberana europea y qué garantiza
La expresión «nube soberana» se usa con más frecuencia de la que se explica. No es simplemente un servidor físico en Europa. Es un conjunto de garantías técnicas, contractuales y operativas que combinadas garantizan que los datos no pueden salir de la jurisdicción europea sin autorización del cliente.
Oracle EU Sovereign Cloud es la infraestructura sobre la que EADTrust despliega sus servicios: Signature Manager, eArchiving, EAD Enterprise Suite. Sus características técnicas son concretas y están documentadas en los T&C de los servicios:
Aislamiento regional físico y lógico. Las regiones de centros de datos de Oracle EU Sovereign Cloud están aisladas física y lógicamente del resto de regiones de Oracle, incluyendo EEUU, Asia-Pacífico, Oriente Medio y África. Las copias de seguridad permanecen dentro de la UE. Los datos no se mueven fuera de la región especificada.
Personal exclusivamente europeo. Solo el personal que reside en la UE, se encuentra en la UE durante la prestación de servicios y está contratado directamente por entidades Oracle dentro de la UE puede gestionar y dar soporte a estas regiones. Ese personal está sujeto a acuerdos de confidencialidad estrictos y formación anual en privacidad y protección de datos.
CDN deshabilitadas. Las redes de distribución de contenido (CDN) que almacenan en caché contenido cerca del usuario final para acelerar la entrega están deshabilitadas en el servicio de archivo electrónico. Las CDN son uno de los mecanismos más frecuentes por los que los datos viajan fuera de la región contratada sin que el cliente sea consciente. Su desactivación garantiza que ningún dato sale de la UE.
Procedimientos ante solicitudes gubernamentales externas. La Oracle EU Sovereign Cloud tiene procedimientos estrictos para responder a solicitudes de datos por parte de agencias estatales ubicadas fuera de las regiones de los centros de datos. Cuando sea posible y conforme a la ley, se notifica al cliente sobre esas solicitudes y se impugnan las que no sean aplicables.
EAD Enterprise Suite Protege tus procesos digitales sobre infraestructura de nube soberana europea Firma, custodia y gestiona documentación empresarial sensible mediante soluciones diseñadas para mantener el control sobre tus datos y procesos. Signature Manager eArchiving Notice Manager Conocer Enterprise Suite →Lo que EADTrust garantiza contractualmente
Los T&C de los servicios de EADTrust (Enterprise Suite, eArchiving) recogen compromisos contractuales concretos que van más allá de lo que la mayoría de los proveedores de nube incluyen en sus condiciones:
Restricción de acceso a personal residente en la UE
EADTrust se compromete a restringir el acceso a los centros de datos en los que estén archivados los documentos electrónicos a personal que resida en la Unión Europea, se encuentre en la Unión Europea durante la prestación de servicios, y esté contratado directamente por EADTrust o entidades asociadas bajo las mismas condiciones.
Confidencialidad frente a agencias de terceros países
La prohibición de divulgación a terceros no autorizados incluye expresamente las agencias estatales ubicadas fuera de la Unión Europea. No es una cláusula de estilo: es un compromiso contractual explícito que diferencia a la nube soberana europea de los contratos de servicios en la nube americanos.
Notificación e impugnación de solicitudes gubernamentales
EADTrust se compromete a notificar al suscriptor sobre solicitudes de acceso gubernamentales, incluyendo pero no limitándose a solicitudes judiciales, siempre que sea legalmente posible, y a oponerse a cualquier solicitud que se considere no aplicable o no coherente con su posición como procesador de datos.
Arquitectura de independencia operativa
La arquitectura del servicio permite que las entidades que operen las regiones de los centros de datos lo hagan de forma independiente, sin necesidad de transferir los documentos electrónicos del suscriptor fuera de la Unión Europea.
Sin transferencias internacionales de datos personales
EADTrust no llevará a cabo transferencias internacionales de los datos de carácter personal responsabilidad del suscriptor a los que tenga acceso, salvo autorización previa y por escrito del suscriptor o debida regulación.
Las categorías de datos para las que la soberanía es crítica
No todos los datos tienen el mismo nivel de exposición al riesgo del CLOUD Act. El riesgo es mayor cuando los datos tienen relevancia estratégica, comercial o jurídica que podría ser de interés para competidores americanos, litigantes o autoridades regulatorias.
- Datos de operaciones M&A y due diligence. Los data rooms de operaciones de fusiones y adquisiciones contienen información estratégica sobre valoraciones, condiciones de la operación y estados financieros internos. Si esa información está en una plataforma americana, una autoridad o un litigante americano con los medios adecuados puede acceder a ella mediante el CLOUD Act.
- Contratos y acuerdos de confidencialidad. Los NDA, los contratos de licencia de tecnología, los acuerdos de distribución y cualquier contrato con secretos comerciales son objetivos potenciales de solicitudes de acceso.
- Documentación de compliance y riesgos. Los informes internos de compliance, los registros de auditoría, la documentación de gestión de riesgos y los expedientes regulatorios pueden ser objeto de solicitudes de información en procesos regulatorios americanos que afectan a empresas europeas.
- Categorías especiales de datos. El RGPD exige que las categorías especiales de datos (salud, afiliación sindical, origen racial, creencias religiosas, datos biométricos) tengan protecciones adicionales. El Real Decreto-ley 14/2019 establece que esos datos deben almacenarse específicamente en territorio español cuando están vinculados a sistemas de identificación de la administración pública.
- Datos de clientes del sector bancario y asegurador. La información financiera de clientes bajo MiFID II, PSD2 o DORA tiene requisitos de residencia y acceso que son incompatibles con el alcance potencial del CLOUD Act.
La tabla de comparación: qué garantiza cada tipo de infraestructura
| Aspecto | AWS / Azure / Google Cloud | Oracle EU Sovereign Cloud (EADTrust) |
| Propietario de la infraestructura | Empresa americana sujeta al CLOUD Act | Oracle entidades UE, operadas por personal residente en la UE |
| Alcance del CLOUD Act | Sí, empresa americana con servidores en Europa es alcanzable | Mitigado, arquitectura de independencia operativa sin necesidad de transferir datos fuera de la UE |
| Personal con acceso a los datos | Personal global de la empresa | Solo personal residente en la UE, empleado por entidades UE |
| Copias de seguridad | Pueden estar fuera de la UE | Permanecen dentro de la UE |
| CDN | Habilitadas por defecto | Deshabilitadas para garantizar que los datos no salen de la región |
| Notificación al cliente sobre solicitudes gubernamentales | Depende de la política del proveedor | Compromiso contractual explícito de notificación e impugnación |
| Transferencias internacionales de datos | Posibles en condiciones del servicio | Prohibición contractual expresa salvo autorización del suscriptor |
| Cumplimiento Real Decreto-ley 14/2019 para AAPP | No garantizable | Sí |
| Competencia QTSP bajo eIDAS | No, no son prestadores de servicios de confianza cualificados | Sí, EADTrust en EU Trusted List |
¿Cuándo importa más la soberanía de los datos?
La respuesta honesta es que importa siempre que los datos que procesas tengan relevancia estratégica, comercial, jurídica o regulatoria, y que tu empresa opere en mercados donde competidores americanos, litigantes o reguladores americanos podrían tener interés en ellos.
Las situaciones más frecuentes en las que la soberanía de datos es crítica son:
- Operaciones corporativas sensibles. Cualquier operación de M&A, desinversión, reestructuración o joint venture donde las condiciones del acuerdo no deben estar al alcance de la contraparte ni de terceros antes del cierre.
- Relaciones con clientes del sector financiero y asegurador. Bancos, aseguradoras y gestoras de fondos tienen obligaciones regulatorias específicas sobre la residencia y protección de datos de clientes que pueden ser incompatibles con el alcance del CLOUD Act.
- Empresas con presencia relevante en EEUU que también operan en Europa. Las empresas que tienen litigios activos o potenciales con partes americanas son el objetivo más evidente de solicitudes bajo el CLOUD Act.
- Despachos de abogados y consultoras. El secreto profesional y la confidencialidad de la información de los clientes son pilares básicos del ejercicio de la abogacía. Almacenar documentación de clientes en infraestructura sujeta al CLOUD Act es un riesgo que los colegios de abogados de varios países ya están discutiendo.
- Empresas que trabajan con la administración pública española. El Real Decreto-ley 14/2019 y la Ley de Contratos del Sector Público ya establecen la obligación de localización en la UE.
Preguntas frecuentes Nube soberana europea vs Cloud Americano
No. La localización física del servidor no determina qué ley aplica a su contenido. Lo que determina la aplicabilidad del CLOUD Act es la nacionalidad corporativa de quien gestiona el servidor. Si el proveedor es una empresa americana, aunque su servidor esté en Frankfurt, el CLOUD Act puede alcanzar los datos.
Oracle Corporation tiene sede en EEUU, pero Oracle EU Sovereign Cloud opera a través de entidades jurídicas europeas con arquitectura, personal y procedimientos operativos independientes del resto de Oracle. La clave está en la independencia operativa: las entidades europeas pueden operar los centros de datos sin necesidad de transferir datos fuera de la UE, y los procedimientos de respuesta ante solicitudes gubernamentales externas están diseñados para maximizar la protección de los datos bajo la ley europea.
Sí. DocuSign tiene sede en San Francisco, California. Sus datos, aunque puedan estar en servidores europeos en determinados planes, están gestionados por una empresa americana sujeta al CLOUD Act. Lo que los proveedores americanos no pueden garantizar, incluso actuando a través de filiales europeas, es la protección frente a la extraterritorialidad de esa ley.
La Ley de Contratos del Sector Público obliga a la empresa adjudicataria a presentar, antes de la formalización del contrato, una declaración sobre dónde van a estar ubicados los servidores y desde dónde se van a prestar los servicios. Y el Real Decreto-ley 14/2019 exige que los sistemas de identificación y firma utilizados en relaciones con la AAPP estén en territorio de la UE.
No necesariamente en coste total de propiedad. EAD Factory opera con modelo de tarifa plana: un coste fijo mensual o anual con independencia del volumen de operaciones. Para empresas con volúmenes medios o altos de documentos, firmas o archivos, el punto de inflexión en el que la tarifa plana es competitiva con los modelos transaccionales de AWS o Azure llega antes de lo que parece.
Tus datos confidenciales merecen una jurisdicción que los proteja
El CLOUD Act no es un riesgo teórico. Es una ley vigente que se ha aplicado, que ha generado jurisprudencia y que sigue siendo un vector de acceso a datos corporativos europeos para autoridades americanas. La pregunta no es si confías en tu proveedor de nube, seguramente sí, sino si confías en que la ley americana nunca va a pedirle tus datos más confidenciales.
La nube soberana europea no es una opción de nicho para empresas con necesidades especiales. Es la respuesta correcta para cualquier empresa que procese datos con relevancia estratégica y que tenga obligaciones de confidencialidad reales frente a sus clientes, socios o la administración. EADTrust opera exclusivamente en Oracle EU Sovereign Cloud. Todos sus servicios: Signature Manager, eArchiving, Notice Manager, EAD Enterprise Suite, garantizan que tus datos permanecen en la Unión Europea, bajo protocolos que ningún proveedor americano puede replicar aunque quiera.
También te puede interesar…
La entrada Nube soberana europea vs CLOUD Act americano: por qué importa dónde están tus datos se publicó primero en EADTrust.
]]>La entrada Certificados híbridos: el puente técnico necesario hacia la resistencia cuántica se publicó primero en EADTrust.
]]>La solución técnica que garantiza esta interoperabilidad y seguridad simultánea son los Certificados híbridos.
Estos artefactos criptográficos permiten a las organizaciones comenzar a desplegar defensas contra la amenaza cuántica hoy, sin romper la compatibilidad con la infraestructura de internet actual que aún depende de RSA y ECC.
Son, en esencia, el eslabón perdido entre el presente clásico y el futuro cuántico.
¿Qué es exactamente un certificado híbrido?
En el contexto de la Infraestructura de Clave Pública (PKI), un certificado híbrido (a veces denominado «Composite Certificate» o «Cross-Certificate» en borradores del IETF) es una credencial digital que incorpora múltiples claves públicas o firmas basadas en diferentes algoritmos criptográficos dentro de una misma estructura X.509.
Anatomía técnica de un certificado híbrido
Para que un ingeniero entienda su funcionamiento, debemos visualizarlo como un contenedor con doble carga:
- Capa clásica (tradicional): contiene una clave pública estándar (ej. RSA-4096 o ECDSA P-256). Esta capa asegura que cualquier navegador, servidor o aplicación actual pueda validar el certificado sin errores.
- Capa Post-Cuántica (PQC): contiene una clave pública o firma basada en los nuevos estándares del NIST (como FIPS 203/ML-KEM o FIPS 204/ML-DSA). Esta capa proporciona la seguridad a largo plazo contra atacantes cuánticos.
El objetivo es lograr un modelo de seguridad «AND» : para que la comunicación se comprometa, el atacante debe romper tanto el algoritmo clásico como el algoritmo post-cuántico.
El problema de la interoperabilidad: ¿por qué no saltar directamente a PQC?
Si el NIST ya ha estandarizado los algoritmos, ¿por qué no abandonar RSA inmediatamente? La respuesta es la interoperabilidad.
- El ecosistema actual: miles de millones de dispositivos (IoT, routers, móviles antiguos, servidores legacy) no saben qué es un algoritmo de retículo (Lattice-based cryptography). Si un servidor web cambiara hoy su certificado a uno puramente PQC (FIPS 204), el 99% de los usuarios vería un error de «Conexión no segura» o «Certificado inválido».
- La solución híbrida: al presentar un certificado híbrido, el cliente (navegador o dispositivo) negocia la conexión.
- Si el cliente es antiguo, ignora la parte PQC y valida solo la parte RSA/ECC. La conexión funciona (aunque no es resistente a lo cuántico).
- Si el cliente es moderno (compatible con PQC), valida ambas partes o prioriza la parte PQC, estableciendo un túnel seguro contra computadoras cuánticas.
Estrategias de implementación técnica (IETF y X.509)
No existe una única forma de construir un certificado híbrido. Actualmente, la industria debate y estandariza principalmente dos enfoques a través del IETF (Internet Engineering Task Force).
1. Enfoque de claves compuestas (Composite Keys)
En este modelo, se define un nuevo algoritmo criptográfico que es, en realidad, la combinación de dos.
- Funcionamiento: se crea un «super-algoritmo» (ej. RSA-with-Dilithium). La clave pública dentro del certificado es una concatenación de la clave RSA y la clave Dilithium.
- Ventaja: simplicidad conceptual. Es un solo objeto.
- Desventaja: requiere que el software entienda explícitamente este nuevo OID (Object Identifier) «compuesto». Si no lo entiende, fallará.
2. Enfoque de extensiones X.509 (Non-Critical Extensions)
Este es el enfoque más compatible y recomendado para la fase de transición temprana.
- Funcionamiento: el certificado principal es un certificado RSA/ECC estándar. La clave post-cuántica se incrusta dentro de una extensión X.509 marcada como «no crítica».
- Mecanismo:
- El software antiguo lee el certificado, ve una extensión que no conoce (la PQC), pero como es «no crítica», la ignora y procede a validar con RSA.
- El software moderno busca específicamente esa extensión, extrae la clave PQC y realiza la validación adicional.
- Ventaja: Retrocompatibilidad total. No rompe sistemas antiguos.
Tabla comparativa de enfoques
| Característica | Claves compuestas | Extensiones X.509 | Múltiples certificados (vinculados) |
| Compatibilidad Legacy | Baja (rompe clientes antiguos) | Alta (transparente para clientes antiguos) | Media (depende del protocolo TLS) |
| Complejidad de Gestión | Media | Baja | Alta (gestionar 2 certs por entidad) |
| Tamaño del certificado | Grande | Grande | Variable (dos archivos) |
| Caso de uso ideal | Entornos cerrados / Controlados | Internet abierto / Web Pública | Protocolos complejos (TLS 1.3) |
Desafíos y consideraciones de rendimiento
Implementar certificados híbridos no es gratuito en términos de recursos. Los CISO deben tener en cuenta el impacto en la infraestructura.
- Latencia y tamaño: los algoritmos PQC suelen tener claves o firmas más grandes que las curvas elípticas. Un certificado híbrido suma el peso de ambas claves. Esto puede aumentar la latencia en el handshake TLS y el consumo de ancho de banda, algo crítico en entornos IoT o móviles con mala cobertura.
- Carga en el servidor: validar dos firmas matemáticas distintas consume más ciclos de CPU. Los balanceadores de carga y servidores web deberán dimensionarse para soportar este incremento computacional.
- Fragmentación de paquetes: debido al tamaño, es probable que el Hello del servidor exceda la unidad máxima de transmisión (MTU), provocando fragmentación de paquetes TCP y posibles pérdidas en redes inestables.
El papel de los certificados híbridos en la estrategia «Defense-in-Depth»
Desde la perspectiva de la seguridad, el certificado híbrido es la máxima expresión de la defensa en profundidad para la criptografía.
- Mitigación de fallos matemáticos: incluso si no existieran las computadoras cuánticas, la criptografía híbrida es deseable. Si mañana un matemático descubre una vulnerabilidad en las curvas elípticas (independiente de lo cuántico), la capa PQC (basada en retículos) mantendría la seguridad, y viceversa.
- Cumplimiento proactivo: permite a las empresas cumplir con las normativas actuales (que exigen algoritmos clásicos aprobados) mientras demuestran diligencia debida al protegerse contra amenazas futuras, alineándose con el principio de Accountability del RGPD.
Preguntas frecuentes sobre certificados híbridos
No por ley, pero son altamente recomendados por agencias de seguridad nacional (como la NSA en su suite CNSA 2.0 o el BSI alemán) para sistemas de seguridad nacional e infraestructuras críticas. En el sector privado, son una decisión estratégica para proteger datos de larga duración.
El soporte es experimental pero creciente. Google Chrome y Mozilla Firefox han realizado pruebas con extensiones híbridas (generalmente usando Kyber para el intercambio de claves). Sin embargo, el soporte nativo generalizado llegará a medida que los estándares del IETF (como X.509 v3 extensions for PQC) se finalicen.
Sí, pero el impacto depende de la implementación. El aumento en el tamaño del certificado puede añadir unos milisegundos a la conexión inicial. Sin embargo, para la mayoría de las aplicaciones empresariales y webs modernas, este retraso es imperceptible para el usuario y justificable por la seguridad añadida.
Como Prestador de Servicios de Confianza en constante evolución, en EADTrust estamos adaptando nuestra infraestructura para emitir credenciales de próxima generación. Actualmente estamos en fase de pruebas piloto y consultoría para organizaciones que desean preparar sus PKI internas para este modelo.
Conclusión
Los certificados híbridos no son una «moda» pasajera, sino la arquitectura estándar que dominará internet durante la próxima década. Representan el pragmatismo técnico: reconocer que el futuro cuántico es inevitable, pero que el presente clásico aún debe funcionar.
Para las empresas, adoptar una estrategia híbrida es la única forma de evitar una migración traumática («Big Bang») en el futuro. Permite una transición suave, controlada y segura. ¿Está tu organización preparada para gestionar certificados de doble algoritmo?
En EADTrust podemos ayudarte a diseñar una prueba de concepto (PoC) para integrar certificados híbridos en tu entorno crítico sin interrumpir tus operaciones actuales.
También te puede interesar…
La entrada Certificados híbridos: el puente técnico necesario hacia la resistencia cuántica se publicó primero en EADTrust.
]]>La entrada Reglamento (UE) 2026/1778 en vigor desde hoy: el registro de pasaportes digitales de productos entra en funcionamiento se publicó primero en EADTrust.
]]>Para cualquier empresa que fabrique, importe o distribuya productos sujetos a un DPP (baterías, productos de construcción, juguetes, detergentes y tensioactivos, y los sectores futuros bajo el ESPR), esta fecha marca el punto a partir del cual el marco operativo del registro ya no es una promesa normativa: es infraestructura real que exige preparación inmediata.
¿A quién le interesa este artículo?
Este artículo está dirigido a:
- Fabricantes, importadores y distribuidores de baterías (vehículos eléctricos, medios de transporte ligeros, aplicaciones industriales) que deben inscribir el pasaporte digital de baterías a partir del 18 de febrero de 2027.
- Operadores económicos de productos de construcción, juguetes, detergentes y tensioactivos, sector textil y cualquier otro producto sujeto a un DPP conforme al ESPR o a legislación sectorial específica.
- Prestadores de servicios de pasaporte digital de productos (art. 2.32 ESPR): terceros independientes que tratan y custodian los datos del DPP en nombre del operador económico.
- Responsables de cumplimiento normativo, directores de calidad y equipos jurídicos de empresas industriales que necesitan entender qué infraestructura técnica y qué certificados digitales deben preparar antes de la primera fecha límite de inscripción.
Conceptos básicos para entender el Reglamento (UE) 2026/1778
Operador económico verificado
Persona física o jurídica que ha superado el proceso de verificación de identidad previsto en el artículo 4 del Reglamento 2026/1778 (mediante sello electrónico cualificado, firma electrónica cualificada o medio de identificación de nivel alto), y que por tanto puede crear su perfil de usuario, inscribir DPP y gestionar derechos de acceso en el registro.
Agente de la cadena de valor verificado
Reparadores, reacondicionadores, fabricantes de productos remanufacturados, recicladores y otros agentes que superan un proceso de verificación equivalente (art. 5) para poder actuar en el registro sobre pasaportes que no son de su titularidad original.
Identificador único de registro
Código persistente y único que el registro genera automáticamente tras la verificación satisfactoria de una solicitud de inscripción. Identifica de forma inequívoca cada DPP inscrito y es el dato que las autoridades aduaneras comprueban para autorizar el despacho a libre práctica (art. 15 ESPR).
Comprobante de inscripción
Documento electrónico descargable que acredita que un DPP ha sido inscrito en el registro. Está protegido por un sello electrónico cualificado de la Comisión y un sello de tiempo electrónico, y permanece disponible durante 90 días naturales desde su generación (puede regenerarse).
Repositorio semántico
Recopilación evolutiva de modelos de datos y definiciones semánticas, versionada, con servicio de búsqueda, accesible mediante API públicas y de uso gratuito. Incluye etiquetas y definiciones multilingües para garantizar la interoperabilidad de los datos del DPP entre sectores y países.
¿Qué es exactamente el registro de pasaportes digitales de productos?
El registro de pasaportes digitales de productos es la infraestructura informática centralizada que la Comisión Europea debía crear a más tardar el 19 de julio de 2026 conforme al artículo 13.1 del ESPR. No es una base de datos voluntaria ni un portal informativo: es el sistema donde cada DPP recibe su identificador único, queda inscrito de forma oficial y se hace verificable por autoridades de vigilancia del mercado y aduanas.
El artículo 3 del Reglamento 2026/1778 define su estructura en nueve componentes:
- Sitio web con interfaz de usuario segura: punto de acceso para operadores económicos verificados.
- API: canal técnico para inscribir DPP y recibir información de forma automatizada.
- Plataforma de verificación: permite confirmar la existencia e integridad de un DPP inscrito.
- Esquema de identificadores: genera identificadores de registro únicos y persistentes para cada pasaporte.
- Componente de almacenamiento: almacena los identificadores únicos y los códigos de mercancía (necesarios para el despacho aduanero a libre práctica).
- Lista de prestadores de servicios DPP verificados: inscritos en el registro y accesibles públicamente.
- Repositorio semántico: modelos de datos versionados, multilingües, con API de consulta gratuita.
- Sistema de archivos de registro (logs): trazabilidad de accesos, modificaciones y acciones administrativas.
- Sistemas de identificación y autorización de usuarios: basados en los mecanismos eIDAS descritos en el artículo 4.
En conjunto, estos componentes garantizan que todo DPP inscrito sea identificable, verificable, auditable y accesible según los derechos de acceso definidos por la normativa sectorial aplicable.
¿A qué productos se aplica el Reglamento 2026/1778?
El artículo 1 define el ámbito de aplicación. El registro de pasaportes digitales de productos se aplica a los operadores económicos que introduzcan en el mercado o pongan en servicio:
- Productos regulados por actos delegados del artículo 4 del ESPR: cualquier categoría de productos para la que la Comisión adopte requisitos específicos de DPP (acero, textiles, aluminio, etc., a medida que se publiquen los actos delegados correspondientes).
- Pilas y baterías del artículo 77 del Reglamento (UE) 2023/1542: baterías para vehículos eléctricos, medios de transporte ligeros y aplicaciones industriales con capacidad superior a 2 kWh.
- Productos de construcción del artículo 76 del Reglamento (UE) 2024/3110.
- Juguetes del artículo 19 del Reglamento (UE) 2025/2509.
- Detergentes y tensioactivos del artículo 21 del Reglamento (UE) 2026/405.
- Cualquier otro producto de la legislación de la Unión que requiera un pasaporte digital de producto e inscripción en el registro.
Es importante señalar que, a efectos de este reglamento, el término «pasaporte digital del producto» incluye expresamente el pasaporte digital para baterías del artículo 77 del Reglamento (UE) 2023/1542. El registro es, por tanto, la infraestructura común que conecta transversalmente todas las regulaciones sectoriales de DPP.
¿Cómo se verifica la identidad de los operadores económicos?
El artículo 4 del Reglamento 2026/1778 establece un mecanismo de verificación basado íntegramente en el marco eIDAS (Reglamento (UE) n.º 910/2014). Según el tipo de operador:
Personas jurídicas (empresas, sociedades)
Establecidas o no en la UE, deben verificarse mediante:
- Sello electrónico cualificado (QSeal) basado en un certificado cualificado de sello electrónico expedido por un prestador cualificado de servicios de confianza (QTSP) conforme al Reglamento eIDAS; o
- Declaración electrónica cualificada de atributos que permita la identificación inequívoca y la verificación del establecimiento de la persona jurídica.
Personas físicas / comerciantes individuales
Establecidos en la UE, pueden verificarse mediante:
- Firma electrónica cualificada (QES) respaldada por un certificado cualificado de firma electrónica; o
- Medio de identificación electrónica de nivel de seguridad «alto»; o
- Declaración electrónica de atributos.
Para personas físicas no establecidas en la UE, las opciones se limitan a firma electrónica cualificada o declaración electrónica de atributos.
Estado «verificado» y su vigencia
Una vez superado el proceso, el operador obtiene el estado de «operador económico verificado», que le habilita para:
- Crear y gestionar su perfil de usuario en el registro.
- Gestionar derechos de acceso de otros usuarios que actúen en su nombre.
- Inscribir nuevos DPP y modificar inscripciones existentes.
El estado «verificado» es válido hasta que caduquen los medios de identificación electrónica utilizados y, en cualquier caso, durante un periodo máximo de 3 años desde la verificación. Transcurrido ese plazo, debe repetirse el proceso.
Agentes de la cadena de valor
Los reparadores, reacondicionadores, fabricantes de productos remanufacturados, recicladores y otros agentes de la cadena de valor deben superar un proceso de verificación equivalente (art. 5) para obtener el estado de «agente de la cadena de valor verificado» y poder actuar en el registro (por ejemplo, actualizar información de un DPP existente tras una reparación o reacondicionamiento).
El reglamento prevé además que se evite la doble verificación cuando el registro se integre con sistemas ya establecidos (como EPREL) que utilicen el mismo nivel de verificación.
EADTrust ¿Necesitas un sello electrónico de entidad? Solicítalo con EADTrust →¿Cómo funciona el proceso de inscripción del pasaporte en el registro?
El artículo 8 del Reglamento 2026/1778 detalla el proceso de inscripción del DPP. El operador económico verificado inscribe cada pasaporte digital indicando el nivel de detalle especificado en el acto delegado aplicable: modelo, lote o artículo (unidad individual).
Reglas clave:
- Si se inscribe a nivel de artículo, deben vincularse también los identificadores de lote y modelo cuando existan.
- Si un mismo producto está sujeto a varias normas con distintos niveles de detalle, se inscribe en el nivel más detallado.
- La inscripción puede realizarse mediante la interfaz de usuario segura o mediante la API.
Verificación automática
Tras la solicitud de inscripción, la Comisión comprueba automáticamente:
- Conformidad semántica de los datos con el modelo definido en el repositorio semántico.
- Coherencia de los datos obligatorios.
- Conformidad con el nivel de detalle exigido por el acto delegado.
- Validez del código de mercancía (nomenclatura combinada para aduanas).
- Enlace a la copia de seguridad alojada por un prestador de servicios de pasaporte digital de productos.
Resultado: identificador único de registro
Tras la verificación satisfactoria, el sistema genera automáticamente un identificador de registro único y persistente, lo almacena y lo comunica al agente que registró el pasaporte. Este identificador es el dato que las autoridades aduaneras comprobarán electrónicamente para autorizar el despacho a libre práctica de productos importados (art. 15 ESPR).
Comprobante de inscripción
Conforme al artículo 9, el operador económico puede solicitar en cualquier momento un comprobante de inscripción. Se trata de un documento electrónico seguro descargable que incluye:
- Identificador único del producto.
- Código de mercancía (si procede).
- Nombre e identidad del operador económico verificado.
- Fecha y hora de inscripción de la última versión, validada por un sello de tiempo electrónico de la Comisión.
- Hash criptográfico de la versión del DPP.
El comprobante está garantizado por un sello electrónico cualificado de la Comisión (art. 38 eIDAS) y permanece disponible 90 días naturales desde su generación. Puede regenerarse tantas veces como sea necesario.
¿Qué papel juega el prestador de servicios de pasaporte digital de productos?
El artículo 2.32 del ESPR define al prestador de servicios de pasaporte digital de productos como una persona física o jurídica, tercero independiente autorizado por el operador económico que introduce el producto en el mercado o lo pone en servicio, que trata los datos del pasaporte digital del producto con el fin de ponerlos a disposición de los operadores económicos y otros agentes con derecho de acceso.
Este rol es central en la arquitectura del DPP por tres motivos:
- Copia de seguridad obligatoria (art. 10.4 ESPR). Todo pasaporte digital debe complementarse con una copia de seguridad gestionada por un prestador de servicios DPP, tercero independiente, para garantizar la disponibilidad de los datos incluso tras insolvencia, liquidación o cese de actividad del operador económico. Sin este enlace de copia de seguridad, el registro no valida la inscripción.
- Custodia y accesibilidad a largo plazo. El prestador garantiza que los datos del DPP permanezcan accesibles durante toda la vida útil del producto y el periodo de conservación regulatorio, con independencia de lo que ocurra con el operador original.
- Integridad y autenticidad de los datos. Conforme al artículo 11 del ESPR, deben garantizarse «la autenticación, la fiabilidad y la integridad de los datos» y un «elevado nivel de seguridad y privacidad».
Este conjunto de obligaciones (independencia, custodia a largo plazo, integridad demostrable, disponibilidad ante insolvencia) encaja directamente con los servicios de archivo electrónico cualificado (eArchiving/Cartulario) regulados por el artículo 45 decies del Reglamento eIDAS 2.0. Un prestador cualificado de servicios de confianza que ofrezca eArchiving cualificado cumple nativamente los requisitos técnicos y jurídicos que el ESPR impone al prestador de servicios DPP.
Newsletter DPP No te pierdas ningún acto delegado que afecte a tu sector Cada sector tendrá su propio calendario de obligaciones DPP. Te avisamos en cuanto salga publicado el que te afecta. Apuntarme a la newsletter →¿Por qué este reglamento es la pieza que faltaba para activar el DPP a escala?
El artículo 13 del ESPR creó la obligación de que existiera un registro. Pero un registro sin reglas de funcionamiento es como un edificio sin instalaciones: la estructura existe, pero no se puede habitar.
El Reglamento de Ejecución (UE) 2026/1778 es exactamente eso: las modalidades técnicas que convierten la obligación legal del ESPR en un sistema operable. Sin este reglamento no estaban definidos:
- Cómo se verifica la identidad de un operador económico (qué certificados se aceptan, qué niveles de seguridad, qué duración tiene la verificación).
- Cómo se estructura la solicitud de inscripción (qué datos son obligatorios, qué verificaciones automáticas se aplican, cómo se genera el identificador único).
- Cómo se garantiza la integridad de los datos inscritos (sellos de tiempo, comprobantes, versionado).
- Cómo se gestionan los derechos de acceso, la transferencia de pasaportes y la intervención de agentes de la cadena de valor.
- Cómo interactúan las autoridades nacionales y las aduanas con el registro.
El registro es la infraestructura horizontal común a todos los sectores DPP: baterías, construcción, juguetes, textiles, detergentes y los futuros sectores que se incorporen bajo el ESPR. Sin las modalidades técnicas de este reglamento de ejecución, el registro creado por el artículo 13 del ESPR no podía operar en la práctica.
Ahora que las reglas del juego están publicadas y en vigor, los operadores económicos ya tienen la certeza jurídica y técnica necesaria para preparar sus sistemas. El primer examen real será el 18 de febrero de 2027, cuando las baterías para vehículos eléctricos, medios de transporte ligeros y aplicaciones industriales deban tener su pasaporte digital inscrito y operativo.
¿Qué debe preparar ya un operador económico o un prestador de servicios DPP?
Aunque las fechas límite sectoriales varíen, las siguientes acciones son comunes a todos los operadores y prestadores que deberán interactuar con el registro:
- Verificación de identidad eIDAS. Obtener un sello electrónico cualificado (QSealC) si se es persona jurídica, o una firma electrónica cualificada (QES) si se es comerciante individual. Es el requisito previo a cualquier acción en el registro. El certificado debe estar vigente y emitido por un QTSP incluido en la EU Trusted List. Solicita tu QSealC.
- Verificación de datos registrales. Comprobar que los datos de la organización (denominación social, NIF/EUID, dirección) coinciden exactamente con los que figuran en el certificado cualificado. Las discrepancias entre los datos del certificado y los datos corporativos son la causa más frecuente de rechazo en la verificación.
- Elección de prestador de servicios DPP para la copia de seguridad. Identificar y contratar un tercero independiente que aloje la copia de seguridad del pasaporte digital (art. 10.4 ESPR). Sin este enlace, la inscripción no supera la verificación automática del registro.
- Adecuación de los sistemas de datos a los modelos semánticos. Revisar que la información de producto se estructura conforme al modelo de datos definido en el repositorio semántico para cada categoría de producto. La verificación automática de conformidad semántica rechazará inscripciones que no cumplan el esquema.
- Gestión de derechos de acceso de terceros. Si se delegará la inscripción en un agente externo (por ejemplo, un integrador tecnológico), este deberá superar su propio proceso de verificación (art. 5). Definir los roles y niveles de acceso con antelación.
- Integración técnica con el registro. Evaluar si se operará mediante la interfaz de usuario o mediante la API. Para volúmenes elevados de productos (líneas industriales, catálogos amplios), la integración vía API será imprescindible.
Revisión del código de mercancía. Confirmar que cada producto tiene asignado un código de nomenclatura combinada válido y actualizado: el registro lo comprueba en la inscripción y las aduanas lo verifican para el despacho a libre práctica.
Preguntas frecuentes sobre el UE 2026/1778
Sin un certificado cualificado vigente emitido por un QTSP, el operador no puede superar la verificación de identidad del artículo 4 y, por tanto, no puede obtener el estado de «operador económico verificado». Esto bloquea cualquier acción posterior: no podrá crear su perfil, inscribir pasaportes ni gestionar derechos de acceso. El propio sistema redirige al operador a contactar con su QTSP para obtener un certificado válido. Es un prerrequisito absoluto.
Es un documento electrónico descargable que acredita que un DPP concreto ha sido inscrito en el registro. Incluye el identificador del producto, los datos del operador, la fecha y hora de inscripción sellada temporalmente por la Comisión, y un hash de la versión del DPP. Está protegido por un sello electrónico cualificado de la Comisión (art. 38 eIDAS). Su utilidad principal es demostrar frente a terceros -clientes, autoridades, socios comerciales- que se ha cumplido la obligación de registro. Permanece disponible 90 días y puede regenerarse.
La verificación fallará. Los datos del certificado cualificado (denominación social, identificador de persona jurídica, país de establecimiento) deben coincidir exactamente con los datos que el operador declara en el formulario del registro. Las discrepancias más habituales son diferencias en la denominación social (abreviaturas, caracteres especiales, traducciones del nombre) o en el número de identificación. La solución es revisar los datos registrales antes de solicitar el certificado, o solicitar la emisión de uno nuevo con datos corregidos.
Si la legislación sectorial establece un periodo específico de disponibilidad del DPP, se aplica ese periodo. En ausencia de indicación expresa, los datos de inscripción se suprimen automáticamente a los 10 años, conforme a la Guía azul de la Comisión de 2022.
EPREL (European Product Registry for Energy Labelling) es un registro preexistente para productos con etiqueta energética. El Reglamento 2026/1778 prevé expresamente evitar la doble verificación cuando el registro DPP se integre con sistemas ya establecidos, como EPREL, que utilicen el mismo nivel de verificación de identidad. En la práctica, un operador ya verificado en EPREL con el mismo nivel eIDAS no debería tener que repetir el proceso para el registro DPP, una vez se implemente la interconexión.
Sí. El operador económico verificado puede delegar derechos de acceso en usuarios terceros que actúen en su nombre (art. 6). Sin embargo, ese tercero debe superar su propio proceso de verificación (art. 5), y el operador sigue siendo plenamente responsable de la exactitud y exhaustividad de los datos inscritos (art. 19).
EADTrust: tu prestador cualificado para operar en el registro DPP
EADTrust es un prestador cualificado de servicios de confianza (QTSP) incluido en la EU Trusted List, supervisado por el Ministerio de Asuntos Económicos y Transformación Digital de España.
En el contexto del registro de pasaportes digitales de productos, EADTrust resuelve directamente dos necesidades críticas:
- Sello electrónico cualificado (QSealC) para la verificación de identidad. El Reglamento 2026/1778 exige que las personas jurídicas se verifiquen mediante un QSealC emitido por un QTSP. EADTrust emite certificados cualificados de sello electrónico compatibles con el registro DPP, verificando previamente que los datos registrales del operador (denominación, EUID/NIF, establecimiento) coinciden con los que figurarán en el formulario del registro. Esto evita los rechazos por discrepancia de datos, que son la causa más frecuente de bloqueo.
- Archivo electrónico cualificado (eArchiving) para la copia de seguridad independiente. El artículo 10.4 del ESPR obliga a que cada DPP se complemente con una copia de seguridad gestionada por un tercero independiente. El servicio de eArchiving cualificado de EADTrust -conforme al artículo 45 decies del Reglamento eIDAS 2.0- ofrece preservación a largo plazo, garantía de accesibilidad independiente del estado del operador, y sellado temporal cualificado que demuestra la integridad de los datos archivados en cualquier momento.
Además, el sello de tiempo cualificado de EADTrust satisface el requisito del artículo 11(g) del ESPR sobre constancia de fecha y hora de introducción o modificación de datos en el DPP.
Ninguna plataforma tecnológica generadora de DPP incorpora por sí misma sello electrónico cualificado ni archivo electrónico cualificado: EADTrust complementa esas plataformas aportando la capa de confianza jurídica que el ESPR exige.
También te puede interesar…
La entrada Reglamento (UE) 2026/1778 en vigor desde hoy: el registro de pasaportes digitales de productos entra en funcionamiento se publicó primero en EADTrust.
]]>La entrada La Cartera IDUE: estado actual en España se publicó primero en EADTrust.
]]>Conceptos para la Cartera IDUE
Cl@ve
Sistema de identificación digital de la administración española con 24 millones de usuarios registrados. Actúa como infraestructura de base para la adopción de la Cartera IDUE, proporcionando una base de usuarios ya familiar con la identificación electrónica ante la administración.
ARF (Architecture Reference Framework)
Marco de arquitectura de referencia definido por la Comisión Europea como base técnica para todas las implementaciones nacionales de la EUDI Wallet. Garantiza la interoperabilidad transfronteriza entre las distintas implementaciones nacionales.
OpenID4VP (OpenID for Verifiable Presentations)
Protocolo de comunicación utilizado para la presentación de credenciales de la wallet en modo en línea. Permite que el ciudadano presente sus atributos a un verificador a través de internet de forma segura y verificable.
ISO/IEC 18013-5
Estándar internacional para la presentación de credenciales en modo proximidad, sin conexión a internet, cara a cara. El mismo estándar que usa la licencia de conducir digital. Permite la verificación de identidad en modo fuera de línea.
SD-JWT VC (Selective Disclosure JWT Verifiable Credentials)
Formato de credencial verificable que permite la divulgación selectiva de atributos. Uno de los dos formatos estándar definidos en los actos de ejecución europeos para la EUDI Wallet, junto al formato mdoc/mDL de ISO/IEC 18013-5.
EUDI Wallet Launchpad
Evento celebrado en Bruselas en diciembre de 2025 donde los países piloto de la EUDI Wallet presentaron el estado de sus implementaciones nacionales ante la Comisión Europea y el ecosistema de actores del proyecto.
Qué es la Cartera IDUE
La Cartera IDUE es la implementación española de la EUDI Wallet regulada por el Reglamento (UE) 2024/1183. El nombre es el acrónimo invertido de Identidad Digital de la UE, una elección de denominación que mantiene la conexión explícita con el estándar europeo del que forma parte. No es un proyecto nacional paralelo: es la instancia española de un sistema que funcionará de forma interoperable en los 27 Estados miembros.
La Cartera IDUE tiene un punto de partida inusualmente fuerte respecto a la mayoría de los países europeos: 24 millones de usuarios tienen ya cuenta activa en Cl@ve, el sistema de identificación digital de la administración española que actúa como infraestructura de base. Esa base de usuarios existente es una ventaja real en el proceso de adopción: no se parte de cero.
La FNMT (Fábrica Nacional de Moneda y Timbre) actúa como emisora del PID (Person Identification Data) en el entorno piloto. Es el organismo que certifica que el dato de identidad que contiene la wallet corresponde a una persona real verificada por el Estado español.
Lo que ya funciona: los casos de uso operativos en el piloto
El piloto español no es una demo estática. Hay casos de uso que ya funcionan en producción, con ciudadanos reales, en entornos controlados. Los dos más avanzados son:
Identificación con PID
El ciudadano puede identificarse ante servicios usando únicamente su PID en la wallet, sin necesidad de presentar el DNI físico ni usar el certificado digital tradicional. El proceso funciona en modo en línea y, en determinados contextos, en modo sin conexión mediante el protocolo ISO/IEC 18013-5, el mismo estándar que usa la licencia de conducir digital. La identidad se transmite de forma verificable entre el dispositivo del ciudadano y el sistema del verificador sin que EADTrust ni ningún otro intermediario tenga acceso al contenido.
Verificación de edad
Este es el caso de uso que mejor ilustra la potencia de la divulgación selectiva. Un ciudadano puede acreditar que es mayor de dieciocho años sin revelar su nombre, su fecha de nacimiento ni ningún otro dato. El sistema recibe únicamente la confirmación booleana «mayor de 18: sí». Nada más. Para plataformas de venta de alcohol, tabaco, juegos de azar o contenido para adultos, este mecanismo cumple la obligación legal de verificación de edad con el mínimo impacto posible sobre la privacidad del usuario.
Más allá de estos dos casos de uso centrales, el piloto español está trabajando en la integración de credenciales de diplomas académicos verificables con universidades y de atributos profesionales con colegios profesionales. Esos casos de uso son los más complejos desde el punto de vista de emisión y los más transformadores desde el punto de vista de valor para el ciudadano.
La arquitectura de la Cartera IDUE: cuatro actores, una cadena
La Cartera IDUE se articula sobre cuatro actores que interactúan dentro de un ecosistema de confianza regulado. Entender cómo se relacionan es fundamental para cualquier organización que quiera participar en él.
El ciudadano y su cartera
La persona física que tiene instalada la app de la Cartera IDUE en su dispositivo móvil. Almacena sus credenciales, decide qué comparte con quién y cuándo, y tiene control completo sobre el historial de transacciones. La wallet es su propiedad: nadie puede acceder a ella sin su consentimiento explícito.
Los emisores de credenciales
Las organizaciones que emiten las credenciales que el ciudadano almacena en la cartera. Hay dos tipos: las autoridades públicas (el Estado, los registros, las administraciones), que emiten el PID y las PubEAA; y los QTSP (como EADTrust), que emiten las QEAA (declaraciones cualificadas de atributos). Solo los QTSP pueden emitir QEAA con pleno valor legal bajo eIDAS 2.
Los verificadores
Las organizaciones (públicas o privadas) que reciben las credenciales presentadas por el ciudadano para verificar su identidad o sus atributos. Un banco que quiere verificar la identidad de un nuevo cliente, un hospital que quiere confirmar la colegiación de un médico, una empresa que quiere verificar los poderes de representación de su interlocutor. Para ser verificador, hay que estar registrado como parte usuaria en el sistema nacional y disponer del certificado de acceso correspondiente.
El directorio y el registro
La infraestructura de confianza que certifica quién puede hacer qué en el ecosistema: qué organizaciones están autorizadas para emitir credenciales, cuáles para verificarlas, y bajo qué condiciones. En España, EADTrust construye el Directorio de Partes Informadas e Informantes (visible en usercentric.id), que es la capa de orientación y conexión para organizaciones que quieren entrar en el ecosistema como emisoras o verificadoras.
El estándar técnico que lo sustenta: ARF y OpenID4VC
La Cartera IDUE no es una aplicación con arquitectura propia: sigue el Architecture Reference Framework (ARF) definido por la Comisión Europea como base técnica de referencia para todas las implementaciones de la EUDI Wallet. Eso garantiza la interoperabilidad: la Cartera IDUE funciona con verificadores en Francia, Alemania o Estonia de la misma forma que con verificadores en España.
Los protocolos de comunicación entre la wallet y los verificadores se basan en OpenID4VP (OpenID for Verifiable Presentations) para la presentación de credenciales en línea, y en ISO/IEC 18013-5 para la presentación en modo proximidad, cara a cara, sin conexión a internet. Esos son los mismos protocolos que se usan en la licencia de conducir digital en EEUU y en múltiples proyectos de identidad digital avanzada en el mundo. España los ha adoptado desde el inicio del piloto.
Las credenciales se emiten en formato SD-JWT VC (Selective Disclosure JWT Verifiable Credentials) e ISO/IEC 18013-5 mdoc/mDL. Son los formatos definidos en los actos de ejecución europeos como estándares obligatorios para la interoperabilidad transfronteriza.
Lo que todavía falta: los riesgos reales de la implementación española
La honestidad sobre el estado actual requiere nombrar también lo que no está resuelto. El piloto es sólido, el punto de partida es bueno y el compromiso político es claro. Pero hay elementos que todavía están pendientes y que condicionan el ritmo de preparación de las organizaciones que quieren integrarse.
La hoja de ruta nacional completa
A fecha de redacción de este artículo, España no tiene publicada una hoja de ruta detallada con los plazos específicos de extensión de la Cartera IDUE más allá de los pilotos. Eso genera incertidumbre para las organizaciones que necesitan planificar sus integraciones. La experiencia de los países que han publicado hojas de ruta (como Alemania y los Países Bajos) muestra que esa publicación acelera la adopción del ecosistema privado de forma significativa.
La proliferación de actores no cualificados
Uno de los riesgos identificados en el informe de contenidos estratégicos de EADTrust es la aparición de emisores de atributos que operan sin la cualificación requerida (colegios profesionales, registros y plataformas privadas que emiten credenciales sin supervisión), generando un ecosistema fragmentado donde no toda la credencial que circula tiene el mismo nivel de garantía. La distinción entre QEAA emitida por un QTSP y una EAA emitida por cualquier otro actor es fundamental para la confianza en el sistema.
La dependencia de los actos de ejecución pendientes
Algunos de los actos de ejecución técnicos de eIDAS 2 todavía están en desarrollo o en consulta pública. Eso crea zonas grises técnicas en las que las organizaciones no pueden terminar de definir su arquitectura de integración hasta que los estándares estén completamente cerrados.
La formación del ecosistema privado
Los verificadores no surgirán solos. Las empresas del sector privado regulado necesitan comprender qué significa integrarse como parte usuaria, qué certificados necesitan, cómo funciona el registro y qué flujos de usuario van a cambiar. Ese proceso de formación del ecosistema privado es el trabajo más intensivo de los próximos doce meses.
El rol de EADTrust en la implementación española
EADTrust no es un observador del proceso de despliegue de la Cartera IDUE. Es uno de sus constructores. Desde nuestra posición como QTSP registrado en España desde 2014, supervisado por el Ministerio de Asuntos Económicos y Transformación Digital e inscrito en la Trust Service List de la Comisión Europea, somos parte de la infraestructura de confianza que el ecosistema necesita para funcionar.
En el ecosistema de la Cartera IDUE, los QTSP tienen un papel que ningún otro actor puede cumplir: solo los QTSP pueden emitir QEAA, las declaraciones cualificadas de atributos con pleno valor legal en toda la Unión. Si una universidad quiere emitir diplomas verificables con valor legal europeo, necesita un QTSP detrás. Si un colegio de abogados quiere emitir la condición de colegiado como credencial verificable, necesita un QTSP detrás. Si una empresa quiere emitir poderes de representación verificables para sus empleados, necesita un QTSP detrás.
EADTrust puede ser ese QTSP. Y ya estamos construyendo las primeras QEAA en el marco de los pilotos españoles. Además, el Directorio de Partes Informadas e Informantes de usercentric.id es la plataforma que conecta a las organizaciones que quieren entrar en el ecosistema con la información técnica, jurídica y operativa que necesitan para hacerlo correctamente. No es un directorio pasivo: es un instrumento activo de formación del ecosistema privado en torno a la Cartera IDUE.
Preguntas frecuentes sobre Carte IDUE
En mayo de 2026, la Cartera IDUE está en fase piloto con casos de uso funcionales (identificación con PID y verificación de edad) disponibles en entornos controlados. La disponibilidad general para todos los ciudadanos españoles debe producirse antes del 24 de diciembre de 2026, conforme al plazo establecido en el Reglamento (UE) 2024/1183. La hoja de ruta exacta de despliegue general todavía no ha sido publicada oficialmente por el Gobierno de España.
El ecosistema privado alrededor de la Cartera IDUE todavía está por construir
La app de la Cartera IDUE será la parte más visible del sistema. Pero el valor real para ciudadanos y empresas depende del ecosistema que se construya alrededor: emisores de credenciales que emitan atributos con valor real, verificadores que los acepten con confianza, y estándares técnicos que garanticen que todo funciona correctamente en los 27 Estados miembros.
Ese ecosistema privado no se construye solo. Se construye con organizaciones que deciden estar dentro, con información suficiente para hacerlo correctamente y con el tiempo necesario para integrarse sin prisas.
EADTrust está construyendo ese ecosistema. El Directorio de usercentric.id es el primer paso. Los servicios de QTSP para la emisión de QEAA son el siguiente. Y el acompañamiento técnico y regulatorio para las organizaciones que quieren integrarse como verificadoras es lo que completa la oferta.
También te puede interesar…
La entrada La Cartera IDUE: estado actual en España se publicó primero en EADTrust.
]]>La entrada Cómo registrarse en el Pasaporte Digital de Producto: guía paso a paso se publicó primero en EADTrust.
]]>Este artículo recorre el proceso completo, desde el acceso a la plataforma hasta el momento en que puedes empezar a inscribir pasaportes digitales. Todo basado en la guía oficial publicada por DG GROW el 17 de julio de 2026.
Conceptos clave para registrarse en el DPP
Alta de la organización
Proceso por el que una empresa facilita sus datos al Registro DPP para que la Comisión Europea pueda verificar que tiene derecho a operar como operador económico. Crea tanto el perfil de la organización como la cuenta del administrador dentro del Registro.
Declaración PDF
Documento generado por la Comisión Europea durante el proceso de verificación. Contiene los datos de la organización que se ha dado de alta, viene sellado con el sello institucional de la Comisión y debe ser contrasellado por el representante legal de la empresa antes de devolverlo al sistema.
PAdES Baseline
Estándar técnico europeo que define cómo debe estructurarse una firma o sello electrónico en un documento PDF para que sea válida y verificable a largo plazo. El Registro DPP exige que el sello o firma cumpla este formato en uno de sus cuatro niveles: B, T, LT o LTA. Si la herramienta utilizada no genera PAdES Baseline, la verificación falla aunque el certificado sea cualificado.
UPI (Unique Product Identifier / Identificador Único de Producto)
Código que identifica de forma exclusiva a cada pasaporte digital. En el Registro DPP, el UPI tiene forma de URL en formato HTTPS que apunta a la ubicación donde están alojados los datos completos del pasaporte. Es el dato obligatorio en cualquier inscripción de DPP y lo genera o asigna el propio operador económico.
URI (Unique Registration Identifier / Identificador Único de Registro)
Identificador que devuelve el Registro DPP cuando una inscripción se completa con éxito. Vincula el asiento almacenado en el Registro con los datos del DPP del operador económico mediante el UPI.
Granularidad del registro
Nivel de detalle con el que se inscribe un DPP. El Registro admite tres niveles: modelo (todos los artículos de una misma familia de producto), lote (todos los artículos fabricados en una misma tirada de producción) y artículo/unidad (un producto individual concreto). Actualmente solo está disponible el nivel de artículo para el grupo de baterías.
Entorno de pruebas DPP
Versión del Registro DPP habilitada por la Comisión para que los operadores puedan explorar el proceso sin consecuencias en el sistema real. Tiene una URL diferente, requiere una cuenta EU Login distinta y los objetos creados pueden eliminarse por rutinas de limpieza. El proceso de verificación es idéntico al de producción: requiere datos válidos y sello cualificado real.
Antes de empezar: dos fases que no conviene confundir
El recorrido en el Registro DPP tiene dos fases claramente separadas, y cada una tiene su propia lógica.
La primera es el alta y la verificación de la organización. Es el proceso por el que acreditas que tienes derecho a operar en el Registro como operador económico. Hasta que no superas esta fase, no puedes hacer nada más en la plataforma.
La segunda es el registro de los DPPs. Una vez verificada la organización, puedes inscribir los pasaportes digitales de tus productos.
Ambas fases son necesarias, pero tienen naturaleza distinta. La primera es esencialmente un proceso de acreditación de identidad. La segunda es operativa: vincula los datos del pasaporte de cada producto con el sistema central de la Comisión.
Fase 1: acceso y alta de la organización
Paso 1. Accede a la plataforma con EU Login
El Registro DPP está disponible en registry.product-passport.ec.europa.eu. Al entrar, el sistema te redirige automáticamente a EU Login, el servicio central de autenticación de la Comisión Europea.
Si ya tienes cuenta EU Login, introduces tus credenciales y accedes directamente. Si no la tienes, el proceso de creación es sencillo: nombre, correo electrónico, aceptación de la declaración de privacidad y confirmación por correo.
Un detalle práctico: si necesitas asociar el acceso al Registro a una dirección de correo diferente a la que ya usas para otros servicios de la UE, puedes crear una cuenta EU Login adicional.
Paso 2. Crea el perfil de tu organización
Una vez dentro, selecciona «Dar de alta una nueva organización» (Enrol New Organisation). La plataforma distingue entre dos tipos de entidad:
- Persona jurídica: cualquier empresa u organización legalmente constituida.
- Persona física: quien actúa como operador económico en nombre propio, por ejemplo, un importador autónomo.
Para personas jurídicas, los campos obligatorios son la razón social (el nombre legal registrado, no el nombre comercial), la dirección del domicilio legal (que debe coincidir con la que figura en el registro mercantil, no una dirección postal de correspondencia), el país de registro y el identificador de la entidad.
Sobre el identificador: el sistema acepta varios tipos, pero el preferido es el NTR (número de registro mercantil nacional). También se admiten el LEI (identificador de entidad jurídica), el número de IVA o un identificador electrónico eID. Para empresas españolas, el NTR es la opción más directa.
Además de los datos de la organización, hay que facilitar un contacto de cumplimiento normativo: una dirección de correo y un teléfono que las autoridades competentes puedan usar para cuestiones relacionadas con el registro de DPPs o el cumplimiento de productos. Estos datos no son públicos.
Paso 3. El proceso de verificación de la organización
Este es el paso central y el que más atención merece.
Una vez guardados los datos, solicitas la declaración PDF pulsando «Request Declaration». La Comisión Europea genera un documento PDF con los datos de tu organización y lo sella con su propio sello electrónico institucional. Ese documento lo descargas en tu equipo.
A partir de ahí, lo que ocurre fuera de la plataforma es lo más importante: el representante legal de la organización tiene que contrafirmar o contrasellar ese PDF. Y el instrumento que se utiliza tiene que ser cualificado bajo eIDAS:
- Si eres una persona jurídica: sello electrónico cualificado (QSeal) emitido por un QTSP.
- Si eres una persona física autónoma: firma electrónica cualificada (QES) emitida por un QTSP.
Hay un detalle importante que la propia guía oficial señala: la persona que crea la solicitud en la plataforma y la persona que firma la declaración no tienen que ser la misma. Si el administrador de la cuenta y el representante legal son personas distintas dentro de la organización, los datos que se facilitan en el formulario deben ser los de quien va a firmar.
Una vez sellado o firmado el PDF, lo cargas de vuelta al sistema y envías la solicitud. La plataforma verifica varios aspectos: que el documento no ha sido modificado después de que la Comisión lo selló, que el sello o firma de la organización alcanza el nivel cualificado, y que los datos del certificado coinciden con los datos de la organización que se dieron de alta.
El resultado puede ser tres cosas: en proceso (PROCESSING), correcto (SUCCESS) o fallido (FAILURE). Si es correcto, la organización queda verificada y quien la ha creado pasa a ser el administrador de la organización en el Registro. Si falla, el sistema genera un informe de errores que indica exactamente qué ha ido mal y qué hay que corregir.
Lo que invalida automáticamente la verificación
Hay tres situaciones que la plataforma rechaza sin excepción:
Primero, modificar el PDF después de descargarlo. La única alteración permitida es añadir el sello o la firma. Cualquier otro cambio, por mínimo que sea, invalida el documento sellado por la Comisión. Si eso ocurre, hay que reiniciar el proceso y solicitar una nueva declaración.
Segundo, usar un sello o firma que no alcance el nivel cualificado conforme a eIDAS. Un sello avanzado, un certificado de servidor o cualquier certificado que no figure como cualificado en la lista de confianza europea simplemente no pasa la validación.
Tercero, que los datos del certificado no coincidan con los de la organización registrada. Si la razón social, el identificador o el país de registro que contiene el QSeal no son exactamente los mismos que los que se introdujeron en el formulario, el sistema lo detecta y rechaza la solicitud.
Fase 2: el registro de los DPPs
Con la organización verificada, ya puedes empezar a inscribir pasaportes. El Registro DPP ofrece dos métodos.
Método 1. Formulario en línea (un DPP por envío)
Desde el menú lateral seleccionas «Registro de DPP» y eliges el grupo de productos al que pertenece el artículo. El sistema te pide que selecciones el nivel de granularidad del registro:
- Modelo: cubre todos los artículos que comparten las mismas especificaciones técnicas dentro de una familia de productos. Es la opción más adecuada cuando la información del DPP aplica de forma homogénea a toda la gama.
- Lote: aplica a todos los artículos fabricados en una misma tirada de producción. Útil cuando hay variaciones entre tiradas que conviene documentar.
- Artículo/unidad: identifica un producto individual concreto. Es el nivel más granular y el único disponible actualmente para baterías.
El dato obligatorio en cualquier caso es el identificador único de producto (UPI), que identifica de forma exclusiva a ese DPP. Debe ser una URL en formato HTTPS que cumpla las normas técnicas JTC 24 y que apunte a la ubicación donde están alojados los datos completos del pasaporte.
Lo que el Registro guarda no son los datos del pasaporte, sino ese UPI y el vínculo con los datos que el operador económico tiene bajo su control o bajo el control del prestador de servicios que haya designado.
Método 2. Carga de archivo (hasta 100 DPPs por envío)
Para volúmenes mayores, el sistema permite enviar varios DPPs a la vez mediante un archivo en formato XML o JSON. La plataforma facilita una plantilla para cada formato que sirve de punto de partida.
El límite es de 100 DPPs por envío. Hay que tener en cuenta algo relevante: si uno solo de los DPPs incluidos en el archivo contiene un error, el sistema rechaza la totalidad del envío. Conviene, por tanto, validar el archivo antes de cargarlo.
Qué pasa tras enviar
Cada solicitud de registro recibe un identificador de correlación. El estado puede consultarse en el panel de actividad de la plataforma. Cuando el registro es correcto (SUCCESS), el sistema devuelve el UPI, el identificador único de registro (URI) y el grupo de productos asociado. Si falla (FAILURE), muestra para cada DPP el UPI, el grupo de productos y la descripción específica del error.
El entorno de pruebas
Antes de operar en producción, la Comisión ha habilitado un entorno de pruebas accesible en registry.acc.product-passport.ec.europa.eu. Requiere una cuenta EU Login diferente a la de producción y los datos que se crean allí no se migran ni afectan al entorno real.
El proceso de verificación en pruebas es idéntico al de producción: necesitas datos válidos y el sello o firma cualificados. Esto conviene tenerlo en cuenta si la idea es usarlo como un «sandbox» sin consecuencias reales, porque tampoco es un proceso trivial.
Preguntas frecuentes (FAQ) sobre el registro DPP
No directamente. Primero tiene que verificarse la organización. El proceso lo inicia quien crea la cuenta EU Login, pero el PDF que se genera tiene que sellarlo o firmarlo el representante legal. Una vez verificada la organización, quien la ha creado pasa a ser el administrador y puede gestionar los permisos de otros usuarios.
No. La guía oficial lo aclara expresamente: quien crea la solicitud y quien firma la declaración pueden ser personas distintas. Lo que importa es que los datos introducidos en el formulario sean los del representante legal que va a firmar.
La verificación falla automáticamente. La única modificación permitida sobre el PDF generado por la Comisión es añadir el sello o la firma de la organización. Cualquier otro cambio invalida el documento y obliga a reiniciar el proceso solicitando una nueva declaración.
Porque no todos los sellos electrónicos son iguales. El Registro DPP exige nivel cualificado conforme a eIDAS y formato PAdES Baseline. Un sello electrónico estándar o avanzado, aunque funcione para otros usos, no alcanza ese nivel y el sistema lo rechaza con un mensaje de error específico.
El sistema rechaza la totalidad del envío. No procesa los DPPs correctos y descarta los erróneos por separado: o pasan todos o no pasa ninguno. Por eso conviene validar el archivo antes de cargarlo.
Sí. La Comisión ha habilitado un entorno de pruebas en registry.acc.product-passport.ec.europa.eu. El proceso de verificación es idéntico al de producción: necesitas datos válidos y un sello o firma cualificados reales. Lo que se crea allí no tiene efectos en el entorno real.
El UPI lo asigna el propio operador económico. Es una URL en formato HTTPS que apunta a donde están alojados los datos completos del pasaporte. El Registro guarda ese enlace, no los datos. El operador es responsable de que la URL esté siempre activa y accesible.
El UPI lo genera el operador económico y es el identificador del DPP. El URI lo genera el Registro DPP cuando la inscripción se completa con éxito: es el identificador del asiento dentro del sistema central de la Comisión. Son complementarios: el UPI apunta a los datos del pasaporte; el URI confirma que ese pasaporte está registrado oficialmente.
Qué necesitas tener resuelto antes de empezar
El proceso en la plataforma es relativamente guiado. El cuello de botella real está antes de entrar.
Para superar la verificación de la organización necesitas tener operativo un certificado de sello electrónico cualificado con los datos de tu entidad exactamente como figuran en el registro mercantil. Obtenerlo implica un proceso de verificación de identidad de la entidad que no es inmediato.
Si tu empresa todavía no dispone de ese certificado, ese es el primer paso. No el EU Login, no el formulario de datos de la organización: el sello.
¿Tienes dudas sobre qué tipo de certificado necesita tu empresa o cómo es el proceso de obtención? Te lo explicamos.
La entrada Cómo registrarse en el Pasaporte Digital de Producto: guía paso a paso se publicó primero en EADTrust.
]]>La entrada El Registro del Pasaporte Digital de Producto ya está operativo: qué significa para tu empresa se publicó primero en EADTrust.
]]>Llevamos meses hablando del DPP como algo que «viene». A partir de ahora viene siendo presente.
Conceptos sobre Registro del Pasaporte Digital de Producto
Registro DPP
Plataforma central de la Comisión Europea donde los operadores económicos verificados inscriben sus pasaportes digitales. No almacena los datos completos del pasaporte: guarda únicamente los identificadores únicos de cada producto y los enlaces hacia donde están alojados esos datos. Es de acceso gratuito.
Firma electrónica cualificada (QES)
Equivalente digital de la firma manuscrita de una persona física, con el mismo valor jurídico en toda la Unión Europea. Es la que se exige en el Registro DPP cuando quien se da de alta es una persona física que actúa como operador económico en nombre propio, por ejemplo, un importador autónomo.
Qué es el Registro del Pasaporte Digital de Producto
El Registro del Pasaporte Digital de Producto es la infraestructura central que la Comisión Europea ha construido para gestionar los pasaportes digitales de producto exigidos por el Reglamento (UE) 2024/1781 de Ecodiseño para Productos Sostenibles (ESPR).
Conviene aclarar desde el principio qué es y qué no es, porque hay mucha confusión en el sector.
El Registro no almacena todos los datos del pasaporte. Lo que hace es actuar como un índice autorizado a escala de la Unión Europea: contiene los identificadores únicos de producto (UPI) y los enlaces hacia donde están alojados los datos completos del DPP. Los datos del pasaporte en sí permanecen bajo el control del operador económico o del prestador de servicios que este designe.
Dicho de otro modo: el Registro es el directorio. El DPP es el expediente.
Esta distinción importa porque define también dónde recae la responsabilidad. El operador económico es quien crea, mantiene y responde de la exactitud de los datos durante todo el ciclo de vida del producto.
Quién puede registrar DPPs: el requisito de verificación
La primera condición que establece el Reglamento (UE) 2024/1781 es clara: solo los operadores económicos verificados pueden crear y gestionar pasaportes digitales de producto.
Operador económico, en el sentido de este reglamento, incluye al fabricante, al representante autorizado, al importador, al distribuidor, al comerciante y al prestador de servicios logísticos. En la práctica, cualquier empresa que coloque un producto en el mercado europeo entra en esta categoría.
Para quedar verificada, la organización tiene que acreditar su identidad y su derecho a representar a la entidad que está dando de alta. Y aquí es donde entra el elemento que muchas empresas no se esperaban, el certificado DPP.
El sello electrónico cualificado: el requisito que no es opcional
Al iniciar el proceso de verificación en el Registro, la Comisión Europea genera una declaración en PDF sellada con su propio sello institucional. Esa declaración contiene los datos de la organización que se quiere dar de alta.
Lo que ocurre a continuación es determinante.
Ese documento debe ser contrafirmado o contrasellado digitalmente fuera del sistema, y el instrumento que se exige depende del tipo de entidad:
- Si la organización es una persona jurídica (una empresa, una entidad legalmente constituida), el documento debe sellarse mediante un sello electrónico cualificado (QSeal) emitido por un prestador cualificado de servicios de confianza (QTSP).
- Si el operador es una persona física que actúa como empresario individual, el documento debe firmarse con una firma electrónica cualificada (QES) emitida igualmente por un QTSP.
Esto no es una recomendación de buenas prácticas. Es el requisito técnico del sistema: si el sello o la firma no alcanzan el nivel cualificado conforme al Reglamento eIDAS, la verificación falla y la organización queda sin acceso al Registro.
La propia guía de usuario DPP publicada por DG GROW lo recoge con esta literalidad: «Un QTSP es una organización acreditada y autorizada para emitir certificados cualificados. Las firmas realizadas con sus certificados cumplen requisitos jurídicos superiores.»
Por qué el nivel cualificado es el único que funciona
Existe la tentación de intentar resolver esto con un sello digital convencional, con una firma avanzada o con un certificado de servidor que ya se tiene contratado para otros usos. El sistema del Registro no lo acepta.
Los errores que devuelve la plataforma cuando el sello no cumple los requisitos son muy explícitos:
- «El sello de la organización no alcanza el nivel de sello electrónico cualificado (QSeal) exigido. Las personas jurídicas deben utilizar un sello electrónico cualificado.»
- «El nivel de cualificación del certificado no ha podido establecerse porque no contiene los atributos eIDAS necesarios. Póngase en contacto con su QTSP.»
- «La firma o sello de la organización no se ajusta al formato PAdES Baseline exigido.»
En todos estos casos, el sistema rechaza la solicitud. La organización no queda verificada. Y sin verificación, no puede registrar ningún DPP.
La diferencia entre un sello cualificado y uno que no lo es no es solo técnica: es jurídica. Un sello electrónico cualificado bajo eIDAS goza de presunción legal de integridad de los datos y de corrección del origen. Ningún otro tipo de sello ofrece esa garantía ante una autoridad de vigilancia del mercado.
Qué supone esto para las empresas en la práctica
El Registro acaba de abrir con las baterías como primer grupo de productos habilitado para registro, en consonancia con la obligatoriedad del pasaporte de batería prevista para febrero de 2027 bajo el Reglamento (UE) 2023/1542. El despliegue a otros grupos de productos (textiles, acero, aluminio, muebles, construcción y más) se irá produciendo conforme se aprueben los actos delegados del ESPR.
Pero lo que el Registro exige para entrar, el sello electrónico cualificado, es el mismo para todos los sectores. No va a cambiar según el tipo de producto. Es una condición de acceso a la infraestructura, no un requisito sectorial.
Esto significa que las empresas que quieran estar listas cuando llegue la obligatoriedad para su categoría de producto tienen que resolver esta pieza ahora. No en 2028. No cuando aprueben el acto delegado de su sector.
Obtener un certificado cualificado de sello electrónico conlleva un proceso de verificación de identidad de la entidad, de comprobación de la inscripción registral y de la representación legal. No es algo que se despacha en un formulario online en diez minutos.
Qué es un QTSP y por qué importa estar en la lista de confianza
Un prestador cualificado de servicios de confianza, o QTSP por sus siglas en inglés, es una organización supervisada por la autoridad competente de un Estado miembro y reconocida formalmente en la lista de confianza europea conforme al marco eIDAS.
Esta condición no es cosmética. La lista de confianza europea, accesible en eidas.ec.europa.eu/efda/trust-services/browse/eidas/tls, recoge los QTSP de todos los Estados miembros y del Espacio Económico Europeo. Un sello emitido por un QTSP inscrito en esa lista es reconocido automáticamente como cualificado en todos los Estados miembros. Un sello emitido fuera de ella, no.
El Registro DPP valida contra esa lista. Si el certificado utilizado no aparece como cualificado, la verificación falla.
Preguntas Frecuentes (FAQ) sobre el Registro DPP
Depende del sector. El primer grupo de productos habilitado son las baterías, con obligatoriedad de pasaporte digital prevista para febrero de 2027. El resto de sectores (textiles, acero, aluminio, muebles, construcción, etc.) irán incorporándose conforme se aprueben los actos delegados del ESPR. Sin embargo, el requisito de verificación con sello cualificado es el mismo para todos. Las empresas que quieran estar listas sin prisas tienen que gestionar ese certificado antes de que la obligatoriedad llegue a su sector.
No. La Comisión Europea no prevé ninguna cuota de suscripción para acceder o utilizar el Registro. Lo que sí tiene coste es obtener el certificado de sello electrónico cualificado necesario para verificarse, que es un servicio prestado por QTSPs como EADTrust.
No. El Registro DPP exige explícitamente un sello electrónico cualificado (QSeal) conforme al Reglamento eIDAS, emitido por un QTSP que figure en la lista de confianza europea. Un sello digital estándar, un certificado SSL/TLS de servidor o una firma avanzada no superan la validación del sistema.
Sí. Uno de los objetivos del nivel «cualificado» bajo eIDAS es precisamente la interoperabilidad y el reconocimiento transfronterizo. Un sello emitido por un QTSP inscrito en la lista de confianza de cualquier Estado miembro es reconocido automáticamente como cualificado en todos los Estados miembros.
El primer sector con obligatoriedad real es el de baterías, con el pasaporte de batería previsto para febrero de 2027. A ese le seguirán textiles, acero, aluminio, muebles, construcción y otros, en función de los plazos que establezcan los actos delegados que la Comisión Europea vaya aprobando.
El momento de prepararse es este
Hemos construido durante años servicios de confianza cualificados conforme al Reglamento eIDAS. Los sellos electrónicos DPP de entidad que emitimos permiten a las personas jurídicas acreditar su identidad digital con el nivel de garantía que exige el mercado europeo y, ahora, el Registro del Pasaporte Digital de Producto.
Si tu empresa va a necesitar registrar DPPs, el primer paso es obtener ese sello. Para eso estamos.
¿Tienes dudas sobre qué tipo de certificado necesita tu empresa o cómo funciona el proceso de obtención? Consúltanos y te lo explicamos.
La entrada El Registro del Pasaporte Digital de Producto ya está operativo: qué significa para tu empresa se publicó primero en EADTrust.
]]>La entrada ¿A qué productos afecta el ESPR? se publicó primero en EADTrust.
]]>Eso es una ruptura respecto a todo lo que vino antes. La Directiva de Ecodiseño que el ESPR deroga (la 2009/125/CE) solo cubría los productos relacionados con la energía, es decir, aquellos cuya utilización tiene un impacto en el consumo energético. El ESPR elimina ese límite. Textiles, muebles, acero, aluminio, pinturas, detergentes, materiales de construcción: todos ellos pueden recibir requisitos de diseño ecológico a través de actos delegados del ESPR, algo que era imposible bajo el marco anterior.
La pregunta relevante no es «¿entra mi sector en el ESPR?», sino «¿cuándo llegan las obligaciones concretas para mi sector y qué forma tomarán?». Para responderla, hay que entender cómo funciona el sistema.
La mecánica del ESPR: el Reglamento como marco, los actos delegados como obligaciones concretas
El ESPR no establece directamente los requisitos técnicos para ningún producto. Lo que establece es el marco legal y el mecanismo: la Comisión adopta actos delegados, grupo de producto a grupo de producto, que fijan los requisitos concretos de durabilidad, reparabilidad, contenido reciclado, huella de carbono y demás parámetros.
Esto tiene una consecuencia práctica importante: que un producto entre en el ámbito teórico del ESPR no significa que tenga obligaciones de ecodiseño hoy. Las tendrá cuando se adopte el acto delegado correspondiente a su grupo. Sin acto delegado, no hay requisitos técnicos exigibles. Con acto delegado, hay un mínimo de dieciocho meses entre la adopción del acto y su fecha de aplicación.
Hay una excepción importante a esta lógica: algunas obligaciones del ESPR no esperan a los actos delegados. La prohibición de destruir prendas de vestir, accesorios y calzado no vendidos ya es aplicable desde el 19 de julio de 2026 para grandes empresas, sin necesidad de ningún acto delegado adicional. Las obligaciones de divulgación sobre destrucción de productos no vendidos también son directamente aplicables.
El ESPR tiene dos velocidades: las obligaciones que vienen directamente del texto del Reglamento (la prohibición de destrucción, la transparencia) y las obligaciones técnicas de ecodiseño (durabilidad, reparabilidad, contenido reciclado) que llegarán vía actos delegados a medida que la Comisión los adopte según el Plan de Trabajo 2025-2030.
Qué productos entran en el ámbito del ESPR: la regla general
El artículo 1 del Reglamento es el punto de partida: el ESPR es aplicable a todo bien físico que se introduzca en el mercado o se ponga en servicio, incluidos los componentes y los productos intermedios.
Esta definición tiene tres implicaciones que conviene explicitar.
Primera: cubre productos terminados y productos intermedios. Un rollo de tela que un fabricante de ropa compra a un proveedor textil puede tener requisitos de contenido reciclado bajo el ESPR, aunque nunca llegue directamente al consumidor.
Segunda: cubre todos los canales de comercialización, incluyendo la venta en línea. Un producto ofrecido en un sitio web que se dirige al mercado europeo está sujeto al ESPR independientemente de dónde esté establecido el operador que lo vende.
Tercera: no requiere que el producto consuma energía. Este es el cambio estructural respecto a la Directiva anterior. Muebles, ropa, materiales de construcción, pinturas: ninguno de ellos «consume energía» en el sentido habitual, pero todos entran en el ámbito del ESPR.
Qué productos quedan fuera: las exclusiones expresas
El Reglamento establece exclusiones concretas que reducen el ámbito de aplicación. No son muchas, pero conviene conocerlas.
Productos destinados exclusivamente a la defensa o la seguridad nacionales
El considerando 23 del ESPR explica la razón: existe determinada información relativa a los equipos de defensa que no debe divulgarse. Por lo tanto, no deben estipularse requisitos de diseño ecológico para productos cuyo único propósito sea el de servir a la defensa o la seguridad nacionales. La exclusión es para productos de uso exclusivamente militar o de seguridad: un producto de uso dual (civil y militar) no queda automáticamente excluido.
Productos espaciales y tecnologías espaciales
El considerando 23 también los menciona expresamente: la industria espacial es estratégica para Europa y su independencia tecnológica. Como las tecnologías espaciales funcionan en condiciones extremas, los requisitos de diseño ecológico deben compensar las consideraciones en materia de sostenibilidad con aspectos de resiliencia y rendimiento esperado. Las tecnologías espaciales pueden seguir siendo reguladas, pero los actos delegados deben equilibrar sostenibilidad con las exigencias operativas.
Productos para los que la Comisión determina que los requisitos de ecodiseño no son adecuados
El Reglamento permite a la Comisión, al adoptar un acto delegado para un grupo de producto, declarar que determinados parámetros no necesitan requisitos concretos para ese grupo. Pero el artículo 4, apartado 3 es explícito: los poderes de la Comisión no incluyen la posibilidad de adoptar un acto delegado que disponga que no resultan necesarios los requisitos de diseño ecológico para un grupo de productos en su totalidad. En otras palabras: la Comisión puede decidir que un parámetro concreto no necesita requisito, pero no puede eximir a un grupo entero del ESPR.
Los grupos prioritarios del Plan de Trabajo 2025-2030
El hecho de que el ESPR se aplique a casi todos los bienes físicos no significa que todos los sectores tengan obligaciones al mismo tiempo. El Plan de Trabajo de Ecodiseño y Etiquetado Energético 2025-2030, adoptado el 16 de abril de 2025, establece los grupos de producto que recibirán actos delegados en los próximos cinco años y el orden en que llegarán.
El artículo 18 del ESPR establece que el primer plan de trabajo debía dar prioridad a grupos específicos enumerados en el propio Reglamento. Estos son los grupos que el Reglamento nombra explícitamente como prioritarios:
- Hierro y acero
- Aluminio
- Productos textiles, en particular prendas de vestir y calzado
- Muebles, incluidos los colchones
- Neumáticos
- Detergentes
- Pinturas
- Lubricantes
- Productos químicos
- Productos relacionados con la energía para los que deban establecerse por primera vez requisitos o para los que las medidas existentes adoptadas en virtud de la Directiva 2009/125/CE deban revisarse
- Productos de tecnología de la información y la comunicación y otros artículos electrónicos
El Plan de Trabajo puede apartarse de esta lista, pero si lo hace la Comisión debe justificar su decisión. En la práctica, el primer Plan de Trabajo incluyó los cuatro primeros grupos (acero, aluminio, textiles y neumáticos) con plazos concretos, y dejó fuera detergentes, pinturas, lubricantes y productos químicos por tener menor potencial de mejora, aplazándolos para el siguiente ciclo.
Tabla: estado actual de los principales grupos de producto bajo el ESPR
| Grupo de producto | Estado en el ESPR (mayo 2026) | Acto delegado estimado | DPP estimado |
| Electrodomésticos con etiqueta energética (neveras, lavadoras, lavavajillas, etc.) | En revisión bajo el ESPR; actos delegados anteriores (Directiva 2009/125/CE) vigentes hasta 31/12/2026 para grupos A y B | 2026 (revisión) | Sin DPP adicional si EPREL cubre la información |
| Hierro y acero | Acto delegado en preparación; primero del Plan de Trabajo 2025-2030 | ~2026 | ~2027/2028 |
| Prendas de vestir y textil | En el Plan de Trabajo; prohibición de destrucción de stocks ya vigente para grandes empresas desde julio 2026 | ~2027 | ~2028/2029 |
| Aluminio | En el Plan de Trabajo 2025-2030 | ~2027 | ~2028/2029 |
| Neumáticos | Ya en EPREL para etiquetado energético; requisitos de sostenibilidad adicionales en el Plan de Trabajo | ~2027 | ~2028/2029 |
| Electrónica y pequeños electrodomésticos (reparabilidad horizontal) | En el Plan de Trabajo como medida horizontal | ~2027 | ~2028/2029 |
| Muebles | En el Plan de Trabajo 2025-2030 | ~2028 | ~2029/2030 |
| Colchones | En el Plan de Trabajo 2025-2030 | ~2029 | ~2030/2031 |
| Detergentes, pinturas, lubricantes | Excluidos del primer Plan de Trabajo; previstos para el siguiente ciclo post-2030 | Post-2030 | Post-2031 |
| Calzado | Estudio exploratorio previsto para finales de 2027; prohibición de destrucción ya vigente | Post-2030 (si estudio favorable) | Post-2031 |
| Productos para defensa/seguridad exclusiva | Excluidos del ámbito del ESPR | No aplica | No aplica |
¿Qué obligaciones llegan antes del acto delegado?
Algunos grupos tienen obligaciones del ESPR que ya son aplicables aunque no haya acto delegado de ecodiseño todavía. El caso más relevante es el sector textil y del calzado:
Desde el 19 de julio de 2026, las grandes empresas tienen prohibido destruir prendas de vestir, accesorios y calzado no vendidos. Esto incluye también los productos devueltos por consumidores en ejercicio del derecho de desistimiento. La prohibición se extiende a las medianas empresas en 2030. Las microempresas y pequeñas empresas están exentas.
Paralelamente, las empresas obligadas deben divulgar públicamente cada año el número y peso de los productos desechados, los motivos del desecho y las medidas adoptadas para evitarlo. Esta obligación aplica a las grandes empresas desde el primer ejercicio completo en que el ESPR esté en vigor.
Estas dos obligaciones, prohibición de destrucción y divulgación, son directamente aplicables desde el texto del Reglamento y no dependen de ningún acto delegado.
¿Cómo saber si tu producto específico está dentro o fuera?
La lógica de verificación es secuencial y tiene tres preguntas.
- Primera: ¿Es un bien físico que se introduce en el mercado europeo o se pone en servicio? Si la respuesta es sí, el producto entra en el ámbito teórico del ESPR.
- Segunda: ¿Está excluido expresamente? Los únicos productos excluidos son los destinados exclusivamente a la defensa o seguridad nacionales y las tecnologías espaciales con las características descritas en el Reglamento. Si no está excluido, sigue estando dentro.
- Tercera: ¿Existe ya un acto delegado del ESPR para su grupo de producto? Si sí, las obligaciones técnicas ya son aplicables o lo serán a partir de la fecha indicada en el acto. Si no, las obligaciones técnicas aún no existen, pero pueden llegar en cualquier momento a través del Plan de Trabajo y los sucesivos actos delegados. La trampa está en la tercera pregunta. Muchas empresas de sectores como mueble, calzado o detergentes consideran que si no hay acto delegado todavía, el ESPR «no les afecta». Eso es incorrecto en dos sentidos: primero, porque algunas obligaciones directas del Reglamento, como la prohibición de destrucción en el textil, ya aplican sin acto delegado. Segundo, porque los actos delegados llegarán, y entre su adopción y su fecha de aplicación solo hay dieciocho meses. Eso no es tiempo suficiente para construir desde cero la arquitectura de datos que el Pasaporte Digital de Producto requiere.
Preguntas frecuentes sobre productos ESPR
No directamente. El ESPR establece requisitos de diseño para la producción de productos nuevos, no para la comercialización de productos usados dentro del mercado europeo. Sin embargo, los productos de segunda mano importados de terceros países pueden quedar sujetos en determinadas circunstancias.
No. El ESPR se aplica exclusivamente a bienes físicos. Los servicios digitales, el software y los contenidos digitales no son «productos» en el sentido del Reglamento.
Los productos de construcción tienen su propio Reglamento europeo (el (UE) 2024/3110, adoptado en noviembre de 2024), que también introduce el Pasaporte Digital de Producto para esa categoría. El ESPR puede aplicarse a productos de construcción de forma complementaria si no quedan excluidos expresamente por el acto delegado correspondiente.
De momento, no tiene obligaciones de ecodiseño bajo el ESPR: esos grupos fueron excluidos del primer Plan de Trabajo. Pero deben seguir el proceso regulatorio porque la Comisión ha anunciado que serán objeto de análisis exploratorios para el siguiente ciclo, y la prohibición de destrucción de productos no vendidos puede aplicarles si son bienes de consumo incluidos en el Anexo VII del Reglamento.
Los juguetes no aparecen expresamente en la lista de grupos prioritarios del Plan de Trabajo 2025-2030, pero el nuevo Reglamento de Seguridad de los Juguetes, previsto para 2025, incluirá su propio DPP, con adopción estimada para ~2029-2030.
¿Tu empresa ya sabe cuándo le llegan las obligaciones del ESPR?
El ESPR no es un riesgo futuro para los sectores que todavía no tienen acto delegado: es un riesgo presente que requiere planificación. Los ciclos de diseño de producto, la arquitectura de datos para el DPP y los contratos con proveedores que permitan recoger la información de sostenibilidad necesaria no se construyen en dieciocho meses. Se construyen ahora.
En EADTrust trabajamos con fabricantes e importadores que operan en el ecosistema regulatorio europeo: desde la verificación en EPREL con sello cualificado NTR hasta los servicios de confianza eIDAS que la infraestructura del DPP va a requerir.
También te puede interesar…
La entrada ¿A qué productos afecta el ESPR? se publicó primero en EADTrust.
]]>