Archivo de la categoría: Custodia digital

De las tablillas cuneiformes al Cartulario: historia de la contabilidad y origen de las RJT


Llevamos más de cinco mil años intentando resolver el mismo problema: dejar constancia fiable de quién tiene qué, quién debe qué y en qué orden ocurrieron las cosas. Las tablillas de arcilla de Mesopotamia, los libros de los mercaderes venecianos, las tarjetas de pago y lo que hoy llamamos blockchain son respuestas sucesivas a esa necesidad.

En este artículo recorro esa historia para defender una idea que ya he planteado otras veces: quien sabe un poco de contabilidad entiende enseguida que lo que estas tecnologías replican es un libro diario (journal), no un libro mayor (ledger). Y que buena parte de lo que se atribuye a blockchain puede conseguirse combinando firma electrónica y un registro fehaciente, también en un servidor centralizado.

Fichas, bullas y tablillas: contar ovejas en arcilla

La escritura nació, en buena medida, para llevar las cuentas. Según la tesis de la arqueóloga Denise Schmandt-Besserat, desde el VIII milenio a. C. se usaban en Oriente Próximo pequeñas fichas de arcilla (tokens) de distintas formas: cada forma representaba un tipo de bien (una oveja, una medida de grano, una jarra de aceite) y cada ficha, una unidad.

Hacia el 3500 a. C. aparece una innovación notable: las fichas de una operación se guardaban dentro de una bulla, una esfera hueca de arcilla que se sellaba. Para saber qué contenía sin romperla, se imprimían las fichas en su superficie antes de cerrarla. Era ya un mecanismo de integridad: el contenido sellado podía cotejarse con su «resumen» exterior, y cualquier manipulación exigía romper el sello.

Con el tiempo sobraron las fichas y bastaron las marcas: así surgieron las tablillas protocuneiformes de Uruk (hacia 3300-3000 a. C.), de contenido mayoritariamente administrativo. Un pastor que recibía un rebaño del templo quedaba anotado con el número de ovejas, cabras y corderos a su cargo, y después se le exigía cuenta de las crías, la lana y las bajas. En la época de Ur III (hacia 2100-2000 a. C.), el gran centro ganadero de Puzrish-Dagan (Drehem) dejó decenas de miles de tablillas con entradas y salidas diarias de animales, con su fecha y el funcionario responsable.

Ahí están ya los ingredientes que reaparecerán en toda esta historia: un asiento por cada hecho, una fecha, un responsable, un sello que impide la alteración y un archivo que conserva la prueba.

De Roma a Venecia: los precursores de la partida doble

Durante siglos la contabilidad fue de partida simple: una lista de cobros y pagos, o de deudas a favor y en contra. Los romanos distinguían ya entre los apuntes provisionales del día (adversaria) y el libro definitivo de ingresos y gastos (codex accepti et expensi). Es un primer esbozo de la separación entre lo que se anota cronológicamente y lo que se ordena para su consulta.

El salto llega con el comercio italiano de la Baja Edad Media. Ayudaron dos cosas: la difusión de los números indoarábigos, impulsada por el Liber Abaci de Fibonacci (1202), y unas sociedades mercantiles con socios, corresponsales y crédito a distancia. Llevar las cuentas con números romanos era penoso; sumar columnas con cifras posicionales, no.

Los primeros rastros de doble anotación aparecen en la Toscana y en Liguria:

  • Florencia: las cuentas de la compañía de Rinieri Fini y sus hermanos (1296) ya registran cada operación en dos lados.
  • Provenza: los libros de la compañía Farolfi (1299-1300), florentina, muestran un sistema muy completo.
  • Génova: los libros de los massari (tesoreros) del Comune de 1340 se consideran el primer ejemplo plenamente desarrollado de partida doble.

Venecia perfeccionó el método y le dio nombre: alla veneziana. Los libros de los hermanos Soranzo (1406-1434) ya presentan la tríada de borrador, diario y mayor que luego se describirá por escrito. En 1458 el mercader ragusino Benedetto Cotrugli explicó la partida doble en Della mercatura e del mercante perfetto, aunque su obra no se imprimió hasta 1573. El método estaba en uso; faltaba un libro impreso que lo enseñase.

Luca Pacioli y la formalización (1494)

Ese libro llegó en 1494. El fraile franciscano y matemático Luca Pacioli, amigo de Leonardo da Vinci, publicó en Venecia la Summa de arithmetica, geometria, proportioni et proportionalità, impresa por Paganino Paganini. Uno de sus tratados, Particularis de computis et scripturis, describe el método veneciano con detalle práctico.

Pacioli no inventó la partida doble, pero la sistematizó y, gracias a la imprenta, la difundió por Europa. Describe tres libros:

  1. El memorial (memoriale): borrador donde se anota todo tal como ocurre.
  2. El diario (giornale): los asientos en orden cronológico, ya depurados, con su cargo y su descargo.
  3. El mayor (quaderno): las mismas partidas reordenadas por cuentas, con un índice alfabético.

Recomienda además cerrar el ejercicio comprobando que la suma de lo cargado coincide con la de lo abonado. Si no coincide, hay un error que buscar.

En España la partida doble llegó pronto a la ley. La Pragmática de Cigales de 1549 obligó a mercaderes y banqueros a llevar sus cuentas en libro de caja con su manual «por debe y ha de haber». El primer tratado en castellano fue el Libro de caxa y manual de cuentas de mercaderes de Bartolomé Salvador de Solórzano (1590).

El principio de la partida doble: una suma de comprobación de cinco siglos

La regla es sencilla: todo hecho económico se anota dos veces, en el debe de una o varias cuentas y en el haber de otras, por el mismo importe. No hay deudor sin acreedor: lo que entra en una cuenta sale de otra.

Si un ganadero compra 100 ovejas a 50 € cada una y paga por transferencia, el asiento es este:

N.ºFechaCuentaDebe (€)Haber (€)
13 de marzoGanado (activo)5.000
13 de marzoBancos (activo)5.000

Como cada asiento cuadra, la suma de todos los cargos del ejercicio debe ser igual a la de todos los abonos. Si no lo es, hay un error de suma, de transcripción o de traspaso. Esa igualdad es un control de integridad incorporado al propio método: no hace falta otra fuente para saber que algo falla.

Es el mismo principio que siglos después usará la informática: añadir redundancia calculada para detectar alteraciones. Son de la misma familia la prueba del nueve (ya conocida por los maestros de ábaco), los dígitos de control de los números de cuenta (el IBAN usa un módulo 97), las sumas de paridad y los CRC (Cyclic Redundancy Check), propuestos por W. Wesley Peterson en 1961 para detectar errores de transmisión.

También comparten limitaciones. El cuadre contable no detecta un asiento omitido entero, un importe erróneo anotado igual en ambos lados ni errores que se compensan. Un CRC detecta errores accidentales, pero cualquiera puede recalcularlo tras modificar los datos. Contra la manipulación intencionada hacen falta otras herramientas: funciones hash criptográficas, sellos de tiempo y firma electrónica. A ellas llegaremos.

Libro diario, libro mayor y los estados que se derivan de ellos

Conviene fijar bien esta distinción, porque es la clave del resto del artículo:

  • El libro diario (journal) registra los asientos en orden cronológico, numerados y fechados, tal como suceden. Es la fuente primaria. Un asiento ya anotado no se borra: si hay un error, se corrige con un contraasiento posterior.
  • El libro mayor (ledger) reordena esas mismas partidas por cuentas (Caja, Bancos, Clientes, Ganado…), normalmente en forma de «cuentas en T» con su debe y su haber. Se obtiene «pasando» los asientos del diario. No añade información: es una vista derivada que permite conocer el saldo de cada cuenta.

El legislador español lo tiene claro. El Código de Comercio (arts. 25 a 28) exige una contabilidad ordenada que permita «un seguimiento cronológico de todas sus operaciones» y obliga a llevar el libro diario y el de inventarios y cuentas anuales, que se legalizan en el Registro Mercantil. El mayor no es obligatorio: siempre puede reconstruirse desde el diario. Lo que tiene valor probatorio es el orden cronológico.

A partir del diario y del mayor se elaboran los estados contables:

EstadoQué muestraPara qué sirve
Balance de comprobación de sumas y saldosSumas del debe y del haber, y saldo, de cada cuentaVerificar que cargos y abonos cuadran antes del cierre
Balance (de situación)Activo, pasivo y patrimonio neto en una fechaSaber qué se tiene y qué se debe: activo = pasivo + patrimonio neto
Cuenta de pérdidas y gananciasIngresos y gastos del ejercicioConocer el resultado (beneficio o pérdida)
Estado de flujos de efectivoCobros y pagos por actividades de explotación, inversión y financiaciónEntender la liquidez, que no coincide con el resultado

La informática no cambió el método, pero sí su manejo. VisiCalc (1979), de Dan Bricklin y Bob Frankston, llevó a la pantalla la hoja de cálculo cuadriculada de los contables. Después llegaron Lotus 1-2-3 (1983) y Excel (1985). Con ellas se popularizaron las previsiones de tesorería y los modelos de flujos de caja, que permiten simular escenarios antes de que ocurran.

Antes de 2009: del cheque al Hashcash

Si la contabilidad resolvió cómo anotar el valor, los medios de pago intentaron resolver cómo moverlo sin mover monedas. Antes de que apareciera Bitcoin, el siglo XX ya había probado casi todas las piezas:

  • Tarjetas de pago. Diners Club lanzó en 1950 la primera tarjeta de uso general. Le siguieron BankAmericard (1958), germen de Visa, y Master Charge (1966), luego Mastercard. Detrás de cada pago hay un apunte en los libros del emisor y del adquirente, conciliados por la red.
  • Transferencias. Las redes interbancarias sustituyeron el envío físico de órdenes. SWIFT se fundó en 1973 y empezó a operar en 1977. En Europa, la transferencia SEPA arrancó en 2008.
  • Adeudos (domiciliaciones). El acreedor inicia el cobro con autorización previa del deudor, que conserva el derecho a devolverlo. Los adeudos directos SEPA llegaron en noviembre de 2009.
  • Dinero electrónico criptográfico. David Chaum propuso en 1982 las firmas ciegas para pagos no rastreables y fundó DigiCash en 1989. Le siguieron e-gold (1996), b-money de Wei Dai (1998) y bit gold de Nick Szabo.
  • Sellado de tiempo encadenado. Stuart Haber y W. Scott Stornetta publicaron en 1991 cómo encadenar documentos mediante hash para que no pudieran antedatarse. Tres de las ocho referencias del artículo de Bitcoin son suyas.

En España también hubo precursores. En 2002, con el impulso del Ministerio de Ciencia y Tecnología, se desarrolló el proyecto PISTA – FIRMA – Títulos cambiarios electrónicos, en el que participé desde FESTE, donde era director general, junto a Banc Sabadell y Roca Junyent, entre otros. Su objetivo era gestionar letras de cambio desmaterializadas y endosables. Para ello combinaba firma electrónica, una entidad de timbrado y una Fuente de Verdad centralizada que impedía que un mismo título se endosara o cobrara dos veces. A eso lo llamábamos «unicidad de fin»: es el mismo problema que Bitcoin resolvería después con el nombre de «doble gasto». Lo conté en «Antecedentes de Blockchain en España».

La pieza más curiosa nació contra el correo basura. En 1992 Cynthia Dwork y Moni Naor propusieron «cobrar» a cada remitente un pequeño esfuerzo de cálculo. En 1997 Adam Back presentó Hashcash: para enviar un correo había que encontrar un valor cuyo hash empezase por un número determinado de ceros. Costaba una fracción de segundo a un remitente legítimo, pero hacía carísimo enviar millones de mensajes. Hal Finney lo reutilizó en 2004 en sus Reusable Proofs of Work.

Satoshi Nakamoto convirtió esa «prueba de trabajo» en el mecanismo para decidir quién añade el siguiente bloque. El artículo de Bitcoin se publicó el 31 de octubre de 2008 y el bloque génesis se minó el 3 de enero de 2009. Casi nada era nuevo: lo nuevo fue la combinación.

¿DLT o RJT? Lo que se replica es un diario

A estas tecnologías se las llamó pronto DLT (Distributed Ledger Technology), y así las nombra la normativa europea. El Reglamento eIDAS 2 regula en su artículo 45 terdecies los registros electrónicos cualificados. La traducción oficial al español habla de libros mayores electrónicos, y así se titula también el Reglamento de Ejecución (UE) 2025/2531, que fija sus normas de referencia. Expliqué ese marco en la entrada sobre la conservación cualificada y los servicios cualificados con orden cronológico (qDLT).

Con la contabilidad en la mano, el nombre chirría. Una cadena de bloques es una sucesión de asientos en orden cronológico, cada uno enlazado con el anterior mediante su hash, que no se borran y solo se corrigen con anotaciones posteriores. Eso es exactamente un libro diario. El «mayor» (los saldos de cada dirección, el conjunto de salidas no gastadas de Bitcoin o el estado de un contrato inteligente) no se transmite: cada nodo lo calcula recorriendo el diario, igual que un contable pasa los asientos a las cuentas.

Por eso propuse hace años hablar de RJT (Replicated Journal Technology), como expliqué en «RJT – Replicated Journal Technologies. Cómo llamar a Blockchain» y en «No es DLT: es RJT, o mejor, simplemente Blockchain» (2019). Las dos palabras importan:

  • Journal (diario), porque lo que se conserva y se protege es el orden cronológico de los hechos, que es lo que tiene valor probatorio.
  • Replicated (replicado), mejor que «distribuido», porque cada nodo tiene una copia completa e idéntica. No hay fragmentos repartidos, sino réplicas que deben coincidir.

En aquel artículo de 2019 señalé que «DLT» solo encaja con los usos que registran valores contabilizables y deja fuera piezas esenciales como la firma electrónica. Concluí entonces que, para nombrar el conjunto, lo más práctico era seguir diciendo simplemente blockchain. Hoy no lo tengo tan claro: sigue faltando un término que agrupe la firma electrónica y el registro donde residen la autenticidad y la historia de los documentos, sin atarlo a una cadena de bloques. Más abajo propongo uno.

Seguiré usando DLT y «libro mayor electrónico» cuando me refiera a la norma, porque son sus términos oficiales. Pero quien haya llevado alguna vez un diario y un mayor entenderá por qué RJT describe mejor lo que hace la tecnología.

Blockchain son dos técnicas que van juntas

Si se quita el ruido, bajo la etiqueta blockchain hay dos técnicas que se necesitan mutuamente.

1. La firma electrónica. Cada transacción va firmada con la clave privada de quien la ordena (en Bitcoin, con ECDSA sobre la curva secp256k1). La firma acredita quién autoriza el movimiento y garantiza que el contenido no se ha alterado. Es la misma función que cumple la firma del comerciante en su libro, o la del otorgante ante notario.

2. Una fuente de verdad. Firmar no basta: hay que saber qué operación vale cuando dos se contradicen (el «doble gasto», o la «unicidad de fin» de PISTA) y en qué orden ocurrieron las cosas. Hace falta un registro único y ordenado que todos acepten como referencia.

Los notarios resolvieron este segundo problema hace mucho con el protocolo notarial. El notario conserva el documento matriz (la escritura original firmada), lo incorpora a su protocolo en orden cronológico y con numeración correlativa, y entrega copias a los interesados. La copia hace fe porque puede cotejarse con la matriz, que no sale de la notaría. Si dos copias discrepan, manda la matriz.

Una cadena de bloques hace lo mismo sin una notaría: el mecanismo de consenso (la prueba de trabajo, en Bitcoin) decide cuál es la «matriz» que todos los nodos replican. Ese consenso es caro y lento precisamente porque sustituye a un tercero de confianza que no existe.

Cuando ese tercero sí existe, como un prestador cualificado de servicios de confianza supervisado, la fuente de verdad puede mantenerse en un servidor centralizado. Se combinan firmas y sellos electrónicos, sellos de tiempo y encadenamiento de hash, y se obtienen las mismas garantías de integridad y orden con mucho menos coste. He tratado su aplicación a la Justicia en Judiciary Blockchain, por ejemplo en «eIDAS 2.0: el reconocimiento europeo de los registros electrónicos con orden cronológico» y en «Unicidad de fin en el documento electrónico».

Una propuesta: SJT, Signed Journal Technology

Si lo esencial son esas dos piezas, el nombre debería decirlas. Propongo SJT (Signed Journal Technology, tecnología de diario de asientos firmados): un diario que conserva la historia de los hechos en orden cronológico y actúa como fuente de verdad, y una firma electrónica que acredita la autenticidad e integridad de cada asiento: lo firma su autor, y el operador lo sella en el tiempo y lo encadena con los anteriores. El término no exige bloques, ni réplicas, ni un mecanismo de consenso concreto.

Con él, los términos dejan de competir y se ordenan:

  • SJT: firma electrónica + diario que actúa como fuente de verdad.
    • SJT centralizada: un prestador de confianza mantiene la fuente de verdad. Es el caso de PISTA en 2002 o del Cartulario hoy.
    • SJT replicada, que es lo que he llamado RJT: la fuente de verdad se decide por consenso entre nodos con copias idénticas.
      • Blockchain: una RJT concreta, que agrupa los asientos en bloques encadenados por hash.

En un texto jurídico, el equivalente en español podría ser diario fehaciente, que recoge a la vez la autenticidad, el orden y el valor probatorio.

Un diario fehaciente en un servidor centralizado: el Cartulario de EADTrust

En la Edad Media, monasterios, catedrales y concejos copiaban en un cartulario los privilegios, donaciones y títulos de propiedad que acreditaban sus derechos. Era su libro de la verdad. En EADTrust tomamos ese nombre para un servicio que aplica las ideas de este artículo sin necesidad de una cadena de bloques pública.

El Cartulario trata el archivo como un registro, no como un simple depósito de ficheros. Anota la titularidad de cada documento, su estado y sus relaciones con otros. Lo diseñamos hace años partiendo de las premisas de la gestión de valores mediante anotaciones en cuenta, con tres funcionalidades en mente:

  • Transferibilidad (endosabilidad): registrar el cambio de titular de un derecho documentado, como ya se hacía con los títulos cambiarios endosables del proyecto PISTA.
  • Obliterabilidad (cancelabilidad): dejar constancia de que un derecho se ha consumido o cancelado, para que no pueda usarse dos veces.
  • Completitud: mantener unidos el documento, sus anexos y sus versiones.

