Identidad digital, Cartera IDUE, Firma electrónica, Archivo digital, blockchain, Medios de pago, eBanca, administración de justicia. administración pública, Seguridad Jurídica Preventiva Digital
Los próximos 19 y 20 de noviembre impartiré con Pere Brachfield el curso Factura Electrónica obligatoria B2B, organizado por iKN Spain. Son dos mañanas en formato virtual, siete horas en total, pensadas para que las empresas entiendan qué les exige el nuevo marco legal y cómo organizar el proyecto de adaptación.
No es la primera vez: en junio ya anuncié una edición anterior. Desde entonces el marco se ha completado y el contenido se ha actualizado con la Orden de octubre y el nuevo calendario.
El momento no es casual. El Real Decreto 238/2026 ya está en vigor, la Orden HAC/1028/2026, de 2 de octubre, por la que se regula la solución pública de facturación electrónica se publicó el 5 de octubre y entró en vigor el 6 de octubre de 2026. Con esa fecha empieza a computarse el plazo: doce meses después (el 6 de octubre de 2027), las empresas cuyo volumen de operaciones del año natural anterior haya superado los 8 millones de euros tendrán que emitir y recibir facturas electrónicas estructuradas y comunicar su estado. Doce meses parecen mucho, pero no lo son cuando hay que revisar procesos, adaptar el software, coordinarse con clientes y proveedores y probarlo todo antes de la fecha.
Qué cambia y cuándo
La obligación nace de la Ley 18/2022, de creación y crecimiento de empresas («Ley Crea y Crece»), que incorporó a la Ley 56/2007 la factura electrónica obligatoria entre empresarios y profesionales. Su desarrollo ha llegado en dos pasos:
El Real Decreto 238/2026, publicado en el BOE el 31 de marzo y en vigor desde el 20 de abril, fija las reglas: formatos admitidos, plataformas de intercambio, interoperabilidad y comunicación del estado de las facturas.
La Orden HAC/1028/2026, publicada el 5 de octubre y en vigor desde el día 6, regula la solución pública de facturación electrónica de la AEAT y pone en marcha los plazos.
El calendario queda así:
Fecha
Quién
Qué
6 de octubre de 2027
Empresas con volumen de operaciones superior a 8 millones de euros
Emitir y recibir facturas electrónicas y comunicar su estado
6 de octubre de 2028
Resto de empresarios y profesionales
Emitir y recibir facturas electrónicas
6 de octubre de 2029
Personas físicas y entidades en atribución de rentas de hasta 8 millones
Comunicar el estado de las facturas
Estos plazos se cuentan desde el 6 de octubre de 2026 (entrada en vigor de la Orden HAC/1028/2026), conforme a la disposición final cuarta del Real Decreto 238/2026 y a la disposición final octava de la Ley 18/2022. El volumen de operaciones se calcula según el artículo 121 de la Ley del IVA. Las personas físicas y las entidades en atribución de rentas con volumen igual o inferior a 8 millones de euros tienen un año adicional (hasta el 6 de octubre de 2029) solo para la obligación de comunicar los estados de las facturas.
Lo importante no es solo el formato. Las facturas tendrán que ajustarse al modelo semántico de la norma europea EN 16931, en alguna de las sintaxis admitidas (UBL, CII, EDIFACT o Facturae), y circular por la solución pública de la AEAT o por plataformas privadas interoperables. Un PDF enviado por correo deja de valer como factura electrónica a estos efectos. Además, el destinatario deberá comunicar en cuatro días si acepta o rechaza la factura y la fecha en que la paga, y esa información llegará a la AEAT. Es la forma que ha elegido el legislador para medir la morosidad comercial.
A todo esto se suma VERI*FACTU, el sistema de registros de facturación inalterables del Real Decreto 1007/2023. Sus fechas vigentes son el 1 de enero de 2027 para las sociedades y el 1 de julio de 2027 para el resto, aunque Hacienda anunció el 5 de octubre su intención de llevarlo a octubre de 2028 para alinearlo con la factura electrónica. A día de hoy ese aplazamiento no se ha publicado en el BOE, así que conviene planificar con las fechas que están en vigor.
El curso
El programa recorre la factura electrónica de lo general a lo concreto, en cinco módulos:
Fundamentos de la facturación electrónica: qué es, en qué se diferencia de la factura tradicional, qué información debe contener y qué formatos reconoce la UE.
La normativa estatal y las normas de la UE: las iniciativas europeas VIDA (VAT in the Digital Age) y los requisitos de información digital (DRR), los precedentes en España, la Ley Crea y Crece y el RD 238/2026.
Aspectos clave del nuevo reglamento: sujetos obligados, excepciones, comunicación del estado de la factura, relación con VERI*FACTU y calendario.
El sistema estatal de intercambio de facturas: la solución pública de la AEAT, las plataformas privadas autorizadas, la interoperabilidad entre ellas, el Observatorio Estatal de la Morosidad Privada y el listado de infractores.
Aspectos técnicos de la factura electrónica B2B y VERI*FACTU, que es el módulo que imparto yo.
Pere Brachfield, abogado y consejero delegado de Brachfield Credit & Risk Consultants, autor de más de treinta libros sobre gestión empresarial y de más de 2.000 artículos publicados en 15 países, se ocupa de la parte jurídica y de gestión. Yo me centro en la parte técnica.
El curso está pensado para directores financieros y de administración, responsables de contabilidad, facturación, tesorería y gestión de cobros, asesores fiscales y contables, abogados, directores de sistemas, proveedores de software y gerentes de pymes. Es decir, para quienes tendrán que decidir y ejecutar el proyecto de adaptación en su empresa o en las de sus clientes.
Mi módulo: la parte técnica
La factura electrónica me acompaña desde hace mucho. En ASIMELEC, y después en AMETIC, impulsé su normalización, y en 2010 ASIMELEC publicó mi libro La Factura Electrónica. En OASIS contribuí a definir cómo se firman las facturas en UBL (UBL Digital Signature Profiles 1.0). Hoy, como prestador cualificado de servicios de confianza, en EADTrust vemos a diario la otra cara del problema: cómo garantizar el origen, la integridad y la fecha de un documento electrónico.
El módulo 5 traduce las obligaciones legales a decisiones técnicas:
Arquitectura de la factura. Qué es una factura estructurada, por qué el modelo semántico EN 16931 es la pieza común de todas las sintaxis admitidas, qué campos son obligatorios y cómo es el ciclo de vida completo: emisión, entrega, aceptación o rechazo y pago.
Firma, sello y sello de tiempo. La normativa de facturación exige garantizar la autenticidad del origen y la integridad del contenido. La firma electrónica avanzada, o el sello electrónico de la empresa basado en un certificado cualificado, es la forma más directa de hacerlo. Veremos los formatos XAdES, CAdES y PAdES, cuándo conviene cada uno y para qué sirve añadir un sello de tiempo cualificado.
VERI*FACTU. Qué son los registros de facturación, cómo funciona la huella encadenada (cada registro incluye el hash del anterior, de modo que no se puede alterar uno sin romper la cadena) y cómo el código QR permite al cliente comprobar la factura en la sede de la AEAT.
Convergencias y divergencias. VERIFACTU registra lo que factura el emisor, sea a empresas o a consumidores; la factura electrónica B2B regula cómo se intercambia el documento entre empresas. Comparten datos, pero no flujos ni calendario, y no afectan a los mismos sujetos: las empresas acogidas al SII quedan fuera de VERIFACTU, pero no de la factura electrónica. Un buen proyecto diseña un solo circuito que cumpla ambas obligaciones.
Requisitos del software de facturación. Integridad, conservación, legibilidad y trazabilidad de los registros, declaración responsable del fabricante, interfaces de programación con las plataformas y gestión de los estados de la factura.
Recursos oficiales de la AEAT. Esquemas XSD, documentación de integración y entornos de pruebas, que conviene usar desde el primer día.
Hoja de ruta del proyecto. Inventario de sistemas y flujos, elección entre la solución pública y una plataforma privada, pruebas con clientes y proveedores y puesta en producción.
Mi objetivo es que quien asista salga sabiendo qué preguntas hacer a su proveedor de software y a su plataforma de intercambio, y con un plan para no llegar con prisas a octubre de 2027.
Datos prácticos
Fechas: jueves 19 y viernes 20 de noviembre de 2026, de 9:30 a 13:15.
Formato: virtual y en directo.
Duración: 7 horas.
Precio: 899 euros más IVA, con opciones que incluyen cursos online adicionales. La formación es bonificable a través de FUNDAE, y iKN gestiona la bonificación sin coste.
Certificado: de asistencia, al finalizar el curso.
Inscripción: en la página del curso, en info@ikn.es o en el 91 700 48 70.
Si tu empresa tiene que dar el paso en 2027 o 2028, este es un buen momento para empezar. Nos vemos en clase.
El 31 de diciembre de 2008 escribí en este blog sobre el segundo intercalar que se añadió aquella Nochevieja: un minuto de 61 segundos que obligaba a los sistemas de sellado de tiempo a contar hasta 23:59:60. Casi dieciocho años después, los metrólogos han decidido jubilarlo. El 15 de octubre de 2026, la Conferencia General de Pesas y Medidas aprobó que, a partir del 20 de mayo de 2027, el UTC (Coordinated Universal Time, tiempo universal coordinado) sea continuo y no vuelva a añadir ni quitar segundos.
Aprovecho la noticia para contar algo que casi nunca se explica: cómo se ponen de acuerdo los laboratorios de todo el mundo para que su hora no difiera más que unos nanosegundos, cuánto se separa de esa referencia la hora que emiten los satélites de navegación y cómo llega la hora oficial hasta nuestros ordenadores y relojes.
Adiós al segundo intercalar
UTC combina dos relojes muy distintos. Por un lado, la escala TAI (Temps Atomique International, tiempo atómico internacional), que cuenta segundos con una regularidad casi perfecta. Por otro, la rotación de la Tierra, medida por el UT1 (Universal Time 1, tiempo universal 1), que es irregular y, a largo plazo, se va frenando por las mareas. Desde 1972, para que UTC no se alejara más de 0,9 segundos de UT1, el IERS (International Earth Rotation and Reference Systems Service, Servicio Internacional de Rotación de la Tierra y Sistemas de Referencia) anunciaba con seis meses de antelación cuándo había que intercalar un segundo. Se han añadido 27; el último, el 31 de diciembre de 2016. Desde entonces, TAI va 37 segundos por delante de UTC.
El sistema tenía dos problemas:
Para la informática, un segundo imprevisible es una fuente de fallos. Ha provocado caídas de servidores, bases de datos y redes. Grandes operadores optaron por «diluirlo» a lo largo de horas (leap smear), con lo que durante ese tiempo su hora no coincidía con la oficial.
La Tierra ha girado algo más rápido en los últimos años. Eso abría la puerta al primer segundo intercalar negativo de la historia, un minuto de 59 segundos que ningún sistema ha probado nunca.
La 28.ª CGPM (Conférence Générale des Poids et Mesures, Conferencia General de Pesas y Medidas), reunida en Versalles, aprobó el 15 de octubre de 2026 su Resolución 5. Desde el 20 de mayo de 2027, Día Mundial de la Metrología, UTC será continuo, y la diferencia tolerada entre UTC y UT1 pasa de 0,9 segundos a una hora, lo que garantiza la continuidad de UTC durante varios siglos. La resolución culmina el camino abierto por la Resolución 4 de la CGPM de 2022, que fijó el horizonte de 2035. Como el boletín del IERS de julio de 2026 descartó un segundo intercalar a final de este año, todo indica que el de 2016 habrá sido el último.
El cambio de enfoque es de fondo. La metrología deja de perseguir la rotación terrestre segundo a segundo y prima una escala de tiempo continua y predecible, que es lo que necesitan las redes, los satélites, los mercados financieros y los servicios de confianza. Quien necesite el tiempo astronómico (navegación astronómica, telescopios, satélites de observación) seguirá teniendo la diferencia UT1−UTC publicada por el IERS. Las estaciones de radio que transmiten esa diferencia (el código DUT1, Delta UT1, es decir, la diferencia UT1−UTC) tienen un periodo de transición hasta 2035, y como máximo hasta 2040, según la Resolución 655 de la Conferencia Mundial de Radiocomunicaciones.
Cómo se ponen de acuerdo los laboratorios de tiempo
Un dato que sorprende: nadie tiene un reloj que marque UTC. UTC es una escala calculada a posteriori por el BIPM (Bureau International des Poids et Mesures, Oficina Internacional de Pesas y Medidas), en Sèvres, a partir de unos 400 relojes atómicos de laboratorios de todo el mundo. Lo que cada país mantiene en tiempo real es su propia realización, llamada UTC(k), donde «k» designa al laboratorio: UTC(ROA) en España; UTC(PTB) en Alemania (PTB: Physikalisch-Technische Bundesanstalt, Instituto Federal de Física y Técnica); UTC(OP) en Francia (OP: Observatoire de Paris, Observatorio de París); UTC(USNO) y UTC(NIST) en Estados Unidos (USNO: United States Naval Observatory, Observatorio Naval de los Estados Unidos; NIST: National Institute of Standards and Technology, Instituto Nacional de Estándares y Tecnología), etc.
El mecanismo funciona así:
Comparación continua. Cada laboratorio compara sus relojes con los de los demás mediante enlaces de transferencia de tiempo. Los más usados son la observación simultánea de satélites de navegación, con técnicas de posicionamiento preciso, y los enlaces bidireccionales por satélite de telecomunicaciones (TWSTFT, Two-Way Satellite Time and Frequency Transfer, transferencia bidireccional de tiempo y frecuencia por satélite), en los que dos laboratorios se envían señales a la vez para que los retardos se cancelen.
Cálculo central. El BIPM pondera los relojes según su estabilidad, obtiene primero una escala libre y la ajusta con los relojes primarios de cesio y los relojes ópticos más exactos. Así calcula TAI y, restándole los segundos intercalares acumulados, UTC.
Publicación. Cada mes publica la Circular T, que indica la diferencia [UTC − UTC(k)] de cada laboratorio cada cinco días. Hay además una solución rápida semanal, UTCr (UTC rapide, UTC rápido).
Corrección. Con esos datos, cada laboratorio «guía» su UTC(k) para acercarlo a UTC.
El resultado es que los grandes laboratorios se mantienen a pocos nanosegundos de UTC, y la mayoría de los demás, a unas decenas. Un nanosegundo es la milmillonésima parte de un segundo: el tiempo que tarda la luz en recorrer unos 30 centímetros.
La cadena del tiempo: BIPM, laboratorios nacionales y vías de difusión
Los laboratorios no reciben la hora del BIPM: la construyen ellos, y el BIPM les dice después cuánto se han desviado.
La hora de los satélites de navegación
Los cuatro GNSS (Global Navigation Satellite Systems, sistemas globales de navegación por satélite) son, en el fondo, relojes atómicos en órbita: para calcular la posición, el receptor mide cuánto tarda en llegar la señal de cada satélite. Cada sistema tiene su propia escala de tiempo, guiada hacia la UTC(k) de un laboratorio de referencia, y transmite en su mensaje de navegación los parámetros para convertirla en UTC.
Sistema
Escala propia
Diferencia con UTC
Laboratorio de referencia
Desvío observado de su UTC difundida
GPS (Global Positioning System, sistema de posicionamiento global; EE. UU.)
Tiempo GPS, sin segundos intercalares desde 1980
+18 s
UTC(USNO)
±5 ns
Galileo (UE)
GST (Galileo System Time, tiempo del sistema Galileo), alineado con el de GPS
+18 s
Conjunto de laboratorios europeos
±5 ns
BeiDou (China)
BDT (BeiDou Time, tiempo BeiDou), sin segundos intercalares desde 2006
+4 s
UTC(NTSC) (National Time Service Center, Centro Nacional del Servicio de Tiempo de China)
5 a 20 ns
GLONASS (Globalnaya Navigatsionnaya Sputnikovaya Sistema, sistema global de navegación por satélite; Rusia)
Tiempo GLONASS, que sí aplica los segundos intercalares
UTC(SU) + 3 h
UTC(SU)
30 a 50 ns
Desvíos medidos por el BIPM entre julio de 2022 y enero de 2023 (estudio del BIPM).
Dos consecuencias prácticas:
Un buen receptor de tiempo GNSS da UTC con un error de pocas decenas de nanosegundos. Por eso los satélites son la fuente de sincronización de redes móviles, redes eléctricas y centros de datos. También por eso las interferencias y la suplantación de señales GNSS (jamming y spoofing) son un riesgo para la infraestructura crítica, que conviene respaldar con otras fuentes, como un enlace a un laboratorio nacional.
Con el fin de los segundos intercalares, las diferencias de GPS, Galileo y BeiDou con UTC quedarán congeladas en 18 y 4 segundos. GLONASS, el único que seguía a UTC segundo a segundo, se ahorrará los saltos.
El ROA, guardián de la hora oficial en España
En España, la hora oficial sale del Real Instituto y Observatorio de la Armada (ROA), en San Fernando (Cádiz). El Real Decreto 1308/1992 lo declara laboratorio depositario del patrón nacional de tiempo y laboratorio asociado al Centro Español de Metrología. Su escala, UTC(ROA), es la referencia legal de la hora en nuestro país y una de las que contribuyen al cálculo de UTC.
Según ha explicado la propia Armada, el ROA mantiene siete relojes atómicos, cinco de cesio y dos máseres de hidrógeno, en una sala con temperatura constante y aislada de vibraciones e interferencias. Las lecturas se combinan con un algoritmo que da más peso a los relojes más estables, y la escala resultante se compara en tiempo real con otros laboratorios. El observatorio desarrolla además un reloj óptico, la siguiente generación de patrones de tiempo.
El ROA no solo guarda la hora; también la reparte:
Servidores NTP públicos (hora.roa.es y minuto.roa.es), que atienden más de 100 millones de peticiones de sincronización al día.
Señales horarias de onda corta desde San Fernando, en 15,006 MHz y 4,998 MHz, en dos emisiones diarias de 25 minutos.
Servicio telefónico con el código horario europeo.
Hora certificada y sellado de tiempo para la Administración (a través de la Red SARA, Sistemas de Aplicaciones y Redes para las Administraciones), para organismos como la Agencia Tributaria, la FNMT (Fábrica Nacional de Moneda y Timbre) o el Colegio de Registradores, y para operadores de telecomunicaciones.
Cómo nos llega la hora
NTP: la hora de Internet
Casi todos los ordenadores, teléfonos y servidores se sincronizan con el protocolo NTP (Network Time Protocol, protocolo de tiempo de red). Funciona en niveles o estratos: el estrato 0 es la fuente (un reloj atómico o un receptor GNSS), el estrato 1 son los servidores conectados directamente a ella, como los del ROA, y cada nivel siguiente se sincroniza con el anterior. NTP corrige el retardo de la red midiendo el tiempo de ida y vuelta de los mensajes. En Internet se consigue una exactitud de milisegundos, y en una red local bien configurada, de decenas de microsegundos.
Dos matices relevantes para la seguridad:
NTP clásico no autentica las respuestas. Un atacante puede falsear la hora de un sistema y, con ello, hacer pasar por válido un certificado caducado o alterar la secuencia de los registros. La extensión NTS (Network Time Security, seguridad del tiempo de red; RFC 8915, Request for Comments, petición de comentarios) añade autenticación criptográfica y conviene activarla donde esté disponible.
Cuando hace falta precisión de nanosegundos, como en redes 5G, el sector eléctrico o la negociación bursátil de alta frecuencia, se usa PTP (Precision Time Protocol, protocolo de tiempo de precisión; norma 1588 del IEEE, Institute of Electrical and Electronics Engineers, Instituto de Ingenieros Eléctricos y Electrónicos) en lugar de NTP. Lo vemos a continuación.
El fin del segundo intercalar simplifica la vida a NTP: el indicador de segundo intercalar que lleva cada mensaje dejará de usarse, y con él desaparece una de las causas clásicas de fallos.
PTP: la hora de precisión dentro del centro de datos
NTP basta para que un portátil o un servidor web tengan la hora con un error de milisegundos, pero se queda corto cuando hay que ordenar acontecimientos separados por microsegundos o menos. Para eso se diseñó PTP, definido en la norma IEEE 1588 (primera versión en 2002, la segunda en 2008 y la vigente, la 1588-2019). En EADTrust lo usamos para dar la hora a nuestra autoridad de sellado de tiempo, como explico más abajo.
PTP sigue un esquema jerárquico parecido al de NTP, pero con tres diferencias que explican su exactitud:
Un reloj maestro elegido automáticamente. En cada red hay un reloj de referencia (grandmaster), normalmente conectado a un receptor GNSS o a un enlace con un laboratorio de tiempo. Los equipos lo eligen con un algoritmo de selección del mejor reloj maestro (BMCA, Best Master Clock Algorithm, algoritmo del mejor reloj maestro), que también designa un sustituto si el principal falla.
Marcas de tiempo por hardware. El maestro envía mensajes de sincronización y los esclavos le responden con peticiones de retardo. Con las cuatro marcas de tiempo de cada intercambio, el esclavo calcula su desfase y el retardo del camino. La clave es que esas marcas no las pone el sistema operativo, sino la propia tarjeta de red en el instante en que el mensaje sale o entra por el cable, lo que elimina la variabilidad del software.
Una red que colabora. Los conmutadores compatibles miden cuánto tiempo retienen cada mensaje y lo anotan (relojes transparentes) o se sincronizan ellos mismos y reparten la hora hacia abajo (relojes frontera). Así, las colas y la congestión de la red no se traducen en error.
El resultado es una exactitud inferior al microsegundo, y de decenas de nanosegundos con equipos adecuados. La extensión White Rabbit, desarrollada en el CERN e incorporada a la norma de 2019 como perfil de alta exactitud, llega por debajo del nanosegundo.
NTP
PTP
Ámbito típico
Internet y redes corporativas
Red local o de operador, con equipos compatibles
Marcas de tiempo
Por software
Por hardware, en la tarjeta de red
Exactitud habitual
Milisegundos (Internet) a decenas de microsegundos (red local)
Inferior al microsegundo; nanosegundos con equipos adecuados
Escala interna
UTC
TAI, con el desfase TAI−UTC en los mensajes
Autenticación
NTS (RFC 8915)
Mecanismo opcional de la versión de 2019
Para cada sector hay un perfil de PTP con sus propias reglas: el de telecomunicaciones de la UIT (Unión Internacional de Telecomunicaciones) para las redes móviles, el del sector eléctrico (IEEE C37.238) para subestaciones, el gPTP (generalized PTP, PTP generalizado; IEEE 802.1AS) para automoción y redes industriales, y el SMPTE 2059 (Society of Motion Picture and Television Engineers, Sociedad de Ingenieros de Cine y Televisión) para la producción de televisión. En los mercados financieros, el Reglamento Delegado (UE) 2017/574, derivado de MiFID II (Markets in Financial Instruments Directive II, Directiva sobre mercados de instrumentos financieros), exige a la negociación de alta frecuencia que sus relojes no se desvíen más de 100 microsegundos de UTC, y PTP es la forma habitual de cumplirlo.
PTP tiene también sus límites. Supone que el retardo de ida y el de vuelta son iguales, de modo que cualquier asimetría del cable o de la red se convierte directamente en error. Además, necesita equipos compatibles en todo el camino, por lo que no sirve para sincronizar a través de Internet. Por eso lo habitual es combinar ambos: PTP dentro de la infraestructura crítica y NTP, mejor con NTS, para el resto.
El fin del segundo intercalar también le afecta, y para bien. PTP trabaja internamente en TAI y transmite en cada mensaje el desfase con UTC (hoy, 37 segundos) y dos indicadores que avisan de un segundo intercalar positivo o negativo. A partir de 2027 ese desfase quedará fijo y los indicadores dejarán de activarse.
Las señales horarias de la radio
Los pitidos que suenan en la radio justo antes de las noticias son una tradición casi centenaria, que popularizó la BBC (British Broadcasting Corporation, Corporación Británica de Radiodifusión) en 1924 con sus seis pitidos. El último marca el inicio exacto de la hora. Con la radio analógica, el oyente recibía la señal con un retardo despreciable. Con la radio digital, la televisión digital o la escucha por Internet, la codificación y el almacenamiento intermedio añaden retardos de uno a varios segundos, así que el pitido que se oye por el móvil o el altavoz inteligente llega tarde.
Además de los pitidos de las emisoras comerciales, existen estaciones dedicadas exclusivamente a difundir la hora oficial, como las emisiones de onda corta del ROA.
DCF77: la señal que pone en hora los relojes «radiocontrolados»
Los relojes de pared y despertadores que se ponen en hora solos en España suelen escuchar a DCF77 (indicativo formado por D de Deutschland, C de emisora de onda larga, F de Fráncfort y 77 por su frecuencia), una emisora de onda larga situada en Mainflingen, cerca de Fráncfort. La controla el instituto alemán de metrología, el PTB, con relojes atómicos sincronizados con sus patrones de Brunswick. Algunos datos:
emite en 77,5 kHz con 50 kW nominales y un alcance oficial de unos 2.000 km, que cubre la península pero no Canarias;
transmite la hora de Europa Central (la peninsular), con el cambio de horario de verano incluido, a razón de un bit por segundo, y marca el inicio de cada minuto suprimiendo la señal en el segundo 59;
un reloj doméstico se sincroniza con una exactitud de alrededor de una décima de segundo, y los receptores profesionales llegan al microsegundo; la señal tarda unos 3 milisegundos en recorrer 1.000 km.
España no tiene una emisora de onda larga propia para la hora, por lo que DCF77 cumple de hecho esa función para el gran público.
Por qué importa para la confianza digital
Un sello de tiempo cualificado vale lo que vale la hora que certifica. La norma europea EN 319 421 del ETSI (European Telecommunications Standards Institute, Instituto Europeo de Normas de Telecomunicaciones) exige que la autoridad de sellado de tiempo mantenga su reloj sincronizado con UTC, con trazabilidad a la UTC(k) de un laboratorio y dentro de la exactitud que declare, y que vigile y registre cualquier desviación. En España esa trazabilidad lleva al ROA. En EADTrust, por ejemplo, nuestra política de sellado de tiempo toma como referencia el patrón nacional que mantiene el ROA.
En nuestro caso, un subsistema de tiempo propio genera la hora en NTP y en PTP para los distintos sistemas de la red. La referencia procede de los satélites de navegación: el receptor aprovecha todos los que son visibles desde un punto de referencia en Madrid, sin depender de una sola constelación. La TSA (Time-Stamping Authority, autoridad de sellado de tiempo) toma la hora por PTP, que a su vez está sincronizado con el NTP del subsistema. Además, un proceso automático compara continuamente esa hora con la de los servidores NTP del ROA. Si detecta una deriva, emite alarmas escalonadas mientras dura y, si la diferencia llegara a un segundo, detendría la TSA para que no emita ningún sello fuera de tolerancia. Hasta ahora nunca ha sido necesario detenerla.
El final del segundo intercalar elimina una fuente de riesgo que en 2008 obligaba a preparar los sistemas para el segundo 60. A cambio, conviene revisar tres cosas antes del 20 de mayo de 2027:
que ningún sistema dependa de las tablas de segundos intercalares para algo más que la historia, y que se actualicen las listas y bibliotecas que las incorporan;
que las fuentes de tiempo estén diversificadas (GNSS, NTP autenticado y, donde proceda, enlace directo con un laboratorio nacional), para no depender de una sola señal que se pueda interferir;
que los sistemas que necesiten tiempo astronómico usen explícitamente UT1−UTC del IERS, porque la diferencia ya no estará acotada a 0,9 segundos.
La hora se ha convertido en una infraestructura invisible que sostiene la firma electrónica, los pagos, la energía y las telecomunicaciones. Que los metrólogos hayan optado por un tiempo continuo es una buena noticia para todos ellos.
Otros artículos de este blog sobre la gestión del tiempo
Hace un año repasé en este blog los retos de adecuación a las normas NIS2, CRA, CER y DORA. Desde entonces he hablado de ellas con partners y clientes en el roadshow NIS2 & DORA de Ingram Micro, en Madrid, Barcelona, Málaga y, este octubre, en Bilbao. La pregunta que más se repite en el turno de preguntas no es «¿qué dice cada norma?», sino «¿cómo cumplo todas a la vez sin montar cinco proyectos distintos?».
En 2026 la lista se ha alargado con el Reglamento de Inteligencia Artificial (AI Act), y varias fechas se han movido. Este artículo actualiza el calendario y propone una respuesta práctica a esa pregunta: tratar el cumplimiento como un único sistema de gobierno, riesgo y cumplimiento (GRC), con un mapa de controles común para todas las normas.
Qué ha cambiado desde 2025
En un año, tres normas han empezado a exigir cosas nuevas y dos siguen esperando su ley española. DORA se aplica desde enero de 2025; la notificación de vulnerabilidades del CRA, desde septiembre de 2026; y las reglas de transparencia del AI Act, desde agosto de 2026. NIS2 y CER, en cambio, siguen sin transponer en España, y el alto riesgo del AI Act se ha aplazado a 2027 y 2028. A eso se suma la disolución de las Cortes el 6 de octubre, con elecciones generales el 29 de noviembre: los proyectos de ley españoles sobre entidades críticas y sobre inteligencia artificial han decaído y vuelven a la casilla de salida.
Calendario de NIS2, DORA, CER, CRA y AI Act: hitos de 2024 a 2028. La línea discontinua marca noviembre de 2026.
La línea discontinua marca el dia de hoy: todo lo que queda a su izquierda ya debería estar resuelto.
Norma por norma
Cada norma mira el riesgo digital desde un ángulo distinto: la entidad, el producto, el sector financiero, la infraestructura física o el algoritmo.
NIS2: la ciberseguridad de la organización
La Directiva (UE) 2022/2555 obliga a las entidades esenciales e importantes de 18 sectores a gestionar sus riesgos de ciberseguridad y a notificar los incidentes significativos: alerta temprana en 24 horas, notificación en 72 horas e informe final en un mes. Exige que los órganos de dirección aprueben las medidas, se formen y respondan de su cumplimiento.
En España seguimos sin ley. El anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad se aprobó en primera vuelta en enero de 2025, pero nunca llegó a remitirse a las Cortes como proyecto de ley, y en julio de 2026 la Comisión Europea llevó a España ante el Tribunal de Justicia de la UE por no transponer la directiva. Tras la disolución de las Cortes, su futuro depende del Gobierno que salga de las elecciones. Mientras tanto siguen vigentes el Real Decreto-ley 12/2018 y el Esquema Nacional de Seguridad, y muchas empresas españolas ya reciben exigencias NIS2 por contrato de clientes de otros países que sí la han transpuesto. Pero el terreno no está vacío.
Que no haya ley no significa que no haya obligaciones. El Reglamento de Ejecución (UE) 2024/2690, de 17 de octubre de 2024, desarrolla NIS2 para once tipos de proveedores digitales: servicios DNS, registros de dominios de primer nivel, computación en nube, centros de datos, redes de distribución de contenidos, servicios gestionados y de seguridad gestionada, mercados en línea, motores de búsqueda, redes sociales y prestadores de servicios de confianza. Al ser un reglamento, es directamente aplicable y no necesita transposición, como ya comenté a propósito del roadshow de Ingram Micro.
Su anexo detalla, en trece secciones, las medidas técnicas y metodológicas que se esperan: política de seguridad, gestión de riesgos, gestión de incidentes, continuidad, cadena de suministro, control de accesos o criptografía, entre otras. También fija cuándo un incidente es significativo, por ejemplo una pérdida económica directa superior a 500.000 euros o al 5 % de la facturación anual, o un servicio en la nube indisponible más de 30 minutos. Para cualquier otra empresa es, además, la mejor guía disponible de lo que un supervisor considerará «medidas adecuadas» cuando llegue la ley española.
CRA: la seguridad del producto
El Reglamento (UE) 2024/2847, de ciberresiliencia, se dirige a fabricantes, importadores y distribuidores de productos con elementos digitales, del software al dispositivo conectado. Exige seguridad desde el diseño, gestión de vulnerabilidades durante todo el ciclo de vida, actualizaciones de seguridad y una lista de componentes (SBOM).
Desde el 11 de septiembre de 2026 ya hay que notificar las vulnerabilidades explotadas activamente y los incidentes graves que afecten a un producto: alerta en 24 horas, notificación en 72 horas e informe final, a través de la plataforma única de notificación de ENISA. El resto de obligaciones, incluido el marcado CE con requisitos de ciberseguridad, se aplica desde el 11 de diciembre de 2027.
DORA: la resiliencia operativa del sector financiero
El Reglamento (UE) 2022/2554 se aplica desde el 17 de enero de 2025 a bancos, aseguradoras, gestoras, entidades de pago y proveedores de criptoactivos. Pide un marco de gestión del riesgo TIC aprobado por el consejo, notificación de incidentes graves, pruebas de resiliencia (incluidas pruebas de penetración basadas en amenazas para las entidades más relevantes) y un control estricto de los proveedores TIC, con registro de información de todos los contratos.
En noviembre de 2025 las autoridades europeas de supervisión publicaron la primera lista de proveedores TIC críticos, que pasan a supervisión europea directa. Para el resto de proveedores de la banca, DORA llega por contrato: cláusulas obligatorias, derecho de auditoría y planes de salida.
CER: la resiliencia física de las entidades críticas
La Directiva (UE) 2022/2557 amplía la protección de infraestructuras críticas a toda amenaza que pueda interrumpir un servicio esencial: catástrofes naturales, sabotaje, terrorismo, crisis sanitarias o fallos en la cadena de suministro. Las entidades designadas como críticas deben evaluar sus riesgos, aprobar un plan de resiliencia y notificar los incidentes en 24 horas.
El Gobierno llevó al Congreso en marzo de 2026 el proyecto de Ley de Protección y Resiliencia de Entidades Críticas, que designaba a la Secretaría de Estado de Seguridad como autoridad competente y convertía el CNPIC en CNPREC. Preveía nueve meses para la evaluación de riesgos tras la designación, seis para el plan de resiliencia y multas de hasta 10 millones de euros o el 2 % de la facturación mundial. La parte de ciberseguridad de estas entidades se remitía a NIS2. El proyecto decayó con la disolución de las Cortes y tendrá que aprobarse y presentarse de nuevo en la próxima legislatura. Mientras tanto sigue vigente la Ley 8/2011 de protección de infraestructuras críticas, y el plazo europeo para identificar a las entidades críticas, julio de 2026, ya ha vencido.
AI Act: el riesgo del algoritmo
El Reglamento (UE) 2024/1689 clasifica los sistemas de IA por nivel de riesgo. Las prácticas prohibidas y la obligación de alfabetización en IA rigen desde febrero de 2025; las obligaciones de los modelos de uso general, desde agosto de 2025; y las de transparencia del artículo 50 (avisar de que se habla con una IA, marcar el contenido sintético), desde el 2 de agosto de 2026.
El paquete ómnibus digital, publicado en julio de 2026 como Reglamento (UE) 2026/1744, aplazó las obligaciones de los sistemas de alto riesgo: al 2 de diciembre de 2027 los del anexo III (empleo, solvencia crediticia, educación, biometría, servicios esenciales) y al 2 de agosto de 2028 los integrados en productos regulados. El aplazamiento da aire, pero no cambia lo que hay que preparar: inventario de sistemas, gestión de riesgos, gobernanza de datos, supervisión humana, registros y ciberseguridad del propio sistema. En España, la autoridad de supervisión es la AESIA. El Proyecto de Ley Orgánica para el buen uso y la gobernanza de la inteligencia artificial, que debía completar el reparto de autoridades y el régimen sancionador nacional, estaba en el Congreso desde junio de 2026 y también decayó con la disolución. El reglamento europeo se sigue aplicando directamente, pero sin esa ley el régimen sancionador español queda incompleto.
Lo que tienen en común
Leídas juntas, las cinco normas piden casi lo mismo con distinto vocabulario. Hay seis piezas que se repiten:
Responsabilidad de la dirección. NIS2 y DORA exigen que el consejo apruebe y supervise las medidas; CER pide una función de seguridad y resiliencia asignada; el AI Act exige un sistema de gestión de la calidad y responsables identificados.
Gestión de riesgos documentada. Todas parten de un análisis de riesgos periódico, con medidas proporcionales y revisiones regulares.
Notificación de incidentes con reloj. NIS2, CRA y CER coinciden en las 24 horas para el primer aviso; DORA pide la notificación inicial en 4 horas desde que el incidente se clasifica como grave, y el AI Act exige comunicar los incidentes graves de los sistemas de alto riesgo.
Cadena de suministro. NIS2 pide evaluar a los proveedores, DORA regula sus contratos, el CRA obliga a controlar los componentes de terceros y el AI Act reparte obligaciones entre proveedor y responsable del despliegue.
Continuidad y recuperación. Copias de seguridad, planes de continuidad y pruebas periódicas aparecen en NIS2, DORA y CER.
Evidencias. Todas esperan que se pueda demostrar el cumplimiento ante un supervisor, un auditor o un cliente: políticas aprobadas, registros fechados, informes de pruebas y trazas de decisión.
La sexta pieza es la que más se olvida. Cumplir y no poder demostrarlo, a efectos prácticos, es no cumplir.
El GRC como hilo conductor
Si las seis piezas se repiten, lo razonable es construirlas una vez. Eso es un sistema de gobierno, riesgo y cumplimiento (GRC): un único marco en el que la dirección fija responsabilidades, se mantiene un solo registro de riesgos y cada control se asocia a todas las obligaciones que satisface.
En la práctica, un GRC bien planteado se apoya en cuatro elementos:
Un mapa de controles común. Se parte de un marco de referencia ya conocido (ISO/IEC 27001 o el Esquema Nacional de Seguridad) y se marca, control a control, a qué artículo de NIS2, DORA, CRA, CER o AI Act responde. Un mismo control de gestión de vulnerabilidades, por ejemplo, sirve a NIS2, al CRA y a DORA.
Normas de gestión complementarias. ISO 22301 para la continuidad, que alimenta DORA y CER, e ISO/IEC 42001 para los sistemas de gestión de la IA, que encaja con el AI Act.
Un procedimiento único de incidentes. Una sola clasificación y un solo flujo que, según el tipo de incidente, dispare la notificación a INCIBE-CERT o CCN-CERT, al Banco de España o la CNMV, a la plataforma de ENISA o al CNPREC, con sus plazos.
Una gestión de proveedores integrada. Un único inventario de terceros, con las cláusulas de DORA, las exigencias de seguridad de NIS2 y los requisitos de producto del CRA en el mismo expediente.
Las herramientas GRC del mercado automatizan buena parte de este trabajo: catálogos de controles con correspondencias entre normas, recogida de evidencias, cuadros de mando para la dirección y seguimiento de planes de acción. Pero la herramienta no sustituye al diseño: primero hay que decidir qué normas aplican y con qué alcance, y después elegir cómo gestionarlo.
La pieza que no aparece en ninguna norma: la criptografía poscuántica
Ninguna de las cinco normas menciona la criptografía poscuántica, pero todas exigen medidas acordes con el estado de la técnica. NIS2 pide políticas sobre el uso de la criptografía y el cifrado, y la sección 9 del anexo del Reglamento de Ejecución 2024/2690 exige una política criptográfica con gestión de claves; DORA, controles criptográficos que se revisen ante la evolución de las amenazas; el CRA, cifrado de los datos con mecanismos actualizados. Un algoritmo que un ordenador cuántico podrá romper dejará de ser estado de la técnica mucho antes de que ese ordenador exista, porque lo que hoy se cifra o se firma puede capturarse ahora y descifrarse o falsificarse después.
El calendario ya lo ha puesto la propia Unión Europea. La hoja de ruta coordinada para la transición a la criptografía poscuántica, publicada en junio de 2025, pide que a finales de 2026 estén hechos los inventarios de activos criptográficos, incluida la cadena de suministro; que en 2030 estén protegidos los casos de uso de alto riesgo; y que en 2035 la transición esté completa para los de riesgo medio. Los algoritmos de referencia, ML-KEM y ML-DSA, están normalizados por el NIST desde agosto de 2024.
Para un sistema GRC esto se traduce en tres tareas concretas: añadir al inventario de activos un inventario criptográfico (qué algoritmos, claves y certificados se usan y dónde), incluir la amenaza cuántica en el registro de riesgos, y exigir criptoagilidad a los proveedores, es decir, la capacidad de cambiar de algoritmo sin rediseñar el sistema. Un fabricante que hoy prepara el marcado CE de su producto para el CRA haría bien en contar con que ese producto seguirá en el mercado en 2030.
Las cinco normas de un vistazo
Norma
Qué protege
A quién obliga
Primer aviso de incidente
Situación a noviembre de 2026
NIS2
Redes y sistemas de información
Entidades esenciales e importantes de 18 sectores
24 horas
Anteproyecto nunca remitido a las Cortes; España, ante el TJUE
CRA
Productos con elementos digitales
Fabricantes, importadores y distribuidores
24 horas
Notificación obligatoria desde el 11-09-2026; resto, desde el 11-12-2027
DORA
Resiliencia operativa TIC
Entidades financieras y proveedores TIC críticos
4 horas tras clasificarlo como grave (máximo 24 horas)
Aplicable desde el 17-01-2025
CER
Continuidad de servicios esenciales ante cualquier amenaza
Entidades designadas como críticas
24 horas
Proyecto de ley decaído al disolverse las Cortes; sigue la Ley 8/2011
AI Act
Derechos y seguridad frente a sistemas de IA
Proveedores y responsables del despliegue de IA
Incidentes graves de sistemas de alto riesgo
Transparencia desde el 02-08-2026; alto riesgo, 2027 y 2028; ley orgánica española decaída
Una hoja de ruta en seis pasos
Determinar qué normas aplican. Por sector, tamaño, productos que se fabrican o distribuyen, uso de IA y relación con clientes financieros o entidades críticas. Muchas empresas descubren que les afectan tres o cuatro, aunque sea por contrato.
Nombrar un responsable y llevarlo al consejo. La dirección tiene que aprobar el marco y recibir informes periódicos.
Hacer un análisis de brechas único contra el mapa de controles común, no uno por norma.
Priorizar por plazos ya vencidos. DORA y la notificación del CRA ya se aplican; la transparencia del AI Act, también.
Unificar incidentes y proveedores en un solo procedimiento y un solo inventario.
Preparar las evidencias desde el principio, con fecha cierta y conservación a largo plazo.
En este último punto los servicios de confianza del Reglamento eIDAS aportan algo que ninguna hoja de cálculo ofrece: la firma y el sello electrónico acreditan quién aprobó una política o emitió un informe, el sello de tiempo cualificado prueba cuándo, y la conservación cualificada mantiene ese valor probatorio durante años. Un registro de incidentes o un informe de pruebas de resiliencia sellado en el momento en que se genera es mucho más difícil de discutir ante un supervisor. Y conviene que esas firmas y sellos sigan siendo válidos cuando llegue la criptografía poscuántica, otra razón para planificar la criptoagilidad.
Ninguna organización tiene que recorrer este camino sola. En el roadshow de Ingram Micro lo hemos visto en cada parada: fabricantes como HPE, SonicWall, Hornetsecurity, Barracuda o Bitdefender aportan la tecnología de protección, copia y recuperación, y la red de partners de Ingram Micro la integra en soluciones adaptadas a cada cliente. El cumplimiento normativo es, al final, una buena excusa para hacer bien lo que habría que hacer de todos modos.
Cómo puede ayudar EADTrust
En EADTrust llevamos años cumpliendo como prestador cualificado de servicios de confianza bajo eIDAS, con certificaciones en el Esquema Nacional de Seguridad (categoría alta), ISO/IEC 27001, ISO/IEC 20000-1 e ISO 22301, y esa experiencia es la que ponemos al servicio de otras organizaciones. Nuestra división de servicios profesionales acompaña a las empresas en todo el recorrido descrito en este artículo: el análisis de brechas unificado frente a NIS2, DORA, CRA, CER y AI Act, la implantación de las medidas y la preparación de evidencias con firma, sello y sello de tiempo cualificados. También ayudamos a hacer el inventario criptográfico y a planificar la migración a la criptografía poscuántica, un trabajo que ya hacemos con grandes clientes, y ofrecemos formación in company en computación cuántica y criptografía poscuántica.
Cuando el reto tiene tanto de jurídico como de técnico, nuestro trabajo puede completar el asesoramiento de Garrigues, accionista de EADTrust y referente en alinear las exigencias legales con las tecnológicas: el despacho interpreta la norma y nosotros la convertimos en controles, procedimientos y evidencias que funcionan. Si quiere un primer diagnóstico, puede escribirnos a info@eadtrust.com o llamarnos al 91 716 05 55 o al 902 365 612.
Hoy, 30 de octubre de 2026, Ainhoa Inza, Tech Policy Officer de EADTrust (cargo en el que se encuadran también sus responsabilidades como directora de Cumplimiento y de Servicios Profesionales), ha impartido a distancia la conferencia magistral internacional «Ciberseguridad en el mundo del cómputo cuántico» (anunciada en el programa como «Ciberseguridad en el tiempo del cómputo cuántico», con la misma filosofía) en el XXXIX Congreso Nacional y XXV Congreso Internacional de Informática y Computación ANIEI 2026, que se celebra del 28 al 30 de octubre en el Centro Universitario de la Costa (CUCosta) de la Universidad de Guadalajara, en Puerto Vallarta (Jalisco, México).
Es una satisfacción que la voz de EADTrust llegue a uno de los foros académicos de referencia de las tecnologías de la información en México, y que lo haga hablando de un tema que nos ocupa a diario: cómo preparar la criptografía, y con ella toda la ciberseguridad, para la llegada de los ordenadores cuánticos.
Las claves de la ponencia de Ainhoa Inza en ANIEI 2026.
ANIEI: casi cuatro décadas impulsando el talento TIC en México
La ANIEI (Asociación Nacional de Instituciones de Educación en Tecnologías de la Información, A.C.) reúne a universidades y centros de educación superior de todo México con programas de informática y computación. Además de sus reuniones de directivos, publica libros electrónicos con las aportaciones de sus congresos desde 2015 y concede cada año los reconocimientos a los mejores programas de tecnologías de la información del país, que distinguen a las titulaciones con más madurez y prestigio académico.
Su congreso anual es el gran punto de encuentro de estudiantes, docentes, investigadores y empresas del sector. La numeración de la edición de este año, la trigésima novena nacional y la vigésima quinta internacional, da idea de su trayectoria. Algunos hitos recientes:
2022, Puerto Vallarta. El CUCosta acogió la XXXV edición nacional y XXI internacional, con la que el congreso celebró su 40 aniversario.
2023, Xalapa. La Universidad Veracruzana organizó la XXXVI edición, con conferencias magistrales de Deborah J. Armstrong (Florida State University), sobre responsabilidad digital y el Objetivo de Desarrollo Sostenible 4; Luciano García Bañuelos (Tecnológico de Monterrey), sobre minería de procesos; Bárbara Baena (IBM), sobre inteligencia artificial generativa; y ponentes de Accenture, SAP, Fortinet y el CONAIC, el organismo acreditador de los programas de informática y computación.
2024, Tonalá. El Centro Universitario de Tonalá (CUTonalá) de la Universidad de Guadalajara fue la sede de la XXXVII edición, del 23 al 25 de octubre.
2025. La XXXVIII edición incorporó un hackatón virtual, la competencia de ciberseguridad Capture The Flag y el networking con empresas de TI, formatos que se mantienen este año.
En 2026 el congreso vuelve a Puerto Vallarta, de nuevo en el CUCosta.
ANIEI 2026: un programa a la altura
Esta edición cuenta con el respaldo de la Universidad Autónoma Metropolitana (UAM), el CONAIC, la Universidad de Guadalajara, la UNAM (FES Acatlán), la Universidad del Caribe y la Universidad de Colima, entre otras instituciones afiliadas. Su objetivo es fortalecer las competencias de las nuevas generaciones de profesionales TIC en un entorno marcado por la transformación digital, la inteligencia artificial, la ciberseguridad y la ciencia de datos.
Además de las conferencias magistrales, el programa incluye ponencias estudiantiles y académicas, talleres especializados, paneles de expertos, el Seminario CONAIC, una feria virtual de empleo, el Concurso Nacional de Programación, un hackatón, una Game Jam, la competencia Capture The Flag, el Concurso Nacional de Tesis, una feria de proyectos y los reconocimientos a los mejores programas y egresados de TI.
Entre los conferenciantes destacan:
Ernesto Piedras, director general de The Competitive Intelligence Unit (The CIU) y uno de los analistas más conocidos del sector de las telecomunicaciones en México, que abrió el congreso con «La creatividad como competencia estratégica para el futuro profesional».
Sanathan Juturu, de Tata Consultancy Services, con «AI Beyond the Hype: Build What Matters», sobre cómo llevar la inteligencia artificial más allá de la moda.
Geoffrey N. Dick, de St. John’s University (Nueva York), comisionado de ABET y veterano de la educación en sistemas de información, con «Cyber security in an AI world?».
Ainhoa Inza, de EADTrust, con la conferencia magistral internacional del último día sobre ciberseguridad y cómputo cuántico.
Gracias, Jorge
Esta intervención no habría sido posible sin Jorge Christen, profesor de la Universidad de Monterrey y colaborador de EADTrust en la formación sobre computación cuántica y criptografía postcuántica. Jorge es el creador de la metodología ENSAR (Experience, Name, Speak, Apply, Repeat) y del kit didáctico IQC, con el que construimos modelos físicos de la esfera de Bloch y de circuitos cuánticos en nuestros cursos. Su conocimiento del mundo académico mexicano y su generosidad han hecho de puente entre EADTrust y la comunidad de ANIEI. Muchas gracias, Jorge, por favorecer esta participación.
La propia ponencia de Ainhoa se apoya en materiales ENSAR, como el «menú» de algoritmos postcuánticos del NIST que usamos en esas formaciones.
La ponencia de Ainhoa Inza: ciberseguridad en el mundo del cómputo cuántico
Ainhoa tiene más de quince años de experiencia en PKI, identidad digital y servicios de confianza. Dirigió TCAB, uno de los primeros organismos europeos de evaluación de la conformidad de prestadores cualificados de confianza bajo eIDAS, y está especializada en los aspectos tecnológicos y normativos de los servicios que aplican criptografía: eIDAS y eIDAS 2, DORA, NIS2, criptoactivos y la Cartera de Identidad Digital Europea. Es auditora de sistemas de información y formadora en computación cuántica y criptografía postcuántica; tiene las certificaciones CISA y CDPSE de ISACA, ECES de EC-Council e ITIL 4, participa en los comités de normalización de ciberseguridad e identidad digital de UNE y es autora de publicaciones sobre identidad digital y MiCA. Es ingeniera química, licenciada en Administración y Dirección de Empresas y máster en Gestión Internacional de Empresas.
Su conferencia, pensada para un público mayoritariamente universitario, fue de lo más conocido a lo menos familiar: la criptografía como cimiento, la amenaza cuántica, la respuesta global, la criptoagilidad y lo que nos espera, con una parada específica en México y un turno de preguntas final.
1. La criptografía, cimiento de la ciberseguridad
Ainhoa partió de una definición: la ciberseguridad es la práctica de proteger equipos, redes, aplicaciones, sistemas críticos y datos frente a amenazas digitales. Protege cuatro propiedades (confidencialidad, integridad, disponibilidad y autenticidad) frente a ataques pasivos (escucha e interceptación), activos (alteración, suplantación, denegación de servicio), internos y distribuidos, y lo hace previniendo, detectando, respondiendo y disuadiendo.
La criptografía es la ciencia que protege la información mediante transformaciones matemáticas que dependen de una clave. Ofrece cuatro herramientas: el cifrado (confidencialidad), el intercambio de claves (acordar un secreto en un canal inseguro), la firma digital (autenticidad, integridad y no repudio) y las funciones hash (huella única de integridad). Para explicar la criptografía asimétrica, base de las comunicaciones en internet, recurrió a la «caja de mago» con dos cerraduras: lo que se cierra con una llave solo se abre con la otra; una es pública y se entrega a los demás, y la otra es privada. Recordó además dos principios:
Principio de Kerckhoffs: los algoritmos son públicos y se someten a escrutinio; el secreto está solo en la clave.
El algoritmo no lo es todo: una clave mal generada o una implementación defectuosa anulan el mejor algoritmo; con algoritmos nuevos, que a menudo implementa el propio sector, conviene ir de la mano de implementadores expertos.
Todos los dominios de la ciberseguridad se apoyan en ella: el cifrado AES, TLS y las VPN dan confidencialidad; SHA-2, SHA-3 y HMAC, integridad; los certificados, la PKI, MFA y FIDO2, autenticidad; y la firma y el sello electrónicos y los sellos de tiempo, no repudio. Su conclusión: si cae el cimiento asimétrico (RSA, curvas elípticas, Diffie-Hellman), se resienten todos los pisos superiores. Y esa criptografía está en todas partes: HTTPS, VPN, firma electrónica, identidad digital (e.firma, DNI electrónico, carteras digitales), pagos y actualizaciones de software.
2. La amenaza cuántica: Shor, Grover y HNDL
Un ordenador cuántico trabaja con cúbits (qubits), que pueden estar en superposición de 0 y 1; n cúbits representan 2ⁿ combinaciones a la vez, pueden entrelazarse y colapsan a un resultado al medirlos. Los cúbits físicos son frágiles, y la corrección de errores agrupa muchos de ellos en un cúbit lógico fiable. Las puertas cuánticas, como Hadamard o CNOT, preparan estados en los que la interferencia amplifica la respuesta correcta. La diferencia entre cúbits físicos y lógicos es enorme: un equipo con un millar de cúbits físicos puede ofrecer apenas un centenar de cúbits lógicos útiles.
No es un ordenador más rápido para todo, pero con algoritmos específicos como el de Shor resuelve los problemas matemáticos que sostienen la criptografía asimétrica. Matizó que estos ataques no son nuevos: ya existen contra la criptografía clásica, pero el ordenador cuántico los hace mucho más eficientes, y la inteligencia artificial también está erosionando la robustez criptográfica actual. Contra Shor no sirve alargar las claves, como se hacía frente a los ordenadores clásicos; contra Grover sí, a costa de más recursos de cómputo. Ainhoa repasó el efecto sobre cada familia criptográfica:
Familia
Ejemplos
Efecto cuántico
Riesgo
Simétrica
AES, ChaCha20
Grover reduce a la mitad la seguridad: AES-256 sigue siendo seguro; AES-128 queda en 64 bits
Moderado
Asimétrica
RSA, ECC, Diffie-Hellman
Shor la rompe en tiempo polinómico
Crítico
Funciones hash
SHA-2, SHA-3
Grover reduce parcialmente su resistencia; SHA-512 y SHA-3 mantienen margen
Bajo
Presentó también cómo han caído las estimaciones de recursos para romper RSA-2048: de unos 20 millones de cúbits físicos en 2019 (Gidney y Ekerå) a menos de un millón en 2025 (Gidney) y, en la estimación más reciente de Alice & Bob, unos 22.600 cúbits de tipo «cat» y 3,14 días de cálculo (Pappalardo et al., Cryptology ePrint Archive 2026/2665). Son estimaciones teóricas: esa máquina aún no existe, pero cada año se necesita una más pequeña. Y el hardware también avanza: en enero de 2026 QuEra publicó en Nature un sistema con 96 cúbits lógicos, codificados en 448 átomos neutros.
El riesgo no empieza el «Q-Day»: con la estrategia «recolectar ahora, descifrar después» (Harvest Now, Decrypt Later, HNDL) un adversario intercepta hoy tráfico cifrado de alto valor y lo descifrará cuando tenga un ordenador cuántico relevante. El teorema de Mosca lo resume: si la vida útil del dato (X) más el tiempo de migración (Y) supera el tiempo hasta un ordenador cuántico relevante (Z), hay que migrar ya. Su ejemplo: un historial médico cifrado hoy con RSA-2048 debe seguir protegido entre 50 y 100 años. Por eso la migración ya es prioritaria en sectores como la energía, la banca, la salud o la educación, donde muchas entidades no es que vayan a llegar justas: van a llegar tarde. En cuanto a horizontes, recordó que algunas previsiones sitúan ya en 2029 el primer ordenador cuántico criptográficamente relevante, que ningún escenario, ni optimista ni pesimista, lo lleva más allá de 2035 y que quien lo consiga primero no lo anunciará: lo usará. Además, advirtió que la inteligencia artificial aplicada al criptoanálisis puede acortar estos plazos.
3. La respuesta global: estándares y normativa
La respuesta ya está estandarizada. Ainhoa presentó el «menú» de algoritmos postcuánticos del NIST:
ML-KEM (FIPS 203, antes Kyber): encapsulado de claves para TLS, que los navegadores ya despliegan en modo híbrido junto con la curva elíptica; recomendó ML-KEM-768 o 1024.
ML-DSA (FIPS 204, Dilithium): sustituto de las firmas actuales en los certificados X.509, para firma general y de código y para autenticación en arquitecturas SOAP y API REST.
SLH-DSA (FIPS 205, SPHINCS+): firma basada en hash, más lenta, para firmware y documentos de larga vida.
FN-DSA (FIPS 206, Falcon): firma compacta y rápida, aún sin publicar; según Ainhoa, el NIST la retrasa a 2027 mientras rehace su implementación para evitar la aritmética de coma flotante.
HQC (seleccionado en 2025): encapsulado basado en códigos, para diversificar frente a los retículos.
Ainhoa insistió en la prudencia. RSA, de finales de los años setenta, acumula décadas de criptoanálisis, mientras que los nuevos algoritmos llevan entre cinco y diez años de escrutinio público, y SIKE, candidato del concurso del NIST, cayó ante un ataque con un ordenador clásico. De ahí los esquemas híbridos y la diversificación de familias matemáticas, para no «poner todos los huevos en la misma cesta». Además, las claves postcuánticas son entre 10 y 50 veces mayores que las actuales, lo que afecta a la memoria de los HSM y al rendimiento.
El calendario ya está en marcha: 2026, gobernanza, política criptográfica, inventario (CBOM) y análisis de riesgo; 2027, pruebas de concepto; 2028, modo híbrido en producción en sistemas críticos; 2030, migración de los sistemas de riesgo alto; y 2035, transición completa. La UE, EE. UU., Canadá y el G7 convergen en el horizonte 2030–2035, y para Latinoamérica los estándares del NIST son la referencia técnica de facto. Es un calendario muy ambicioso: abandonar SHA-1, que se sabe débil desde hace unos veinte años, ha llevado más de dos décadas, y ahora se pretende una migración criptográfica generalizada en menos de diez.
Del estándar se pasa a la obligación: normas técnicas (NIST, ISO/IEC 27001 y 42001, ETSI, PCI DSS 4.0), regulación europea (NIS2, DORA, eIDAS 2 y CRA) y referencias nacionales. La regulación europea no fija algoritmos: exige un análisis de riesgos que contemple los riesgos emergentes, como el cuántico, y deja los controles a cada entidad según la proporcionalidad, como en protección de datos. En España, según explicó, la Administración trabaja además en un real decreto que incluirá una hoja de ruta criptográfica.
4. México: el contexto regulatorio
Ainhoa dedicó una parte específica al país anfitrión:
Plan Nacional de Ciberseguridad de la Agencia de Transformación Digital y Telecomunicaciones (4 de diciembre de 2025), con un modelo preventivo que prevé una estrategia nacional y una ley general.
Política General de Ciberseguridad para la Administración Pública Federal (DOF, 17 de diciembre de 2025), obligatoria para sus dependencias y entidades.
Iniciativa de Ley de Ciberseguridad en el Senado (30 de abril de 2025), con una agencia nacional, infraestructuras críticas y auditorías con estándares internacionales.
Ley Federal de Protección de Datos Personales en Posesión de los Particulares, vigente desde el 21 de marzo de 2025, que exige medidas de seguridad proporcionales al riesgo.
Y un dato que lo resume: la e.firma del SAT supera los 55 millones de certificados y se apoya en una PKI de clave pública, justo lo que amenaza Shor. Su propuesta: aprovechar la futura ley y sus lineamientos para incorporar la criptoagilidad y los estándares postcuánticos del NIST. México podría ser así uno de los pocos países que recojan la criptoagilidad en el propio texto de la ley, al menos en su exposición de motivos.
5. Criptoagilidad: cambiar sin romper
Con una metáfora muy gráfica, Ainhoa comparó una cerradura soldada a la puerta (criptografía «cableada» en cada programa o dispositivo, que obliga a rehacer el sistema para cambiar un algoritmo) con un bombín intercambiable (criptografía como servicio separado que se actualiza sin tocar el resto). Deben poder cambiarse el algoritmo (RSA por ML-KEM), los parámetros (tamaños de clave), el protocolo (versión de TLS), los datos (el archivo histórico) y las reglas (nuevas normas). Porque «la criptografía ya no es un activo inmutable y seguro a perpetuidad». Y las políticas también deben ser criptoágiles: no se puede responder a ritmo humano a ataques que se producen a velocidad de máquina.
6. Qué nos espera
Ainhoa identificó cinco impactos para los próximos años:
Convivencia de algoritmos: clásicos, híbridos y postcuánticos coexistirán durante años, y la negociación entre ellos será superficie de ataque (degradación).
Criptografía visible: deja de ser invisible y afecta a gobiernos, empresas, universidades y personas.
Núcleos de estabilidad: NIST, ISO, ETSI y los supervisores nacionales darán estabilidad en un entorno de cambio continuo.
Soberanía digital: sin capacidad de evaluar o acceder a algoritmos seguros, la soberanía queda restringida; la criptografía ya fue tratada como un arma, y por eso China y Corea del Sur han lanzado sus propios concursos de algoritmos postcuánticos.
Transformación del hardware: HSM, tarjetas, IoT y redes deben adaptarse a claves y firmas mayores y a más consumo de recursos, y certificar el nuevo hardware puede llevar cuatro o cinco años: hay que vigilar qué dependencias llegarán a tiempo para 2030.
Cinco mensajes y un primer paso
Cerró con cinco mensajes: la criptografía es el cimiento; la amenaza es real y asimétrica; el riesgo empieza hoy; los estándares ya existen; y la criptoagilidad es una responsabilidad compartida. Y con una invitación dirigida a los estudiantes: aprender los fundamentos, identificar dónde usan criptografía, preguntar «¿con qué algoritmo y con qué clave?» ante cada «eso está cifrado», pensar en la vida útil de la información, exigir criptoagilidad a plataformas y proveedores, y compartir lo aprendido.
La pregunta de los estudiantes
En el turno de preguntas, un asistente planteó lo difícil que puede resultar el cómputo cuántico a los estudiantes de informática en México, donde estos conceptos apenas empiezan a entrar en los planes de estudio. Ainhoa lo comparó con los inicios de la computación clásica y las tarjetas perforadas: se aprende probando. Citó el enfoque de Jorge Christen, que tras una primera base pasa enseguida a la práctica con simuladores gratuitos como los de IBM y Qiskit. Y tranquilizó a quienes temen las matemáticas: para afrontar la migración postcuántica no hace falta dominar la matemática de los algoritmos (pocos informáticos sabrían explicar RSA), sino tener criterio para saber dónde se usa la criptografía y elegir implementaciones correctas y certificadas, como las bibliotecas que ya incorporan algoritmos postcuánticos, entre ellas OpenSSL.
Para seguir leyendo
Enhorabuena a Ainhoa por su intervención, y gracias a la organización de ANIEI 2026 por la invitación. Si quieres profundizar en estos temas, estos artículos del blog son un buen punto de partida:
Si tu organización necesita evaluar su uso de la criptografía o planificar la transición postcuántica, en EADTrust podemos ayudarte: info@eadtrust.com · http://www.eadtrust.eu.
En 1994 la web apenas tenía un año de vida pública y Netscape acababa de inventar SSL. En 2026, los Estados miembros apuran el plazo para ofrecer a cada ciudadano una Cartera de Identidad Digital Europea en su móvil. Entre ambos momentos caben 32 años de certificación y firma electrónica en España: pioneros privados, normas que llegaron tarde, el DNI electrónico, dos reglamentos europeos y una ley española, la 6/2020, que cerró el ciclo abierto en 1999.
En octubre de 2006 publiqué en este blog «12 años de firma electrónica en España», una versión ampliada de un artículo que publiqué en la revista eSecurity Latinoamérica. Veinte años después, merece la pena recoger aquella historia y continuarla. Las primeras partes de este artículo resumen lo que entonces conté; las siguientes, lo que ha pasado desde entonces.
1994-1999: los pioneros
El sector nació de la mano del comercio electrónico. Netscape creó SSL en 1994 y los «servidores seguros» necesitaban un certificado que acreditara su identidad. RSA escindió su departamento de certificación en una empresa nueva, Verisign, que dominó el mercado mundial, con la sudafricana Thawte como competidora agresiva en precio.
En España, en 1995, Banesto puso en marcha la primera Autoridad de Certificación privada y no académica. Era una CA de un solo nivel, sin jerarquía, que emitía certificados de servidor SSL y de correo S/MIME y que autenticaba a las tiendas conectadas a la pasarela de pagos del banco. Las páginas de novedades de banesto.es que conserva la Wayback Machine, de julio de 1997, anuncian «Banesto lanza la emisión de Certificados» junto a otros hitos de la época: el primer servidor seguro de España, la tarjeta de dinero virtual Virtu@lCash, la tienda virtual y una oficina navegable en VRML. Casi a la vez, las universidades politécnicas de Madrid y Barcelona trabajaban en proyectos académicos como ICE-TEL.
Le siguieron otras iniciativas privadas:
IPS-CA vendía certificados desde principios de 1996 y fue de las primeras en lograr que Microsoft incluyera su raíz en Internet Explorer.
ACE, la Agencia de Certificación Electrónica, se constituyó en mayo de 1997 con CECA, Sistema 4B, SERMEPA y Telefónica, y desplegó una de las primeras infraestructuras del mundo para SET, el protocolo de Visa y Mastercard para pagos con tarjeta.
FESTE, la Fundación para el Estudio de la Seguridad de las Telecomunicaciones, nació a finales de 1997 en Barcelona, presidida por Miquel Roca. Notarios, corredores de comercio y abogados aportaron la visión de la seguridad jurídica preventiva y la fe pública, que influyó en la Directiva europea.
Mientras tanto, la exportación de criptografía seguía controlada por Estados Unidos. Los navegadores fuera de ese país solo cifraban con 40 bits efectivos hasta que, en 2000, se liberalizó del todo. Lo conté con detalle en «Cuando la criptografía era un arma».
1999-2006: de la Directiva a la Ley 59/2003
El Real Decreto-ley 14/1999, de 17 de septiembre, se adelantó incluso a la Directiva 1999/93/CE, de 13 de diciembre de 1999. Pero aquella norma, y la Orden de 21 de febrero de 2000 que regulaba la acreditación de prestadores, sirvieron de poco. Preveían un registro en el Ministerio de Justicia que nunca se creó y una evaluación sin normas ni evaluadores. Durante cuatro años, la Directiva tuvo más valor práctico para los prestadores privados que la norma española que la trasponía, mientras sucesivas normas atribuían a la FNMT-RCM competencias que debían prestarse en libre competencia.
El sector se organizó igualmente. En junio de 2000 nació AECODI, la Asociación de Entidades de Confianza Digital, y en julio AC Camerfirma se independizó del Consejo Superior de Cámaras, con la red de autoridades de registro más densa del país. En 2001 llegó Firmaprofesional, ligada a los colegios profesionales catalanes. Abogados, ingenieros de caminos, registradores y notarios (con FESTE, después con la FNMT y finalmente con ANCERT) lanzaron sus propias CA. ANF AC apostó por la factura electrónica y por UBL.
Camerfirma tenía un antecedente europeo: ChamberSign, creada en 1999 por Eurochambres y varias organizaciones camerales europeas, entre ellas la española, para que las firmas electrónicas de empresas certificadas por las cámaras fueran interoperables entre países. Era, avant la lettre, la preocupación por el reconocimiento transfronterizo que eIDAS resolvería quince años después.
Las administraciones abrieron grietas en el monopolio de hecho. La AEAT, con la Orden HAC/1181/2003, admitió certificados de prestadores distintos de la FNMT. El Real Decreto 209/2003 impulsó los registros telemáticos de los ministerios. Comunidades como la valenciana (ACCV), la catalana (CatCert) y la vasca (Izenpe) reconocieron también a prestadores privados.
Los usos reales crecían despacio. Según el estudio de AECE-fecemd de 2003, solo el 37,8% de los entrevistados usaba Internet y apenas uno de cada cinco internautas compraba en línea, con la desconfianza como freno principal. Hacia 2003 la firma se usaba sobre todo en las relaciones con la AEAT, en la factura telemática (Orden HAC/3134/2002), en los partes de accidentes de trabajo del sistema Delt@ y, ya integrada, en Office XP y Acrobat. La Ley 26/2003 abrió además la puerta al voto electrónico de los accionistas en las juntas de las sociedades cotizadas.
La Ley 59/2003, de 19 de diciembre, de firma electrónica cambió las expectativas. Sustituyó el registro fallido por un censo de prestadores en el Ministerio de Ciencia y Tecnología y aclaró el régimen de los certificados reconocidos. En aquel censo figuraba, entre los prestadores de certificados no reconocidos, BANESTO CA.
El ciclo de esos primeros doce años culminó en marzo de 2006 con la expedición en Burgos del primer DNI electrónico, regulado por el Real Decreto 1553/2005.
2006-2014: la administración electrónica toma el relevo
En 2006 confiaba en que el DNIe haría ubicua la firma electrónica, con seis millones de tarjetas al año. Lo segundo se cumplió y lo primero no del todo: los lectores de tarjetas y el software de cada sistema operativo frenaron su uso masivo. El certificado en fichero de la FNMT siguió siendo, durante años, la herramienta habitual de ciudadanos y gestorías.
El impulso vino del lado normativo y de la Administración:
La Ley 11/2007, de acceso electrónico de los ciudadanos a los servicios públicos, reconoció el derecho a relacionarse electrónicamente y dio cobertura a los sellos de órgano y a la actuación administrativa automatizada.
La Ley 56/2007, de medidas de impulso de la sociedad de la información, retocó la Ley 59/2003, como esperábamos en 2006.
Los Esquemas Nacionales de Seguridad e Interoperabilidad (Reales Decretos 3/2010 y 4/2010) y la plataforma de validación @firma ordenaron el uso de certificados de distintos prestadores en todas las administraciones.
Cl@ve, desde 2014, ofreció alternativas a la tarjeta y al certificado para trámites de menor riesgo.
Las Leyes 39/2015 y 40/2015 generalizaron la obligación de relacionarse electrónicamente para empresas y profesionales y distinguieron entre identificación y firma.
En 2015, el DNI 3.0 incorporó la interfaz sin contacto (NFC), pensando ya en el móvil. Mientras, la Directiva de 1999 envejecía: había creado mercados nacionales poco interoperables, y Bruselas preparaba su sustitución por un reglamento de aplicación directa.
2014-2016: el Reglamento eIDAS
El Reglamento (UE) 910/2014, de 23 de julio, sustituyó a la Directiva 1999/93/CE y se aplica a los servicios de confianza desde el 1 de julio de 2016. Al ser un reglamento, rige directamente en todos los Estados miembros, sin trasposición. Cambió el vocabulario: de «prestadores de servicios de certificación» y «certificados reconocidos» pasamos a prestadores cualificados de servicios de confianza y certificados cualificados.
El cambio de nombre zanjaba una vieja queja. Ya en 2004 se criticaba en la revista Información Comercial Española que la versión española de la Directiva hubiera traducido «qualified certificates» como «certificados reconocidos», cuando «cualificados» era más fiel y evitaba confundirlos con la figura homónima de la normativa española. eIDAS acabó dando la razón a quienes lo pedíamos.
Sus aportaciones principales fueron cuatro:
Amplió el catálogo de servicios: además de la firma, el sello electrónico de persona jurídica, el sello de tiempo, la entrega electrónica certificada, los certificados de autenticación de sitios web y la validación y conservación de firmas y sellos.
Creó las listas de confianza nacionales: estar en ellas es la prueba de la cualificación, verificable por cualquiera en toda la Unión.
Exigió una auditoría de conformidad periódica por un organismo acreditado, apoyada en normas ETSI y CEN.
Estableció el reconocimiento mutuo de la identificación electrónica notificada, obligatorio desde septiembre de 2018, y con él el nodo eIDAS español.
España se convirtió en uno de los países con más prestadores cualificados de la Unión, con una mezcla poco frecuente de prestadores públicos, corporativos y privados. Una parte de aquel ecosistema nacido en los años noventa y dos mil se integró en grupos internacionales, y aparecieron prestadores nuevos especializados en servicios de valor añadido.
2020: la Ley 6/2020 cierra el ciclo de 1999
La Ley 6/2020, de 11 de noviembre, reguladora de determinados aspectos de los servicios electrónicos de confianza, se publicó en el BOE del 12 de noviembre y entró en vigor al día siguiente. Derogó la Ley 59/2003 y, con ella, el último resto del modelo nacido con el Real Decreto-ley de 1999. También derogó el artículo 25 de la Ley 34/2002 sobre terceros de confianza, porque el Reglamento eIDAS ya regulaba la entrega electrónica certificada y la conservación.
A diferencia de sus predecesoras, no pretende regular de forma sistemática los servicios de confianza, ya cubiertos por el Reglamento, que por primacía del Derecho de la Unión no debe reproducirse. Se limita a completarlo donde el Reglamento remitía a los Estados:
Valor probatorio: modifica la Ley de Enjuiciamiento Civil y basta acreditar que el servicio figura en la lista de confianza para que opere la presunción a favor del documento.
Certificados cualificados: vigencia máxima de cinco años, contenido obligatorio de identificadores como el número de DNI, NIE o NIF, condiciones de suspensión, y renovación «encadenada» con un certificado vigente permitida una sola vez.
Identificación a distancia: abre la puerta a métodos distintos de la presencia física con seguridad equivalente, desarrollados después por la Orden ETD/465/2021 sobre videoidentificación.
Obligaciones de los prestadores: garantía económica para prestar servicios cualificados, gestión de riesgos de seguridad y notificación de incidentes al órgano de supervisión, y un régimen sancionador para cualificados y no cualificados.
Veinte años después de aquellas quejas por una «defectuosa regulación», España tenía por fin una norma breve, coherente con el marco europeo y útil para el sector.
2024: eIDAS 2 y la Cartera de Identidad Digital Europea
El Reglamento (UE) 2024/1183, de 11 de abril, en vigor desde el 20 de mayo de 2024, modificó el Reglamento eIDAS. Su pieza central es la Cartera de Identidad Digital Europea: una aplicación que cada Estado debe ofrecer a sus ciudadanos, en la que guardar sus datos de identificación personal y otras credenciales, presentarlos de forma selectiva y firmar con firma electrónica cualificada.
Para los prestadores, eIDAS 2 añade nuevos servicios de confianza cualificados:
Declaraciones electrónicas de atributos, cualificadas o emitidas por organismos públicos responsables de fuentes auténticas, que acreditan titulaciones, apoderamientos, licencias o cualquier otro atributo. Las expliqué en «¿Qué son las declaraciones electrónicas de atributos?».
Archivo electrónico cualificado, que da continuidad a la conservación.
Gestión de dispositivos remotos de creación de firma y sello, que consolida la firma en la nube.
El detalle técnico llega por oleadas de actos de ejecución que citan normas ETSI y CEN, y por el Architecture and Reference Framework (ARF) de la Comisión. Los sigo en esta entrada actualizada. A finales de 2026 vence el plazo para que los Estados pongan sus carteras a disposición de los ciudadanos, y en 2027 llegará la obligación de aceptarlas para muchas entidades privadas.
2025-2026: el DNI en el móvil, la cartera española y la transición postcuántica
España ha llegado a la era de la cartera por dos caminos paralelos. El primero es MiDNI, la aplicación de la Policía Nacional lanzada el 2 de abril de 2025 al amparo del Real Decreto 255/2025. Genera un código QR temporal firmado tras consultar en tiempo real la unidad de gestión del DNI, y desde abril de 2026 las entidades públicas y privadas están obligadas a aceptarlo para la identificación presencial. Es útil, pero es una solución nacional que convivirá con la Cartera de Identidad Digital Europea, y no será fácil que los ciudadanos distingan una de otra.
El segundo es la propia cartera. En octubre de 2026 el Ministerio para la Transformación Digital y de la Función Pública sometió a audiencia, con tramitación urgente, un proyecto de Real Decreto que regula su ecosistema en España: emisores, partes usuarias, fuentes auténticas y el papel de los prestadores cualificados. Como en 1999, la norma nacional llega con prisas detrás de la europea.
Mientras tanto, el sector afronta su siguiente gran cambio técnico. La amenaza del ordenador cuántico obliga a migrar a algoritmos postcuánticos y a diseñar sistemas criptoágiles, capaces de sustituir algoritmos sin rehacer las infraestructuras. Las administraciones ya han empezado a retirar las claves RSA de 2048 bits. Es la misma lección de los 40 bits de 1996: la robustez criptográfica nunca es definitiva.
Lo que enseñan 32 años
Tres constantes recorren estas tres décadas. La primera: la tecnología y el mercado van por delante de la norma, y la norma española suele llegar tarde y con prisas, aunque con la Ley 6/2020 acertó al limitarse a completar el Reglamento. La segunda: lo que impulsa la adopción no es la firma en sí, sino los servicios que la necesitan, del servidor seguro de 1995 a la sede electrónica, la factura o la cartera. La tercera: la fe pública y la seguridad jurídica preventiva, que FESTE defendía en 1997, han acabado en el corazón del modelo europeo de servicios cualificados.
En 2006 terminé con la maldición china: «vamos a vivir tiempos interesantes». Lo fueron. Los próximos, con la Cartera de Identidad Digital Europea, las declaraciones electrónicas de atributos y la criptografía postcuántica, lo serán todavía más.
Cronología
Año
Hito
1994
Netscape crea SSL; nace el mercado de certificados de servidor
1995
Banesto pone en marcha la primera CA privada no académica de España
1996
IPS-CA comercializa certificados
1997
Nacen ACE (con infraestructura SET) y FESTE; Banesto anuncia la emisión de certificados
1999
Real Decreto-ley 14/1999, Directiva 1999/93/CE y ChamberSign
2000
Nacen AECODI y AC Camerfirma como empresa independiente
2003
Orden HAC/1181/2003, Real Decreto 209/2003, Ley 26/2003 (voto electrónico en juntas) y Ley 59/2003 de firma electrónica
2006
Se expiden los primeros DNI electrónicos
2007
Ley 11/2007 de acceso electrónico y Ley 56/2007 de impulso de la sociedad de la información
2010
Esquemas Nacionales de Seguridad e Interoperabilidad
2014
Reglamento (UE) 910/2014 (eIDAS) y Cl@ve
2015
Leyes 39/2015 y 40/2015; DNI 3.0 con NFC
2016
eIDAS se aplica a los servicios de confianza (1 de julio)
2020
Ley 6/2020 de servicios electrónicos de confianza; deroga la Ley 59/2003
2021
Orden ETD/465/2021 de identificación remota por vídeo
2024
Reglamento (UE) 2024/1183 (eIDAS 2) y la Cartera de Identidad Digital Europea
2025
Real Decreto 255/2025 y lanzamiento de MiDNI
2026
MiDNI de aceptación obligatoria; proyecto de Real Decreto de la cartera española
Nota (octubre de 2026). La presentación de Ángel Martín que se recoge en el video referenciado en este artículo es muy interesante y sigue siendo una buena foto del proyecto, pero se dio el 26 de febrero de 2026 y desde entonces han pasado algunas cosas. Se han publicado nuevas versiones del Architecture and Reference Framework (la 2.9.0 en mayo y la 3.0.0 en verano). También se han adoptado nuevos actos de ejecución:
el Reglamento de Ejecución (UE) 2026/248, sobre los formatos de firma y sello electrónicos;
el Reglamento de Ejecución (UE) 2026/798, sobre el alta a distancia en la cartera, que el ponente da por rechazada «ayer»;
los Reglamentos de Ejecución (UE) 2026/1730, 2026/1731 y 2026/1735, de julio, que modifican los actos reabiertos (entre otras cosas, la fotografía del PID deja de ser una propuesta).
Lo que el ponente presenta como pendiente o en discusión debe leerse con esa perspectiva. Al final del resumen lo detallo.
En el XVI Congreso Nacional de Innovación y Servicios Públicos (CNIS 2026), celebrado el 26 de febrero de 2026, Ángel Luis Martín Bautista, jefe adjunto del Departamento de Tecnologías Disruptivas e Integridad de la Información de la Agencia Estatal de Administración Digital (AEAD), presentó la ponencia «Cartera de identidad digital: situación y ecosistema asociado».
La ponencia tiene tres partes: cómo avanza el proyecto europeo de cartera, el ecosistema de actores que la rodea y el estado del proyecto español. Sus mensajes principales son estos:
La cartera sustituye el modelo de nodos eIDAS de 2014 por otro en el que el ciudadano lleva sus datos y decide qué comparte.
La aplicación es solo una pieza. Para que funcione hacen falta una docena de actores, muchos de los cuales hay que notificar a la Comisión Europea.
La complejidad técnica crece: varios actos de ejecución se han reabierto y las tecnologías de formatos han pasado de 2 a 35, sin que se amplíe el plazo.
La cartera española debe estar lista el 24 de diciembre de 2026 y saldrá con el PID y las credenciales de mayor de 18 y de 16 años. El PID incluirá el número del DNI.
El alta exigirá nivel alto: cita presencial en una oficina de registro o lectura del DNIe por NFC. El alta totalmente remota no prosperó en la votación del acto de ejecución del día anterior a la charla.
El cotejo de identidades (identity matching) es un problema abierto, porque algunos países no incluirán un número de identificación en el PID.
Del eIDAS de 2014 a la cartera (0:53–3:44)
El primer Reglamento eIDAS, de 2014, buscaba que los medios de identificación electrónica de cada país sirvieran en los demás. La idea era buena, pero con los años mostró carencias:
Cada país notificaba su medio de identificación y los demás tenían que estudiarlo y aceptarlo, un proceso largo y farragoso.
Solo 14 Estados miembros llegaron a notificar un esquema; muchos ni siquiera ofrecían identificación electrónica a sus ciudadanos.
El sector privado no lo usó, aunque sí el público.
Era un sistema de «todo o nada»: se compartía toda la identificación o ninguna.
Exigía que cada Estado tuviera un nodo eIDAS que hacía de traductor. Cada vez que un país notificaba un medio nuevo, los 27 nodos tenían que actualizarse.
El nuevo modelo prescinde de los nodos: es el ciudadano quien lleva el dato y hace con él lo que quiere. La pieza central es la cartera digital.
Qué es la cartera de identidad digital de la UE y quién debe aceptarla (3:44–10:54)
Es el primer medio de identificación común de la UE: todos los ciudadanos podrán identificarse entre sí, en presencia y en línea, con un sistema interoperable.
Contiene los datos de identificación de la persona (PID), equivalentes a los del DNI español o la tarjeta de identidad de otros países.
Será obligatorio que cada Estado la ofrezca a finales de 2026, gratuita y voluntaria para el ciudadano.
Tiene tres funciones: identificar, presentar declaraciones electrónicas de atributos (cualquier atributo predicable de una persona, objeto o empresa) y firmar documentos electrónicos de forma gratuita para el ciudadano par usos particulares.
Se trabaja en casos de uso europeos y nacionales. Los europeos se definirán en rulebooks, guías con los datos, metadatos y arquitectura de cada caso.
Requisitos de ciberseguridad de nivel alto, divulgación selectiva de atributos y código fuente abierto.
Quién está obligado a aceptarla: el sector público; las entidades del sector privado obligadas a identificar a sus clientes (know your customer), como la banca, y los sectores que enumera el Reglamento (transporte, energía, servicios financieros, sanidad, agua…); y las grandes plataformas definidas por la Ley de Mercados Digitales. La diapositiva amplía la lista con seguridad social, servicios postales, infraestructura digital, educación y telecomunicaciones.
Otros servicios de confianza nuevos: la emisión de declaraciones electrónicas de atributos, con el mismo valor jurídico que un documento en papel; el archivo electrónico cualificado; y los libros mayores electrónicos. La gobernanza se apoya en un grupo de alto nivel sobre identidad digital en el que participan todos los Estados.
Esquema de funcionamiento: el ciudadano, en el centro, recibe las credenciales (declaraciones electrónicas de atributos) procedentes de fuentes auténticas o de emisores cualificados (hay credenciales cualificadas, no cualificadas y de organismos públicos) y las entrega a quien se las pida. La confianza transfronteriza se basa en registros de la Comisión y nacionales y en certificados de acceso y de registro. El ponente pone el ejemplo de una empresa alemana de alquiler de coches: la cartera debe saber que la empresa existe y alquila coches, y la empresa debe poder fiarse de los datos que recibe.
Actos de ejecución, consorcios y calendario (10:54–16:20)
Las especificaciones se debaten en el Marco de Arquitectura y Referencia (ARF), con un volumen de trabajo «increíble». Pero «lo que va a misa» es lo que los Estados votan en comitología: los actos de ejecución, que pasan a ser derecho vinculante.
La diapositiva de situación (referida a la versión 2.8.0 del ARF) detalla los lotes. La tabla sigue la presentación; la descripción oral del ponente no la sigue al pie de la letra.
Lote
Fecha en la diapositiva
Reglamentos de Ejecución (UE)
Situación en febrero de 2026
1
21/11/2024
2024/2979 (integridad y funcionalidades básicas), 2024/2977 (PID y declaraciones electrónicas de atributos), 2024/2980 (notificaciones del ecosistema), 2024/2982 (protocolos e interfaces), 2024/2981 (certificación)
Aprobados; todos salvo 2024/2981, reabiertos
2
06/05/2025 y 25/06/2025
2025/849 (listas de carteras), 2025/847 (brechas de seguridad), 2025/848 (partes usuarias), 2025/846 (cotejo de identidades), 2025/1569 (declaraciones electrónicas cualificadas de atributos)
Aprobados; 2025/848 y 2025/1569, reabiertos
3
25–26/06/2025
2025/1566, 1567, 1568, 1570, 1571, 1572, 1929, 1942, 1943, 1945 y 1946 (servicios de confianza: firma y sello electrónicos, certificados cualificados, dispositivos cualificados, validación y conservación)
Aprobados
4
16/09/2025
2025/2164 (formatos de las listas de confianza), 2025/2160 (prestadores no cualificados), 2025/2162 (organismos de evaluación de la conformidad)
Aprobados
5
13/11/2025
2025/2530 (requisitos de los prestadores cualificados), formatos de firma y sello electrónicos (sin número en la diapositiva; hoy, 2026/248), 2025/2527 (certificados cualificados de sitio web), 2025/2532 (archivo electrónico), 2025/2531 (libros mayores electrónicos)
Aprobados
6
—
Alta (on-boarding) en la cartera
Non paper enviado
Siguientes
—
Nivel de garantía (art. 8.3), certificación de dispositivos cualificados de creación de firma, marco de los esquemas de identificación electrónica
Non paper pendiente
El dato más llamativo: en el acto de formatos del lote 1 había dos formatos; con la reapertura, las tecnologías propuestas ascienden a 35, y el plazo para tener las carteras no se amplía. «Fácil no nos lo están poniendo.»
Grandes consorcios europeos: proyectos multipaís que trabajan casos de uso para redactar los rulebooks. Ha habido seis: DC4EU, Potential, EWC, NOBID, APTITUDE y WE BUILD. El primero, DC4EU (Digital Credentials for Europe), lo lideró España, con 101 participantes de 26 Estados. Casos de uso citados: pagos, permiso de circulación, tarjeta sanitaria europea, títulos académicos, apertura de cuenta bancaria y el documento portátil A1 para acreditar la vida laboral en varios países.
Calendario: en 2026 deben adoptarse todos los actos de ejecución y notificarse a la Comisión los actores responsables en cada país. A finales de 2026 las carteras deben estar disponibles para los ciudadanos, y a finales de 2027 las empresas obligadas deben aceptarlas. La diapositiva de planificación lo detalla así: eIDAS2 en vigor en 2024; actos de ejecución adoptados entre 2024 y 2026; notificaciones a la Comisión en 2026; verificación de edad en 2025–2026; aceptación obligatoria para el sector público a finales de 2026–2027 y para el privado a finales de 2027.
Verificación de edad (16:20–18:47 y 30:45–31:29)
Varios Estados, España quizá el primero, se plantearon proteger a los menores del contenido para adultos y vieron que era un problema transfronterizo que nadie podía resolver por su cuenta. La cartera, obligatoria en 2026, era el instrumento natural: un caso de uso más.
El reto técnico es grande, porque hay que demostrar sin lugar a dudas que se supera una edad sin revelar ningún otro dato, y además:
lo que se presente debe ser distinto cada vez, para impedir el perfilado;
no debe existir ningún registro («efecto Gran Hermano») de cuándo y dónde se ha usado la cartera para esto.
Ya está terminada una primera versión de las especificaciones. Es un protocolo armonizado en la UE, alineado con el artículo 28 del Reglamento de Servicios Digitales sobre protección de menores en línea. La cartera española incluirá dos credenciales, mayor de 18 y mayor de 16 años, derivadas de la fecha de nacimiento del PID.
El ecosistema, actor por actor (18:47–30:45)
Para el ponente, la cartera es «un aspecto, y no de los más complejos» del ecosistema. Todos estos actores deben estar funcionando el día del lanzamiento, y muchos hay que notificarlos a la Comisión Europea.
Actor
Qué hace, según la ponencia
Punto de contacto único
Persona u organismo de referencia en cada Estado para todo el ecosistema
Proveedor de la cartera
Quien la suministra a los ciudadanos; se notifica a la Comisión
Usuario titular
Ciudadano o empresa que tiene la cartera
Proveedor de PID
Emite los datos de identificación. Su acto de ejecución se había reabierto
Emisores de declaraciones electrónicas de atributos
Desde la DGT con el permiso de circulación hasta la empresa de alquiler de coches
Registro de partes usuarias
Nuevo procedimiento administrativo: un registro público, igual en todos los países, que acredita que una empresa existe, a qué se dedica y qué datos pide y para qué. Permite al ciudadano detectar peticiones excesivas («un título académico para alquilar un coche») y quejarse
Prestadores de servicios de confianza
Emiten a las partes usuarias registradas los certificados de acceso (obligatorios) y de registro (opcionales): X.509 «de toda la vida», pero exclusivos del ecosistema. El de acceso garantiza que la parte usuaria está registrada y comprobada; el de registro indica la finalidad y por qué se piden los datos. Este último es opcional porque aún faltan semánticas y metadatos por acordar
Organismo de supervisión
Ya existe; previsiblemente asumirá nuevas responsabilidades
Fuentes auténticas
Lugar donde reside de forma indudable el origen de una información (un registro público, una academia de inglés). Los prestadores podrán consultarlas para emitir credenciales, y las fuentes podrán encargar a un tercero que emita por ellas
Certificación
Esquema, organismo de certificación y organismos de evaluación de la conformidad. Dos esquemas: uno de ciberseguridad, con requisitos «extraordinariamente altos», y otro funcional
Cotejo de identidades (identity matching)
Mecanismo para saber si dos identificaciones corresponden a la misma persona
El PID y el problema del cotejo. Según el ponente, los datos obligatorios del PID son muy pocos: nombre, apellidos, fecha de nacimiento y nacionalidad. Entre los opcionales está el número de identificación administrativo, en el que España incluirá el número del DNI, así que los españoles no causarán problemas a nadie. Pero habrá países que no lo incluyan, porque no tienen ese número (en algunos se considera inconstitucional) o porque tienen varios. «¿Cómo sé yo que el John Smith irlandés que me pidió una subvención por la mañana no es el mismo que me la pidió por la tarde?» El cotejo de identidades pretende permitir pedir los datos adicionales necesarios para asegurarse.
La reapertura del acto del PID proponía además incluir la fotografía. España la veía interesante, pero difícil antes de fin de año, porque muchas oficinas de registro no tienen cámaras.
La cartera española (20:48–23:00 y 31:29–33:08)
Alta con nivel alto. Como la cartera se basa en un esquema de nivel alto, obtenerla exigirá las mismas garantías que un pasaporte o un DNI. Habrá dos vías:
Cita presencial en una oficina de registro. España es uno de los Estados con más oficinas de registro de la UE y las pondrá todas a disposición.
DNI electrónico por NFC: quien recuerde la contraseña de su DNIe y tenga activos sus certificados podrá acercarlo al móvil y crear el PID con garantías.
Se discutía en Europa una tercera vía, el alta digital remota (videollamada o verificación del documento por inteligencia artificial, como en la banca). El acto de ejecución se votó «ayer» (el 25 de febrero) y no salió adelante, porque muchos países no lo consideraban tan seguro.
Prototipo. El ponente mostró las pantallas: descarga, ayuda, activación, añadir la credencial de identidad digital y pedir cita desde la propia aplicación si no se tiene NFC. Las credenciales se piden mediante un código QR que lleva dentro la solicitud concreta.
Lanzamiento. La cartera saldrá con el PID y las credenciales de mayor de 18 y mayor de 16 años. Hay muchas otras en preparación, tanto europeas, procedentes de los consorcios, como españolas. La fecha fijada es el 24 de diciembre: «Vienen para Papá Noel».
La diapositiva de credenciales de valor añadido marca la de mayor de 16 años como «en estudio». Como futuras credenciales cita: titulaciones universitarias y no universitarias, permiso de conducción (DGT), tarjeta sanitaria europea, documento A1 de la Seguridad Social, residencia, tarjeta sanitaria de las comunidades autónomas y certificado de ausencia de delitos sexuales.
Cierre. «Es un proyecto muy complejo precisamente porque quiere ser sencillo para el usuario, muy seguro, y confluir con Europa.»
Qué ha cambiado desde febrero, y algunos matices
Alta remota. Pese a la votación fallida del 25 de febrero, en abril se publicó el Reglamento de Ejecución (UE) 2026/798, que regula el alta a distancia en la cartera con nivel de garantía alto.
Actos reabiertos. En julio se publicaron los Reglamentos de Ejecución (UE) 2026/1730, 2026/1731 y 2026/1735. Modifican los actos que la diapositiva marcaba como reabiertos: 2025/848; 2024/2977, 2024/2979, 2024/2980 y 2024/2982; y 2025/1569. Con el 2026/1731, la fotografía del titular pasa a formar parte del PID salvo que el usuario decida no incluirla.
Formatos de firma y sello. El acto del lote 5 que aparecía sin número es el Reglamento de Ejecución (UE) 2026/248.
ARF. La presentación se basa en la versión 2.8.0. Después llegaron la 2.9.0 y la 3.0.0, alineada con los actos modificados.
Datos obligatorios del PID. Entre ellos el ponente no menciona el lugar de nacimiento, que sí figura en el Reglamento de Ejecución (UE) 2024/2977.
Cotejo de identidades. El ponente lo presenta como un acto «en elaboración», pero su propia diapositiva muestra el Reglamento de Ejecución (UE) 2025/846 aprobado en mayo de 2025. Probablemente se refiere a su desarrollo práctico.
Lotes. Su descripción oral no coincide del todo con la diapositiva: sitúa las listas de confianza en el lote 5 (en la diapositiva están en el lote 4), y no solo el lote 1 estaba reabierto, sino también dos actos del lote 2.
Certificados de acceso y de registro. El registro de partes usuarias y estos certificados abren un papel nuevo para los prestadores de servicios de confianza.
Una de las claves privadas de una autoridad de certificación de confianza pública era, literalmente, el número 4. Otra era el 56. Las ocho claves de las CA intermedias que la entidad de certificación india eMudhra generó en abril de 2025 eran números enteros menores que 256, cuando deberían haber sido números aleatorios de 384 bits. Cualquiera podía calcularlas en menos de un segundo a partir de los certificados públicos.
Para entender por qué esto es tan grave (y por qué un algoritmo criptográfico basado en una curva «excelente» no salvó la situación), conviene recordar brevemente cómo funciona un certificado digital y qué es realmente una clave privada. Si ya conoces estos conceptos, puedes saltarte el siguiente apartado.
Qué es una clave privada y una clave pública
Imagina una caja de mago con dos tapas, dos cerraduras y un mecanismo que gira al cerrarla. Lo que se introduce en la caja con una llave solo se puede sacar por la otra tapa, con la otra llave. Una de las llaves se define para que pueda conocerla cualquiera (la llave pública) y la otra se protege celosamente (la llave privada).
En criptografía de curva elíptica (ECDSA), la clave privada es un número secreto muy grande, y la clave pública se calcula a partir de ese número. Si el número secreto es fácil de adivinar, cualquiera puede fabricar la «llave» privada y hacerse pasar por la autoridad de certificación.
Qué es una autoridad de certificación raíz y una intermedia
Una autoridad de certificación (CA, Certification Authority) es una entidad de confianza que emite certificados digitales, los «DNI» de los sitios web. Hay una CA raíz, la de más confianza, y CA subordinadas a ella (CA intermedias), que son las que firman los certificados de los sitios web que se usan en el protocolo TLS. Si la clave privada de una CA intermedia queda comprometida, un atacante puede emitir certificados válidos para cualquier dominio (google.com, tu banco, etc.) que los navegadores aceptarían, siempre que esa CA haya superado los requisitos de aceptación del CA/Browser Forum.
Entropía y generación de claves
La seguridad de la clave privada depende de que ese número sea impredecible. Si en lugar de un número aleatorio de unos 384 bits se usa un número pequeño (como 4 o 56), cualquiera puede probar todos los valores posibles en segundos. Es como poner «0004» como combinación de la caja fuerte.
HSM y ceremonia de claves
Un HSM (Hardware Security Module) es un dispositivo físico diseñado para generar y proteger claves de forma segura. Una ceremonia de claves es el procedimiento formal (con testigos, auditores, guiones, controles duales…) que se sigue para generar las claves de una CA. El fallo del prestador de servicios de certificación eMudhra no fue del algoritmo ni, aparentemente, del HSM en sí, sino de un error en el procedimiento y en el código de automatización durante esa ceremonia.
Las claves usaban el algoritmo ECDSA sobre la curva NIST P-384, uno de los algoritmos más robustos que hoy se usan en una PKI. Y no sirvió de nada. El caso recuerda algo que en el debate sobre criptografía postcuántica y criptoagilidad a veces se olvida: el algoritmo no lo es todo. Tan importante como elegir bien la curva o el tamaño de clave es generar la clave correctamente, comprobar que se ha generado bien y poder sustituirla con rapidez cuando algo falla, incluso cuando el fallo está en el propio hardware.
Qué ha pasado
Los certificados afectados son seis CA intermedias de TLS (EM DV, EM OV y EM EV TLS CA – G3B y G3C) y dos de firma de código (EM OV CS CA – G3B y G3C), que dependían de la raíz emSign ECC Root CA – G3 y tenían además una certificación cruzada de Sectigo.
Fecha
Hecho
30 de abril de 2025
Ceremonia de generación de claves en la que se crean las intermedias
2025
Las listas de revocación (CRL) de esas intermedias aparecen con firmas no válidas (bug 1970728 de Mozilla). eMudhra las vuelve a firmar y el síntoma desaparece
17 de octubre de 2026
Un investigador firma un mensaje con las ocho claves privadas y lo comunica a los programas de raíces. Chrome (CRLSet) y Firefox (OneCRL) bloquean las intermedias en pocas horas
18 de octubre
eMudhra revoca las ocho intermedias por compromiso de la CA; Sectigo revoca las certificaciones cruzadas
19 y 20 de octubre
Bloqueo en Android, Apple y Microsoft. Mozilla retira la raíz de su almacén. Go publica CVE-2026-111943
22 de octubre
eMudhra anuncia que abandona el negocio global de certificados SSL/TLS
27 de octubre (previsto)
Chrome retira la raíz emSign ECC Root CA – G3 de su almacén
Según Google, no llegó a registrarse en Certificate Transparency (el registro histórico público de certificados emitidos) ningún certificado fraudulento emitido con esas claves, por lo que los navegadores que exigen CT no pudieron ser atacados. Pero durante año y medio, cualquiera que hubiera mirado los certificados con atención habría podido emitir certificados de cualquier dominio aceptados por clientes que no exigen CT, como muchas aplicaciones y servicios que usan bibliotecas de Go, Python, Java o Node. eMudhra estima en unos 30.000 los certificados de clientes que deben migrar.
Actualización (26 de octubre). El hilo de Mozilla sigue abierto y aporta matices:
eMudhra insiste en que ella no emitió certificados finales con esas intermedias. Pero un participante ha contado 107.107 certificados registrados en Certificate Transparency entre el 20 y el 21 de octubre bajo seis de las ocho claves, emitidos por terceros una vez que las claves eran públicas. Es la demostración práctica de que cualquiera podía firmar con ellas.
Mozilla envió el 20 de octubre una lista de preguntas con 24 horas de plazo que, a 23 de octubre, seguían sin respuesta. El programa de raíces de Chrome ha rechazado que la presión mediática justifique el retraso.
eMudhra ha anunciado que presentará su informe completo dentro del plazo de 14 días que fija la CCADB. Varias respuestas vencen el 28 de octubre.
Se ha abierto otro incidente (bug 2085612) porque los servidores de CRL y OCSP de eMudhra bloqueaban peticiones según el agente de usuario, lo que podría incumplir los Requisitos Básicos sobre disponibilidad del estado de revocación.
La causa: una curva excelente con una clave ridícula
En ECDSA, la clave privada d es un número entero elegido al azar entre 1 y el orden de la curva, y la clave pública es el punto Q = d · G, que resulta de sumar el punto generador G consigo mismo d veces. La seguridad descansa en que, con un d de 384 bits aleatorios, recuperarlo a partir de Q (el problema del logaritmo discreto en curva elíptica) es inviable. Pero si d es menor que 256, basta con calcular 4·G, 56·G… hasta encontrar el punto que coincide con la clave pública del certificado: como mucho, 255 multiplicaciones.
Certificado intermedio
Clave privada (d)
EM OV TLS CA – G3C
4
EM EV TLS CA – G3C
56
EM OV CS CA – G3B
66
EM EV TLS CA – G3B
115
EM OV TLS CA – G3B
155
EM DV TLS CA – G3B
156
EM DV TLS CA – G3C
230
EM OV CS CA – G3C
237
Para hacerse una idea del tamaño: una clave privada correcta de P-384 tiene del orden de 2³⁸⁴ posibilidades, un número de 116 cifras. Estas claves tenían menos de 256.
Según la explicación preliminar de eMudhra en el hilo del incidente en Mozilla, el HSM funcionó correctamente. El fallo estuvo en el procedimiento:
Durante la ceremonia se generaron primero pares de claves correctos.
Una prueba de envoltura y desenvoltura (wrap/unwrap) aprobada como desviación del guión, combinada con un error en el código de automatización, creó en el HSM un segundo juego de claves con entropía truncada.
Por la coincidencia de etiquetas entre ambos juegos, el script usó las claves débiles para generar las solicitudes de certificado.
La raíz firmó esas solicitudes, y las listas de revocación, firmadas con las claves buenas, empezaron a fallar. En vez de investigar por qué, se volvieron a firmar con las claves débiles.
Hay un detalle técnico que merece atención: las comprobaciones habituales de validez de la clave pública no detectan este fallo. Un punto 4·G es un punto perfectamente válido de la curva P-384: cumple la ecuación, está en el subgrupo correcto y supera la validación completa de clave pública de NIST. Solo lo delata una prueba específica, comparar la clave pública con los múltiplos pequeños del generador, o una revisión de la clave privada antes de usarla.
No es la primera vez
La historia de la criptografía aplicada está llena de algoritmos impecables arruinados por una mala generación de claves o de números aleatorios. Y varios de los casos más graves ocurrieron en dispositivos certificados.
Año
Caso
Qué falló
Lección
2008
OpenSSL de Debian (CVE-2008-0166)
Un cambio en el código dejó como única fuente de entropía el identificador de proceso: solo unas 32.000 claves posibles por tipo y tamaño, durante casi dos años
Un fallo de software en la generación anula cualquier algoritmo
2010
Consola PlayStation 3
Sony firmaba con ECDSA reutilizando siempre el mismo número aleatorio por firma, y su clave privada pudo despejarse
En ECDSA no basta con una buena clave: cada firma necesita aleatoriedad nueva
2012
Estudio «Mining your Ps and Qs» (Heninger y otros)
Miles de dispositivos de red generaban claves RSA al arrancar, sin entropía suficiente, y compartían factores primos
Los dispositivos embebidos son especialmente vulnerables
2013
Tarjetas del certificado digital ciudadano de Taiwán (Bernstein y otros)
Un generador de números aleatorios defectuoso en tarjetas certificadas permitió factorizar 184 claves RSA
La certificación del hardware no garantiza la calidad de cada clave
2017
ROCA (CVE-2017-15361)
La biblioteca RSALib de Infineon generaba primos con una estructura que permitía factorizar claves de 1024 y 2048 bits. Afectó a TPM, a YubiKey 4 y a documentos de identidad electrónicos de Estonia (unos 760.000), Eslovaquia y España, cuyos certificados se suspendieron
El fallo puede estar en el chip, y afectar a millones de claves a la vez
2024
EUCLEAK (CVE-2024-45678)
La implementación de ECDSA de la biblioteca de Infineon filtraba la clave por canal lateral; estuvo sin detectar unos 14 años y unas 80 evaluaciones Common Criteria
Tampoco la curva elíptica en un chip certificado es garantía absoluta
2025-2026
eMudhra
Un error en el guión de la ceremonia dejó en producción claves P-384 menores que 256
El procedimiento importa tanto como el HSM
El caso ROCA tiene especial interés en España. A principios de noviembre de 2017, la Policía anunció que suspendía los certificados de los DNI electrónicos afectados y que los sustituiría, aunque los documentos siguieron siendo válidos para identificarse y viajar. Estonia tuvo que suspender los certificados de unas 760.000 tarjetas y abrir centros temporales para renovarlos. Fue una demostración a escala nacional de lo que significa no tener criptoagilidad.
Generar en el HSM, sí; pero poder importar claves también
La buena práctica, y lo que exigen las normas para las claves de las autoridades de certificación, es generar las claves dentro de un módulo criptográfico seguro (HSM): así la clave privada nunca existe en claro fuera de un entorno protegido. Es lo correcto, pero no basta, por dos motivos.
El hardware también falla. ROCA, las tarjetas de Taiwán o EUCLEAK demuestran que el generador de claves o la biblioteca criptográfica de un chip certificado pueden tener defectos que afectan a todas las claves que produce. Cuando eso ocurre, el fabricante necesita meses para corregir el firmware y volver a certificarlo, y mientras tanto el prestador no puede generar claves fiables con ese equipo.
La diversidad es una defensa. Si un prestador puede instalar en su HSM claves generadas externamente, en otro dispositivo certificado de un fabricante distinto o en un entorno de generación aislado y auditado, no depende de un único generador de números aleatorios ni de una única biblioteca. Si se descubre un fallo en uno, puede seguir operando con el otro sin esperar a que el fabricante lo corrija. Es criptoagilidad aplicada no al algoritmo, sino al origen de las claves.
Ahora bien, el caso eMudhra tiene una ironía: las claves débiles nacieron precisamente en una prueba de envoltura y desenvoltura, que es el mecanismo con el que se exportan e importan claves entre HSM. Importar claves no es más seguro por sí mismo; exige el mismo rigor que generarlas:
La clave viaja siempre cifrada con otra clave (wrapping) y nunca en claro.
El proceso se divide entre varias personas, con conocimiento compartido y control dual (esquemas M de N, que exigen la presencia de al menos M custodios de entre N posibles).
La importación se hace en una ceremonia con guion, auditores, testigos y acta, igual que la generación.
Las pruebas se hacen en un entorno distinto del de producción, y nunca dejan material criptográfico en el HSM productivo.
Cada clave lleva una etiqueta única y se verifica, antes de firmar la solicitud de certificado, que la clave pública de la solicitud es la que se acaba de generar o importar.
Y, sobre todo, venga de donde venga la clave, hay que comprobarla antes de certificarla.
Qué revisar en una ceremonia de claves
Las normas ya obligan a documentar y supervisar la generación de claves de las autoridades de certificación. Los Requisitos Básicos del CA/Browser Forum exigen un guión de generación de claves, que la ceremonia la presencie o la grabe un auditor cualificado y que este emita un informe. En Europa, la norma ETSI EN 319 411-1, que aplican los prestadores de servicios de confianza bajo eIDAS, pide que las claves de CA se generen en dispositivos criptográficos seguros y bajo control múltiple. Los Requisitos Básicos obligan además a rechazar claves con debilidades conocidas, como las del OpenSSL de Debian o las afectadas por ROCA.
La ceremonia de eMudhra se hizo con un HSM certificado FIPS 140-2 de nivel 3 y bajo un guión aprobado, y aun así falló. Por experiencia en auditoría, añadiría a la lista de comprobaciones algunas que no siempre se hacen:
Comprobar la calidad de cada clave generada, no solo que el HSM esté certificado. Para curvas elípticas, descartar que la clave pública coincida con múltiplos pequeños del generador. Para RSA, aplicar los detectores de ROCA, las listas de claves débiles conocidas y las pruebas de primos demasiado cercanos. Existen herramientas abiertas que agrupan estas pruebas, como paranoid_crypto, de Google, aunque su repositorio se archivó en agosto de 2026; en el hilo de eMudhra ya se ha preguntado si los programas de raíces aplican este tipo de comprobaciones a todas las intermedias.
Probar la clave con el certificado ya emitido: firmar un mensaje de prueba y verificarlo con la clave pública del certificado, no con la que el sistema «cree» que tiene.
Separar de verdad las pruebas de la producción. Cualquier desviación del guión, como la prueba de envoltura de eMudhra, debe repetirse después en un entorno limpio o justificar por qué no deja rastro.
Exigir etiquetas únicas e inventario de objetos del HSM al final de la ceremonia: cuántas claves hay, cuáles y para qué.
Tratar cualquier anomalía criptográfica como un posible incidente de claves. La firma no válida de las listas de revocación en 2025 era la pista que lo explicaba todo. Volver a firmarlas para que el error desapareciera fue tapar el síntoma.
Prever la sustitución. Tener ensayado cómo revocar una intermedia, generar o importar otra y migrar a los clientes en horas, no en meses.
Conclusión
En plena transición postcuántica, buena parte del debate se centra en qué algoritmos elegir: ML-DSA, SLH-DSA, curvas elípticas o RSA de más bits. El caso eMudhra recuerda que una clave de P-384 que vale 4 es más débil que una clave RSA de 512 bits bien generada. La seguridad de una PKI depende de una cadena con muchos eslabones: el algoritmo, el generador de números aleatorios, el hardware, el guión de la ceremonia, las personas que lo ejecutan, las comprobaciones posteriores y la capacidad de reaccionar. Y la criptoagilidad no consiste solo en poder cambiar de algoritmo, sino también en poder cambiar de clave, de fabricante y de origen de las claves cuando uno de esos eslabones falla.
As long as personal_administrative_number remains optional in the EUDI Wallet PID, reliable cross-border identity matching and qualified certificate issuance will be systematically weaker for citizens of Germany, France, Austria and several other Member States. A PID without a stable personal number forces relying parties and trust service providers to fall back on name + date of birth + nationality — a combination that is not unique. This is a design choice that undermines one of the core goals of eIDAS 2.
When a bank, a public body or a trust service provider receives a citizen’s person identification data (PID) from a European Digital Identity Wallet, it will want to know one thing above all: is this the same person I already know? Answering that question requires a stable identifier. Qualified certificates have had a standard way of encoding one for years. The PID has one too, but it is optional, and several Member States do not have a permanent personal number to put in it. This post explains how both encodings work, how they relate to each other, and where the gap lies.
The PID is issued in two encodings, built on the rules of Implementing Regulation (EU) 2024/2979:
ISO/IEC mdoc, with document type eu.europa.ec.eudi.pid.1. personal_administrative_number is a tstr (UTF-8 text string).
SD-JWT VC, with verifiable credential type urn:eudi:pid:1. personal_administrative_number is a string claim, selectively disclosable like the other claims.
Two details matter for identity matching:
personal_administrative_number is optional. The regulation defines it as a value assigned to the user that is unique among the numbers issued by the same PID provider. When a Member State chooses to include it, it must describe the policy for its values in its electronic identification scheme.
document_number is metadata about the PID itself, not a citizen identifier. It identifies the PID as a document and is also optional.
How qualified certificates encode identity numbers
For natural persons, the identifier goes in the serialNumber attribute of the subject field. When the certificate declares ETSI semantics (OID 0.4.0.194121.1.1), the value has four parts: a three-character type, the ISO 3166-1 two-letter country code, a hyphen and the identifier.
Prefix
Identifier type
Example
PAS
Passport number
PASSK-P3000180
IDC
National identity card number
IDCES-12345678Z
PNO
National personal number (civil register)
PNOBE-12345678901
TIN
Tax identification number, as listed by the European Commission (TAX is deprecated)
TINIT-RSSMRA80A01H501U
EID
Identifier based on electronic identification means, such as a national eID (new in V1.6.1)
EIDDE-…
XX:
National scheme registered in nameRegistrationAuthorities
EI:SE-200007292386
The PASSK and EI:SE examples come from the standard itself; the others are illustrative.
For legal persons, the organizationIdentifier follows the same pattern with the prefixes VAT, NTR, PSD and LEI. Since V1.6.1, NTR may carry the EUID of the European business registers, which already includes its own country code: the EUID ES28065.080862918 is encoded as NTRES-ES28065.080862918.
From PID to certificate
The EUDI Wallet will often be the starting point for issuing a qualified certificate: the trust service provider verifies the user’s identity from the PID and then issues the certificate. At that point it has to decide what to put in serialNumber. The choice depends on what the PID contains:
What the PID contains
Natural choice for serialNumber
Stable over time?
personal_administrative_number that is the national personal number
PNO + country, e.g. PNOBE-…
Yes
personal_administrative_number that is the identity card number
IDC + country, e.g. IDCES-…
Only where that number survives card renewal, as with the Spanish DNI
personal_administrative_number that is a number specific to the eID scheme or the PID provider
EID + country, the prefix added in V1.6.1
As stable as the scheme’s policy makes it
No personal_administrative_number
Only the identity document or passport number, verified by other means (PAS or IDC)
No: it changes with every new document
The last row is the problem. A PID without personal_administrative_number gives the provider nothing stable to anchor the certificate to, and the same applies to any relying party that needs to link the PID to an existing customer record.
The missing identity number
Checking the identity card specimens in PRADO, the Council’s public register of authentic identity and travel documents, shows that not every Member State prints a permanent personal number on its identity documents:
Country
Situation
Germany
Only the document number: 9 alphanumeric characters, starting with a letter and drawn from a restricted character set, which changes on renewal. Germany has no general-purpose national identification number
Austria
Only the document number, 2 letters + 7 digits (e.g. PA1234567), which changes on renewal; the Austrian eID works with sector-specific identifiers
France
Only the document number, 9 alphanumeric characters on the card issued since 2021 (e.g. X4RTBPFW4), which changes on renewal
Luxembourg
A 13-digit national register number exists, but it is not printed on the card
Ireland and Denmark
No national identity card
The EU has harmonised identity cards themselves: Council Regulation (EU) 2025/1208, which replaced Regulation (EU) 2019/1157 after the Court of Justice annulled it on procedural grounds, requires ID-1 cards with a machine-readable zone following ICAO Doc 9303. Cards without a functional machine-readable zone ceased to be valid on 3 August 2026. But harmonisation covers the document number, which appears in the machine-readable zone and changes with each card, not a personal number, which only some countries assign.
Cyprus shows the difference well: its card carries both a 10-digit identity card number, which is permanent, and a document number of 2 letters and 7 digits (e.g. HT0000000), which is the one in the machine-readable zone.
The reverse case also exists. In the Spanish DNI and the Portuguese Cartão de Cidadão, the document number field of the machine-readable zone holds the card (support) number, which changes with each card, while the permanent personal number goes in the optional data field. Italy has a permanent tax code (codice fiscale) alongside an electronic identity card number (2 letters + 5 digits + 2 letters, e.g. CA00000AA) that changes on renewal, and the Netherlands prints its permanent citizen service number (BSN, 9 digits) on both the identity card and the passport. A verifier reading only the document number of the machine-readable zone will therefore get a changing number even in countries that do have a permanent one.
Why this matters for cross-border identity matching
Commission Implementing Regulation (EU) 2025/846 on cross-border identity matching is designed precisely for situations in which a relying party needs to confirm that a person presenting a PID is the same person already known to it. When a stable personal number is present, matching is reliable and low-friction. When it is absent, matching falls back to the mandatory attributes (name, date of birth, place of birth, nationality).
These attributes are not unique. Common names combined with frequent birth dates produce collisions. A German or French citizen presenting a PID without personal_administrative_number will be harder for a bank in another Member State (or for a trust service provider issuing a qualified certificate) to match unambiguously than a Spanish or Dutch citizen whose PID carries a permanent number. The burden is highest exactly for the citizens of the countries listed in the table above.
What should be done
Member States and PID providers
Include personal_administrative_number in the PID whenever a permanent identifier exists, even if it is not printed on the identity card.
Where no national number exists, assign a stable, scheme-specific identifier to each citizen and publish the policy for its values, as the regulation requires.
Never use the identity card or passport document number as personal_administrative_number: it changes with every renewal.
Trust service providers
Use EID as the serialNumber prefix when the identifier comes from the eID scheme or the PID provider, and PNO or IDC only when it really is the national personal number or a permanent card number.
Record in the certificate policy how the identifier was obtained, so that relying parties can interpret it.
Relying parties
Do not assume that every PID will contain personal_administrative_number.
For citizens of countries without one, plan a matching procedure based on the mandatory attributes, and accept that it will be less reliable.
Suggested addition to the PID Rulebook / CIR 2024/2977
When a Member State has a permanent personal number (even if not printed on the identity document), it SHALL be included in personal_administrative_number. When it does not, it SHALL assign a stable scheme-specific identifier and document the policy for its values. The identity card or passport document number SHALL NOT be used as personal_administrative_number.
The eIDAS 2 Regulation asks Member States to ensure the unambiguous identification of persons in cross-border situations. As long as the stable identifier remains optional in the PID, record matching will fall to each relying party, and the burden will be heaviest precisely for the citizens of the countries in the table above.
Call to action
This gap is still open in the current ARF and in the consolidated text of Implementing Regulation (EU) 2024/2977. It can be closed without breaking existing implementations: the attribute already exists, it is simply optional. Making its use mandatory (or strongly recommended) whenever a stable number is available would improve matching reliability for a significant share of EU citizens and simplify the work of trust service providers and relying parties.
Feedback is welcome, especially from PID providers, wallet implementers and the eIDAS Expert Group.
EADTrust offers professional services to public and private entities (including those in the sectors obliged to accept the EUDI Wallet) that need to implement parts of the EUDI Wallet ecosystem — from PID and attribute issuance to relying-party integration, conformity assessment support and post-quantum readiness.
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:
El memorial (memoriale): borrador donde se anota todo tal como ocurre.
El diario (giornale): los asientos en orden cronológico, ya depurados, con su cargo y su descargo.
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.º
Fecha
Cuenta
Debe (€)
Haber (€)
1
3 de marzo
Ganado (activo)
5.000
1
3 de marzo
Bancos (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:
Estado
Qué muestra
Para qué sirve
Balance de comprobación de sumas y saldos
Sumas del debe y del haber, y saldo, de cada cuenta
Verificar que cargos y abonos cuadran antes del cierre
Balance (de situación)
Activo, pasivo y patrimonio neto en una fecha
Saber qué se tiene y qué se debe: activo = pasivo + patrimonio neto
Cuenta de pérdidas y ganancias
Ingresos y gastos del ejercicio
Conocer el resultado (beneficio o pérdida)
Estado de flujos de efectivo
Cobros y pagos por actividades de explotación, inversión y financiación
Entender 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.
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.
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.
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.
Hoy los Gobiernos fijan calendarios para que todos adoptemos criptografía más robusta, la postcuántica. Hace treinta años ocurría justo lo contrario: Estados Unidos consideraba la criptografía fuerte un arma y prohibía exportarla. Aquella etapa, conocida como las «guerras criptográficas» (crypto wars), dejó historias memorables, como la de un código fuente que viajó por el mundo impreso en un libro, y una herencia de algoritmos debilitados que tardó quince años en desaparecer. Merece la pena recordarla, porque es la mejor demostración práctica de por qué necesitamos criptoagilidad.
La criptografía como material militar
Durante décadas, Estados Unidos incluyó la criptografía en su lista de material de defensa, sometida a las normas sobre comercio de armas (ITAR). Desde 1996 pasó a regularse como bien de doble uso por el Departamento de Comercio (EAR), pero el efecto práctico fue el mismo durante años: exportar software con cifrado fuerte requería una licencia que, en general, no se concedía.
La consecuencia más visible afectó a la naciente web segura. Las versiones «internacionales» de Netscape Navigator e Internet Explorer solo podían negociar cifrado simétrico de 40 bits (RC4 o RC2) y un intercambio de claves RSA limitado a 512 bits. Fuera de Estados Unidos y Canadá, las conexiones HTTPS de bancos, tiendas y administraciones se protegían con una criptografía que, ya entonces, podía romperse en días con recursos modestos. La limitación no estaba en el certificado del sitio web, sino en el software del navegador.
Los certificados SGC: criptografía fuerte con permiso
Para los usos que el Gobierno estadounidense consideraba aceptables, sobre todo la banca, se ideó una excepción. Microsoft la llamó Server-Gated Cryptography (SGC) y Netscape, International Step-Up. Funcionaba así: si el servidor presentaba un certificado especial, el navegador de exportación «subía» la conexión a 128 bits. Esos certificados solo podían emitirlos unas pocas autoridades de certificación autorizadas, principalmente VeriSign y Thawte, y solo a entidades aprobadas: bancos y organizaciones con necesidades justificadas de criptografía fuerte.
Era, en el fondo, un sistema de licencias de exportación encarnado en una extensión de certificado: la robustez de la criptografía dependía de quién eras, no de lo que necesitabas proteger.
PGP y el código fuente que viajó en un libro
En 1991, Phil Zimmermann publicó PGP (Pretty Good Privacy), un programa de cifrado de correo electrónico con criptografía fuerte. PGP se difundió rápidamente fuera de Estados Unidos a través de Internet, y Zimmermann fue objeto de una investigación penal por presunta exportación ilegal de armas, que el Gobierno cerró en 1996 sin presentar cargos.
Mientras tanto, a Zimmermann se le ocurrió una idea brillante. Las normas de exportación se aplicaban al software, pero un libro está protegido por la Primera Enmienda de la Constitución estadounidense, que garantiza la libertad de expresión. Así que en 1995 la editorial del MIT publicó PGP: Source Code and Internals, con el código fuente completo de PGP impreso en sus páginas. Como el propio Zimmermann explicaba en el prefacio, el libro estaba pensado para que pudiera escanearse con un programa de reconocimiento óptico de caracteres (OCR) y reconstruir el código. Un libro es mucho más difícil de prohibir que un programa.
La idea funcionó. Las versiones posteriores de PGP se exportaron también impresas y, en Europa, voluntarios del proyecto internacional de PGP las escanearon y compilaron, lo que dio lugar a las versiones «i» (internacionales) que se distribuían legalmente fuera de Estados Unidos.
La EFF: el código es expresión
La Electronic Frontier Foundation (EFF) llevó la batalla a los tribunales y a los laboratorios.
En los tribunales, respaldó a Daniel J. Bernstein, entonces estudiante de doctorado en Berkeley, que quería publicar su algoritmo de cifrado Snuffle, un artículo que lo explicaba y el código fuente que lo implementaba. En el caso Bernstein contra el Departamento de Justicia de Estados Unidos, iniciado en 1995, los tribunales declararon inconstitucionales partes de la normativa de exportación, y en mayo de 1999 el Tribunal de Apelaciones del Noveno Circuito confirmó que publicar código fuente de cifrado es una forma de expresión protegida. En enero de 2000, Estados Unidos relajó sustancialmente sus controles de exportación de criptografía.
En el laboratorio, la EFF quiso demostrar que el algoritmo estándar de la época, DES, con claves de 56 bits, era inseguro, algo que algunos responsables públicos negaban. Construyó por menos de 250.000 dólares una máquina específica, Deep Crack, que en julio de 1998 recuperó una clave DES en 56 horas. Y publicó todos los detalles en el libro Cracking DES (O’Reilly, 1998), incluido el código de los chips y del software, impreso en papel y preparado para leerse con OCR. De nuevo, por la misma razón: el papel podía exportarse; el disco, no.
La herencia envenenada: FREAK y Logjam
Con la liberalización del año 2000, la criptografía «de exportación» dejó de tener sentido y los certificados SGC perdieron su razón de ser. Pero los algoritmos debilitados no desaparecieron: siguieron escondidos en las bibliotecas criptográficas y en la configuración de muchos servidores, por compatibilidad.
En 2015 dos ataques demostraron el precio de ese olvido:
FREAK permitía a un atacante en posición intermedia forzar a clientes y servidores a negociar el RSA «de exportación» de 512 bits y factorizar la clave en horas.
Logjam hacía lo mismo con el intercambio Diffie-Hellman de 512 bits. Según sus descubridores, el 8,4 % de los principales sitios web del mundo era vulnerable cuando se dio a conocer.
Quince años después de que dejaran de ser obligatorios, los 512 bits de exportación seguían ahí.
Las lecciones para la transición postcuántica
La historia ofrece cuatro enseñanzas que hoy son de plena actualidad:
Los algoritmos debilitados no mueren solos. Si no se retiran activamente, permanecen durante años en bibliotecas, configuraciones y protocolos, esperando a que alguien los explote. La migración a la criptografía postcuántica exige un inventario criptográfico (CBOM) y la eliminación deliberada de lo obsoleto, no solo la incorporación de lo nuevo.
La negociación de algoritmos es una superficie de ataque. FREAK y Logjam no rompieron la criptografía fuerte: engañaron a los sistemas para que eligieran la débil. Los esquemas híbridos y los mecanismos de transición deben diseñarse para resistir ataques de degradación.
La criptoagilidad es una propiedad de diseño. Los sistemas que en 2000 pudieron pasar de 40 a 128 bits con una simple actualización de navegador sobrevivieron; los que tenían los algoritmos «cableados» arrastraron el problema durante años. Lo mismo ocurrirá con el paso a ML-KEM, ML-DSA y sus sucesores.
Desplegar TLS 1.3 y retirar todo lo anterior. Al poner en marcha un sistema, la buena práctica es usar TLS 1.3 y desactivar SSL 2.0 y 3.0, prohibidos desde 2011 y 2015, y también TLS 1.0 y 1.1, que el IETF declaró obsoletos en 2021 (RFC 8996). TLS 1.2 solo debería mantenerse donde siga siendo necesario por compatibilidad, y con una configuración restringida. TLS 1.3 aprendió de aquellos errores: eliminó los cifrados de exportación, el intercambio de claves RSA y los grupos Diffie-Hellman débiles, firma toda la negociación e incorpora un mecanismo específico contra la degradación de versión, para impedir ataques como FREAK y Logjam. Y es la versión en la que se están desplegando los intercambios de claves híbridos postcuánticos, como X25519MLKEM768, normalizado este verano en el RFC 10024 y negociado por defecto desde 2024 por Chrome y Firefox. Mantener versiones antiguas «por si acaso» es repetir el error de los 512 bits.
Hay, además, una lección de fondo. Las guerras criptográficas enfrentaron la seguridad de todos con el interés de algunos Gobiernos en poder descifrar comunicaciones, y aquel debate no ha terminado: reaparece cada vez que se proponen accesos excepcionales o puertas traseras. La experiencia de los 40 bits demuestra que debilitar la criptografía «solo para algunos» acaba debilitándola para todos.
La coincidencia de fechas no ha sido buscada, pero viene al caso: este artículo se publica un día después del Global Encryption Day, el día mundial del cifrado que la Global Encryption Coalition, con el apoyo de la Internet Society, promueve cada 21 de octubre desde 2021. La edición de este año, la sexta, se ha centrado precisamente en defender el cifrado de extremo a extremo frente a las propuestas que pretenden debilitarlo. Treinta años después de los 40 bits, el mensaje sigue siendo el mismo.