Cómo empezar a preparar una migración post-cuántica

Preparar el cambio antes de ejecutarlo

Una migración post-cuántica es un proceso sobre sistemas, datos y responsables. No empieza cambiando todos los certificados ni instalando una biblioteca experimental en producción. Empieza por comprender qué depende de criptografía y qué podés actualizar de manera controlada.

Esta ruta adapta principios de preparación y agilidad publicados por organismos técnicos. Es una orientación inicial para una empresa, no un cronograma garantizado ni una auditoría. El alcance real depende de los servicios, las obligaciones y la capacidad operativa de cada organización.

Paso 1: delimitar e inventariar

Elegí un alcance manejable: por ejemplo, la web pública y sus proveedores. Registrá servicio, función criptográfica, versión conocida, responsable y evidencia. No completes casilleros con supuestos. Un dato pendiente es más útil que una certeza inventada.

Paso 2: ordenar prioridades

Considerá la vida confidencial de los datos, la criticidad del servicio, el tiempo de actualización y la dependencia de terceros. No confundas una clasificación editorial de madurez con el riesgo de tu organización. Son cosas distintas y requieren evidencia distinta.

Paso 3: pedir un camino verificable

Consultá al proveedor qué soporte existe, en qué versiones, para qué tramos y con qué limitaciones. Diferenciá disponibilidad actual de hoja de ruta. Identificá quién puede autorizar una prueba y quién responderá si aparece un problema.

Paso 4: probar sin comprometer el servicio

Definí casos representativos: clientes antiguos y actuales, errores, latencia, tamaños de mensajes e integraciones. Compará antes y después. Prepará una reversión segura y criterios para detener la prueba. Un resultado exitoso con un navegador no demuestra compatibilidad con todos los clientes.

Paso 5: desplegar gradualmente y revisar

Solo después de validar, planificá un cambio acotado con observación y responsables. Documentá lo que se desplegó realmente. La preparación continúa cuando cambian versiones, proveedores o necesidades de los datos.

Un ejemplo concreto

Una empresa elige revisar el tramo público de su web. Confirma quién termina TLS, solicita documentación y prueba una opción soportada en un entorno de validación. Si funciona, organiza el cambio con el proveedor. Los backups y la VPN quedan identificados como trabajos separados; no se consideran resueltos por esa prueba.

Hecho: la transición requiere compatibilidad entre componentes. Inferencia: un alcance pequeño y verificable permite aprender sin perder control. Hipótesis: una prueba exitosa puede facilitar una adopción más amplia, pero no la garantiza. Limitación: esta ruta no define parámetros criptográficos ni autoriza cambios en infraestructura ajena.

Qué recordar

Inventario → prioridades → proveedores → pruebas → despliegue gradual → revisión. Cada paso debería dejar evidencia y un responsable.

Qué NO significa esto

No significa prometer una empresa “100% quantum safe”. Tampoco reemplaza las tareas actuales de seguridad. Preparar PQC debe integrarse con mantenimiento, control de acceso y continuidad operativa.