Cada solicitud de archivo recibe un sello de tiempo con precisión de 1 milisegundo, lo que refuerza la garantía del orden cronológico. Es, en términos contables, un libro diario fehaciente: firma electrónica para la autoría e integridad, y una fuente de verdad centralizada, operada por un prestador de servicios de confianza, para el orden y el estado.

Hoy el Cartulario se presta como servicio de confianza no cualificado. El Reglamento de Ejecución (UE) 2025/2531 ya fija las normas de referencia de los libros mayores electrónicos cualificados, tanto centralizados como distribuidos. Podrá presentarse como cualificado cuando supere la correspondiente evaluación de conformidad eIDAS.

Conclusión

De la bulla sellada de Uruk al bloque encadenado por hash hay cinco mil años, pero el problema es el mismo: anotar hechos en orden, impedir que se alteren y poder comprobarlo. La partida doble aportó un control de integridad aritmético. La criptografía aportó la firma y el hash. Y lo que la tecnología replica entre nodos es, ante todo, un diario. Por eso sigo pensando que RJT es mejor nombre que DLT. Y, para el conjunto de firma y diario, propongo SJT: el valor no está en que el registro sea distribuido, sino en que sea un diario firmado y fehaciente.

Si quiere saber más sobre el Cartulario o los servicios de confianza de EADTrust, puede escribir a info@eadtrust.com, llamar al 91 716 05 55 o visitar www.eadtrust.eu.

Artículos relacionados

Estándares publicados en el desarrollo de la Cartera de Identidad Digital Europea y del resto de aspectos cubiertos por #EIDAS2


En la entrada «Los actos de ejecución de #eIDAS2, al día, junto con las normas ETSI y CEN que citan», actualizada en octubre de 2026, relaciono cada Reglamento de Ejecución con las normas técnicas que lo hacen operativo. Muchos lectores me han pedido la vista inversa: partir de cada norma y saber qué es, de qué trata y qué actos la exigen.

Eso es lo que recoge esta entrada: un catálogo de las normas de ETSI, CEN e ISO citadas en los actos de ejecución de eIDAS2, ordenadas por organismo y número, con su título oficial en inglés, una traducción al español, un breve resumen de su contenido y los actos que las citan. Las dos entradas se complementan: aquella sirve para saber qué normas aplica un acto concreto y esta, para entender cada norma y ver en qué actos aparece.

Las referencias se han obtenido del texto de cada acto publicado en EUR-Lex, incluidos los reglamentos modificativos de julio de 2026 (CIR (UE) 2026/1730, 2026/1731 y 2026/1735), que incorporan buena parte de las especificaciones ETSI más recientes sobre la cartera, y el anexo II del CIR (UE) 2025/2162, que recoge las normas de referencia para evaluar cada servicio de confianza cualificado.

Siglas utilizadas: DEA = declaración electrónica de atributos; DECA = declaración electrónica cualificada de atributos; PID = datos de identificación de la persona (DIP); CIR = Reglamento de Ejecución de la Comisión; CID = Decisión de Ejecución de la Comisión.

Criterio de clasificación

Las normas se agrupan en dos bloques:

  • Bloque 1, Cartera de Identidad Digital Europea (38 entradas): normas citadas por alguno de los actos de la cartera y de sus partes usuarias, es decir, los CIR (UE) 2024/2977, 2024/2979, 2024/2980, 2024/2981, 2024/2982, 2025/848, 2026/798, 2026/1730 y 2026/1731. Algunas de ellas, como la EN 319 401 o los formatos AdES, las citan también actos de servicios de confianza; en ese caso se indican todos.
  • Bloque 2, resto de servicios de confianza (35 entradas): normas que solo citan los demás actos de ejecución.

Dentro de cada bloque el orden es alfabético por organismo (CEN, ETSI, ISO) y numérico dentro de cada uno. En la serie ETSI de firmas electrónicas se han traducido los títulos de forma orientativa; los títulos originales en inglés son los que hay que usar en pliegos y auditorías.

Bloque 1. Normas de la Cartera de Identidad Digital Europea

Normas CEN

CEN EN 17640:2018

  • Versión citada: 2018
  • Título: Fixed-time cybersecurity evaluation methodology for ICT products
  • En español: Metodología de evaluación de ciberseguridad de tiempo fijo para productos TIC
  • Contenido: Metodología de evaluación de seguridad con duración y esfuerzo acotados (conocida como FITCEM), en la que se inspiran esquemas nacionales como CSPN (Francia), BSZ (Alemania) o LINCE (España). Sirve de referencia para evaluar componentes de la cartera cuando no se exige una evaluación Common Criteria completa.
  • Citada en: CIR (UE) 2024/2981 (certificación de las carteras: metodología de evaluación y tabla de certificados reutilizables)

Normas ETSI

ETSI TS 119 182-1

  • Versión citada: V1.2.1 (2024-07)
  • Título: Electronic Signatures and Infrastructures (ESI); JAdES digital signatures; Part 1: Building blocks and JAdES baseline signatures
  • En español: Firmas electrónicas e infraestructuras (ESI); firmas digitales JAdES; parte 1: componentes básicos y firmas JAdES de nivel básico
  • Contenido: Formato de firma avanzada para JSON basado en JWS, con los niveles B, T, LT y LTA.
  • Citada en: CIR (UE) 2024/2979 (formato opcional de la cartera); CIR (UE) 2025/2531 (con adaptaciones); CIR (UE) 2026/248; CIR (UE) 2025/2162 (anexo II, que la cita por error como «EN 319 182-1»)

ETSI TS 119 411-8

  • Versión citada: V1.1.1 (2025-10)
  • Título: Electronic Signatures and Trust Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 8: Access Certificate Policy for EUDI Wallet Relying Parties
  • En español: Firmas electrónicas e infraestructuras de confianza (ESI); requisitos de política y seguridad para los prestadores que expiden certificados; parte 8: política de certificados de acceso para las partes usuarias de la Cartera EUDI
  • Contenido: Política de certificación específica para los certificados de acceso con los que las partes usuarias se identifican ante las carteras al solicitar datos. Sustituye a la referencia genérica a la política NCP de la EN 319 411-1.
  • Citada en: CIR (UE) 2026/1730 (modifica el CIR (UE) 2025/848 en lo relativo a los certificados de acceso)

ETSI TS 119 412-6

  • Versión citada: V1.1.1 (2025-09)
  • Título: Electronic Signatures and Trust Infrastructures (ESI); Certificate Profiles; Part 6: Certificate profile requirements for PID, Wallet, EAA, QEAA, and PSBEAA providers
  • En español: Firmas electrónicas e infraestructuras de confianza (ESI); perfiles de certificado; parte 6: requisitos de perfil de certificado para los proveedores de PID, de carteras, de DEA, de DECA y de DEA del sector público
  • Contenido: Perfiles de los certificados con los que firman o sellan los proveedores de datos de identificación personal, los proveedores de carteras y los emisores de declaraciones electrónicas de atributos.
  • Citada en: CIR (UE) 2026/1731 (anexo II del CIR (UE) 2024/2979)

ETSI TS 119 432

  • Versión citada: v1.3.1 (2026-03)
  • Título: Electronic Signatures and Trust Infrastructures (ESI); Protocols for remote digital signature creation
  • En español: Firmas electrónicas e infraestructuras de confianza (ESI); protocolos para la creación de firmas digitales a distancia
  • Contenido: Protocolos e interfaces de programación para firmar a distancia, alineados con la especificación del Cloud Signature Consortium. Es la interfaz que deben admitir las aplicaciones de firma usadas por la cartera.
  • Citada en: CIR (UE) 2026/1731 (anexo IV del CIR (UE) 2024/2979, cláusulas 6.4.3, A.6, A.7 y A.8)

ETSI TS 119 461

  • Versión citada: V2.1.1 (2025-02)
  • Título: Electronic Signatures and Trust Infrastructures (ESI); Policy and security requirements for trust service components providing identity proofing of trust service subjects
  • En español: Firmas electrónicas e infraestructuras de confianza (ESI); requisitos de política y seguridad para los componentes de servicio de confianza que verifican la identidad de los sujetos
  • Contenido: Requisitos para verificar la identidad de personas físicas y jurídicas, presencial o a distancia (vídeo, documento con chip, identificación electrónica), con casos de uso y niveles de confianza. El CIR 2026/798 la aplica al alta remota en la cartera.
  • Citada en: CIR (UE) 2025/1566 (verificación de identidad); CIR (UE) 2026/798 (alta remota en la cartera); CIR (UE) 2025/2162 (anexo II)

ETSI TS 119 472-1

  • Versión citada: V1.2.1 (2026-02)
  • Título: Electronic Signatures and Trust Infrastructures (ESI); Profiles for Electronic Attestation of Attributes; Part 1: General requirements
  • En español: Firmas electrónicas e infraestructuras de confianza (ESI); perfiles de las declaraciones electrónicas de atributos; parte 1: requisitos generales
  • Contenido: Perfiles de las declaraciones electrónicas de atributos en los formatos SD-JWT VC e ISO/IEC mdoc: contenido, firma, metadatos, revocación y políticas de divulgación integradas.
  • Citada en: CIR (UE) 2026/1731 (anexo II del CIR (UE) 2024/2979)

ETSI TS 119 472-2

  • Versión citada: V1.2.1 (2026-03)
  • Título: Electronic Signatures and Trust Infrastructures (ESI); Profiles for Electronic Attestation of Attributes; Part 2: Profiles for EAA/PID Presentations to Relying Party
  • En español: Firmas electrónicas e infraestructuras de confianza (ESI); perfiles de las declaraciones electrónicas de atributos; parte 2: perfiles de presentación de DEA y PID a la parte usuaria
  • Contenido: Perfil del protocolo de presentación de datos de la cartera a las partes usuarias, basado en OpenID4VP, en remoto y en proximidad.
  • Citada en: CIR (UE) 2026/1731 (anexo II del CIR (UE) 2024/2982)

ETSI TS 119 472-3

  • Versión citada: V1.1.1 (2026-03)
  • Título: Electronic Signatures and Trust Infrastructures (ESI); Profiles for Electronic Attestation of Attributes; Part 3: Profiles for issuance of EAA or PID
  • En español: Firmas electrónicas e infraestructuras de confianza (ESI); perfiles de las declaraciones electrónicas de atributos; parte 3: perfiles de expedición de DEA o PID
  • Contenido: Perfil del protocolo de expedición de PID y declaraciones de atributos a la cartera, basado en OpenID4VCI, incluidos los metadatos del emisor y el uso de certificados de registro.
  • Citada en: CIR (UE) 2026/1731 (anexo I del CIR (UE) 2024/2982, protocolos de expedición; anexo III del CIR (UE) 2024/2979, políticas de divulgación integradas; nota en el anexo Ib del CIR (UE) 2024/2979)

ETSI TS 119 475

  • Versión citada: V1.2.1 (2026-03)
  • Título: Electronic Signatures and Trust Infrastructures (ESI); Relying party attributes supporting EUDI Wallet user’s authorisation decisions
  • En español: Firmas electrónicas e infraestructuras de confianza (ESI); atributos de la parte usuaria que respaldan las decisiones de autorización del usuario de la Cartera EUDI
  • Contenido: Define los certificados de registro y los datos de las partes usuarias (identidad, finalidad, atributos que pueden solicitar) que la cartera muestra al usuario para que decida si comparte sus datos.
  • Citada en: CIR (UE) 2026/1730 (anexo V del CIR (UE) 2025/848, certificados de registro); CIR (UE) 2026/1731 (anexo II del CIR (UE) 2024/2982)

ETSI EN 319 122-1

  • Versión citada: V1.3.1 (2023-06)
  • Título: Electronic Signatures and Infrastructures (ESI); CAdES digital signatures; Part 1: Building blocks and CAdES baseline signatures
  • En español: Firmas electrónicas e infraestructuras (ESI); firmas digitales CAdES; parte 1: componentes básicos y firmas CAdES de nivel básico
  • Contenido: Formato de firma avanzada basado en CMS (estructuras binarias ASN.1), con los niveles B, T, LT y LTA.
  • Citada en: CIR (UE) 2024/2979 (formato opcional de firma de la cartera; el DOUE lo escribe por error «EN 3191 22-1»); CIR (UE) 2025/2531 (libros registro electrónicos); CIR (UE) 2026/248 (sector público); CIR (UE) 2025/2162 (anexo II, libros registro)

ETSI EN 319 132-1

  • Versión citada: V1.2.1 (2022-02) en 2024/2979; V1.3.1 (2024-07) en 2025/2531
  • Título: Electronic Signatures and Infrastructures (ESI); XAdES digital signatures; Part 1: Building blocks and XAdES baseline signatures
  • En español: Firmas electrónicas e infraestructuras (ESI); firmas digitales XAdES; parte 1: componentes básicos y firmas XAdES de nivel básico
  • Contenido: Formato de firma avanzada para documentos XML basado en XMLDSig, con los niveles B, T, LT y LTA.
  • Citada en: CIR (UE) 2024/2979 (formato opcional de la cartera); CIR (UE) 2025/2531; CIR (UE) 2026/248; CIR (UE) 2025/2162 (anexo II)

ETSI EN 319 142-1

  • Versión citada: V1.1.1 (2016-04) en 2024/2979; V1.2.1 (2024-01) tras 2026/1731
  • Título: Electronic Signatures and Infrastructures (ESI); PAdES digital signatures; Part 1: Building blocks and PAdES baseline signatures
  • En español: Firmas electrónicas e infraestructuras (ESI); firmas digitales PAdES; parte 1: componentes básicos y firmas PAdES de nivel básico
  • Contenido: Formato de firma avanzada integrada en documentos PDF. Es el formato obligatorio que debe admitir la cartera para firmar o sellar.
  • Citada en: CIR (UE) 2024/2979 (formato obligatorio de la cartera), actualizada a V1.2.1 por CIR (UE) 2026/1731; CIR (UE) 2026/248

ETSI EN 319 162-1 y EN 319 162-2

  • Versión citada: V1.1.1 (2016-04)
  • Título: Electronic Signatures and Infrastructures (ESI); Associated Signature Containers (ASiC); Part 1: Building blocks and ASiC baseline containers; Part 2: Additional ASiC containers
  • En español: Firmas electrónicas e infraestructuras (ESI); contenedores de firma asociada (ASiC); parte 1: componentes básicos y contenedores ASiC de nivel básico; parte 2: contenedores ASiC adicionales
  • Contenido: Contenedores (basados en ZIP) que agrupan uno o varios documentos con sus firmas o sellos de tiempo separados, en variantes ASiC-S y ASiC-E.
  • Citada en: CIR (UE) 2024/2979 (formato opcional de la cartera); CIR (UE) 2026/248

ETSI EN 319 401

  • Versión citada: V3.1.1 (2024-06); V3.2.1 (2026-01) en 2026/1735
  • Título: Electronic Signatures and Trust Infrastructures (ESI); General Policy Requirements for Trust Service Providers
  • En español: Firmas electrónicas e infraestructuras de confianza (ESI); requisitos generales de política para los prestadores de servicios de confianza
  • Contenido: Requisitos horizontales para cualquier prestador: gestión de riesgos, políticas y prácticas, recursos humanos, seguridad física y lógica, gestión de incidentes, continuidad de negocio y cese de actividad. Es la base sobre la que se construyen las normas específicas de cada servicio.
  • Citada en: CIR (UE) 2025/1566; 2025/1567; 2025/1569; 2025/1929; 2025/1942; 2025/1943; 2025/1944; 2025/1946; 2025/2160; 2025/2531; 2025/2532; 2026/798 (alta remota en la cartera); 2026/1735 (V3.2.1); CIR (UE) 2025/2162 (anexo II, con una errata «EN 310 401» en dos entradas)

ETSI EN 319 411-1

  • Versión citada: V1.4.1 (2023-10) en 2025/848; V1.5.1 (2025-04) en 2025/1943 y 2025/1944
  • Título: Electronic Signatures and Trust Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 1: General requirements
  • En español: Firmas electrónicas e infraestructuras de confianza (ESI); requisitos de política y seguridad para los prestadores de servicios de confianza que expiden certificados; parte 1: requisitos generales
  • Contenido: Políticas de certificación normalizadas (NCP, NCP+, LCP, EVCP…) y requisitos de ciclo de vida de los certificados: registro, emisión, revocación y servicios de estado.
  • Citada en: CIR (UE) 2025/848 (certificados de acceso y de registro de las partes usuarias, sustituida después por TS 119 411-8 y TS 119 475 mediante CIR (UE) 2026/1730); CIR (UE) 2025/1942; CIR (UE) 2025/1943; CIR (UE) 2025/1944; CIR (UE) 2025/2162 (anexo II, como «EN 319 411»)

ETSI EN 319 412-1

  • Versión citada: V1.6.1 (2025-06)
  • Título: Electronic Signatures and Infrastructures (ESI); Certificate Profiles; Part 1: Overview and common data structures
  • En español: Firmas electrónicas e infraestructuras (ESI); perfiles de certificado; parte 1: visión general y estructuras de datos comunes
  • Contenido: Estructuras comunes a todos los perfiles de certificado de ETSI, como la semántica de identificadores (por ejemplo, el NIF o el VAT en el campo organizationIdentifier).
  • Citada en: CIR (UE) 2025/1943; CIR (UE) 2026/1731 (referencia normativa de la TS 119 472-1 en el anexo II del CIR (UE) 2024/2979); CIR (UE) 2025/2162 (anexo II)

ETSI EN 319 412-2

  • Versión citada: V2.4.1 (2025-06)
  • Título: Electronic Signatures and Infrastructures (ESI); Certificate Profiles; Part 2: Certificate profile for certificates issued to natural persons
  • En español: Firmas electrónicas e infraestructuras (ESI); perfiles de certificado; parte 2: perfil de certificado para certificados expedidos a personas físicas
  • Contenido: Perfil de los certificados de personas físicas, incluidos los certificados cualificados de firma.
  • Citada en: CIR (UE) 2025/1943; CIR (UE) 2026/1731 (certificados de los registros en el anexo II del CIR (UE) 2024/2980); CIR (UE) 2025/2162 (anexo II)

