Hablar de criptografía poscuántica cuando todavía estamos instalando cámaras con contraseñas débiles puede parecer adelantarse demasiado al problema. Y, hasta cierto punto, lo es.
Pero Axis acaba de introducir una idea que merece bastante más atención que la típica actualización de firmware: AXIS OS incorpora soporte para Post-Quantum Cryptography (PQC) mediante un esquema híbrido ML-KEM para comunicaciones TLS 1.3. La capacidad puede utilizarse en servicios como HTTPS, MQTT, RTSPS y 802.1X cuando el otro extremo de la conexión también sea compatible.
La pregunta interesante no es si mañana una computadora cuántica va a descifrar nuestras cámaras. No va por ahí.
La pregunta es mucho más incómoda para quienes diseñamos sistemas que permanecerán instalados diez o quince años:
¿puede una cámara seguir siendo criptográficamente segura durante toda su vida útil?
Criptografía poscuántica. ¿Qué está incorporando realmente Axis?
AXIS OS añade soporte para un esquema híbrido ML-KEM dentro de TLS 1.3. Axis lo relaciona específicamente con la protección frente al denominado store now, decrypt later: capturar comunicaciones cifradas hoy para intentar descifrarlas años después, cuando exista tecnología capaz de hacerlo.
La palabra importante aquí es híbrido.
No significa que Axis haya abandonado de repente la criptografía convencional y que todo el tráfico de una cámara haya pasado a depender de algoritmos poscuánticos. La estrategia híbrida combina mecanismos actuales con un mecanismo diseñado para resistir futuros ataques cuánticos.
También existe otra condición que no conviene perder de vista: el otro extremo debe soportarlo.
Que una cámara tenga capacidad PQC no significa automáticamente que la conexión:
cámara → VMS
o:
cámara → servidor MQTT
esté utilizando protección poscuántica.
El cliente, servidor o infraestructura que negocia TLS con el dispositivo también debe ser compatible.
Por eso una casilla que diga PQC supported en un datasheet cuenta solo una parte de la historia.
¿Por qué pensar ahora en un ataque que todavía no tenemos?
Aquí es donde el asunto empieza a resultar relevante para seguridad electrónica.
Un teléfono puede sustituirse en tres o cuatro años. Una cámara instalada en un aeropuerto, universidad, hospital, puerto o planta industrial puede continuar funcionando durante diez años o más.
Y durante ese período cambia prácticamente todo lo que la rodea.
Cambian los sistemas operativos. Cambian los navegadores. Cambian los certificados. Cambian los protocolos aceptables. Cambian las vulnerabilidades conocidas. Y cambian también los algoritmos criptográficos que consideramos seguros.
El hardware envejece lentamente.
La confianza criptográfica puede envejecer mucho más rápido.
Esto crea una diferencia importante entre especificar una cámara por sus capacidades actuales y especificarla por su capacidad de evolucionar.
Una cámara puede tener hoy HTTPS, certificados y comunicaciones cifradas y aun así convertirse en un problema dentro de ocho años si su arquitectura no permite abandonar algoritmos que para entonces hayan quedado obsoletos.
Eso es lo que hace interesante AXIS OS 13: no tanto ML-KEM por sí mismo, sino el concepto de cryptographic agility que hay detrás.
¿Qué significa “store now, decrypt later”?
Imaginemos un atacante capaz de interceptar comunicaciones cifradas de una instalación.
Hoy no puede leerlas.
Pero eso no necesariamente significa que tenga que descartarlas.
Puede almacenarlas.
Si dentro de varios años aparece suficiente capacidad computacional —cuántica o de otro tipo— para romper parte de la criptografía utilizada actualmente, aquella información histórica podría adquirir nuevamente valor.
De ahí la expresión:
store now, decrypt later.
Ahora bien, conviene poner el riesgo en perspectiva.
No todo video de seguridad necesita permanecer secreto durante décadas. Las imágenes de un estacionamiento grabadas esta mañana probablemente tengan poco valor estratégico dentro de quince años.
Pero una cámara moderna tampoco transmite solamente imágenes.
Puede intercambiar credenciales, certificados, información de administración, eventos, metadata, datos de analítica, mensajes MQTT y comunicaciones asociadas con infraestructura crítica.
Por tanto, el riesgo depende enormemente del proyecto.
Una tienda minorista y una instalación militar no deberían tener exactamente el mismo threat model.
La criptografía poscuántica no convierte automáticamente una cámara en “más segura” para cualquier aplicación. Su importancia depende del valor y de la vida útil de la información que estamos intentando proteger.
El cambio más inmediato de AXIS OS 13 puede no ser poscuántico
Mientras la criptografía poscuántica atrae titulares, hay otro cambio de AXIS OS 13 que puede provocar problemas mucho antes.
Axis está eliminando de SRTP los mecanismos considerados débiles:
- HMAC-SHA1 para autenticación;
- AES-CTR-128;
- AES-CTR-256.
La nueva dirección utiliza AES-GCM-128 y AES-GCM-256.
Y esto tiene una consecuencia muy concreta: un VMS o cliente que todavía dependa de los algoritmos anteriores puede perder conectividad de video SRTP después de actualizar la cámara.
Axis lo advierte explícitamente y recomienda mantener temporalmente AXIS OS 12.11 LTS cuando la infraestructura todavía necesite esos mecanismos legacy, mientras se verifica compatibilidad con el proveedor del VMS.
Esta es probablemente la parte que un integrador debería revisar primero.
Porque el riesgo cuántico es futuro.
Una incompatibilidad VMS puede ocurrir el mismo día del upgrade.
¿Actualizar firmware puede hacer más seguro un sistema y romperlo al mismo tiempo?
Perfectamente.
Y esta es una de las contradicciones que tendremos que administrar cada vez con mayor frecuencia.
Desde cybersecurity queremos eliminar protocolos, algoritmos y comportamientos inseguros.
Desde operaciones queremos que todo lo que funcionaba ayer siga funcionando mañana.
Ambos objetivos pueden entrar en conflicto.
Supongamos un campus con 800 cámaras Axis conectadas a un VMS existente. Técnicamente, AXIS OS 13 puede ofrecer una postura de seguridad superior.
Pero actualizar las 800 cámaras directamente porque “la nueva versión es más segura” sería una mala práctica.
Antes deberíamos comprobar al menos:
cámara → streaming → VMS → grabación → reproducción → analytics → ACAP → certificados → 802.1X → integraciones externas.
Una sola incompatibilidad puede transformar una mejora de cybersecurity en un incidente operacional.
Por eso Axis recomienda probar el nuevo OS y mantener capacidad de rollback.
La lección trasciende a Axis.
Firmware management ya es parte de la ingeniería del sistema de seguridad.
¿Qué cambia para una especificación de videovigilancia?
Durante muchos años hemos especificado cámaras principalmente mediante características visibles:
resolución, frame rate, lente, WDR, sensibilidad, almacenamiento, analítica, temperatura, IP rating.
Cybersecurity agregó después requisitos como HTTPS, secure boot, signed firmware, certificados y 802.1X.
El siguiente paso debería ser exigir también capacidad de evolución.
Una especificación moderna puede empezar a preguntar:
- ¿durante cuántos años recibirá security updates el dispositivo?
- ¿pueden actualizarse sus mecanismos criptográficos?
- ¿soporta TLS 1.3?
- ¿cómo administra certificados?
- ¿qué ocurre cuando un cipher queda obsoleto?
- ¿existe una rama LTS?
- ¿puede hacerse rollback?
- ¿qué política sigue el fabricante para eliminar protocolos inseguros?
- ¿cómo se prueban las integraciones antes de un breaking change?
Son preguntas menos atractivas que “¿cuántos megapíxeles?”, pero probablemente determinen mejor cuánto tiempo podrá permanecer el equipo instalado.
¿Qué aporta Strict Security Mode?
La documentación actual de Axis muestra otra pieza de esta estrategia: Strict Security Mode.
Cuando se activa, el dispositivo adopta configuraciones mucho más restrictivas. Entre ellas aparecen TLS 1.3 obligatorio bajo determinadas políticas, bloqueo de comunicaciones HTTP sin cifrar, restricciones sobre RTSP/RTP sin cifrar, eliminación de algoritmos SRTP débiles, protección reforzada contra brute force y restricciones sobre software downgrades.
Esto es interesante porque reconoce algo que muchas veces olvidamos:
no todos los proyectos necesitan exactamente el mismo equilibrio entre compatibilidad y seguridad.
Una instalación legacy puede necesitar temporalmente mecanismos que una infraestructura crítica nueva debería prohibir desde el primer día.
Permitir distintos niveles de hardening puede ser más realista que pretender que toda instalación adopte inmediatamente la configuración más restrictiva.
Pero también introduce responsabilidad.
Alguien tendrá que decidir qué nivel aplicar, documentar las excepciones y entender qué integración dejará de funcionar cuando se endurezca el dispositivo.
Eso ya no es simplemente configuración de una cámara.
Es security engineering.
¿Es la criptografía poscuántica una función de marketing?
En parte, inevitablemente.
“Post-Quantum Cryptography” tiene un valor comercial evidente en 2026 y seguramente veremos la expresión aparecer cada vez más en productos de cybersecurity, networking y seguridad física.
Pero reducirla únicamente a marketing sería equivocarse en la dirección contraria.
El valor inmediato no está en afirmar que mañana tendremos ataques cuánticos contra CCTV.
Está en que un fabricante de dispositivos con ciclos de vida largos empiece a diseñar pensando en cryptographic agility.
Ese concepto sí tiene consecuencias presentes.
La industria está aprendiendo que no basta con que un producto salga seguro de fábrica. Tiene que existir una arquitectura que permita mantenerlo razonablemente seguro mientras cambian estándares, vulnerabilidades y requisitos regulatorios.
ONVIF está siguiendo una lógica parecida con Security Add-ons que pueden evolucionar independientemente de sus perfiles funcionales.
La regulación europea también está aumentando la presión sobre vulnerability management y soporte durante el ciclo de vida.
Y los fabricantes están empezando a retirar algoritmos que hace algunos años eran perfectamente aceptables.
Son señales diferentes de una misma transición.
¿Qué debería hacer hoy un integrador?
No hay ninguna razón para comenzar mañana a reemplazar cámaras porque no tengan ML-KEM.
Sí existe una buena razón para revisar cómo administramos firmware y criptografía durante el ciclo de vida del proyecto.
Para instalaciones Axis, antes de migrar masivamente a AXIS OS 13 conviene crear un grupo pequeño de dispositivos de prueba y validar el VMS, SRTP/RTSPS, aplicaciones ACAP, certificados, 802.1X, MQTT y cualquier integración de terceros.
Si existe dependencia de AES-CTR o HMAC-SHA1, la propia documentación de Axis apunta a AXIS OS 12.11 LTS como transición mientras se moderniza la infraestructura.
Y para nuevos proyectos, empezaría a incorporar una pregunta que hasta hace poco casi nunca aparecía en una especificación:
¿cómo evolucionará la seguridad criptográfica de este dispositivo durante toda su vida útil?
Esa pregunta probablemente sea más importante que saber si hoy soporta el algoritmo más moderno.
Preguntas frecuentes
¿AXIS OS 13 hace que las cámaras sean resistentes a computadoras cuánticas?
Incorpora soporte para un esquema híbrido ML-KEM con TLS 1.3, pero la protección depende también de que el otro extremo de la comunicación sea compatible. No convierte automáticamente todas las comunicaciones del dispositivo en poscuánticas.
¿Debo actualizar inmediatamente todas las cámaras a AXIS OS 13?
No. En instalaciones profesionales conviene validar primero VMS, streaming, ACAP, certificados, autenticación e integraciones. Los cambios de SRTP pueden afectar clientes que dependan de algoritmos legacy.
¿Qué hago si mi VMS todavía necesita AES-CTR?
Axis recomienda utilizar temporalmente AXIS OS 12.11 LTS mientras se verifica o implementa soporte para AES-GCM-128/256 en la infraestructura correspondiente.
¿PQC debería exigirse ya en todas las especificaciones CCTV?
No necesariamente. El requisito debería depender del threat model, vida útil del proyecto y sensibilidad de la información. Más importante hoy es evaluar cryptographic agility, soporte de firmware y lifecycle del fabricante.
La cámara puede durar diez años. ¿Y su criptografía?
La llegada de criptografía poscuántica a AXIS OS es interesante, pero probablemente no por la razón que aparecerá en los titulares.
No estamos ante una emergencia cuántica.
Estamos ante una señal de que la seguridad de una cámara ya no puede evaluarse solamente en el momento de comprarla.
Un sistema instalado hoy tendrá que convivir con vulnerabilidades que todavía no conocemos, protocolos que serán retirados, certificados que cambiarán y algoritmos que eventualmente dejarán de considerarse seguros.
Por eso la verdadera pregunta no es si una cámara soporta ML-KEM en 2026.
Es si su arquitectura y el fabricante que hay detrás pueden mantenerla segura hasta el final de su vida útil.
Si trabajas diseñando, especificando o integrando sistemas de seguridad electrónica, puedes suscribirte al boletín de Infoteknico para recibir análisis técnicos como este. Y si estás evaluando una arquitectura, migración de firmware o requisitos de cybersecurity para un proyecto, también puedes contactarme directamente para conversar sobre el caso.
Deja una respuesta