PQC StatusUn proveedor de servicios de pago (PSP) puede iniciar ya su migración poscuántica en los elementos que controla por sí solo: TLS en los endpoints públicos y de cara a socios, el tráfico interno entre servicios, la administración por SSH y el inventario criptográfico que PCI DSS ya exige. Los elementos que dependen de terceros (especificaciones de los esquemas de tarjetas, criptografía EMV de chip y sin contacto, módulos de seguridad hardware (HSM) y terminales de pago) avanzan al ritmo de sus proveedores. Todo el ejercicio consiste en separar ambos ámbitos: migrar lo que es suyo, documentar lo que no lo es y mantener ambos en un único inventario fechado.
Por qué el intercambio de claves va primero
RSA, ECDSA, EdDSA, ECDH y Diffie-Hellman sobre cuerpos finitos quedan rotos por el algoritmo de Shor en un ordenador cuántico suficientemente grande, sea cual sea el tamaño de clave. Aquí no se ofrece ninguna fecha creíble para la llegada de una máquina así. Lo que importa en pagos es la forma del riesgo, conocida como harvest now, decrypt later (HNDL, recolectar ahora y descifrar después): el tráfico capturado hoy solo está protegido por el intercambio de claves que generó la clave de sesión, de modo que un atacante que lo grabe puede descifrarlo más adelante, cuando ese intercambio de claves pueda romperse. Con una firma es distinto: falsificarla solo resulta útil mientras la firma siga siendo de confianza.
Por eso el intercambio de claves híbrido va primero y las firmas vienen después. Para un PSP, el tráfico grabado es concreto: mensajes de autorización, llamadas a la API de tokenización, ficheros de liquidación y conciliación, transferencias por lotes a adquirentes y procesadores, y sesiones de administración en el entorno de datos del titular de la tarjeta. Nuestro artículo sobre harvest now, decrypt later expone el razonamiento en detalle. Un grupo híbrido combina un intercambio de claves clásico con ML-KEM (Module Lattice Key Encapsulation Mechanism), publicado por el NIST como FIPS 203 el 13 de agosto de 2024, de modo que la sesión sigue siendo al menos tan robusta como hoy aunque falle uno de los dos componentes.
Qué puede migrar ya un PSP
- Endpoints HTTPS públicos: páginas de pago alojadas, scripts de checkout, paneles de comercios, receptores de webhooks y API públicas. El grupo híbrido X25519MLKEM768 (codepoint IANA 0x11EC, véase el registro de parámetros TLS) se ofrece por defecto en las versiones actuales de Chrome, Edge y Firefox, y los clientes que no lo admiten negocian en su lugar el grupo clásico.
- TLS entre servicios dentro del entorno de datos del titular de la tarjeta, donde usted controla ambos extremos y puede actualizar las bibliotecas según su propio calendario.
- Administración por SSH: OpenSSH 9.9 (19 de septiembre de 2024) añadió mlkem768x25519-sha256, OpenSSH 10.0 (9 de abril de 2025) lo convirtió en el acuerdo de claves por defecto y OpenSSH 10.1 (6 de octubre de 2025) emite un aviso cuando una conexión negocia un acuerdo de claves no poscuántico. Consulte las notas de versión de OpenSSH.
- Restos preestándar: cualquier grupo X25519Kyber768Draft00 (codepoint 0x6399) que siga en uso está obsoleto y debería sustituirse por los grupos ML-KEM.
- El propio inventario, que es un ejercicio de documentación más que un proyecto criptográfico, y que suele ser el primer entregable que pide un evaluador.
Compruebe qué negocia hoy un endpoint antes de cambiar nada. Los grupos ML-KEM requieren OpenSSL 3.5 o posterior:
openssl version
openssl s_client -connect api.example.com:443 -groups X25519MLKEM768 </dev/null 2>&1 | grep -i negotiatedEn nginx compilado con OpenSSL 3.5 o posterior, el grupo híbrido se habilita situándolo por delante de los clásicos, lo que mantiene el mecanismo de respaldo:
ssl_protocols TLSv1.3 TLSv1.2;
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;Los nombres de las directivas y de los grupos admitidos varían entre servidores y distribuciones, así que verifíquelos en su propia compilación. Pruebe primero en preproducción y, después de cada cambio en producción, vigile las tasas de fallo del handshake y la compatibilidad de los clientes. La key share híbrida es más grande que una clásica, lo que puede importar en enlaces con recursos limitados y en middleboxes antiguos que inspeccionan el handshake. El acuerdo de claves híbrido para TLS 1.3 está especificado en el RFC 10024 (agosto de 2026).
Qué depende de los esquemas, los fabricantes de HSM y los terminales
Los siguientes ámbitos no son decisión de un PSP. Aquí no se indican fechas poscuánticas para ellos, porque en este sitio solo se publican fuentes primarias fechadas, y los esquemas, EMVCo y los fabricantes de HSM son la única autoridad sobre sus propios planes.
- La criptografía EMV de chip y sin contacto, incluida la autenticación de datos offline, que se basa en claves RSA y de curva elíptica fijadas por la especificación.
- Las interfaces de red de los esquemas de tarjetas y las jerarquías de claves que imponen a adquirentes y procesadores.
- El firmware de los HSM, las configuraciones certificadas y la compatibilidad PKCS#11 con ML-KEM y ML-DSA (Module Lattice Digital Signature Algorithm, FIPS 204).
- Los formatos de key block y la criptografía relacionada con el PIN.
- El hardware de los terminales de pago, cuyo ciclo de sustitución se mide en años.
Interpretación, no requisito: asigne a cada una de estas dependencias una línea en el inventario, con un responsable interno, la posición publicada del proveedor si existe y una fecha de revisión. Cuando aparezca un boletín de un esquema o una nota de versión de un HSM, esa línea cambia y el historial muestra cuándo lo supo. Los cuestionarios a proveedores en la renovación de contratos son la otra palanca: pida una hoja de ruta por escrito en lugar de dar por hecho que existe.
PCI DSS 12.3.3 ya es la columna vertebral
El requisito 12.3.3 de PCI DSS v4.0.1 exige que los conjuntos de cifrado y protocolos en uso se documenten y revisen al menos una vez cada 12 meses. Tiene tres partes: un inventario actualizado que indique la finalidad de cada algoritmo y dónde se utiliza, el seguimiento de la viabilidad continuada de lo que está en uso y una estrategia documentada para responder a los cambios previstos en las vulnerabilidades criptográficas. Es obligatorio desde el 31 de marzo de 2025, tras haber sido una buena práctica hasta esa fecha; la norma está disponible en la biblioteca de documentos del PCI SSC. Nuestra guía sobre el inventario criptográfico de PCI DSS 12.3.3 explica la estructura, y la página de referencia de PCI DSS v4.0.1 recoge los hitos fechados.
Lea con atención la tercera parte. Los cambios previstos en las vulnerabilidades criptográficas son el lugar que corresponde a lo poscuántico. Interpretación: la vulnerabilidad cuántica del intercambio de claves RSA y de curva elíptica es uno de esos cambios previstos, de modo que la estrategia 12.3.3 de un PSP puede mencionar el intercambio de claves híbrido, indicar qué endpoints ya están migrados y enumerar las dependencias de esquemas y HSM con sus responsables. El requisito 12.3.3 no exige ML-KEM hoy.
DORA: qué exige el texto a las entidades financieras de la UE
El Reglamento Delegado (UE) 2024/1774 de la Comisión, las normas técnicas de regulación sobre gestión del riesgo TIC en el marco de DORA, se aplica a las entidades financieras de la UE, incluidas las entidades de pago y de dinero electrónico. El Art. 6 exige una política de cifrado y controles criptográficos que incluya disposiciones para actualizar o cambiar la tecnología criptográfica en función de la evolución del criptoanálisis. El Art. 7 exige la gestión de claves a lo largo de todo su ciclo de vida y un registro de certificados de los activos TIC que dan soporte a funciones críticas o importantes. Ambos se resumen con sus hitos en la página de referencia de DORA.
El texto no menciona ningún algoritmo ni fija ninguna fecha poscuántica. Interpretación: el Art. 6 se cumple con una política que tenga un desencadenante definido y un circuito de aprobación para cambiar un algoritmo, y el Art. 7 con un registro de certificados que ya recoja el algoritmo y el tamaño de clave, lo que lo convierte en el lugar natural para ver qué sigue en RSA o ECDSA. NIS2 Art. 21(2)(h) pide políticas y procedimientos sobre el uso de la criptografía en términos similares, a través de la transposición nacional. Este artículo es informativo y no constituye asesoramiento jurídico.
Del requisito a la evidencia
| Requisito | Qué dice el texto | Evidencia que puede aportar un PSP |
|---|---|---|
| PCI DSS v4.0.1 req. 12.3.3 | Inventario de los conjuntos de cifrado y protocolos en uso, revisado al menos cada 12 meses, más una estrategia ante los cambios criptográficos previstos | Exportación fechada del inventario, registro de la revisión anual, una sección poscuántica identificada en la estrategia |
| DORA RTS 2024/1774 Art. 6 | Política de cifrado con disposiciones para actualizar o cambiar la tecnología criptográfica a medida que evoluciona el criptoanálisis | Política aprobada que identifica el desencadenante, el responsable y el circuito de aprobación de un cambio de algoritmo |
| DORA RTS 2024/1774 Art. 7 | Gestión de claves durante todo el ciclo de vida y un registro de certificados para funciones críticas o importantes | Registro de certificados con algoritmo, tamaño de clave, caducidad y responsable del sistema |
| NIS2 Art. 21(2)(h) | Políticas y procedimientos sobre el uso de la criptografía y, cuando proceda, del cifrado | La misma política, vinculada a la transposición nacional aplicable |
| CRA Annex I, Part I (2)(e) | Confidencialidad protegida mediante mecanismos de vanguardia; no se menciona ningún algoritmo | Documentación de diseño de terminales, SDK o dispositivos comercializados en el mercado de la UE |
Fechas oficiales para planificar
Ninguna de ellas es específica de pagos, y ninguna es un plazo legal para un PSP salvo que la última columna lo indique. Mantenga los matices cuando las cite internamente.
| Fuente | Hitos | Estatus |
|---|---|---|
| Hoja de ruta coordinada de implementación de la UE v1.1 (23 de junio de 2025) | Inventario criptográfico y hojas de ruta nacionales antes de finales de 2026; casos de uso de alto riesgo migrados antes de finales de 2030; de riesgo medio antes de finales de 2035 | Orientación coordinada para los Estados miembros, no un reglamento vinculante para las empresas |
| NIST IR 8547 (12 de noviembre de 2024) | Propone declarar obsoleta la seguridad de 112 bits, como RSA-2048, después de 2030 y prohibir los algoritmos de clave pública vulnerables a la computación cuántica después de 2035 | Borrador público inicial, todavía en fase de borrador |
| BSI TR-02102-1 (versión 2026-01, 23 de enero de 2026) | El acuerdo de claves clásico por sí solo se recomienda únicamente hasta finales de 2031, finales de 2030 para necesidades de protección muy elevadas | Directriz técnica |
| NCSC del Reino Unido (20 de marzo de 2025) | Descubrimiento y plan inicial antes de 2028, migraciones de máxima prioridad antes de 2031, migración completa antes de 2035 | Orientación |
| ANSSI (Francia) | Hibridación obligatoria dentro de su ámbito regulado; PQC prevista para los productos que entren en cualificación a partir de 2027 | Fuera de ese ámbito, la ANSSI indica que sus recomendaciones sobre PQC aún no son obligaciones reglamentarias |
Empiece por los endpoints que puede ver
El primer paso útil más rápido es medir qué negocian hoy sus endpoints de pago públicos y, a partir de ahí, decidir el orden de los trabajos: analice su dominio con PQC Status para comprobar la compatibilidad con ML-KEM híbrido, las versiones de TLS y la cadena de certificados. Ejecútelo por separado en el dominio de checkout, en el host de la API y en el host de webhooks, ya que a menudo están detrás de terminadores distintos. Registre cada resultado con su fecha en el inventario 12.3.3, añada las dependencias de esquemas, HSM y terminales como líneas abiertas con responsables y fije la próxima revisión en un plazo no superior a doce meses.