ETSI EN 319 412-3

  • Versión citada: V1.3.1 (2023-09)
  • Título: Electronic Signatures and Infrastructures (ESI); Certificate Profiles; Part 3: Certificate profile for certificates issued to legal persons
  • En español: Firmas electrónicas e infraestructuras (ESI); perfiles de certificado; parte 3: perfil de certificado para certificados expedidos a personas jurídicas
  • Contenido: Perfil de los certificados de personas jurídicas, incluidos los certificados cualificados de sello.
  • Citada en: CIR (UE) 2025/1943; CIR (UE) 2026/1731 (anexo II del CIR (UE) 2024/2980); CIR (UE) 2025/2162 (anexo II)

ETSI EN 319 412-5

  • Versión citada: V2.5.1
  • Título: Electronic Signatures and Trust Infrastructures (ESI); Certificate Profiles; Part 5: QCStatements
  • En español: Firmas electrónicas e infraestructuras de confianza (ESI); perfiles de certificado; parte 5: declaraciones QCStatements
  • Contenido: Extensiones QCStatements que indican en el certificado su carácter cualificado, el tipo (firma, sello o web), si la clave está en un dispositivo cualificado y otros datos. El CIR 2026/1731 añade un tipo nuevo para los certificados de los emisores de declaraciones de atributos del sector público (id-etsi-qct-eidaspsbeaa).
  • Citada en: CIR (UE) 2025/1943; CIR (UE) 2026/1731 (anexo II del CIR (UE) 2024/2979, Pub-EAA); CID (UE) 2025/2164 (lista de confianza); CIR (UE) 2025/2162 (anexo II)

Normas ISO e ISO/IEC

ISO 3166-1

  • Versión citada: (sin versión; 2006 en 2025/2164)
  • Título: Codes for the representation of names of countries and their subdivisions — Part 1: Country code
  • En español: Códigos para la representación de los nombres de los países y sus subdivisiones — Parte 1: Códigos de país
  • Contenido: Códigos de país de dos letras (alfa-2), como ES o FR. Se usa en los datos PID, en el identificador de las partes usuarias (con la excepción de Grecia, «EL») y en las listas de confianza.
  • Citada en: CIR (UE) 2024/2977 (PID); CIR (UE) 2025/848 (registro de partes usuarias); CIR (UE) 2026/1731 (anexo del CIR (UE) 2024/2977); CID (UE) 2025/2164

ISO 3166-2:2020

  • Versión citada: 2020
  • Título: Codes for the representation of names of countries and their subdivisions — Part 2: Country subdivision code
  • En español: Códigos para la representación de los nombres de los países y sus subdivisiones — Parte 2: Códigos de subdivisión de país
  • Contenido: Códigos de regiones y provincias (por ejemplo, ES-MD). Se usa para indicar la jurisdicción que expide los datos PID.
  • Citada en: CIR (UE) 2024/2977; CIR (UE) 2026/1731

ISO/IEC 5218

  • Versión citada: (sin versión)
  • Título: Information technology — Codes for the representation of human sexes
  • En español: Tecnologías de la información — Códigos para la representación de los sexos humanos
  • Contenido: Códigos numéricos del sexo (0, 1, 2 y 9), que el PID usa para el atributo opcional «sex», ampliado con otros valores propios.
  • Citada en: CIR (UE) 2024/2977; CIR (UE) 2026/1731

ISO 8601-1

  • Versión citada: (sin versión)
  • Título: Date and time — Representations for information interchange — Part 1: Basic rules
  • En español: Fecha y hora — Representaciones para el intercambio de información — Parte 1: Reglas básicas
  • Contenido: Formato normalizado de fechas (AAAA-MM-DD), que se usa, por ejemplo, para la fecha de nacimiento en la codificación SD-JWT VC del PID.
  • Citada en: CIR (UE) 2026/1731 (anexo del CIR (UE) 2024/2977)

ISO/IEC 15408

  • Versión citada: 2022 (partes 1 a 5)
  • Título: Information security, cybersecurity and privacy protection — Evaluation criteria for IT security
  • En español: Seguridad de la información, ciberseguridad y protección de la privacidad — Criterios de evaluación de la seguridad TI
  • Contenido: Los «Common Criteria»: marco para especificar y evaluar requisitos funcionales y de garantía de seguridad de productos TIC, con niveles EAL y componentes como AVA_VAN (análisis de vulnerabilidades).
  • Citada en: CIR (UE) 2024/2981 (parte 3, AVA_VAN.5 para el dispositivo criptográfico seguro de la cartera); CIR (UE) 2025/1929; 2025/1942; 2025/1943; 2025/1944; 2025/1946; 2025/2531; 2025/2532; 2026/1735

ISO/IEC 17000:2020

  • Versión citada: 2020
  • Título: Conformity assessment — Vocabulary and general principles
  • En español: Evaluación de la conformidad — Vocabulario y principios generales
  • Contenido: Términos y principios comunes de la evaluación de la conformidad (certificación, inspección, validación, verificación…).
  • Citada en: CIR (UE) 2024/2981

EN ISO/IEC 17020:2012

  • Versión citada: 2012
  • Título: Conformity assessment — Requirements for the operation of various types of bodies performing inspection
  • En español: Evaluación de la conformidad — Requisitos para el funcionamiento de diferentes tipos de organismos que realizan la inspección
  • Contenido: Requisitos de competencia, imparcialidad y funcionamiento de los organismos de inspección.
  • Citada en: CIR (UE) 2024/2981; CIR (UE) 2025/2162

EN ISO/IEC 17021-1:2015

  • Versión citada: 2015
  • Título: Conformity assessment — Requirements for bodies providing audit and certification of management systems — Part 1: Requirements
  • En español: Evaluación de la conformidad — Requisitos para los organismos que realizan la auditoría y la certificación de sistemas de gestión — Parte 1: Requisitos
  • Contenido: Requisitos de los organismos que auditan y certifican sistemas de gestión. Los actos la usan también para las auditorías de seguimiento y de renovación.
  • Citada en: CIR (UE) 2024/2981; CIR (UE) 2025/2162

EN ISO/IEC 17025:2017

  • Versión citada: 2017
  • Título: General requirements for the competence of testing and calibration laboratories
  • En español: Requisitos generales para la competencia de los laboratorios de ensayo y calibración
  • Contenido: Requisitos de los laboratorios que realizan ensayos, aplicables a los laboratorios de evaluación de seguridad.
  • Citada en: CIR (UE) 2024/2981; CIR (UE) 2025/2162

EN ISO/IEC 17029:2019

  • Versión citada: 2019
  • Título: Conformity assessment — General principles and requirements for validation and verification bodies
  • En español: Evaluación de la conformidad — Principios generales y requisitos para los organismos de validación y verificación
  • Contenido: Requisitos de los organismos que validan o verifican declaraciones, aplicables a la verificación de las afirmaciones del proveedor de la cartera.
  • Citada en: CIR (UE) 2024/2981

EN ISO/IEC 17065:2012

  • Versión citada: 2012
  • Título: Conformity assessment — Requirements for bodies certifying products, processes and services
  • En español: Evaluación de la conformidad — Requisitos para organismos que certifican productos, procesos y servicios
  • Contenido: Norma base de los organismos de certificación de productos y servicios. Rige tanto a los organismos que certifican carteras como a los que evalúan a los prestadores cualificados.
  • Citada en: CIR (UE) 2024/2981 (plan de evaluación, apartado 7.4.1); CIR (UE) 2025/2162

EN ISO/IEC 17067:2013

  • Versión citada: 2013
  • Título: Conformity assessment — Fundamentals of product certification and guidelines for product certification schemes
  • En español: Evaluación de la conformidad — Fundamentos de la certificación de producto y directrices para los esquemas de certificación de producto
  • Contenido: Tipología de los esquemas de certificación. Los esquemas nacionales de certificación de carteras deben ser de «tipo 6» (producto, proceso y servicio, con vigilancia).
  • Citada en: CIR (UE) 2024/2981; CIR (UE) 2025/2162

ISO/IEC 18013-5:2021

  • Versión citada: 2021
  • Título: Personal identification — ISO-compliant driving licence — Part 5: Mobile driving licence (mDL) application
  • En español: Identificación personal — Permiso de conducción conforme a ISO — Parte 5: Aplicación del permiso de conducción móvil (mDL)
  • Contenido: Define el formato «mdoc» (CBOR/COSE) y la presentación en proximidad (QR, NFC, BLE) del permiso de conducir móvil. Es uno de los dos formatos obligatorios del PID y la base de la presentación presencial.
  • Citada en: CIR (UE) 2024/2977 (formato del PID); CIR (UE) 2024/2982 (protocolos); CIR (UE) 2026/1731

ISO/IEC TS 18013-7:2024 / ISO/IEC 18013-7:2025

  • Versión citada: 2024 (TS) en 2024/2982; 2025 en 2026/1731
  • Título: Personal identification — ISO-compliant driving licence — Part 7: Mobile driving licence (mDL) add-on functions
  • En español: Identificación personal — Permiso de conducción conforme a ISO — Parte 7: Funciones adicionales del permiso de conducción móvil (mDL)
  • Contenido: Extiende la parte 5 para la presentación en remoto (por internet) de los datos mdoc. El anexo C, que se apoya en la Digital Credentials API de los navegadores, es el que se aplica a la cartera.
  • Citada en: CIR (UE) 2024/2982 (versión TS de 2024); CIR (UE) 2026/1731 (versión de 2025, anexo C)

ISO/IEC 19794-5

  • Versión citada: (sin versión)
  • Título: Information technology — Biometric data interchange formats — Part 5: Face image data
  • En español: Tecnologías de la información — Formatos de intercambio de datos biométricos — Parte 5: Datos de imagen facial
  • Contenido: Formato y requisitos de calidad de la imagen facial. Se mantiene por compatibilidad para el retrato del PID.
  • Citada en: CIR (UE) 2024/2977 (como «ISO 19794-5»); CIR (UE) 2026/1731

EN ISO/IEC 27001:2022

  • Versión citada: 2022
  • Título: Information security, cybersecurity and privacy protection — Information security management systems — Requirements
  • En español: Seguridad de la información, ciberseguridad y protección de la privacidad — Sistemas de gestión de la seguridad de la información — Requisitos
  • Contenido: Requisitos del sistema de gestión de la seguridad de la información (SGSI). Se admite como certificación reutilizable en la certificación de carteras y para los nodos del marco de interoperabilidad de la identificación electrónica.
  • Citada en: CIR (UE) 2024/2981; CIR (UE) 2025/1568 (revisiones inter pares de los esquemas de identificación electrónica)

EN ISO/IEC 30111:2019

  • Versión citada: 2019
  • Título: Information technology — Security techniques — Vulnerability handling processes
  • En español: Tecnologías de la información — Técnicas de seguridad — Procesos de gestión de vulnerabilidades
  • Contenido: Procesos para investigar, clasificar y corregir vulnerabilidades notificadas. El titular del certificado de la cartera debe tenerla en cuenta en su política de gestión de vulnerabilidades.
  • Citada en: CIR (UE) 2024/2981

ISO/IEC 39794-5

  • Versión citada: (sin versión)
  • Título: Information technology — Extensible biometric data interchange formats — Part 5: Face image data
  • En español: Tecnologías de la información — Formatos extensibles de intercambio de datos biométricos — Parte 5: Datos de imagen facial
  • Contenido: Sucesora de la ISO/IEC 19794-5, con formatos extensibles. Es la referencia principal para el retrato del PID (imagen frontal completa).
  • Citada en: CIR (UE) 2024/2977 (como «ISO 39794»); CIR (UE) 2026/1731

Bloque 2. Normas del resto de servicios de confianza

Normas CEN

CEN/TS 18170:2025

  • Versión citada: 2025
  • Título: Functional and security requirements for electronic archiving services
  • En español: Requisitos funcionales y de seguridad de los servicios de archivo electrónico
  • Contenido: Especificación técnica de CEN que define los requisitos de organización, procesos y seguridad de los prestadores de servicios de archivo electrónico, incluida la conservación de la integridad, autenticidad y legibilidad de los documentos a lo largo del tiempo.
  • Citada en: CIR (UE) 2025/2532 (archivo electrónico cualificado, con adaptaciones); CIR (UE) 2025/2162 (anexo II, archivo electrónico y libros registro electrónicos)

CEN/TS 419261:2015

  • Versión citada: 2015
  • Título: Security requirements for trustworthy systems managing certificates and time-stamps
  • En español: Requisitos de seguridad de los sistemas fiables que gestionan certificados y sellos de tiempo
  • Contenido: Requisitos de seguridad de los sistemas que utilizan los prestadores para generar y gestionar certificados (registro, emisión, revocación) y sellos de tiempo, con base en perfiles de protección y criterios de evaluación de seguridad.
  • Citada en: CIR (UE) 2025/1943 (certificados cualificados de firma y de sello)

Normas ETSI

ETSI TS 103 171

  • Versión citada: v2.1.1
  • Título: Electronic Signatures and Infrastructures (ESI); XAdES Baseline Profile
  • En español: Firmas electrónicas e infraestructuras (ESI); perfil básico XAdES
  • Contenido: Perfil «baseline» anterior de las firmas XAdES (XML). Se mantiene como formato admitido para facilitar la transición desde la Decisión 2015/1506.
  • Citada en: CIR (UE) 2026/248 (anexo II, formatos heredados)

ETSI TS 103 172

  • Versión citada: (versión según el anexo II)
  • Título: Electronic Signatures and Infrastructures (ESI); PAdES Baseline Profile
  • En español: Firmas electrónicas e infraestructuras (ESI); perfil básico PAdES
  • Contenido: Perfil «baseline» anterior de las firmas PAdES (PDF), admitido de forma transitoria junto a la norma EN 319 142-1.
  • Citada en: CIR (UE) 2026/248 (anexo II, formatos heredados)

ETSI TS 103 173

  • Versión citada: (versión según el anexo II)
  • Título: Electronic Signatures and Infrastructures (ESI); CAdES Baseline Profile
  • En español: Firmas electrónicas e infraestructuras (ESI); perfil básico CAdES
  • Contenido: Perfil «baseline» anterior de las firmas CAdES (CMS), admitido de forma transitoria junto a la norma EN 319 122-1.
  • Citada en: CIR (UE) 2026/248 (anexo II, formatos heredados)

ETSI TS 103 174

  • Versión citada: (versión según el anexo II)
  • Título: Electronic Signatures and Infrastructures (ESI); ASiC Baseline Profile
  • En español: Firmas electrónicas e infraestructuras (ESI); perfil básico ASiC
  • Contenido: Perfil «baseline» anterior de los contenedores de firma asociada ASiC, admitido de forma transitoria junto a las normas EN 319 162-1/-2.
  • Citada en: CIR (UE) 2026/248 (anexo II, formatos heredados)

ETSI TS 119 101

  • Versión citada: V1.1.1 (2016-03)
  • Título: Electronic Signatures and Infrastructures (ESI); Policy and security requirements for applications for signature creation and signature validation
  • En español: Firmas electrónicas e infraestructuras (ESI); requisitos de política y seguridad para aplicaciones de creación y validación de firmas
  • Contenido: Requisitos de seguridad para las aplicaciones de software que crean y validan firmas: gestión del documento a firmar, presentación al firmante, integridad del proceso y control de los componentes.
  • Citada en: CIR (UE) 2025/1942 (servicios cualificados de validación); CIR (UE) 2025/1945 (validación de firmas y sellos); CIR (UE) 2025/1946 (preservación)

ETSI TS 119 102-2

  • Versión citada: V1.4.1 (2023-06)
  • Título: Electronic Signatures and Infrastructures (ESI); Procedures for Creation and Validation of AdES Digital Signatures; Part 2: Signature Validation Report
  • En español: Firmas electrónicas e infraestructuras (ESI); procedimientos de creación y validación de firmas digitales AdES; parte 2: informe de validación de firma
  • Contenido: Define la estructura y la semántica (XML) del informe de validación, de modo que el resultado y sus motivos sean legibles por máquinas e interoperables entre validadores.
  • Citada en: CIR (UE) 2025/1942; CIR (UE) 2025/1945; CIR (UE) 2025/2162 (anexo II)

ETSI TS 119 172-1

  • Versión citada: (citada por cláusulas)
  • Título: Electronic Signatures and Infrastructures (ESI); Signature Policies; Part 1: Building blocks and table of contents for human readable signature policy documents
  • En español: Firmas electrónicas e infraestructuras (ESI); políticas de firma; parte 1: componentes básicos e índice de contenidos de los documentos de política de firma legibles por personas
  • Contenido: Estructura de las políticas de firma y de validación. Los actos se remiten a ella para fijar restricciones concretas, como el modo de comprobar la revocación de los certificados.
  • Citada en: CIR (UE) 2025/1942; CIR (UE) 2025/1945; CIR (UE) 2025/1946

ETSI TS 119 172-4

  • Versión citada: V1.1.1 (2021-05)
  • Título: Electronic Signatures and Infrastructures (ESI); Signature Policies; Part 4: Signature applicability rules (validation policy) for European qualified electronic signatures/seals using trusted lists
  • En español: Firmas electrónicas e infraestructuras (ESI); políticas de firma; parte 4: reglas de aplicabilidad (política de validación) para firmas y sellos electrónicos cualificados europeos mediante listas de confianza
  • Contenido: Política de validación que permite determinar si una firma o un sello es cualificado a partir de las listas de confianza de la UE.
  • Citada en: CIR (UE) 2025/1942; CIR (UE) 2025/1945; CIR (UE) 2025/1946; CIR (UE) 2025/2162 (anexo II)

ETSI TS 119 411-5

  • Versión citada: V2.1.1 (2025-02)
  • Título: Electronic Signatures and Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 5: Specification for the coexistence of EU qualified website authentication certificates and publicly-trusted website certificates
  • En español: Firmas electrónicas e infraestructuras (ESI); requisitos de política y seguridad para los prestadores que expiden certificados; parte 5: especificación para la coexistencia de los certificados cualificados de autenticación de sitios web de la UE y los certificados de sitio web de confianza pública
  • Contenido: Define cómo se presentan los QWAC junto a los certificados TLS reconocidos por los navegadores, incluidos los QWAC vinculados a TLS y los no vinculados a TLS, para cumplir el artículo 45 de eIDAS2.
  • Citada en: CIR (UE) 2025/2527 (QWAC); CIR (UE) 2025/2162 (anexo II)

