Los estándares NIST para criptografía post-cuántica son definitivos desde agosto de 2024 – ML-KEM para encapsulación de claves, ML-DSA y SLH-DSA para firmas. Año y medio después, las primeras migraciones empiezan a correr en producción en las empresas de DACH. Este texto rompe con el romanticismo del roadmap y muestra qué activos criptográficos se mueven realmente en 2026 – y cuáles aguantarán hasta 2028 o más.
Lo esencial en resumen
- Los stacks híbridos son la realidad en 2026. Casi nadie pone cripto PQC pura en producción – los handshakes TLS combinan X25519+ML-KEM, las firmas siguen en su mayoría con RSA/ECDSA más una co-firma ML-DSA opcional. El cambio va de forma incremental a través de actualizaciones de librería.
- Code-signing y Root-CAs son los candidatos duros. Sus largos periodos de validez (10-20 años) los hacen estratégicos frente a escenarios «Harvest-Now-Decrypt-Later». Ahí empieza en 2026 la reforma seria – empujada por la BSI-TR-02102, no por el hype.
- Gateways VPN y firmware IoT se quedan atrás. HSM hardware, concentradores VPN antiguos y firmware embebido atado por diseño no llegan a la migración antes de 2027, a menudo hasta el siguiente ciclo de reemplazo. Quien lo fuerce hoy rompe más de lo que asegura.
RelacionadoCloud Repatriation 2026: el modelo TCO / Platform Engineering 2026: Internal Developer Platforms
La situación en abril de 2026
ML-KEM (antes CRYSTALS-Kyber), ML-DSA (antes CRYSTALS-Dilithium) y SLH-DSA (antes SPHINCS+) son, como FIPS 203, 204 y 205, estándares federales definitivos de EE. UU. desde agosto de 2024. En paralelo, la BSI trabaja en actualizaciones de la serie TR-02102 que en 2026 incluirán las primeras recomendaciones vinculantes para autoridades federales y operadores KRITIS. Una migración obligatoria con fecha tope no existe en Alemania – pero las preguntas de auditoría se vuelven concretas.
En las auditorías de seguridad de bancos y aseguradoras aparecen de forma sistemática dos preguntas desde el Q1 de 2026. Primera: ¿qué sistemas vuestros usan hoy procedimientos cripto considerados «cuántico-críticos»? Segunda: ¿qué roadmap de migración hasta 2028 tenéis documentado? Las respuestas que circulan en la mayoría de las empresas son claramente más finas de lo que las diapositivas dejan suponer.
Quien en 2026 empieza una migración post-cuántica rara vez lo hace voluntariamente. El detonante es casi siempre una pregunta de compliance, una auditoría de proveedor o una ronda de C5 en la que el auditor pregunta expresamente por la preparación PQC. La clásica «prevención» como proyecto independiente rara vez es financiable – la PQC se arrastra como parte de iniciativas más amplias de higiene criptográfica.
El sector bancario juega un papel especial en este movimiento. BaFin y BCE han dejado claro en varias circulares a principios de 2026 que la preparación post-cuántica forma parte de las evaluaciones de riesgo operacional – no como obligación con fecha tope, pero sí como categoría de documentación obligatoria. Eso lleva en la IT bancaria a un inventario acelerado que otros sectores no necesitan a ese ritmo. Las aseguradoras se suman en el Q2 de 2026, las eléctricas y la sanidad KRITIS están de todas formas en el foco por la reforma de la ley BSI.
La industria, en cambio, trabaja con una línea de tiempo más larga. Aquí los departamentos IT negocian con equipos OT, fabricantes de máquinas y proveedores de control – una cadena que solo se mueve al ritmo de los ciclos de inversión. Un proveedor de automoción que planifica nuevas líneas de producción incluye hoy hardware apto para PQC en los pliegos, pero el entorno productivo existente permanece hasta 2028 o más.
Qué activos migran realmente en 2026
La realidad de la migración sigue tres clústeres: lo que ya corre en producción, lo que está migrando y lo que se queda estable. La clasificación se basa en observaciones de proyecto en entornos enterprise entre el Q4 de 2025 y el Q1 de 2026 – grandes bancos, dos empresas industriales del DAX y tres medianas empresas más grandes.
| Activo criptográfico | Hoy típico | Objetivo PQC 2026-2028 | Realidad de migración |
|---|---|---|---|
| Terminación TLS (pública) | ECDHE + ECDSA/RSA | Híbrido X25519+ML-KEM (TLS 1.3) | Rollout amplio en 2026 en Chrome/Edge/Firefox, server-side vía OpenSSL 3.5+ y BoringSSL |
| Code-signing (software) | RSA-3072 / ECDSA-P-256 | ML-DSA o SLH-DSA | Primeros despliegues productivos en Sigstore, la firma de Microsoft está en pruebas – adopción amplia en 2027 |
| Root-CAs / intermediarias | RSA-4096 / ECDSA-P-384, validez 10-20 años | Jerarquía CA paralela con ML-DSA | Apenas en producción – fase de planificación, primeras CA federales y grandes PKI corporativas construyen trust-stores paralelos |
| Gateways VPN (Site-to-Site) | IKEv2 con ECP256/ECP384 | IKEv2 híbrido + ML-KEM | Depende del hardware. Los fabricantes de firewalls entregan primeras actualizaciones de firmware, rollout realista en 2027 |
| IoT / firmware embebido | ECDSA, en parte RSA-2048 | ML-DSA o híbrido | Atado por diseño – migración normalmente solo en el próximo ciclo de reemplazo hardware (2028+) |
| Claves ligadas a HSM | RSA / ECC según FIPS 140-2/3 | Firmware PQC de los fabricantes HSM | Depende de Thales, Utimaco, Entrust. Los ciclos de firmware son largos, la certificación está en marcha |
Fuente: NIST FIPS 203/204/205 (agosto de 2024), BSI TR-02102-1 (actualización 2026), observaciones de proyecto en grandes bancos y empresas industriales del DAX Q4/2025-Q1/2026.
El avance más claro está en la terminación TLS para endpoints públicos. Google activó en el navegador Chrome en 2024 el grupo híbrido X25519+Kyber768, Firefox lo siguió en 2025. Del lado del servidor, Cloudflare, Akamai y los grandes load balancers absorben el handshake de forma transparente – quien hoy opere un reverse-proxy moderno hace PQC-TLS sin intervención activa. La parte interesante no es el handshake en sí, sino la pregunta de qué servicios internos detrás del proxy se han enterado hasta ahora de este cambio.
Code-signing es el segundo terreno donde algo se mueve en 2026. Microsoft prueba firmas ML-DSA para catálogos de drivers de Windows, Sigstore experimenta con cadenas de firma híbridas. Para el software enterprise vale: quien despliegue firmas propias de producto (por ejemplo en publicaciones en App Store o en pipelines internos de deploy) tiene en 2026 un buen momento para cambiar, porque las librerías de verificación están ampliamente disponibles en el lado del consumidor. En firmas de firmware con root-of-trust hardware, el tema sigue en la sala de espera al menos hasta 2027.
El patrón es consistente. Donde la cripto es sustituible vía software y se arrastra con el ciclo de actualizaciones, la migración avanza en 2026. Donde hay hardware, firmware o validez larga en juego, pasa poco hasta 2028 – o la migración ocurre en el próximo cambio de equipo, no como proyecto propio.
Qué flaquea en los roadmaps
Casi todos los roadmaps post-cuánticos escritos en 2025 tienen una o varias de estas tres debilidades. Primera: sobrestiman la velocidad con la que las librerías y certificaciones avanzan. OpenSSL 3.5 con ML-KEM nativo está disponible desde el Q1 de 2026 – pero el middleware enterprise, las bases de datos y los terminadores TLS antiguos usan con frecuencia versiones de OpenSSL claramente más viejas. Hasta que el soporte PQC ha cruzado todo el grafo de dependencias de un entorno productivo pasan entre 12 y 24 meses.
Segunda: los roadmaps subestiman la gestión de certificados en estructuras de confianza paralelas. Quien, además de la Root-CA existente, planifica una Root-CA PQC tiene que pensar la mecánica de despliegue para los trust-stores de los navegadores, los sistemas internos y las PKI de partners. Eso no es una cuestión de cripto, es gestión del ciclo de vida de identidades y certificados – un área que la mayoría de las empresas ya opera hoy con gran esfuerzo.
Tercera: muchos roadmaps ignoran la dimensión de supply chain. El software de terceros, sobre todo el SaaS enterprise con handshake TLS en manos ajenas, escapa al control directo. Quien pregunte hoy a Salesforce, Microsoft 365 o HubSpot cuándo van a pasar su terminación TLS a PQC híbrido, recibe habitualmente una respuesta de roadmap sin fecha. No es negligencia de los proveedores, es una evaluación realista de sus propias dependencias.
Un detalle que en los proyectos aparece tarde con frecuencia: los costes de rendimiento de los handshakes TLS híbridos son reales pero, en la mayoría de los escenarios, despreciables. ML-KEM-768 en modo híbrido añade entre uno y dos kilobytes al Client-Hello y alarga el handshake en unos pocos milisegundos. Para HTTPS de cara al usuario no se nota. Se vuelve serio en pipelines mTLS de alta frecuencia en las que cada conexión se abre de nuevo – allí esos pocos milisegundos pueden convertirse en piedra de tropiezo, en particular en service meshes con session-timeouts cortos. Por eso, antes del rollout, merece la pena un benchmark en la propia línea mTLS, antes de que las latencias de producción se conviertan en sorpresa.
Un segundo punto que los papers de roadmap rara vez mencionan: las integraciones KMIP y los templates de certificados en el software PKI existente suelen no estar listos para PQC. Quien opere Microsoft Certificate Services, Dogtag, EJBCA o productos comerciales de CA enterprise tiene que revisar la versión – las firmas PQC aparecen solo en los ciclos actuales de producto. La migración del stack PKI es un subproyecto mediano propio junto al simple cambio de algoritmo.
Qué hacer en la práctica en 2026
Las empresas que afrontan en serio sus deberes PQC este año siguen un patrón poco espectacular. Empiezan con un inventario criptográfico – no como documento teórico, sino como escaneo ejecutable a través de SBOM CycloneDX, herramientas de inventario TLS y revisión manual de todos los procedimientos de firma en la propia pipeline de CI/CD. El inventario es la base de todo lo demás y se lleva tres o cuatro meses por sí solo.
En paralelo, las actualizaciones de librerías se integran como parte de los releases regulares de plataforma. OpenSSL 3.5+, versiones recientes de LibreSSL o BoringSSL, stacks TLS de Java con soporte PQC, paquetes de cripto de Go. Quien planifique el upgrade como proyecto propio lo pierde – quien lo acople al ciclo de parches habitual lo saca adelante en seis a nueve meses.
Lo que sostiene la operación en 2026
- TLS híbrido sobre OpenSSL 3.5 o BoringSSL en la capa de reverse-proxy
- Inventario criptográfico vía SBOM y escaneo TLS, actualizado al menos trimestralmente
- Actualizaciones de plataforma en el ciclo de parches habitual, no como proyecto especial
- Alineación con BSI-TR-02102 para sistemas KRITIS y administraciones
Lo que descarrila el rollout
- Reemplazo forzado de hardware VPN fuera del ciclo de refresh
- Despliegue de Root-CA paralela sin un proceso bien pensado de trust-store
- Migración de flotas IoT ligadas al firmware sin roadmap del fabricante
- SaaS de terceros como bloqueador de migración en vez de riesgo residual documentado
El inventario criptográfico es, en la práctica, la parte más dura. Herramientas de inventario TLS como testssl.sh, sslyze o escáneres comerciales como Venafi ofrecen un primer mapa de los endpoints públicamente visibles. Pero las preguntas de inventario aparecen en lugares que ningún escáner encuentra automáticamente: ¿qué capa de messaging firma con qué clave? ¿Qué interfaces de módulos ERP usan qué suites de cifrado? ¿Qué claves de firma JWT rotan con qué ritmo y qué librerías las verifican? Estas preguntas se trabajan en varias iteraciones a lo largo de varios equipos – no se resuelven en un sprint.
El tercer pilar es la conversación con los proveedores. Quien opere software en la nube debería preguntar explícitamente en 2026 a sus tres proveedores SaaS más importantes cuándo pasarán su terminación TLS a PQC híbrido y cuándo las infraestructuras de firma internas soportarán procedimientos PQC. Las respuestas rara vez son precisas, pero marcan las dependencias que hay que documentar en los propios roadmaps como riesgo residual. Un buen patrón: estado PQC anual en las reuniones de supplier-review, documentado en el vendor-risk-register junto a temas de GDPR y NIS2.
Por último, está la vertiente de comunicación. Las direcciones que en 2027 sean preguntadas por un auditor o por un supervisor sobre el estado PQC necesitan un informe de estado sobrio – no un documento de lujo. Un resumen de una página con tres cifras (porcentaje de endpoints TLS migrados, estado de code-signing, dependencias de supply chain documentadas) gana a cualquier concepto de 40 páginas que nadie lee.
La hoja de ruta hasta 2028
Cronograma realista desde la perspectiva de proyecto – no como prescripción, sino como orientación para CIOs que tienen que hacer plausible ante la dirección y los auditores por qué cada paso llega cuándo.
Lo que queda – y lo que no
La expectativa de que la criptografía post-cuántica corra en producción de forma generalizada para 2027 es irrealista. La expectativa de que no pasará nada es igual de falsa. 2026 es el año en el que el TLS híbrido se vuelve amplio en la web pública, los proyectos de code-signing empiezan en serio y se construyen los inventarios criptográficos. La verdadera migración de los casos duros – Root-CAs, claves ligadas a HSM, firmware embebido – se estira hasta el final de la década.
Para los CIOs y responsables de seguridad la pregunta operativamente relevante no es cuán avanzados están los ordenadores cuánticos. Es qué higiene criptográfica sobrevive a la próxima auditoría en la propia casa y qué deberes hay que atacar ahora para que la migración sea siquiera posible dentro de tres años. Quien hoy tenga un inventario criptográfico limpio y mantenga las librerías actualizadas ha hecho el 70 por ciento de la preparación post-cuántica – sin poner un solo procedimiento PQC en producción.
Preguntas frecuentes
¿Tengo que desplegar PQC en producción ya en 2026?
No, salvo en contextos específicos con validez de clave larga o una obligación clara de compliance. Para la mayoría de las empresas DACH, 2026 es el año en que el TLS híbrido se vuelve ampliamente disponible y se construyen inventarios criptográficos. La migración PQC pura es la excepción, no la regla.
¿Qué librerías soportan PQC hoy de forma apta para producción?
OpenSSL 3.5 (marzo de 2025) con ML-KEM nativo en TLS 1.3, BoringSSL (Chrome, Edge), Mozilla NSS (Firefox) desde 2025 con híbrido X25519+ML-KEM. Sigstore prueba ML-DSA para code-signing. Java soporta PQC de forma experimental desde OpenJDK 24. Para embebido están wolfSSL y mbedTLS con ramas PQC.
¿Cuánto cuesta una migración post-cuántica para una empresa mediana?
Rara vez hay cifras serias, porque la migración se integra en el ciclo de parches de plataforma y pocas veces se imputa como proyecto aparte. El esfuerzo separado para inventario criptográfico, refactor PKI y gestión de trust-store se sitúa, para una empresa de 1.000 empleados, según experiencia, en el rango medio de seis cifras repartido en tres años – menos que la mayoría de las implementaciones de NIS2.
¿Es «Harvest-Now-Decrypt-Later» un modelo de amenaza realista?
Para secretos estatales, contratos de larga validez y datos de identidad con diez años de explotación: sí. Para datos de negocio típicos, con una vida útil operativa corta: más bien no. La BSI-TR-02102 diferencia en consecuencia. Quien hoy cifre tráfico TLS que en cinco años no tendrá valor no necesita desplegar post-cuántica como previsión.
¿Qué papel juega la BSI-TR-02102 para empresas no KRITIS?
Formalmente, ninguno obligatorio. En la práctica, la TR-02102 es el marco de referencia en el que se apoyan los auditores, las aseguradoras y los partners de contrato marco. Quien concurra a licitaciones o busque ciberseguros se verá cada vez más preguntado por la conformidad con TR-02102 – también más allá de la obligación formal.
Recomendaciones de lectura
- Canal Broadcom-VMware: el panorama de providers 2026
- Cloud Repatriation 2026: el modelo TCO
- Platform Engineering 2026: Internal Developer Platforms
Más en la red MBF Media
La BSI advierte sobre F5, Citrix y Trivy: qué hay que hacer operativamente en abril de 2026
NIS2 operativo: tres decisiones para la alta dirección en abril de 2026
EU AI Act en vigor desde el 6 de abril de 2026: qué deben aclarar ya los equipos tech de la mediana empresa
Fuente de la imagen de portada: Pexels / Markus Spiske (px:1089438)
