En todo proyecto post-cuántico hay un momento reconfortante. La librería está actualizada, el intercambio de claves dice ML-KEM-768, el ticket se cierra. Listo.

Solo que no. Has cambiado una cerradura. No has revisado las ventanas, ni el sello de las cartas, ni si alguien llevaba un inventario de las demás cerraduras.

En el sector se ha empezado a llamar a esto la diferencia entre migración PQC y transformación PQC. La migración cambia algoritmos. La transformación cambia algoritmos y reconstruye la verificación, la visibilidad y la confianza que los rodean. La mayoría de proveedores se quedan en lo primero.

La migración es el algoritmo. La transformación es todo lo demás.

La migración es necesaria y no la despreciamos. RSA y ECC caerán ante un ordenador cuántico criptográficamente relevante, y los FIPS 203 (ML-KEM) y FIPS 204 (ML-DSA) del NIST son sus sustitutos. Si no has empezado, empieza.

Pero un algoritmo es un componente, no una postura de seguridad. Un intercambio de claves cuántico-seguro protege la confidencialidad de un mensaje. No dice nada sobre si el mensaje es auténtico, si el token que autorizó la petición fue falsificado, o si el certificado al otro extremo de la conexión lo emitió alguien que rompió ECDSA el año pasado.

La transformación hace cuatro preguntas en lugar de una: ¿Es confidencial? ¿Es verificable? ¿Sé dónde vive toda mi criptografía? ¿Y en quién confío en última instancia?

El cifrado no detiene a un man-in-the-middle. La verificación sí.

Harvest Now, Decrypt Later va de confidencialidad: un atacante graba texto cifrado hoy y lo lee cuando el hardware le alcance. ML-KEM cierra esa puerta. Ya escribimos sobre ello, y sigue siendo el problema más urgente para cualquiera que guarde datos con una vida útil larga.

Pero el mismo ordenador cuántico que rompe el cifrado RSA rompe también las firmas RSA y ECDSA. Es un ataque distinto con una consecuencia distinta. En vez de leer tus datos más tarde, el atacante te suplanta ahora. Piensa en qué partes de una arquitectura típica están protegidas solo por una firma clásica:

Tokens de acceso y JWT — falsifica uno y no necesitas robar ninguna contraseña.
Certificados TLS — un certificado falsificado es un man-in-the-middle con candado válido.
Firma de código y firmware — una firma falsificada distribuye malware como actualización oficial.
Webhooks, respuestas de API y logs de auditoría — la integridad de todo lo que viene después.

Si has actualizado el cifrado y has dejado las firmas en ECDSA, has sellado el sobre y has dejado el lacre falsificable. ML-DSA (FIPS 204) y SLH-DSA (FIPS 205) existen exactamente para este lado del problema. Una transformación de verdad protege ambos lados.

No puedes migrar lo que no ves

Pregunta a un CISO dónde se usa RSA en su organización y la respuesta honesta es "en más sitios de los que sabemos". Está en cabeceras JWT, claves SSH, claves de KMS en la nube, firmas de PDF, registros de contenedores, SDKs de proveedores y esa herramienta interna de 2017.

Por eso toda hoja de ruta PQC seria — incluida la hoja de ruta coordinada de la UE de junio de 2025 — pone el inventario antes que la migración. El primer hito no es "ser cuántico-seguro". Es "conocer tu patrimonio criptográfico": qué algoritmos, qué tamaños de clave, qué sistemas, qué vida útil de los datos. Sin eso, migrarás el 60% visible y te entrarán por el 40% que nadie apuntó.

El inventario criptográfico no es glamuroso. También es el paso que decide si una transformación es real o cosmética.

Cómo es una transformación completa

En conjunto, cuatro capas — cada una es necesaria, ninguna basta por sí sola:

Confidencialidad — encapsulación de claves ML-KEM envolviendo AES-256-GCM para datos en reposo y en tránsito. Es la defensa frente a HNDL.
Verificación — firmas ML-DSA o SLH-DSA en tokens, documentos, artefactos y mensajes, para que la manipulación y la suplantación fallen incluso frente a un adversario cuántico.
Anclas de confianza — claves generadas con entropía cuántica real, emitidas y verificadas por infraestructura bajo una jurisdicción en la que puedas confiar. Zero-trust significa que cada capa es post-cuántica, no solo el transporte.
Inventario — una vista viva de qué algoritmos, claves y sistemas están en juego, para que la migración sea medible y no se escape nada.

Dónde está QuantumAPI — con honestidad

Esto es lo que hay en producción hoy. QuantumAPI cifra y descifra con ML-KEM-512/768/1024 envolviendo AES-256-GCM, y firma y verifica con ML-DSA-44/65/87 y SLH-DSA. QuantumID emite tokens de acceso que llevan una prueba ML-DSA-65 junto a la firma clásica, de modo que los clientes preparados para PQC pueden verificar ambas. QuantumVault guarda secretos, claves y certificados bajo el mismo cifrado híbrido ML-KEM, y su motor transit firma con ML-DSA. Las claves se siembran desde hardware cuántico real, con fallback automático. Todo corre en infraestructura europea, bajo jurisdicción de la UE, y se cobra por uso — nunca por usuario.

Y esto es lo que todavía no está. Un panel de inventario criptográfico, para ver tu patrimonio de algoritmos de un vistazo, está en nuestro roadmap y no en el producto. Las respuestas de API firmadas están planificadas, no en producción. Preferimos decírtelo a poner un tick en una tabla.

Si estás planificando un proyecto post-cuántico, planifica una transformación, no una migración. Empieza por ambos lados — cifrado y verificación — y exige un inventario a quien trabaje contigo. Puedes probar hoy los endpoints de cifrado y firma en el plan gratuito en quantumapi.eu, y la documentación en docs.quantumapi.eu muestra exactamente qué hace cada algoritmo.