ETSI TS 119 431-1

  • Versión citada: V1.3.1 (2024-12)
  • Título: Electronic Signatures and Trust Infrastructures (ESI); Policy and security requirements for trust service providers; Part 1: TSP service components operating a remote QSCD / SCDev
  • En español: Firmas electrónicas e infraestructuras de confianza (ESI); requisitos de política y seguridad para los prestadores; parte 1: componentes de servicio del prestador que operan un dispositivo cualificado o un dispositivo de creación de firma a distancia
  • Contenido: Requisitos del componente que gestiona dispositivos de creación de firma o sello a distancia (firma «en la nube»), incluida la activación de la clave bajo control exclusivo del firmante.
  • Citada en: CIR (UE) 2025/1567 (gestión a distancia de dispositivos); CIR (UE) 2025/2162 (anexo II)

ETSI TS 119 441

  • Versión citada: V1.2.1 (2023-10)
  • Título: Electronic Signatures and Infrastructures (ESI); Policy requirements for TSP providing signature validation services
  • En español: Firmas electrónicas e infraestructuras (ESI); requisitos de política para los prestadores que ofrecen servicios de validación de firmas
  • Contenido: Requisitos de organización y seguridad del servicio de validación: política de validación, firma de los informes y gestión de evidencias.
  • Citada en: CIR (UE) 2025/1942; CIR (UE) 2025/2162 (anexo II)

ETSI TS 119 442

  • Versión citada: (sin versión)
  • Título: Electronic Signatures and Infrastructures (ESI); Protocol profiles for trust service providers providing AdES digital signature validation services
  • En español: Firmas electrónicas e infraestructuras (ESI); perfiles de protocolo para los prestadores que ofrecen servicios de validación de firmas digitales AdES
  • Contenido: Protocolo de petición y respuesta entre el cliente y el servicio de validación.
  • Citada en: CIR (UE) 2025/2162 (anexo II)

ETSI TS 119 471

  • Versión citada: V1.1.1 (2025-05)
  • Título: Electronic Signatures and Trust Infrastructures (ESI); Policy and Security requirements for Providers of Electronic Attestation of Attributes Services
  • En español: Firmas electrónicas e infraestructuras de confianza (ESI); requisitos de política y seguridad para los proveedores de servicios de declaraciones electrónicas de atributos
  • Contenido: Requisitos de organización y seguridad para los proveedores de DEA y DECA, incluida la verificación de los atributos contra fuentes auténticas.
  • Citada en: CIR (UE) 2026/1735 (modifica el CIR (UE) 2025/1569, con adaptaciones); CIR (UE) 2025/2162 (anexo II)

ETSI TS 119 478

  • Versión citada: V1.1.1 (2026-01)
  • Título: Electronic Signatures and Trust Infrastructures (ESI); Specification of interfaces related to Authentic Sources
  • En español: Firmas electrónicas e infraestructuras de confianza (ESI); especificación de las interfaces relacionadas con las fuentes auténticas
  • Contenido: Interfaces para que los proveedores de DECA verifiquen atributos ante las fuentes auténticas y reciban resultados de verificación firmados o sellados.
  • Citada en: CIR (UE) 2026/1735 (modifica el CIR (UE) 2025/1569)

ETSI TS 119 495

  • Versión citada: V1.7.1 (2024-07)
  • Título: Electronic Signatures and Infrastructures (ESI); Sector Specific Requirements; Certificate Profiles and TSP Policy Requirements for Open Banking
  • En español: Firmas electrónicas e infraestructuras (ESI); requisitos sectoriales; perfiles de certificado y requisitos de política del prestador para la banca abierta
  • Contenido: Perfil de los certificados cualificados (QWAC y sellos) para proveedores de servicios de pago en el marco de PSD2 y la banca abierta, con sus roles y la autoridad competente.
  • Citada en: CIR (UE) 2025/2527 (QWAC); CIR (UE) 2025/2162 (anexo II)

ETSI TS 119 511

  • Versión citada: V1.1.1 (2019-06)
  • Título: Electronic Signatures and Infrastructures (ESI); Policy and security requirements for trust service providers providing long-term preservation of digital signatures or general data using digital signature techniques
  • En español: Firmas electrónicas e infraestructuras (ESI); requisitos de política y seguridad para los prestadores que ofrecen preservación a largo plazo de firmas digitales o de datos mediante técnicas de firma digital
  • Contenido: Requisitos de los servicios de preservación que mantienen la validez de las firmas a lo largo del tiempo (aumentos, resellado, evidencias de preservación).
  • Citada en: CIR (UE) 2025/1946 (preservación cualificada); CIR (UE) 2025/2162 (anexo II; en archivo electrónico la cita por error como «EN 119 511»)

ETSI TS 119 512

  • Versión citada: (sin versión)
  • Título: Electronic Signatures and Infrastructures (ESI); Protocols for trust service providers providing long-term data preservation services
  • En español: Firmas electrónicas e infraestructuras (ESI); protocolos para los prestadores que ofrecen servicios de preservación de datos a largo plazo
  • Contenido: Protocolo de interacción entre clientes y servicios de preservación (envío, recuperación y obtención de evidencias).
  • Citada en: CIR (UE) 2025/2162 (anexo II, servicios de preservación)

ETSI TS 119 612

  • Versión citada: V2.3.1 (2024-11); v2.4.1 en 2025/2162
  • Título: Electronic Signatures and Infrastructures (ESI); Trusted Lists
  • En español: Firmas electrónicas e infraestructuras (ESI); listas de confianza
  • Contenido: Formato y semántica de las listas de confianza nacionales y de la lista de listas (LOTL) de la Comisión.
  • Citada en: CIR (UE) 2025/1942; 2025/1945; 2025/1946; CID (UE) 2025/2164 (versión de la norma de la plantilla común); CIR (UE) 2025/2162 (anexo II, v2.4.1)

ETSI EN 301 549

  • Versión citada: (sin versión)
  • Título: Accessibility requirements for ICT products and services
  • En español: Requisitos de accesibilidad de productos y servicios TIC
  • Contenido: Norma europea armonizada de accesibilidad, que permite comprobar que los servicios de confianza pueden ser usados por personas con discapacidad (artículo 15 de eIDAS).
  • Citada en: CIR (UE) 2025/2162 (anexo II, en casi todos los servicios cualificados; en archivo electrónico aparece por error como «TS 301 549»)

ETSI EN 319 102-1

  • Versión citada: V1.4.1 (2024-06)
  • Título: Electronic Signatures and Infrastructures (ESI); Procedures for Creation and Validation of AdES Digital Signatures; Part 1: Creation and Validation
  • En español: Firmas electrónicas e infraestructuras (ESI); procedimientos de creación y validación de firmas digitales AdES; parte 1: creación y validación
  • Contenido: Norma central del algoritmo de validación de firmas avanzadas: modelo de validación, bloques de comprobación (formato, identificación del firmante, cadena de certificados, revocación, sellos de tiempo, validación a largo plazo) y resultados (TOTAL-PASSED, TOTAL-FAILED, INDETERMINATE). Los actos aclaran que las referencias a la antigua TS 119 102-1 se entienden hechas a esta EN.
  • Citada en: CIR (UE) 2025/1942; CIR (UE) 2025/1945; CIR (UE) 2025/1946; CIR (UE) 2025/2162 (anexo II, servicios de validación)

ETSI EN 319 403-1

  • Versión citada: v2.3.1
  • Título: Electronic Signatures and Trust Infrastructures (ESI); Trust Service Provider Conformity Assessment; Part 1: Requirements for conformity assessment bodies assessing Trust Service Providers
  • En español: Firmas electrónicas e infraestructuras de confianza (ESI); evaluación de la conformidad de los prestadores de servicios de confianza; parte 1: requisitos para los organismos de evaluación de la conformidad que evalúan a los prestadores
  • Contenido: Completa la ISO/IEC 17065 con requisitos específicos para los organismos que auditan a prestadores: competencia de los auditores, proceso de auditoría y contenido del informe de evaluación.
  • Citada en: CIR (UE) 2025/2162 (acreditación de organismos de evaluación de la conformidad; régimen transitorio para los acreditados con la EN 319 403 v2.2.2)

ETSI EN 319 411-2

  • Versión citada: V2.6.1 (2025-06)
  • Título: Electronic Signatures and Trust Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 2: Requirements for trust service providers issuing EU qualified certificates
  • En español: Firmas electrónicas e infraestructuras de confianza (ESI); requisitos de política y seguridad para los prestadores que expiden certificados; parte 2: requisitos para los prestadores que expiden certificados cualificados de la UE
  • Contenido: Políticas de certificación de los certificados cualificados (QCP-n, QCP-l, QCP-n-qscd, QCP-l-qscd, QCP-w) y requisitos adicionales a la parte 1.
  • Citada en: CIR (UE) 2025/1943; CIR (UE) 2025/2527 (QWAC); CIR (UE) 2025/1942 (referencia informativa); CIR (UE) 2025/2162 (anexo II)

ETSI EN 319 412-4

  • Versión citada: (sin versión)
  • Título: Electronic Signatures and Infrastructures (ESI); Certificate Profiles; Part 4: Certificate profile for web site certificates
  • En español: Firmas electrónicas e infraestructuras (ESI); perfiles de certificado; parte 4: perfil de certificado para certificados de sitio web
  • Contenido: Perfil de los certificados de autenticación de sitios web, base de los QWAC.
  • Citada en: CIR (UE) 2025/2162 (anexo II, certificados cualificados de autenticación de sitios web)

ETSI EN 319 421

  • Versión citada: V1.3.1 (2025-07)
  • Título: Electronic Signatures and Infrastructures (ESI); Policy and Security Requirements for Trust Service Providers issuing Time-Stamps
  • En español: Firmas electrónicas e infraestructuras (ESI); requisitos de política y seguridad para los prestadores que expiden sellos de tiempo
  • Contenido: Requisitos de las autoridades de sellado de tiempo: sincronización con UTC, precisión, gestión de claves y política de sellado.
  • Citada en: CIR (UE) 2025/1929 (sellos cualificados de tiempo, con adaptaciones); CIR (UE) 2025/2532 (archivo electrónico); CIR (UE) 2025/2162 (anexo II)

ETSI EN 319 422

  • Versión citada: V1.1.1 (2016-03)
  • Título: Electronic Signatures and Infrastructures (ESI); Time-stamping protocol and time-stamp token profiles
  • En español: Firmas electrónicas e infraestructuras (ESI); protocolo de sellado de tiempo y perfiles del token de sello de tiempo
  • Contenido: Perfil del protocolo de sellado de tiempo (RFC 3161) y del token resultante.
  • Citada en: CIR (UE) 2025/1929; CIR (UE) 2025/2162 (anexo II)

ETSI EN 319 521

  • Versión citada: V1.1.1 (2019-02)
  • Título: Electronic Signatures and Infrastructures (ESI); Policy and security requirements for Electronic Registered Delivery Service Providers
  • En español: Firmas electrónicas e infraestructuras (ESI); requisitos de política y seguridad para los prestadores de servicios de entrega electrónica certificada
  • Contenido: Requisitos de organización y seguridad de los prestadores de entrega electrónica certificada.
  • Citada en: CIR (UE) 2025/1944 (QERDS); CIR (UE) 2025/2162 (anexo II)

ETSI EN 319 522-1 a 319 522-4

  • Versión citada: V1.2.1 (2024-01)
  • Título: Electronic Signatures and Infrastructures (ESI); Electronic Registered Delivery Services; Part 1: Framework and Architecture; Part 2: Semantic contents; Part 3: Formats; Part 4: Bindings
  • En español: Firmas electrónicas e infraestructuras (ESI); servicios de entrega electrónica certificada; parte 1: marco y arquitectura; parte 2: contenidos semánticos; parte 3: formatos; parte 4: vinculaciones
  • Contenido: Arquitectura, evidencias, formatos de mensajes y protocolos de los servicios de entrega electrónica certificada.
  • Citada en: CIR (UE) 2025/1944; CIR (UE) 2025/2162 (anexo II)

ETSI EN 319 531 y EN 319 532

  • Versión citada: (sin versión)
  • Título: Electronic Signatures and Infrastructures (ESI); Policy and security requirements for Registered Electronic Mail (REM) Service Providers; Registered Electronic Mail (REM) Services
  • En español: Firmas electrónicas e infraestructuras (ESI); requisitos de política y seguridad para los prestadores de correo electrónico certificado (REM); servicios de correo electrónico certificado (REM)
  • Contenido: Versión de la entrega electrónica certificada basada en correo electrónico (REM): requisitos del prestador y perfiles técnicos.
  • Citada en: CIR (UE) 2025/2162 (anexo II, QERDS)

Normas ISO e ISO/IEC

ISO 14641

  • Versión citada: (sin versión)
  • Título: Electronic document management — Design and operation of an information system for the preservation of electronic documents — Specifications
  • En español: Gestión de documentos electrónicos — Diseño y explotación de un sistema de información para la conservación de documentos electrónicos — Especificaciones
  • Contenido: Requisitos técnicos y organizativos de los sistemas de archivo electrónico que garantizan la integridad y la trazabilidad de los documentos.
  • Citada en: CIR (UE) 2025/2162 (anexo II, archivo electrónico)

ISO 14721:2025

  • Versión citada: 2025
  • Título: Space data system practices — Reference model for an open archival information system (OAIS)
  • En español: Prácticas de los sistemas de datos espaciales — Modelo de referencia para un sistema abierto de información de archivo (OAIS)
  • Contenido: Modelo de referencia OAIS de preservación digital a largo plazo (ingreso, almacenamiento, gestión de datos, acceso y planificación de la preservación), nacido en el ámbito espacial y adoptado por los archivos de todo el mundo.
  • Citada en: CIR (UE) 2025/2532 (archivo electrónico); CIR (UE) 2025/2162 (anexo II)

EN ISO/IEC 17011:2017

  • Versión citada: 2017
  • Título: Conformity assessment — Requirements for accreditation bodies accrediting conformity assessment bodies
  • En español: Evaluación de la conformidad — Requisitos para los organismos de acreditación que realizan la acreditación de organismos de evaluación de la conformidad
  • Contenido: Requisitos para las entidades nacionales de acreditación (en España, ENAC).
  • Citada en: CIR (UE) 2025/2162

ISO 23257:2022

  • Versión citada: 2022
  • Título: Blockchain and distributed ledger technologies — Reference architecture
  • En español: Cadena de bloques y tecnologías de registro distribuido — Arquitectura de referencia
  • Contenido: Arquitectura de referencia de las tecnologías de registro distribuido. Su cláusula 9 sirve para describir el sistema DLT de los libros registro electrónicos cualificados.
  • Citada en: CIR (UE) 2025/2531 (libros registro electrónicos); CIR (UE) 2025/2162 (anexo II)

ISO/TS 23635:2022

  • Versión citada: 2022
  • Título: Blockchain and distributed ledger technologies — Guidelines for governance
  • En español: Cadena de bloques y tecnologías de registro distribuido — Directrices de gobernanza
  • Contenido: Directrices sobre la gobernanza de los sistemas DLT, aplicables a las políticas y prácticas del servicio de libro registro.
  • Citada en: CIR (UE) 2025/2531; CIR (UE) 2025/2162 (anexo II)

Notas y cautelas

  • Versiones. Cada acto fija una versión concreta de la norma, y a veces con adaptaciones o exclusiones de cláusulas. Antes de usar una referencia en un pliego, una política de certificación o una auditoría, conviene comprobar la versión y las adaptaciones en el anexo del acto publicado en el DOUE.
  • Erratas en los actos. Algunas referencias aparecen con errores tipográficos en el DOUE: «EN 3191 22-1» (CIR 2024/2979), «EN 310 401», «TS 301 549», «EN 119 511» y «EN 319 182-1» (anexo II del CIR 2025/2162). En este catálogo se han asignado a la norma correcta.
  • Especificaciones que no son de ETSI, CEN ni ISO. Los actos también citan especificaciones de otros organismos que no se incluyen aquí: RFC del IETF (por ejemplo, RFC 3161, RFC 5280, RFC 7515, RFC 7519, RFC 8392 o RFC 8949), el modelo W3C Verifiable Credentials Data Model 1.1, las especificaciones OpenID4VCI y OpenID4VP, la especificación del Cloud Signature Consortium (v2.0), FIPS PUB 140-3 y el documento Agreed Cryptographic Mechanisms del grupo de criptografía del ECCG publicado por ENISA, al que remite el nuevo anexo Ia del CIR 2024/2979.
  • Títulos recientes. Las especificaciones ETSI publicadas en 2025 y 2026 (TS 119 411-8, TS 119 412-6, TS 119 432 v1.3.1, TS 119 472-1/-2/-3, TS 119 475 y TS 119 478), así como la CEN/TS 18170:2025, conviene cotejarlas con el catálogo del organismo, porque sus títulos pueden variar entre versiones.

Como de costumbre, iré actualizando este catálogo a medida que se publiquen nuevos actos de ejecución o correcciones de errores.

Servicios Profesionales de EADTrust

La recopilación y el análisis de esta información forman parte de los Servicios Profesionales de EADTrust. Si tu organización, sea una administración pública o una empresa, está valorando proyectos relacionados con la Cartera de Identidad Digital Europea, las declaraciones electrónicas de atributos o la adaptación a eIDAS2, podemos acompañarte en el análisis normativo, el diseño y la implantación. Escríbenos a info@eadtrust.com o llámanos al 91 716 05 55. Más información en www.eadtrust.eu.

Cómo implementar el registro de jornada digital: hashes encadenados y sellos de tiempo cualificados para un fichaje con valor probatorio


Aviso. Este análisis se basa en el borrador del Real Decreto «por el que se desarrolla el texto refundido de la Ley del Estatuto de los Trabajadores en materia de registro de jornada» que circuló hacia octubre de 2025 (tramitación urgente autorizada por el Consejo de Ministros el 30 de septiembre de 2025). A día de hoy la norma no está publicada en el BOE. Tras el dictamen desfavorable del Consejo de Estado, la tramitación se aplazó y se ha publicado que su tramitación se retoma en septiembre de 2026. Estamos atentos. El texto que finalmente se apruebe puede diferir del que aquí se comenta. Por otro lado, las orientaciones de este blog no pueden considerarse asesoramiento jurídico.

