La criptografía post-cuántica ha dejado de ser un tema de laboratorio: el Gobierno de Estados Unidos ha fijado el 31 de diciembre de 2030 como fecha límite para migrar sus sistemas críticos, y el NIST ya da por amortizados el RSA y las curvas elípticas que hoy protegen la mayoría de webs corporativas. Esto afecta a cualquier responsable de marketing o de sistemas que gestione un dominio, un formulario de contacto o una pasarela de pago, porque el candado verde del navegador puede quedar obsoleto antes de que acabe la década. Aquí se explica qué cambia, con qué plazos reales y qué debe revisar tu equipo técnico este mismo año.
La criptografía post-cuántica es el conjunto de algoritmos —ML-KEM para el intercambio de claves y ML-DSA para las firmas, ya estandarizados por el NIST— diseñados para resistir a un ordenador cuántico. Estados Unidos exige migrar sus sistemas críticos antes del 31 de diciembre de 2030, y el propio NIST prevé retirar RSA y las curvas elípticas actuales entre 2030 y 2035.
La amenaza cuántica sobre el cifrado de tu web
Cada vez que un visitante carga tu web por HTTPS, el navegador y el servidor negocian una clave usando RSA o curvas elípticas (ECC). Son algoritmos seguros frente a un ordenador clásico, pero vulnerables a uno cuántico suficientemente potente, que podría factorizarlos en minutos en lugar de en milenios. El riesgo no es solo futuro: la táctica «harvest now, decrypt later» consiste en capturar hoy el tráfico cifrado —datos de clientes, contratos, credenciales— para descifrarlo en cuanto exista esa máquina.
La orden ejecutiva 14412, firmada el 22 de junio de 2026, sitúa la aparición de un ordenador cuántico criptográficamente relevante en torno a 2031, justo el año en que exige tener migrada la autenticación de los sistemas de alto valor. No es una previsión alarmista: es el plazo sobre el que ya están construyendo su calendario la Casa Blanca, el NIST y los grandes proveedores de infraestructura web.
Calendario oficial de la criptografía post-cuántica
El NIST IR 8547 marca la hoja de ruta: RSA, ECDSA, ECDH y Diffie-Hellman de campo finito quedan «deprecados» a partir de 2030 y «no permitidos» a partir de 2035. Deprecado no significa prohibido de golpe: seguir usándolos exige que el responsable del sistema documente por escrito que asume el riesgo, algo poco defendible en una auditoría o ante un cliente que pregunte por su política de seguridad.
La orden ejecutiva de junio de 2026 traduce eso en fechas concretas para las agencias federales y sus contratistas: 31 de diciembre de 2030 para el cifrado de los sistemas de alto valor y 31 de diciembre de 2031 para la autenticación. Tu empresa probablemente no es un contratista federal, pero los navegadores, los CMS y las autoridades certificadoras sí les venden a ellos, y ese calendario es el que ya está marcando sus hojas de ruta de producto.
Los algoritmos que sustituyen a RSA y ECC
El NIST estandarizó en 2024 tres familias: ML-KEM para establecer claves, ML-DSA para firmas digitales y SLH-DSA como alternativa de respaldo basada en hash. Ninguno sustituye a RSA en solitario de forma inmediata: la transición pasa por esquemas híbridos que combinan el algoritmo clásico con el post-cuántico, de modo que un fallo en el componente nuevo —todavía joven, con menos años de escrutinio— no deje el tráfico expuesto.
ML-KEM sustituye el intercambio de claves
El híbrido que ya circula en producción se llama X25519MLKEM768: combina la curva elíptica X25519 con ML-KEM-768, un algoritmo basado en retículos. Chrome, Edge y las versiones recientes de Firefox lo negocian por defecto en la mayoría de conexiones HTTPS, y según Cloudflare, más de dos tercios del tráfico TLS que llega a su red desde navegadores ya va protegido así. El coste técnico es real —el paquete de claves pesa varias veces más que el clásico y a veces obliga a un viaje de red adicional—, pero para el usuario final es invisible.
Navegadores y servidores ya migran a la criptografía post-cuántica
La migración no depende ya de que cada empresa la active a mano: gran parte ocurre en la capa de infraestructura. Cloudflare activó en julio de 2026 el intercambio automático de claves, que detecta qué admite el servidor de origen y prioriza el híbrido post-cuántico sin que el cliente toque nada. Para un sitio en WordPress, PrestaShop o Shopify detrás de un proxy así, buena parte del trabajo ya está hecho en el tramo navegador-CDN.
Lo que queda pendiente es el tramo que sí depende de cada empresa:
- El certificado SSL/TLS del propio dominio, emitido casi siempre todavía con firmas RSA o ECDSA clásicas.
- El servidor de origen: necesita TLS 1.3 y una versión reciente de OpenSSL (3.5 o superior) para hablar el híbrido con el CDN.
- Las integraciones propias —pasarelas de pago, APIs de terceros, VPN de la oficina— que aún negocian solo con algoritmos clásicos.
El histórico de recortes en la vida útil de los certificados, que ya tratamos en certificados SSL: el calendario de recortes hasta 2029, va en la misma dirección: menos margen para aplazar una renovación con algoritmos que están de salida.
Cuatro pasos de tu empresa antes de 2030
No hace falta un proyecto faraónico este año, pero sí un inventario. Sin saber cuántos certificados, librerías y dependencias usan RSA o ECC, no hay forma de priorizar ni de calcular el coste real de la migración cuando los proveedores empiecen a exigirla en firme.
DigiCert y Sectigo ya prueban certificados ML-DSA
DigiCert ha fijado 2029 como objetivo para completar su infraestructura post-cuántica interna y ya emite certificados ML-DSA en su CA privada; los públicos llegarán en cuanto el CA/Browser Forum apruebe el formato. Sectigo, por su parte, lanzó en abril de 2026 un servicio de certificados PQC privados pensado para que las empresas empiecen a probar sin tocar aún su cadena de confianza pública. Ninguno de los dos exige todavía nada a sus clientes, pero ambos están construyendo la vía por la que pasará la migración real.
Con eso en mente, el orden razonable de trabajo es:
- Auditar qué certificados, servidores y librerías criptográficas usa hoy la empresa y con qué algoritmo.
- Confirmar con el proveedor de hosting o el CDN si ya soporta TLS 1.3 con el híbrido X25519MLKEM768.
- Pedir a la autoridad certificadora su calendario de certificados ML-DSA antes de renovar a ciegas por otros tres años.
- Revisar las integraciones de terceros —pasarelas de pago, APIs, VPN— que puedan quedarse atrás del resto.
Certificados ML-DSA, el reemplazo de RSA en tu web
Para una empresa con ecommerce, el punto más delicado no es la web corporativa sino la pasarela de pago: ahí es donde vive el dato que de verdad interesa capturar con «harvest now, decrypt later». Una tienda con clientes en Barcelona que procese tarjetas a través de una pasarela externa depende del calendario de migración de ese proveedor, no solo del suyo propio, y conviene preguntarlo ahora en lugar de descubrirlo en una auditoría de seguridad.
Este no es un cambio que deba improvisar quien lleva el blog o las campañas: exige revisar servidores, certificados y dependencias con criterio técnico. Si tu empresa no tiene ese perfil dentro de casa, es trabajo para una auditoría de seguridad informática o para una consultoría de sistemas IT que ya esté siguiendo de cerca estos plazos.
Preguntas frecuentes sobre criptografía post-cuántica
¿Mi certificado SSL actual deja de funcionar en 2030?
No de forma automática: 2030 es la fecha en la que el NIST considera «deprecado» el algoritmo, no un interruptor que apague tu certificado. En la práctica, seguirá funcionando, pero los navegadores y auditorías empezarán a señalarlo como riesgo asumido, y renovarlo con RSA dejará de ser una opción neutra.
¿Qué algoritmo debo pedir a mi proveedor de hosting?
Hoy, que soporte TLS 1.3 con el híbrido X25519MLKEM768, que ya es el estándar de facto en Chrome y Cloudflare. Para certificados, pregunta por su calendario de ML-DSA: casi ninguna autoridad los emite aún en público, pero varias, como DigiCert, ya los prueban en entornos privados.
¿Afecta esto a comercios electrónicos en Barcelona?
Sí, igual que a cualquier tienda online: el riesgo no depende de la ubicación del negocio sino de qué pasarela de pago y qué proveedor de hosting use. Una tienda con clientes locales que trabaje con una pasarela sin plan de migración post-cuántica corre el mismo riesgo que una internacional.
Fuente: NIST IR 8547 — Transition to Post-Quantum Cryptography Standards