La migración poscuántica no es un futuro cambio de algoritmo. Para equipos backend, abarca dependencias, vida útil de datos, protocolos, certificados, firmas, proveedores y observabilidad, comenzando con evidencia.
Un ordenador cuántico suficientemente capaz amenazaría los algoritmos de clave pública usados hoy para establecer claves y producir firmas digitales. El riesgo inmediato de ingeniería es “recolectar ahora, descifrar después”: tráfico o ciphertext pueden guardarse hoy para un ataque futuro, haciendo que la vida útil del dato importe más que adivinar cuándo llegará esa capacidad.
NIST finalizó FIPS 203, 204 y 205 en agosto de 2024. Estos estándares definen ML-KEM para establecimiento de claves, ML-DSA para firmas y SLH-DSA como firma basada en hash. Esto vuelve concreta la preparación, pero no significa que cada balanceador, SDK, HSM, autoridad certificadora, driver de base de datos o socio esté listo.
Un inventario útil no es una hoja con una lista de algoritmos. Conecta cada uso criptográfico con responsable, propósito, dato protegido, protocolo, biblioteca, runtime, certificado o clave, proveedor, roadmap y ruta de reemplazo. El proyecto de migración de NCCoE trata el descubrimiento criptográfico como trabajo fundamental porque no se puede priorizar lo que no se ve.
| Superficie | Dependencia backend común | Pregunta poscuántica | Acción de ingeniería |
|---|---|---|---|
| Entrada pública | CDN, WAF, balanceador, certificados TLS, DNS y automatización de certificados. | ¿Quién controla negociación, certificados y grupos soportados? | Registra roadmap del proveedor, telemetría TLS, cadena de certificados y rollback. |
| Entre servicios | Service mesh, mTLS, API gateway, gRPC, brokers y drivers de base de datos. | ¿Todos los pares negocian algoritmos compatibles sin romper latencia o MTU? | Mapea ambos extremos, versiones, política criptográfica, tamaño del handshake y fallback. |
| Identidad y tokens | OIDC, OAuth, JWT/JWS, firma de sesión, API keys y refresh tokens duraderos. | ¿Cuánto tiempo deben verificarse firmas y dónde están fijados los algoritmos? | Reduce vidas útiles cuando sea posible; inventaría emisores, validadores, claves y rotación. |
| Artefactos y datos | Backups, objetos cifrados, campos de base, auditoría, builds y releases firmados. | ¿La confidencialidad o autenticidad seguirá importando dentro de varios años? | Prioriza datos y firmas duraderos; conserva metadatos para recifrado o nueva firma. |
| Custodia de secretos | KMS, HSM, Vault, autoridad certificadora, signing service y appliances. | ¿El proveedor soporta estándares, tamaños, APIs e implementaciones validadas? | Sigue firmware, cuotas, límites de exportación, rendimiento, compliance y compromisos. |
| Integraciones externas | Pagos, SSO empresarial, APIs de socios, webhooks y SaaS administrado. | ¿Quién debe actualizar primero y qué ocurre cuando las capacidades difieren? | Incluye preparación PQC en evaluaciones, contratos, pruebas y planes de deprecación. |
No implementes primitivas poscuánticas directamente en la aplicación. Preparar backend significa eliminar supuestos hard-coded, centralizar política criptográfica, versionar algoritmos y formatos de clave, actualizar bibliotecas soportadas y hacer observable la negociación. Un sistema que puede reemplazar algoritmos de forma segura vale más que una prueba de concepto aislada.
TLS merece atención especial porque la aplicación quizá no controle el handshake. El tráfico puede terminar en CDN, proxy inverso, sidecar, gateway, base administrada o socio. El trabajo de IETF sobre ML-KEM e intercambio híbrido para TLS sigue activo; los equipos deben seguir los estándares e implementaciones de plataforma, identificando claramente experimentos y drafts.
Un access token de cinco minutos y una firma de release que debe seguir siendo confiable durante diez años no tienen la misma prioridad. Inventaría algoritmos y validadores, pero ordénalos por vida útil, exposición, costo de reemplazo y consecuencia de una historia falsificada. Evidencia de auditoría, firmware, documentos legales, releases y datos archivados pueden exigir decisiones antes que las sesiones cortas.
La criptografía simétrica y el hashing se ven afectados de forma diferente a los sistemas vulnerables de clave pública. Evita un proyecto ciego de reemplazar todo. Sigue orientación aprobada, conserva el contexto del algoritmo junto a objetos y firmas, y diseña transiciones de recifrado, nueva firma o verificación antes de que desaparezcan implementaciones antiguas.
Construiría un registro de dependencias criptográficas alimentado por escaneos de repositorios, observaciones TLS, inventarios de certificados, metadatos de KMS y HSM, configuración cloud, SBOMs y cuestionarios de proveedores. Cada registro tendría responsable, score de riesgo, vida útil del dato, bloqueo, reemplazo probado y fecha límite.
El dashboard respondería preguntas operativas: qué rutas de producción todavía dependen de clave pública vulnerable, qué datasets duraderos están expuestos, qué proveedores no tienen un roadmap creíble y qué migraciones fallaron en interoperabilidad o rendimiento.
La preparación poscuántica no consiste en predecir el día exacto en que los ordenadores cuánticos serán peligrosos. Consiste en hacer visible y reemplazable la criptografía antes de que la urgencia elimine tus opciones. Inventaría primero, prioriza por vida útil e impacto, usa implementaciones estandarizadas y soportadas, prueba la ruta completa y conserva la capacidad de volver a cambiar.
Artículo sobre preparación poscuántica para ingenieros backend, incluyendo inventario criptográfico, dependencias TLS, vida útil de tokens, firmas, proveedores, agilidad, pruebas y migración.