El artículo 34.9 del Estatuto de los Trabajadores ya obliga, desde el 12 de mayo de 2019, a garantizar el registro diario de jornada (inicio y fin), a conservarlo cuatro años y a ponerlo a disposición de la persona trabajadora, de su representación legal y de la Inspección de Trabajo. Ese marco sigue vigente. Admite, hoy, papel, hoja de cálculo u otros medios si el registro es objetivo y fiable.

El borrador de real decreto pretende ir más allá: registro por medios digitales, con un contenido mínimo más amplio, y con tres cualidades definidas (objetividad, fiabilidad y accesibilidad). No impone técnicas como las que voy a describir en este artículo: hashes, sellos de tiempo ni un prestador cualificado. Lo que sigue es una propuesta de implementación para quien quiera que el registro no solo «exista», sino que resista un peritaje o una inspección cuando se discuta si se ha alterado.

Hitos de la tramitación (hasta septiembre de 2026)

  • 8 de marzo de 2019 – El Real Decreto-ley 8/2019 da nueva redacción al artículo 34.9 del Estatuto de los Trabajadores e impone el registro diario de jornada (obligación efectiva desde el 12 de mayo de 2019). Es el marco que sigue vigente.
  • 2024–2025 – La reforma del registro se vincula al proyecto de ley de reducción de jornada a 37,5 horas.
  • Septiembre de 2025 – El proyecto de reducción de jornada decae en el Congreso; el registro de jornada se desgaja y continúa por vía reglamentaria propia.
  • 30 de septiembre de 2025 – El Consejo de Ministros autoriza la tramitación urgente del proyecto de Real Decreto de registro de jornada.
  • Octubre de 2025 – Consulta pública y trámites de audiencia e información pública (es el borrador que se comenta en este artículo).
  • 17 de febrero de 2026 – El expediente entra en el Consejo de Estado.
  • 23 de marzo de 2026 – El Consejo de Estado emite dictamen desfavorable (preceptivo, no vinculante).
  • Junio–julio de 2026 – Discrepancias entre ministerios; el Ministerio de Trabajo se muestra dispuesto a incorporar cambios manteniendo la digitalización como objetivo.
  • 24 de julio de 2026 – Los Ministerios de Trabajo y Economía aplazan la aprobación a septiembre para reelaborar el texto.
  • Septiembre de 2026 – Se retoma la tramitación. A la fecha de este artículo, la norma sigue sin publicarse en el BOE.

Qué dijo el Consejo de Estado (y qué no dijo)

El dictamen de 23 de marzo de 2026 fue desfavorable (concluyó que no procedía aprobar el real decreto en esos términos), si bien no es vinculante y el Gobierno puede continuar la tramitación. Sus objeciones principales, resumidas, fueron:

  • Rango normativo insuficiente. Una obligación de este calado debería articularse por ley tramitada en las Cortes, y no mediante real decreto, por dudas sobre la cobertura legal.
  • Impacto económico infravalorado. Consideró poco realista la estimación de coste del Ministerio (del orden de 55 € por trabajador y año) y cifró un impacto muy superior para las pymes (según el dictamen, del orden de 800–900 millones de euros al año).
  • Falta de adaptación sectorial. Un sistema único no encaja igual en todos los sectores (hostelería, ferrocarril, construcción, empleo del hogar,…); pidió excepciones y mayor flexibilidad.
  • Garantías de protección de datos. La AEPD informó en sentido desfavorable. Advirtió que la protección frente a riesgos no puede quedar en meras alegaciones y cuestionó el acceso remoto de la Inspección sin salvaguardas técnicas concretas.
  • Urgencia y plazo. No vio justificada la vía de urgencia y consideró escaso el periodo de adaptación de apenas 20 días.

En este contexto, se refuerza la idea de que si se digitaliza el registro, la integridad tiene que ser demostrable, no solo declarada. Por eso puede ayudar contar con servicios de confianza: un registro con integridad demostrable y una capa de custodia independiente responden justamente a esas preocupaciones, con independencia del rango final de la norma.

Qué pide el borrador

El borrador desarrolla los artículos 12.4.c), 34.9 y 35.5 del Estatuto de los Trabajadores. En lo que aquí importa:

  • Registro diario por medios digitales (con matices: en el servicio del hogar se admite un medio proporcionado a los recursos; las actividades con normativa específica se rigen por esta en lo que no sea incompatible).
  • Objetividad: información imparcial, perceptible e «indiscutible» (en el sentido del propio borrador: calidad del dato registrado, no un sello mágico de inatacabilidad judicial).
  • Fiabilidad: los asientos no se modifican sin autorización de empresa y de la persona trabajadora; toda modificación deja huella clara e indeleble de los cambios y de su autoría.
  • Accesibilidad: uso sencillo, sin discriminación.
  • Asiento libre, personal, directo e inmediato al inicio y al fin de cada situación que deba registrarse.
  • Contenido mínimo más amplio que el inicio y el fin: régimen de jornada, pausas no computables, presencial o a distancia, naturaleza de las horas, tiempos de espera, interrupciones de la desconexión, medidas de conciliación o irregularidad, totalización diaria y mensual, y autoría de las modificaciones.
  • Conservación cuatro años.
  • Consulta y copia inmediatas por la persona trabajadora; resumen con el recibo de salarios; acceso de la representación legal con minimización de datos; acceso de la Inspección remoto y presencial, en cualquier momento.
  • Formato tratable, legible y compatible.
  • Protocolo interno, evaluación periódica y formación (el tiempo de formación es tiempo de trabajo).

El artículo 5 del borrador presume, salvo prueba en contrario, que un sistema que cumpla los requisitos técnicos de futuras disposiciones de desarrollo respeta los artículos 2 y 3. Esas disposiciones aún no existen.

La propuesta: un diario append-only con cadena de hashes y cierre diario sellado

La idea es sencilla: no modificar los datos ya registrados. Cada hecho (entrada, salida, pausa, corrección) se añade. Nunca se sustituye un asiento anterior.

Propongo usar dos piezas que se refuerzan entre sí.

1) Encadenamiento de hashes

Para cada asiento n:

  1. Se construye un registro canónico (mismos campos, mismo orden, misma codificación y misma zona horaria; por ejemplo UTC con offset explícito). Ahí entra, como mínimo, el contenido del artículo 3 del borrador.
  2. Se calcula hash1(n) = H(registro_canónico_n).
  3. Se calcula hash2(n) = H(hash2(n-1) || hash1(n)).
    En el primer asiento del día, hash2(n-1) es el hash2 de cierre del día anterior (o un valor inicial público y documentado).

H debe ser una función hash criptográfica de uso general (por ejemplo SHA-256 o SHA-3). El detalle del algoritmo, la canonicalización y el valor inicial tienen que estar en el protocolo interno; si no, dos implementaciones distintas (aun auditadas) no obtendrán el mismo hash.

Cualquier cambio en un asiento pasado rompe la cadena a partir de ese punto. Eso es una huella detectable de alteración. No es, por sí sola, prueba de que el fichaje original fuera veraz ni de que lo hiciera la persona trabajadora.

En otros artículos de este blog he llamado RJT (Replicated Journal Technology) a un diario append-only replicado. No es un estándar ETSI ni un RFC: es una forma de describir este tipo de libro diario.

2) Cierre diario con sello de tiempo cualificado

Al cierre de cada día se toma el último hash2 y se solicita un sello de tiempo cualificado sobre ese hash (RFC 3161 / ETSI EN 319 422), emitido por un prestador cualificado.

Aquí se tienen en cuenta, dos artículos del Reglamento eIDAS:

  • Artículo 42: requisitos del sello cualificado (vinculación criptográfica fecha-datos, fuente ligada a UTC, firma o sello del prestador cualificado).
  • Artículo 41.2: efecto jurídico. El sello cualificado presume (admite prueba en contrario) la exactitud de la fecha y hora que indica y la integridad de los datos a los que esa fecha y hora están vinculadas.

Qué prueba, entonces, el sello diario: que ese hash de cierre existía en ese instante y no se ha alterado desde entonces. Qué no prueba: que cada fichaje intramardía se produjo exactamente a la hora que figura en el asiento. Esa hora intramardía depende del reloj del sistema, salvo que se selle (o se ancle de otro modo auditable) cada evento, no solo el cierre.

Las modificaciones autorizadas no reescriben el asiento original: se añade uno nuevo que identifica el asiento afectado, el autor, el momento, el motivo y, si hay discrepancia, la posición de cada parte. Así se cumple la lógica del borrador (autorización dual y huella) sin romper la cadena.

Conservación y puesta a disposición: informes periódicos en el eArchivo

Una capa de custodia ante un prestador cualificado (archivo electrónico / cartulario) puede guardar, cada mes, un informe consolidado sellado del periodo: totalizaciones, resumen entregado con la nómina, hash de cierre de cada día y evidencia de los sellos. Eso ayuda a la conservación a cuatro años y a reconstruir el estado del diario si el sistema de producción falla.

No sustituye:

  • el registro diario en el que se practican los asientos;
  • la consulta inmediata de la persona trabajadora sobre sus asientos;
  • el acceso inmediato, remoto y presencial de la Inspección al sistema;
  • el formato tratable del registro vivo.

La obligación sigue siendo del empleador. El prestador aporta sellado y, en su caso, custodia de evidencias. Tampoco hay que situar el registro en zonas de acceso público ni permitir que un tercero fiche por la persona trabajadora: la criptografía no sana un asiento que no sea personal, directo e inmediato.

Checklist de requisitos (según el borrador)

Lista para verificar un sistema de registro frente al borrador. Recordatorio: el texto definitivo que se publique en el BOE puede cambiar estos puntos.

Obligación y forma

  • ☐ Registro diario y por medios digitales de toda persona trabajadora.
  • ☐ Sistema objetivo (imparcial, perceptible e indiscutible), fiable y accesible.
  • ☐ Asientos inmodificables sin autorización; toda modificación con huella indeleble y autoría.

Contenido mínimo

  • ☐ Identificación de la persona trabajadora.
  • ☐ Régimen de jornada (completa/parcial, con porcentaje de parcialidad).
  • ☐ Inicio y fin de cada jornada (hora y minuto).
  • ☐ Inicio y fin de las pausas no computables como trabajo efectivo.
  • ☐ Trabajo presencial o a distancia.
  • ☐ Naturaleza de las horas (ordinarias, extraordinarias o complementarias; y si las extra se compensan o retribuyen).
  • ☐ Tiempos de espera y a disposición de la empresa.
  • ☐ Interrupciones del derecho a la desconexión.
  • ☐ Horas por conciliación, flexibilidad o distribución irregular.
  • ☐ Totalización diaria y mensual.
  • ☐ Identificación, autorizaciones y autoría de todas las modificaciones.

Práctica de los asientos y conservación

  • ☐ Asiento libre, personal, directo e inmediato al iniciar y al terminar.
  • ☐ Modificaciones autorizadas; discrepancias trasladadas a la representación legal.
  • ☐ Asientos sin condicionamiento ni presión.
  • ☐ Alternativa ante incidencia técnica, con paso posterior a soporte digital.
  • ☐ Registro no accesible a terceros ni en zonas de acceso público.
  • ☐ Conservación durante cuatro años.

Requisitos técnicos y prueba

  • ☐ Cumplir los requisitos técnicos de desarrollo, o un sistema alternativo con informe de técnico competente.
  • ☐ Aprovechar la presunción de conformidad para quien cumpla la totalidad de requisitos técnicos.

Acceso, copia y organización

  • ☐ Consulta y copia inmediatas por la persona trabajadora; resumen con el recibo de salarios.
  • ☐ Acceso de la representación legal (con minimización de datos personales).
  • ☐ Acceso remoto y presencial de la Inspección de Trabajo, en cualquier momento.
  • ☐ Formato tratable, legible y compatible.
  • ☐ Protocolo de organización y documentación, con evaluación periódica y participación de la representación legal.
  • ☐ Formación a las personas que asienten o accedan (tiempo de trabajo; coste no repercutible).

En resumen

El borrador (si se aprueba en términos parecidos) pedirá un registro digital objetivo, fiable y accesible.

Un diario encadenado con cierre diario sellado mejora la integridad demostrable y encaja con la idea de huella indeleble. Un sello cualificado, por el artículo 41 eIDAS, presume fecha e integridad del hash sellado; no convierte en indiscutible ni la hora de cada fichaje ni la veracidad de la jornada.

Cuando el texto salga en el BOE habrá que ajustar el detalle (plazo de adaptación, requisitos técnicos de desarrollo, especialidades). El criterio no cambia: separar el sistema con el que se ficha, la prueba de que ese sistema no se ha reescrito, y la custodia de lo que se quiera conservar fuera de la aplicación de producción.

Lo que añade esta propuesta (no es requisito legal hoy)

  • Diario append-only.
  • hash1 / hash2 documentados y verificables.
  • Sello cualificado de cierre diario sobre el último hash2.
  • Correcciones como asientos nuevos, nunca como tachadura invisible.
  • Depósito periódico de informes sellados, además del sistema operativo.

Cuando el texto se publique en el BOE, ajustaremos el detalle; el enfoque, previsiblemente, seguirá siendo válido.


Cómo puede ayudar EADTrust

EADTrust (European Agency of Digital Trust) puede intervenir en dos planos complementarios:

  • Servicios de confianza. Sellado de tiempo cualificado y archivo electrónico (eArchivo / Cartulario) para robustecer el registro de jornada: cierres diarios anclados en el tiempo, integridad demostrable y custodia de los informes periódicos con valor probatorio, a disposición de la empresa, la representación legal y la Inspección.
  • Servicios Profesionales. Nuestra división de Servicios Profesionales asesora a las empresas que desarrollan sistemas de control horario para diseñar la mejor solución técnica desde el inicio (hashes encadenados, sellado, trazabilidad de modificaciones, conservación y accesibilidad), y también audita soluciones ya desarrolladas para verificar y garantizar que cumplen todos los requisitos exigibles.

¿Hablamos? Tanto si va a incorporar servicios de confianza a su registro de jornada, como si desarrolla una solución de control horario o necesita auditar la que ya tiene, en EADTrust podemos ayudarle a hacerlo con garantías de integridad y valor probatorio.
Web: www.eadtrust.eu · Correo: info@eadtrust.com · Teléfonos: 902 365 612 y 91 716 05 55.

From qualified preservation of electronic signatures and seals to qualified chronological-order archiving services (qDLT)


On 14 September 2026 I took part, in Tallinn (Estonia), in the ETSI ESI Certification Authority (CA) Open Session. I went as an attendee, but by the end of the afternoon I ended up on the panel as a speaker.

The slot had been planned for Steffen Schwalm, who in the end could not attend, and I was asked to step in to talk about how the standardisation of distributed ledger technologies (DLT) is evolving and, in particular, about what we are beginning to call qDLT: the qualified distributed ledger.

I was glad to accept, although (given the short time available to think about what to say) I told my own ideas, not those of the announced speaker.

And in this summary I set out those ideas about what is happening in the standardisation of DLTs: not so much a technological revolution arriving from outside to reinvent digital trust, but a very coherent evolution of something we have been building in Europe for almost a decade. The line of reasoning runs from the preservation of qualified signatures and seals to the ordering of archived files with respect to the moment their custody was requested from the Trust Service Provider. This is how I see it.

The starting point: preserving qualified electronic signatures and seals

The first piece is the one that has been standardised longest, and the one we sometimes forget to mention when we talk about blockchain as if it were virgin territory. Under the umbrella of the first eIDAS, ETSI developed the standard TS 119 511 (the one we usually cite simply as «511») which sets the policy and security requirements for providers offering long-term preservation of electronic signatures (or of data in general) using digital-signature techniques. Its companion, TS 119 512, defines the protocols for interoperating with those preservation services. This first variant (the qualified preservation of qualified electronic signatures and qualified electronic seals) already has its own implementing act: Commission Implementing Regulation (EU) 2025/1946, adopted on the basis of Articles 34(2) and 40 of the eIDAS Regulation. It is worth noting that these are original eIDAS articles, plain numbers, with none of the letter suffixes (Article 45a, 45b, 45c…) that English-language EU legislation uses to mark the provisions eIDAS2 kept inserting; its annex points to ETSI TS 119 511 (together with TS 119 172-4) as the reference standard.

The problem 511 solves is subtle but enormous: an electronic signature is valid today because the certificate backing it is still in force, because the cryptographic algorithms used are considered robust, and because there is an infrastructure that confirms it. But time erodes all of that. Certificates expire, authorities change, and (increasingly relevant ) algorithms age. A qualified preservation service keeps the evidence alive: it periodically reasserts integrity and validity through new time stamps or preservation techniques (such as chained hashes) and new layers of cryptographic protection, so that twenty years from now one can still prove that the document was signed and has not been altered.

This is worth pausing on, because it is exactly the ground where crypto-agility and post-quantum cryptography stop being an academic debate. Preserving for the long term means, by definition, surviving the moment when today’s algorithms cease to be trustworthy. A good preservation service is, at heart, a machine designed to migrate algorithms without losing the evidentiary thread. Whoever understands 511 already understands half of why the rest of this story matters.

The second step: qualified electronic archiving

The second eIDAS (Regulation (EU) 2024/1183) threw nothing away. It broadened. Among the new qualified trust services appears qualified electronic archiving, abbreviated in English jargon as q-earchiving, which in the European standardisation work relies on the technical specification CEN/TS 18170. Its implementing act is Commission Implementing Regulation (EU) 2025/2532, of 16 December 2025, adopted on the basis of Article 45j(2) of the Regulation (the provision eIDAS2 added for qualified electronic archiving) whose annex points precisely to CEN/TS 18170:2025 as the reference standard.

The difference with signature preservation is one of scope. 511 focuses on maintaining the validity of the cryptographic evidence of a signed document. Qualified archiving goes a step further and deals with the document as an object that must be kept intact, legible and available over time, whether signed or not, including the guarantee of its integrity, the traceability of access, and retention policies. It is the regulatory translation of a very old need — the archive — into the language of qualified trust services. For the first time, a provider can offer archiving with the same level of legal assurance already enjoyed by the signature, the seal or the time stamp.

And it is worth clearing up a common misunderstanding: archiving does not replace signature preservation, it relies on it. 511 remains the piece that guarantees the survival of the signature evidence, so a qualified electronic archiving provider can use the services of a preservation provider for that part, turning to a 511 service to keep alive the signatures and seals of the documents it holds. These are not competing services but complementary ones: archiving orchestrates the custody of the file and delegates to preservation the long-term care of the cryptographic evidence. It is exactly the layered logic that runs through this whole article.

There is also a second function of archiving worth highlighting, because it often goes unnoticed: format conversion. Keeping a document for decades is not only about its bits not changing; it is about it remaining legible. And formats age too. A file format that is universal today may become obsolete and fall out of use in favour of others, and when that happens the archiving service must be able to convert the document to the new format while preserving its content, its faithful rendering and its evidentiary value. It is, in the realm of formats, the exact parallel of what preservation does in the realm of algorithms: just as a 511 service migrates cryptographic algorithms before they cease to be trustworthy, an archiving service migrates formats before they cease to be openable. Future legibility of the data and future robustness of the cryptography are two sides of the same promise: that twenty years from now the document will not only exist, but can be opened and proven.

If preservation protects the signature, archiving protects the file. And the next step is to ask what happens when what we need to protect is not an isolated document, but the relationship among many facts over time.

The third step: temporal ordering

Here comes the most interesting novelty of the second eIDAS: electronic ledgers as a new qualified trust service. The reference specification is CEN/TS 18264, published in 2025.

And its implementing act, from the same December 2025 batch, is Commission Implementing Regulation (EU) 2025/2531, adopted on the basis of Article 45l(3) of the Regulation (the provision eIDAS2 devoted to qualified electronic ledgers).

I prefer to explain it with a simple idea: an electronic ledger is a chronologically ordered archive. It does not merely store data entries; it guarantees their temporal sequence in such a way that none can be inserted, deleted or reordered without it showing. It is, if you like, time-stamping raised to the level of a structure: we do not mark a single document with a date, but build a chain of events whose ordering is itself the proof.

And once we accept that what adds value is the guaranteed chronological ordering, the technical question that gives the session its name arises: how is that order built? And there are two legitimate answers.

The first is to use a centralised infrastructure: a single qualified provider maintains the ledger, seals it and is accountable for its integrity. It is simple to audit and fits perfectly into the qualified-provider model we already know.

The second is to use an infrastructure of interconnected nodes that replicate the information (sometimes called a distributed infrastructure): the chronological order is built through the connection of nodes that agree among themselves (through governance rules) on the sequence of entries. This is where distributed ledger technology (DLT) comes into play — not as a fashion, but as a concrete way of achieving that ordering without depending on a single point. When that distributed ledger is provided with the guarantees of a qualified trust service, we speak of qDLT: a qualified distributed ledger.

Allow me a terminological note here that I have been making for some time. The Regulation has enshrined the term DLT (Distributed Ledger Technology), and I stick to it for regulatory rigour. But, if we were to name the idea precisely, I would rather speak of RJT (Replicated Journal Technology). The reason is accounting: in double-entry bookkeeping, the chronological order of events is not kept in the ledger (the general ledger, which groups entries by account) but in the journal (the day book, which records them one after another as they happen). And since what we are preserving here is precisely the temporal sequence, the fitting name for this technology should point to the replicated journal rather than to the distributed ledger. It is, most likely, a terminological battle already lost against the official text, but no less accurate for that.

A good European example of this approach is EBSI, the European Blockchain Services Infrastructure, today governed through the figure of the Europeum-EDIC (a European digital-infrastructure consortium). EBSI shows that the distributed model is not incompatible with qualified trust: the nodes can be operated by identified administrations and providers, with governmental trust anchors, so that the result combines the resilience of distribution with the legal accountability that the eIDAS framework demands.

And it is worth noting a detail of Commission Implementing Regulation (EU) 2025/2531, because it captures this duality precisely. The implementing act requires all providers of qualified electronic ledgers to comply with the standard ETSI EN 319 401 (general policy requirements for trust service providers) and adds specific requirements for the distributed variant: when the ledger is built through nodes, the provider must also comply with ISO 23257:2022 (reference architecture for distributed ledger technologies) and ISO/TS 23635:2022 (governance guidelines). In other words, it is the implementing act itself that recognises the two variants and reserves the DLT consensus and governance standards for the distributed case, which is when we speak, properly, of qDLT. Regulation, once again, does not impose a technology: it describes guarantees and leaves the way of achieving them open.

It is worth underlining the regulatory continuity: from preservation (511) we move to qualified archiving (18170), and from there to chronological ledger, or qDLT (18264). These are not three worlds but three layers of a single idea that keeps gaining ambition: first, keeping an electronic signature fully effective; then, holding a document (signed or not) while guaranteeing its future recovery; and finally, ordering and relating the facts in a verifiable way, when that order can produce legal effects.

What a chronological ledger makes possible

The part I find most interesting (and to which I devoted much of my intervention) is not the ledger technology itself, but the functionalities it enables when we register not only the document but also its context: who its owner is, what rights it embodies and how it evolves. A well-designed chronological ledger opens the door to three capabilities that until now were hard to bring into the digital world with full guarantees.

The first is transferability (or endorsability). If the ledger records not only that a document exists, but also who its holder is, then it can equally record the transfer of that ownership. This is what allows an electronic file to be treated as an asset that changes hands: think of commercial paper, of documents of title to goods, or of any right that was traditionally «endorsed» on paper. The chronological ledger turns the chain of endorsements into a verifiable sequence of entries.

The second is obliterability (or cancellability). A right is not only transferred: it is also consumed. If a file represents a cinema ticket or admission to a show, we need to be able to mark that the right has already been exercised, so that it cannot be used twice. The ledger does not delete the entry (the evidence remains) but records indelibly its change of state: issued, transferred, consumed. It is the difference between crossing out and throwing away: the fact that a right has been exhausted is, in itself, a fact worth recording. The postmark is a good example.

The third is completeness, which I like to describe as an electronic staple. A document rarely travels alone. A contract carries annexes; a deed carries endorsements; an agreement evolves through successive versions. Think of contractual novations, in which the parties agree to modify the clauses: what matters legally is not only the latest text, but the complete relationship between the original document, its annexes and each of its evolutions. Completeness consists of keeping the document and everything that accompanies it (notes, annexes and their own versions) verifiably bound together, so that the whole is preserved as an indivisible and traceable unit. The staple does not just hold papers together: it records the order in which they were joined.

These three functionalities share one trait: they are only possible if the ledger stores more than the document. It stores its ownership, its state and its relationships. And they are only trustworthy if that information is ordered in time in a way that cannot be tampered with. That is why the qualified chronological ledger is not a technical whim, but the substrate on which one can build services that until now were tied to paper or to closed trusted intermediaries.

A database with legal ancestry: book-entry securities and EADTrust’s Cartulario

For these three functionalities to be more than a promise, one needs to manage a database associated with the service, with very specific properties: it must record, for each archived object, who its holder is, in what state the embodied right stands (and where or against whom that right is exercised) and how it relates to other documents; and it must do so in such a way that every change is recorded in sequence and is enforceable against third parties. Anyone familiar with securities law will recognise the pattern at once, because it is exactly the one governing the representation of securities through book entries («anotaciones en cuenta» in spanish): an accounting register in which ownership, transfers, encumbrances and the extinction of rights are not documented on a physical certificate but are constituted and proven by their inscription. Transferability is, in that language, the transfer of the entry; obliterability, its cancellation; completeness, the link between the principal entry and its ancillary ones. It is no coincidence: the qualified chronological ledger and the book-entry register solve the same problem (giving certainty about the ownership and state of a right over time) with the same tool: a reliable, ordered database.

At EADTrust we have been working on this idea for a long time. Our Cartulario service was designed many years ago on precisely those premises: treating the archive not as a mere repository of files, but as a register that records ownership, state and relationships, with an eye on functionalities such as endorsability, cancellability and completeness long before the European regulatory framework captured them explicitly.

And since we are on the subject of the name: Cartulario is simply the Spanish word for a cartulary (also spelled chartulary) — in the Middle Ages, the codex in which monasteries and cathedral chapters copied and safeguarded their charters, privileges and donations so they would not be lost (it is, roughly, the great-grandfather of the notarial protocol). So, all things considered, at EADTrust we have been in this business of chronological-order archiving for several centuries before the PDF was invented; the only difference is that we have swapped the vellum for a digital server and the copyist monk for a millisecond-precision time stamp.

And to that foundation Cartulario now adds a refinement that goes straight to the heart of what we were discussing in Tallinn: millisecond-precision (1 ms) time stamps associated with every archiving request. When the proof is the ordering, temporal resolution matters: having a millisecond-precision mark on each operation makes it possible to guarantee the chronological order of entries with far greater fineness, and to resolve the sequence unambiguously even when several requests pile up within a very short interval. It is, in practice, the materialisation of that idea of a «chronologically ordered archive» from which this whole line of reasoning starts.

Why this fits with the rest of the ecosystem

I do not want to close the article without connecting this story to the broader conversation about European digital identity. The ecosystem of the European wallet (EUDI Wallet) and of electronic attestations of attributes needs solid trust anchors: places where one can verifiably record who said what, about whom and when. A qualified chronological ledger (centralised or in the form of qDLT) is precisely one of those anchors. It can join the world of identity with the legal accountability of the eIDAS framework.

And all of this still rests on the first stone I mentioned at the beginning: the ability to preserve evidence over the long term and to migrate algorithms when needed. The arrival of post-quantum cryptography does not invalidate this architecture; on the contrary, it makes it more necessary. A ledger that orders documents in time must be, by design, a ledger capable of surviving the passage of time, including the time when today’s algorithms cease to protect us or the document-encoding formats are replaced by others.

That was, in essence, my thesis in Tallinn: that DLT and qDLT do not appear out of nowhere, but are the next natural rung on a ladder that began by preserving signatures, went on to archive documents, and is now learning to order facts. Seeing it this way helps a great deal not to get lost: each new standard does not replace the previous one, it adds a layer of ambition to it.

And here is my presentation summarising this article:

Try Cartulario

If you would like to experiment with these ideas on a real service, at EADTrust we make Cartulario available to anyone who wishes to try it. Its current nature is worth stating with full transparency: today it is offered as a non-qualified trust service and is pending audit to be considered a qualified service within the eIDAS framework. This distinction is no minor nuance (it is, precisely, the line that separates a trust service from a qualified trust service), and we prefer to make it clear from the outset.

Anyone who wishes to learn about it, propose a pilot project or discuss use cases (endorsability, cancellability, completeness or millisecond-precision time-stamping) can write to us at info@eadtrust.com or call us at +34 902 365 612 / +34 91 716 05 55. More information at www.eadtrust.eu.

De la conservación cualificada de firmas y sellos a los servicios cualificados de archivo con orden cronológico (qDLT)


El pasado 14 de septiembre de 2026 participé en Tallin (Estonia) en el evento ETSI ESI Certification Authority (CA) Open Session. Al principio como asistente, pero al final de la tarde participé como panelista.

La intervención estaba prevista para Steffen Schwalm, que finalmente no pudo asistir, y me pidieron que me incorporara para hablar de cómo evoluciona la estandarización de las tecnologías de registro distribuido (DLT) y, en particular, de lo que empezamos a llamar qDLT: el registro distribuido cualificado.

Acepté encantado, aunque conté mis ideas, no las del ponente anunciado, tras el corto plazo disponible para reflexionar sobre qué contar.

Y en este resumen recojo esas ideas sobre lo que está ocurriendo en la normalización de DLTs, no tanto como una revolución tecnológica que llega de fuera para reinventar la confianza digital, sino una evolución muy coherente de algo que llevamos casi una década construyendo en Europa. La cadena de razonamiento va desde la conservación de firmas y sellos cualificados a la ordenación de archivos respecto al momento en el que se pidió su custodia al Prestador de Servicios de Confianza. Así es como lo veo:

El punto de partida: conservar firmas y sellos cualificados

La primera pieza es la que lleva más tiempo normalizada y la que a veces olvidamos citar cuando hablamos de blockchain como si fuera terreno virgen. Bajo el paraguas del primer eIDAS, ETSI desarrolló la norma TS 119 511 (la que solemos citar simplemente como «511»), que fija los requisitos de política y de seguridad para los prestadores que ofrecen conservación a largo plazo de firmas electrónicas (o de datos en general) mediante técnicas de firma digital. Su compañera, la TS 119 512, define los protocolos para interoperar con esos servicios de conservación. Esta primera variante —la conservación cualificada de firmas electrónicas cualificadas y de sellos electrónicos cualificados— cuenta ya con su propio acto de ejecución: el Reglamento de Ejecución (UE) 2025/1946, dictado al amparo de los artículos 34, apartado 2, y 40 del Reglamento EIDAS. Conviene reparar en que estos son artículos originales de eIDAS y, por tanto, no llevan la numeración latina bis, ter, quater… propia de los preceptos que eIDAS2 fue insertando; su anexo remite a la ETSI TS 119 511 (con la TS 119 172-4) como norma de referencia.

El problema que resuelve la 511 es sutil pero enorme: una firma electrónica es válida hoy porque el certificado que la respalda está vigente, porque los algoritmos criptográficos empleados se consideran robustos y porque existe una infraestructura que lo confirma. Pero el tiempo erosiona todo eso. Los certificados caducan, las autoridades cambian, y (esto es cada vez más relevante) los algoritmos envejecen. Un servicio de conservación cualificado mantiene viva la evidencia: reafirma periódicamente la integridad y la validez mediante nuevos sellos de tiempo o técnicas de preservación (como hashes encadenados) y nuevas capas de protección criptográfica, de modo que dentro de veinte años se pueda seguir demostrando que aquel documento estaba firmado y que no ha sido alterado.

Aquí conviene detenerse, porque este es exactamente el terreno donde la criptoagilidad y la criptografía postcuántica dejan de ser un debate académico. Conservar a largo plazo significa, por definición, sobrevivir al momento en que los algoritmos actuales dejen de ser fiables. Un buen servicio de conservación es, en el fondo, una máquina diseñada para migrar de algoritmos sin perder el hilo probatorio. Quien entienda la 511 entiende ya la mitad de por qué el resto de esta historia importa.

El segundo paso: el archivado electrónico cualificado

El segundo eIDAS (el Reglamento (UE) 2024/1183) no tiró nada de lo anterior. Lo amplió. Entre los nuevos servicios cualificados de confianza aparece el archivado electrónico cualificado, lo que en la jerga anglosajona se abrevia como q-earchiving y que en el desarrollo normativo europeo se apoya en la especificación técnica CEN/TS 18170. Su acto de ejecución es el Reglamento de Ejecución (UE) 2025/2532, de 16 de diciembre de 2025, dictado al amparo del artículo 45 undecies, apartado 2, del Reglamento (el precepto que eIDAS2 añadió para el archivado electrónico cualificado), cuyo anexo remite precisamente a la CEN/TS 18170:2025 como norma de referencia.

La diferencia con la conservación de firmas es de alcance. La 511 se centra en mantener la validez de la evidencia criptográfica de un documento firmado. El archivado cualificado va un paso más allá y se ocupa del documento como objeto que debe conservarse íntegro, legible y disponible a lo largo del tiempo, esté firmado o no, incluyendo la garantía de su integridad, la trazabilidad de accesos y las políticas de retención. Es la traducción normativa de una necesidad muy antigua (el archivo) al lenguaje de los servicios cualificados de confianza. Por primera vez, un prestador puede ofrecer archivado con el mismo nivel de garantía jurídica que ya tenían la firma electrónica, el sello electrónico o el sellado de tiempo.

Y merece la pena deshacer un malentendido frecuente: el archivado no sustituye a la conservación de firmas, sino que se apoya en ella. La propia 511 sigue siendo la pieza que garantiza la pervivencia de la evidencia de firma, de modo que un prestador de archivado electrónico cualificado puede utilizar los servicios de un prestador de conservación para esa parte (recurrir a un servicio 511 para mantener vivas las firmas y sellos de los documentos que custodia). No estamos ante servicios que compiten, sino ante servicios que se complementan: el archivado orquesta la custodia del expediente y delega en la conservación el cuidado a largo plazo de la evidencia criptográfica. Es exactamente la lógica de capas que recorre todo este artículo.

Hay además una segunda función del archivado que merece destacarse porque a menudo pasa desapercibida: la conversión de formatos. Custodiar un documento durante décadas no consiste solo en que sus bits no cambien; consiste en que siga siendo legible. Y los formatos también envejecen. Un formato de fichero que hoy es universal puede quedar obsoleto y dejar de utilizarse en favor de otros, y cuando eso ocurra el servicio de archivado debe poder convertir el documento al nuevo formato preservando su contenido, su presentación fiel y su valor probatorio. Es, en el plano de los formatos, el paralelo exacto de lo que la conservación hace en el plano de los algoritmos: así como un servicio 511 migra de algoritmos criptográficos antes de que dejen de ser fiables, un servicio de archivado migra de formatos antes de que dejen de poder abrirse. Legibilidad futura de los datos y robustez futura de la criptografía son las dos caras de la misma promesa: que dentro de veinte años el documento no solo exista, sino que se pueda abrir y demostrar.

Si la conservación protege la firma, el archivado protege el expediente. Y el siguiente paso es preguntarse qué ocurre cuando lo que necesitamos proteger no es un documento aislado, sino la relación entre muchos hechos a lo largo del tiempo.

El tercer paso: orden temporal

Aquí entra la novedad más interesante del segundo eIDAS: los registros electrónicos (electronic ledgers) como nuevo servicio cualificado de confianza. La especificación de referencia es CEN/TS 18264, publicada en 2025.

Y su acto de ejecución, del mismo lote de diciembre de 2025, es el Reglamento de Ejecución (UE) 2025/2531, dictado al amparo del artículo 45 terdecies, apartado 3, del Reglamento (el precepto que eIDAS2 dedicó a los registros electrónicos cualificados).

Yo prefiero explicarlo con una idea sencilla: un registro electrónico es un archivo de orden cronológico. No solo guarda entradas de datos, sino que garantiza su secuencia temporal de forma que ninguna se pueda insertar, borrar o reordenar sin que se note. Es, si se quiere, un sellado de tiempo elevado a la categoría de estructura: no marcamos un único documento con una fecha, sino que construimos una cadena de acontecimientos cuya ordenación es en sí misma la prueba.

Y una vez que aceptamos que lo que aporta valor es la ordenación cronológica garantizada, surge la pregunta técnica que da nombre a la sesión: ¿cómo se construye ese orden? Y hay dos respuestas legítimas.

La primera es usando una infraestructura centralizada: un único prestador cualificado mantiene el registro, lo sella y responde de su integridad. Es sencillo de auditar y encaja perfectamente en el modelo de prestador cualificado que ya conocemos.

La segunda es usando una infraestructura de nodos interconectados que replican la información (a veces llamada infraestructura distribuida): el orden cronológico se construye mediante la conexión de los nodos que acuerdan entre sí (por las reglas de gobernanza) la secuencia de las entradas. Aquí es donde la tecnología de registro distribuido (DLT) entra en juego, no como una moda, sino como una forma concreta de lograr esa ordenación sin depender de un único punto. Cuando ese registro distribuido se presta con las garantías de un servicio cualificado de confianza, hablamos de qDLT: un registro distribuido cualificado.

Permítaseme aquí un apunte terminológico que vengo defendiendo desde hace tiempo. El Reglamento ha consagrado el término DLT (Distributed Ledger Technology, tecnología de registro distribuido), y a él me atengo por rigor normativo. Pero, puestos a bautizar la idea con precisión, yo preferiría hablar de RJT (Replicated Journal Technology). La razón es contable: en la partida doble, el orden cronológico de los hechos no se guarda en el ledger (el libro mayor, que agrupa los apuntes por cuenta), sino en el journal (el libro diario, que los anota uno tras otro según van ocurriendo). Y como lo que aquí estamos preservando es justamente la secuencia temporal, el nombre idóneo a adoptar para esta tecnología debería orientarse al diario replicado antes que al mayor distribuido. Es, seguramente, una batalla terminológica ya perdida frente al texto oficial, pero no por ello menos exacta.

Un buen ejemplo europeo de esta aproximación es EBSI, la infraestructura europea de servicios blockchain, hoy gobernada a través de la figura del Europeum-EDIC (un consorcio de infraestructura digital europea). EBSI muestra que el modelo distribuido no es incompatible con la confianza cualificada: los nodos pueden estar operados por administraciones y prestadores identificados, con anclas de confianza gubernamentales, de modo que el resultado combina la resiliencia de la distribución con la responsabilidad jurídica que exige el marco eIDAS.

Y vale la pena fijarse en un detalle del Reglamento de Ejecución (UE) 2025/2531, porque recoge con precisión esta dualidad. El acto de ejecución exige a todos los prestadores de registros electrónicos cualificados cumplir con la norma ETSI EN 319 401 (requisitos generales de política para prestadores de servicios de confianza) y añade requisitos específicos para la variante distribuida: cuando el registro se construye mediante nodos, el prestador debe cumplir además la ISO 23257:2022 (arquitectura de referencia de las tecnologías de registro distribuido) y la ISO/TS 23635:2022 (directrices de gobernanza). Dicho de otro modo, es el propio acto de ejecución el que reconoce las dos variantes y reserva las normas de consenso y gobernanza de DLT para el caso distribuido, que es cuando hablamos con propiedad de qDLT. La regulación, una vez más, no impone una tecnología: describe garantías y deja abierta la forma de alcanzarlas.

Merece la pena subrayar la continuidad normativa: de conservación (511) pasamos a archivado cualificado (18170) y de ahí a registro cronológico o qDLT (18264). No son tres mundos, sino tres capas de una misma idea que va ganando ambición: primero mantener con plenos efectos una firma electrónica, luego custodiar un documento (firmado o no) garantizando su recuperación futura, y finalmente ordenar y relacionar los hechos de forma verificable, cuando ese orden pueda producir efectos legales.

Lo que un registro cronológico permite hacer

La parte que más me interesa, y a la que dediqué buena parte de mi intervención, no es la tecnología del registro en sí, sino las funcionalidades que habilita cuando registramos no solo el documento, sino también su contexto: quién es su propietario, qué derechos incorpora y cómo evoluciona. Un registro cronológico bien diseñado abre la puerta a tres capacidades que hasta ahora eran difíciles de trasladar al mundo digital con plenas garantías.

La primera es la transferibilidad (o endosabilidad). Si el registro no anota únicamente que existe un documento, sino también quién es su titular, entonces puede anotar igualmente la transmisión de esa titularidad. Esto es lo que permite tratar un archivo electrónico como un bien que cambia de manos: pensemos en los efectos comerciales, en los títulos representativos de mercancías o en cualquier derecho que tradicionalmente se «endosaba» sobre un papel. El registro cronológico convierte la cadena de endosos en una secuencia verificable de entradas.

La segunda es la obliterabilidad (o cancelabilidad). Un derecho no solo se transmite: también se consume. Si un archivo representa una entrada de cine o el acceso a un espectáculo, necesitamos poder marcar que ese derecho ya se ha ejercido, de forma que no pueda usarse dos veces. El registro no borra la entrada (la evidencia permanece), pero anota de manera indeleble su cambio de estado: emitido, transferido, consumido. Es la diferencia entre tachar y tirar: el hecho de que un derecho se agotó es, en sí mismo, un hecho que merece quedar registrado. Es el caso del matasellos, por ejemplo.

La tercera es la completitud, que a mí me gusta describir como una grapa electrónica. Un documento raramente viaja solo. Un contrato lleva anexos; una escritura lleva anotaciones; un acuerdo evoluciona mediante versiones sucesivas. Pensemos en las novaciones contractuales, en las que las partes acuerdan modificar el clausulado: lo que importa jurídicamente no es solo el último texto, sino la relación completa entre el documento original, sus anexos y cada una de sus evoluciones. La completitud consiste en mantener unidos, de forma verificable, el documento y todo lo que le acompaña (anotaciones, anexos y sus propias versiones), de modo que el conjunto se conserve como una unidad indivisible y trazable. La grapa no solo junta papeles: registra en qué orden se fueron juntando.

Estas tres funcionalidades comparten un rasgo: solo son posibles si el registro guarda más que el documento. Guarda su titularidad, su estado y sus relaciones. Y solo son fiables si esa información está ordenada en el tiempo de forma que no pueda manipularse. Por eso el registro cronológico cualificado no es un capricho técnico, sino el sustrato sobre el que se pueden construir servicios que hasta ahora vivían atados al papel o a intermediarios de confianza cerrados.

Una base de datos con genealogía jurídica: las anotaciones en cuenta y el Cartulario de EADTrust

Para que estas tres funcionalidades sean algo más que una promesa, hace falta gestionar una base de datos asociada al servicio con unas propiedades muy concretas: que registre, para cada objeto archivado, quién es su titular, en qué estado se encuentra el derecho que incorpora (y donde o frente a quien se ejerce este derecho) y cómo se relaciona con otros documentos; y que lo haga de modo que cada cambio quede anotado en secuencia y resulte oponible frente a terceros. Quien conozca el Derecho del mercado de valores reconocerá el patrón de inmediato, porque es exactamente el que rige la representación de valores mediante anotaciones en cuenta: un registro contable en el que la titularidad, las transmisiones, los gravámenes y la extinción de los derechos no se documentan sobre un título físico, sino que se constituyen y se prueban por su inscripción. La transferibilidad es, en ese lenguaje, la transmisión de la anotación; la obliterabilidad, su cancelación; la completitud, el vínculo entre la anotación principal y sus accesorias. No es una coincidencia: el registro cronológico cualificado y el registro de anotaciones en cuenta resuelven el mismo problema —dar certeza sobre la titularidad y el estado de un derecho a lo largo del tiempo— con la misma herramienta: una base de datos fiable y ordenada.

En EADTrust llevamos tiempo trabajando sobre esta idea. Nuestro servicio Cartulario se diseñó hace ya bastantes años partiendo precisamente de esas premisas: tratar el archivo no como un simple depósito de ficheros, sino como un registro que anota titularidad, estado y relaciones, con la vista puesta en funcionalidades como la endosabilidad, la cancelabilidad y la completitud mucho antes de que el marco normativo europeo las recogiera de forma explícita.

Y ya que hablamos del nombre: un cartulario era, en la Edad Media, el códice en el que monasterios y cabildos copiaban y custodiaban sus escrituras, privilegios y donaciones para que no se perdieran (viene a ser el bisabuelo de la matriz notarial). Así que, bien mirado, en EADTrust llevamos en esto del archivo de orden cronológico desde varios siglos antes de que se inventara el PDF; la única diferencia es que hemos cambiado la vitela por un servidor digital y al monje amanuense por un sello de tiempo de precisión de milisegundo.

Y a esa base de partida Cartulario añade ahora un refinamiento que va justo al corazón de lo que discutíamos en Tallinn: sellos de tiempo de precisión de milisegundo (1 ms) asociados a cada solicitud de archivo. Cuando la prueba es la ordenación, la resolución temporal importa: disponer de una marca de tiempo con precisión de milisegundo en cada operación permite garantizar con mucha mayor finura el orden cronológico de las entradas, y resolver sin ambigüedad la secuencia incluso cuando varias solicitudes se acumulan en un intervalo muy breve. Es, en la práctica, la materialización de esa idea de «archivo de orden cronológico» de la que parte todo este razonamiento.

Por qué esto encaja con el resto del ecosistema

No quiero concluir el artículo sin conectar esta historia con la conversación más amplia sobre identidad digital europea. El ecosistema de la cartera europea (EUDI Wallet) y de las declaraciones electrónicas de atributos necesitan anclas de confianza sólidas: lugares donde asentar de forma verificable quién ha dicho qué, sobre quién y cuándo. Un registro cronológico cualificado (centralizado o en forma de qDLT) es precisamente uno de esos anclajes. Puede unir el mundo de la identidad con la responsabilidad jurídica del marco eIDAS.

Y todo ello sigue descansando sobre la primera piedra que mencionaba al principio: la capacidad de conservar la evidencia a largo plazo y de migrar de algoritmos cuando haga falta. La llegada de la criptografía postcuántica no invalida esta arquitectura; al contrario, la hace más necesaria. Un registro que ordena documentos en el tiempo debe ser, por diseño, un registro capaz de sobrevivir al paso del tiempo, incluido el tiempo en que los algoritmos de hoy dejen de protegernos o los formatos de codificación de documentos se sustituyan por otros..

Esa fue, en esencia, mi tesis en Tallinn: que las DLT y el qDLT no aparecen de la nada, sino que son el siguiente peldaño natural de una escalera que empezó conservando firmas, siguió archivando documentos y ahora aprende a ordenar los hechos. Verlo así ayuda mucho a no perderse: cada norma nueva no sustituye a la anterior, sino que le añade una capa de ambición.

Probar Cartulario

Si quieres experimentar con estas ideas sobre un servicio real, en EADTrust ponemos Cartulario a disposición de quienes deseen probarlo. Conviene precisar su naturaleza actual con total transparencia: hoy se ofrece como servicio de confianza no cualificado y está pendiente de auditoría para ser considerado servicio cualificado en el marco de eIDAS. Esa distinción no es un matiz menor (es, precisamente, la línea que separa un servicio de confianza de un servicio cualificado de confianza), y preferimos dejarla clara desde el principio.

Quien quiera conocerlo, plantear un proyecto piloto o comentar casos de uso (endosabilidad, cancelabilidad, completitud o el sellado de tiempo de precisión de milisegundo) puede escribirnos a info@eadtrust.com o llamarnos al 902 365 612 / 91 716 05 55. Más información en www.eadtrust.eu.

Hoy se han publicado 4 nuevos actos de ejecución de desarrollo del Reglamento #EIDAS2


La Comisión Europea ha publicado cuatro nuevos reglamentos de ejecución en el Diario Oficial de la Unión Europea del 17 de diciembre. Ya son varias rondas de actos de ejecución, que comenzaron en diciembre de 2024, y se alcanza la publicación de 26 actos de ejecución.


Los reglamentos de ejecución publicados hoy son los siguientes:

📌 Qarchiv: servicios de archivo electrónico cualificados. REGLAMENTO DE EJECUCIÓN (UE) 2025/2532 DE LA COMISIÓN de 16 de diciembre de 2025 por el que se establecen disposiciones de aplicación del Reglamento (UE) n.o 910/2014 del Parlamento Europeo y del Consejo en lo que respecta a las normas y especificaciones de referencia para los servicios cualificados de archivo electrónico
📌 QELedgers: libros de contabilidad electrónicos cualificados. REGLAMENTO DE EJECUCIÓN (UE) 2025/2531 DE LA COMISIÓN de 16 de diciembre de 2025 por el que se establecen disposiciones de aplicación del Reglamento (UE) n.o 910/2014 del Parlamento Europeo y del Consejo en lo que respecta a las normas y especificaciones de referencia para los libros mayores electrónicos cualificados
📌 QWACs: certificados cualificados para la autenticación de sitios web. REGLAMENTO DE EJECUCIÓN (UE) 2025/2527 DE LA COMISIÓN de 16 de diciembre de 2025 por el que se establecen disposiciones de aplicación del Reglamento (UE) n.o 910/2014 del Parlamento Europeo y del Consejo en lo que respecta a las normas de referencia para los certificados cualificados de autenticación de sitios web
📌 QTSPs: normas de cumplimiento y seguridad: proveedores de servicios de confianza cualificados. REGLAMENTO DE EJECUCIÓN (UE) 2025/2530 DE LA COMISIÓN
de 16 de diciembre de 2025 por el que se establecen disposiciones de aplicación del Reglamento (UE) 910/2014 del Parlamento Europeo y del Consejo en lo que respecta a los requisitos para los prestadores cualificados de servicios de confianza que prestan servicios de confianza cualificados.

Esta es la lista de los actos de ejecución anteriores.

Y el mapa que actualiza permanentement Joerg Lenz:

EAD Trust Factory los servicios cualificados de EADTrust como infraestructura propia de entidades digitalizadas


GoCertius es la base conceptual (con su forma particular de certificar evidencias digitales) sobre la que EADTrust y Garrigues (a través de su división g-digital) han construido los servicios de EAD Trust Factory. Una panoplia de servicios que pasan a formar parte de la infraestructura de nuestros clientes, como si ellos mismos fueran Prestadores Cualificados de Servicios de Confianza Digital.

Son clientes de diferentes tamaños y sectores que así pueden desarrollar entornos de gestión de evidencias electrónicas sacando ventaja de los servicios regulados, tales como los que se describen en el Reglamento europeo eIDAS y su ampliación eiDAS2.

Las soluciones de EAD Trust Factory, al integrar servicios de confianza digital y optimizar procesos legales, pueden beneficiar a diversas industrias que requieren gestión segura y eficiente de documentos y transacciones digitales. De esta forma se pueden optimizar los procesos empresariales de gestión rediseñándolos para que sean completamente digitales y confiables por diseño, sabiendo que se podrá contar con evidencias digitales prescindiendo del papel. Y que estas evidencias podrán acreditar los servicios prestados y su seguridad, con certeza del momento en que se prestaron en cualquier contexto de resolución de controversias.

A continuación, se presentan algunos de los sectores que se benefician de estas soluciones:

  1. Sector Financiero y Seguros:
    • Beneficios: La gestión segura de documentos financieros y la autenticidad de las transacciones son cruciales en este sector. EAD Trust Factory añade servicios cualificados a la infraestructura de cada entidad para ayudar a cumplir con las regulaciones financieras y de protección de datos, como el Reglamento General de Protección de Datos (GDPR), Digital Operational Resilience Act (DORA), Directiva 2022/2555 (NIS2) y el Reglamento 910/2014 eIDAS con los cambios introducidos por el Reglamento 1183/2024.
  2. Industria Legal y Jurídica:
    • Beneficios: La generación de evidencias digitales y la gestión de contratos electrónicos son fundamentales para este sector. EAD Trust Factory facilita la creación de documentos legales electrónicos seguros y auténticos, mejorando la eficiencia en los procesos legales. Por su influencia en otras actividades el punto de vista legal es crucial para entender el ·»Compliance» la presunción Iuris Tantum de los servicios cualificados de confianza
  3. Sector de la Salud:
    • Beneficios: La gestión de registros médicos electrónicos o los Consentimientos Informados requiere altos niveles de seguridad y confianza. EAD Trust Factory puede ayudar a proteger la privacidad de los pacientes y asegurar la integridad de los datos médicos. También ayuda digitalizar historias clínicas, respetando la normativa definida para ellos,
  4. Industria de la Energía y Recursos Naturales:
    • Beneficios: La optimización de procesos y la gestión eficiente de documentos son clave en este sector, donde la seguridad y el cumplimiento normativo son fundamentales. EAD Trust Factory puede ayudar a mejorar la eficiencia operativa y reducir costes. También la contratación se beneficia de un marco regulatorio más garantista.
  5. Sector de Transporte y Logística:
    • Beneficios: La gestión de documentos de transporte y la trazabilidad de mercancías requieren sistemas confiables. EAD Trust Factory proporciona soluciones para asegurar la autenticidad y seguridad en la gestión de documentos relacionados con el transporte y la logística. En particular, albaranes gestionados de forma digital que puedan surtir efecto también como documentos híbridos con versión en papel de ser necesaria.

En resumen, cualquier industria que requiera gestión segura de documentos y transacciones digitales puede beneficiarse de las soluciones de EAD Truat Factory. La plataforma es especialmente útil para sectores con altos requisitos de seguridad y cumplimiento normativo.

EAD Trust Factory está formado por diferentes servicios cualificados de confianza, entre los que destacan los sellos de tiempo`, las notificaciones fehacientes y las comprobaciones de validez de firmas y certificados electrónicos. También el Onboarding digital, incluyendo servicios de Videoidentificación.

Los servicios orquestados por EAD Trust Factory incluyen servicios cualificados de confianza definidos por el reglamento #eIDAS y desarrollos auxiliares que permiten dotar a cualquier proceso que incluya gestión digital de un respaldo regulatorio en forma de evidencias digitales con valor «Iuris Tantum» que aportar tanto en entornos MASC (Medios adecuados de solución de controversias) como contextos de litigación.

Y con infraestructura de Criptoagilidad Postcuántica resistente al futuro Criptocalipsis.

Llame al (+34) 917160555 o envíe un email a info(at)eadtrust.eu para pedir información y compruebe que adoptar recursos técnicos de PSC en su propia infraestructura es más sencillo y económico de lo que parece

Prestadores de servicios de confianza no cualificados


En relación con los Servicios de Confianza, en España rige la Ley 6/2020, de 11 de noviembre, reguladora de determinados aspectos de los servicios electrónicos de confianza, junto con el Reglamento 910/2014 (actualizado con el Reglamento 2024/1183).

En su preámbulo se menciona que

  • Todos los prestadores de servicios de confianza, cualificados y no cualificados, están sometidos a la obligación de adoptar las medidas técnicas y organizativas adecuadas para gestionar los riesgos para la seguridad de los servicios de confianza que prestan, así como de notificar al órgano de supervisión cualquier violación de la seguridad o pérdida de la integridad que tenga un impacto significativo en el servicio de confianza prestado.
  • Los prestadores de servicios no cualificados pueden prestar servicios sin verificación previa de cumplimiento de requisitos, sin perjuicio de su sujeción a las potestades de seguimiento y control posterior de la Administración. No obstante, deberán comunicar al órgano supervisor la prestación del servicio en el plazo de tres meses desde que inicien su actividad, a los meros efectos de conocer su existencia y posibilitar su supervisión

Y en su articulado:

Artículo 12. Inicio de la prestación de servicios electrónicos de confianza no cualificados.

Los prestadores de servicios de confianza no cualificados no necesitan verificación administrativa previa de cumplimiento de requisitos para iniciar su actividad, pero deberán comunicar su actividad al Ministerio de Asuntos Económicos y Transformación Digital en el plazo de tres meses desde que la inicien, que publicará en su página web el listado de prestadores de servicios de confianza no cualificados en una lista diferente a la de los prestadores de servicios de confianza cualificados, con la descripción detallada y clara de las características propias y diferenciales de los prestadores cualificados y de los prestadores no cualificados.

En el mismo plazo deberán comunicar la modificación de los datos inicialmente transmitidos y el cese de su actividad.

Identificación de Prestadores

En la actualidad el Ministerio ya publica la información básica de los Prestadores de Servicios Electrónicos de Confianza No Cualificados como su Nombre/Razón Social, su CIF, el Nombre Comercial y el Dominio, si bien todavía no incorpora la descripción detallada y clara de las características propias y diferenciales.

De la citada página se extrae la siguiente lista de prestadores, respecto a lo que hay que considerar que algunos de ellos son también Prestadores Cualificados de Servicios de Confianza y no queda claro qué servicios no cualificados de los que prestan hace recomendable su inclusión en este listado.

  • 360nrs
  • 3G Mobile Group (Foldersign)
  • Addalia
  • Agencia de Tecnología y Certificación Electrónica – ACCV
  • ANF AC
  • Aplicaciones Inmovilla SLU
  • Aralink Wallet Id
  • Aviva Voice
  • Banco de España
  • Bianca Schulte Gutiérrez
  • Bigle Legal
  • Bounsel
  • BTP Onetec
  • Camerfirma
  • Cedro
  • CEREC Fábrica Nacional De Moneda Y Timbre – Real Casa De La Moneda E.P.E – M.P. (FNMT-RCM)
  • Certificacion De Envios ICPM
  • Certifirm
  • CGI Information Systems and Management Consultants España S.A
  • Codicert
  • Colegio Oficial de Arquitectos de Sevilla
  • Confirmsign, S.L.
  • Consorci AOC (Catcert)
  • Constata EU
  • Customer Comms
  • Digitaldocu Digitel TS
  • Dirección General de Política Digital – Consejería de Hacienda y Adm. Pública – Junta de Andalucía
  • Docalia
  • Docuten
  • Doyfe
  • EADTrust
  • ECS TSA
  • Edatalia
  • Edicom
  • Edigitaltrust
  • Eevidence
  • Efirma Go
  • Egarante
  • Elix Regtech
  • Factorymail
  • Factum Id
  • Fidestamp
  • Fikrea
  • Fingerink
  • Finveris
  • Firma Documentos
  • Firma365
  • Firmafy
  • Firmaprofesional, S.A.
  • Full Certificate – Wevote – Full Signature
  • Gohu TPA
  • Grupo Backup
  • Ianet Conecta S.L.
  • Icommunity
  • Idealista
  • IESA
  • Ilovepdf
  • Isigma
  • Izenpe, S.A.
  • Legal Intermedia «Verum Digital»
  • Legalbono
  • Legalpin
  • Leypal
  • Lleida.Net
  • Lleidanet Pki
  • Logalty Servicios de Tercero de Confianza S.L.
  • Mailsuite
  • Mailteck
  • Mensagia
  • Mensatek
  • Metaposta
  • Ministerio de Asuntos Económicos y Transformación Digital
  • Ministerio de Defensa de España
  • Nivimu
  • Nodalblock
  • Notificad@S
  • On Diversity Limited España
  • Pipeline Software
  • Punto Neutro
  • R2 Docuo
  • RD Post
  • Registradores De España
  • Rubricae
  • Salvador Portillo Naranjo
  • Sectigo
  • Segursign
  • Seres
  • SGNTJ / GGTDAL
  • Signaturit
  • Signaturit- Ivnosys
  • Signe Autoridad De Certificación
  • Signicat Spain
  • Signyourdocs
  • Sihecert, S.L
  • Sinatura
  • Smartbiometrik
  • Softy
  • Spairal Commerce
  • Tecalis
  • Teenvio
  • Terraminium
  • Uanataca
  • Validated Id
  • Vintegris
  • Wiwink
  • Zertiban
  • Zertifika Outsourcing

Me ha parecido interesante publicar información más detallada de las entidades que así lo deseen.

Por ejemplo algunos servicios no cualificados de EADTrust:

Si desea que incluya información adicional de alguno de los prestadores de servicios de confianza no cualificados, contacte conmigo a través de este mail. También si detecta algún error en la denominación.

Ponga al principio del asunto [PSCNC] para facilitar la búsqueda.

SI puede incluir en alguna parte del correo electrónico el texto exacto a incluir es preferible (incluyendo los enlaces), porque así puedo copiar y pegar el texto sin más. También puede incluir un logo si lo desea.

EADTrust, la entidad líder en Digital Transaction Management (DTM)


El concepto Digital Transaction Management (DTM), Gestión de Transacciones Digitales engloba un conjunto de servicios y tecnologías basados en la nube diseñados para gestionar digitalmente transacciones basadas en documentos. El objetivo principal de la Gestión de Transacciones Digitales es eliminar la fricción inherente a las transacciones que involucran personas, documentos y datos, creando procesos más rápidos, fáciles, convenientes y seguros.

Los componentes clave de un sistema DTM incluyen:

  1. Firmas electrónicas: Permiten la vinculación de documentos a sus firmantes, su autenticación segura y la atribución legalmente vinculante de documentos firmados.
  2. Gestión de documentos y transacciones: Incluye almacenamiento digital, asociado al concepto de custodia, organización y recuperación eficiente de documentos y operaciones.
  3. Automatización de flujos de trabajo: Reduciendo tareas manuales y mejorando la consistencia de los procesos.
  4. Protocolos de seguridad: Implementando el cifrado donde se precisa (teniendo en ciuenta los riesgos que anuncia la computación cuántica) y controles de acceso para proteger información sensible.
  5. Autenticación digital: Verificando la identidad de los participantes en las transacciones.
  6. Gestión de evidencias digitales para favorecer la fuerza probatoria en contextos de resolución de controversias.
  7. Gestión de entornos híbridos de documentos digitales y en papel, con gestión de la digitalización cualificada de documentos en papel con fuerza probatoria y documentos nacidos digitales que se pueden usar impresos por la posibilidad de cotejo de su CSV (Código Seguro de Verificación) en su sede electrónica de referencia.

Los servicios de EADTrust encajan perfectamente en el concepto de Digital Transaction Management, ya que ofrecen varias soluciones clave que son fundamentales para la gestión digital de transacciones:

  1. Firmas electrónicas cualificadas: EADTrust emite certificados cualificados para personas físicas y entidades legales, que permiten la creación de firmas y sellos electrónicos avanzados y cualificados. También ofrece servicios de comprobación de las firmas electrónicas que se reciben en las entidades.
  2. Sellos de tiempo cualificados: Estos sellos permiten probar el momento exacto en que ocurrió un evento digital, dejando un registro irrefutable de la fecha, hora y contenido del evento mediante criptografía. Se asocia un sello de teiempo con cada transacción.
  3. Custodia digital: EADTrust ha desarrollado una tecnología que permite a los usuarios almacenar documentos digitalmente, pudiendo probar su autenticidad a través de CSV y su inalterabilidad mediante métodos criptográficos avanzados. En línea con la normativa de eArchivos de EIDAS2
  4. Notificaciones certificadas (Noticeman): Ofreciendo una plataforma de gestión de correo electrónico y SMS certificados que permite registrar la identidad del remitente, el receptor, el contenido y el momento exacto en que se realizaron las comunicaciones.
  5. Servicios corporativos: Proporcionan testimonios de publicación de documentos a las entidades obligadas para convocatorias de juntas generales de accionistas, foros y gestión de voto electrónico, cumpliendo con la Ley de Sociedades de Capital.
  6. Custodia de claves privadas: Celebran ceremonias de creación de claves, generando pares de claves asimétricas y manteniendo la clave privada para garantizar la integridad. Estos servicios son esenciales en la gestión de firmas manuscritas capturadas en tabletas digitalizadoras

Estos servicios de EADTrust abordan aspectos críticos de DTM, como la autenticación, la seguridad, la gestión de documentos y el cumplimiento normativo. Al ofrecer estas soluciones, EADTrust contribuye significativamente a la transformación digital de las empresas, permitiéndoles gestionar sus transacciones de manera más eficiente, segura y conforme a la normativa vigente.

En relación con las Carteras IDUE ayuda a adaptarse a las entidades obligadas por mandato del Reglamento EIDAS2 en el articulo 5 septies: 

Cuando el Derecho de la Unión o nacional exija que las partes usuarias privadas que prestan servicios —con la excepción de las microempresas y pequeñas empresas según se definen en el artículo 2 del anexo de la Recomendación 2003/361/CE de la Comisión ( 5 )— utilicen una autenticación reforzada de usuario para la identificación en línea, o cuando se requiera una autenticación reforzada de usuario para la identificación en línea en virtud de una obligación contractual, en particular en los ámbitos del transporte, la energía, la banca, los servicios financieros, la seguridad social, la sanidad, el agua potable, los servicios postales, la infraestructura digital, la educación o las telecomunicaciones, dichas partes usuarias privadas también aceptarán, a más tardar treinta y seis meses a partir de la fecha de entrada en vigor de los actos de ejecución a que se refieren el artículo 5 bis, apartado 23, y el artículo 5 quater, apartado 6, y únicamente a petición voluntaria del usuario, las carteras europeas de identidad digital proporcionadas de conformidad con el presente Reglamento.

Compartir lotería usando GoCertius y Telegram


Antecedentes

El año pasado publiqué el artículo «Como generar evidencias digitales con GoCertius cuando se comparte lotería» dando instrucciones sobre la manera de generar evidencias digitales por parte del depositario de un décimo de lotería que surte los efectos del «recibo » de participación de lotería usado durante muchos años.


La posibilidad de generar evidencias digitales de lotería con GoCertius ya era un gran avance porque permite dejar constancia de información crucial como el décimo concreto que se comparte, la persona que ejerce como depositaria, la identidad de los participantes y las reglas de reparto en caso de premio.

Nueva funcionalidad de GoCertius de certificación de canales especiales en Telegram

Pero ahora la App GoCertius se amplía para incluir la opción de gestionar «Chats Certificados» de Telegram y entre muchos usos potenciales, en esta época del año tiene sentido poner como ejemplo de sus usos el «Acuerdo Lotero GoCertius«.

En EADTrust, g-digital y Garrigues creemos que estamos dando un paso disruptivo en lo que se refiere a la gestión de evidencias digitales, al poder incorporar el testimonio reforzado con sellos de tiempo cualificados de acuerdo a la Regulación EIDAS de los diálogos de un canal de Telegram para los que participan en el.

Generación de un canal de chat certificado de Telegram desde GoCertius

Para el caso que proponemos, el «Acuerdo Lotero» el depositario del décimo (o décimos, si hay mas de uno) organiza un canal de chat de Telegram certificado desde GoCertius.

Para ello, en la App GoCertius hay que pulsar el botón de «Menú» (abajo), luego «Mis chats» y luego la opción «Crear chat» en la que se define el nombre del chat en la App GoCertius, el Título que tendrá el canal de Telegram y la descripción que aparecerá en «Información» en el canal de Telegram. Es recomendable que esta Información sea clara ya que será lo primero que se verá a entrar en el canal.

Hay que esperar un poco a que se cree el canal porque no es instantáneo y después, pulsando de nuevo «Mis chats» ya aparece el que se ha creado.

En esa pantalla se pincha en «Abrir en Telegram» y se entra en el nuevo canal, ya en la App de mensajería.

Inicialmente hay 3 participantes: EADtrust que es el «Propietario», Certy, que es el robot que recoge los mensajes y los convierte en constancias y el usuario que ha creado el chat desde GoCertius y que ya puede invitar al resto de participantes en el canal.

Inicialmente se explica el objetivo de la creación del canal para ayudar a formar el consentimiento de los participantes, preferentemente cuando están dados de alta en el canal todos los que recibirán participaciones de la lotería, luego se añade el texto contractual y la foto del décimo o décimos y se inicia una «encuesta» para recoger el consentimiento de los participantes, en forma de votación.

Para crear encuestas en Telegram hay que pinchar en el icono del clip que aparece abajo en la pantalla de App de mensajería y luego en el icono de Encuesta. 

La encuesta solicita la conformidad de los participantes y la expresión del consentimiento por lo que habrá que redactarla de forma acorde. La encuesta la reformula «Certy» para capturar la respuesta de cada participante y dejarla recogida en la constancia que se genera al final en forma de «Certificación».

Con esta funcionalidad de Chat Certificado cada mensaje, archivo o encuesta queda registrado con un sello de tiempo cualificado regulado en el Reglamento europeo EIDAS y su  certificación está disponible para todos los participantes.

¿Qué aporta la posibilidad de certificar la mensajería?

Las plataformas de mensajería son parte de nuestra experiencia digital cotidiana. La posibilidad de añadirles servicios de confianza digital regulados que dejen constancia de lo tratado (cuando interese) y que generen certificaciones que puedan presentarse como pruebas en contextos de resolución de controversias (Negociación,  Conciliación, Mediación, Arbitraje o la Vía Jurisdiccional) es una importante aportación a a seguridad jurídica preventiva digital.

El equipo de desarrollo

En este desarrollo, han trabajado mentes de EADTrust, IOBuilders, g-digital y Garrigues.

Texto sugerido del acuerdo lotero

El condicionado lo decide cada grupo, pero podría parecerse a esto:

ACUERDO DE COMPARTICIÓN DEL DÉCIMO DE LOTERÍA NÚMERO 00245 – SORTEO DE NAVIDAD 2024

FECHA: 12 de diciembre de 2024
PARTICIPANTES: Todos los miembros del grupo «Nombre del Grupo» que hayan expresado su conformidad a través de la herramienta de votación del canal en GoCertius Chat certificado.

Por tanto quien no vote en el chat de Telegram no será beneficiario de este acuerdo.

DÉCIMO:

•⁠ ⁠Número: XXXXX
•⁠ ⁠Sorteo: Sorteo Extraordinario de Navidad 2024
•⁠ ⁠Administración de lotería: la URL, si la sabemos
•⁠ ⁠Custodia física: Persona depositaria del décimo
•⁠ ⁠Custodia digital: Confirmada por la administración de lotería citada.


REPARTO DEL PREMIO:
En caso de resultar premiado el décimo número XXXXX en el Sorteo Extraordinario de Navidad 2024, el premio se repartirá de forma equitativa entre todos los participantes que hayan aprobado este acuerdo a través de la herramienta de votación en GoCertius Chatcertificado.


APROBACIÓN DEL ACUERDO Y EFECTOS EQUIVALENTES A LA FIRMA:

Este acuerdo entrará en vigor y surtirá plenos efectos una vez que cada participante lo haya aprobado de manera individual a través de la herramienta de votación (encuestas) habilitada en el Canal. La aprobación de este acuerdo mediante la votación en el chat certificado constituye una manifestación inequívoca de la voluntad de cada participante de adherirse al mismo y produce los mismos efectos legales que la firma manuscrita. Dicha votación implica la aceptación incondicional de las condiciones establecidas y la conformidad para participar en el reparto del premio en caso de resultar ganador.


CONSIDERACIONES ADICIONALES:
•⁠ ⁠Confirmación de la custodia: El depositario en calidad de custodio del décimo, se compromete a presentar una prueba fehaciente de la custodia física y/o digital del décimo a solicitud de cualquier participante.
•⁠ ⁠Transparencia: El depositario se compromete a informar a todos los participantes de cualquier novedad relevante relacionada con el décimo y a mantener un registro de todas las comunicaciones relacionadas con este acuerdo.
•⁠ ⁠Legislación aplicable: Este acuerdo se regirá por la legislación española vigente.


ACEPTACIÓN (MEDIANTE VOTACIÓN EN GoCertius Chatcertificado):
La participación en la votación con la opción de «APROBAR» implica la lectura, comprensión y aceptación total de este acuerdo.


OBSERVACIONES:
•⁠ ⁠Evidencia digital: La aprobación a través de la herramienta de votación de GoCertius Chatcertificado constituye una evidencia digital irrefutable de la aceptación de este acuerdo por parte de cada participante.
•⁠ ⁠Adaptación: Este acuerdo podrá ser modificado o complementado únicamente por consenso unánime de todos los participantes que lo hayan aprobado inicialmente, mediante una nueva votación certificada en el mismo chat de GoCertius Chatcertificado.
¡Mucha suerte a todos!
El depositario (indicar nombre y apellidos), CUSTODIO Y TITULAR DEL DÉCIMO XXXXX REPRODUCIDO A CONTINUACIÓN


Prueba GoCertius:

Te invitamos a descargar y probar GoCertius, una herramienta gratuita que te ofrece tranquilidad y seguridad en tu start up o para desarrollar tu idea de negocio innovadora. GoCertius es una aplicación provista por EAD Trust, proveedor cualificado de servicios de confianza digital, visítanos en https://www.eadtrust.eu/.

Referencias

Se mencionó la novedad desarrollada en GoCertius que otorga la posibilidad de certificar el contenido de ciertos canales de Telegram en una publicación de LinkedIn que resume este mismo tema del «Acuerdo Lotero»