Cyber Resilience Act
La Ley de Ciberresiliencia de la UE eleva el listón para los proveedores de tecnología de seguridad física
16 min lectura
Imagen generada por IAUna cámara que abre una puerta, un lector que valida una identidad o una plataforma que centraliza miles de eventos de seguridad ya no son simples dispositivos instalados en un edificio. Son productos conectados, con software, dependencias externas, actualizaciones y, en muchos casos, acceso a datos personales o a sistemas críticos. La Ley de Ciberresiliencia de la Unión Europea obliga a tratar esa realidad como lo que es: una superficie de ataque regulada.
La guía publicada por Genetec para responsables de seguridad física llega en un momento especialmente incómodo para los proveedores. El Reglamento (UE) 2024/2847, conocido como Cyber Resilience Act o CRA, ya está en vigor y sus primeras obligaciones operativas no esperan a 2027. Desde el 11 de septiembre de 2026, los fabricantes deben notificar a ENISA las vulnerabilidades explotadas activamente y los incidentes graves que afecten a productos con elementos digitales. La aplicación general del reglamento llegará el 11 de diciembre de 2027.
La diferencia entre ambas fechas no es un detalle de calendario. Significa que un fabricante puede estar todavía preparando su evaluación de conformidad mientras ya tiene que demostrar que sabe detectar, clasificar y comunicar determinados problemas de seguridad. La vieja estrategia de “lo arreglaremos cuando salga la versión siguiente” acaba de adquirir un coste regulatorio.
La seguridad física entra por la puerta principal de la CRA
El CRA se aplica a los productos con elementos digitales, una categoría deliberadamente amplia que cubre tanto hardware como software capaz de conectarse, directa o indirectamente, a un dispositivo o una red. La cuestión no es si el producto se vende como una solución de ciberseguridad. La pregunta es si incorpora funciones digitales y puede afectar a la confidencialidad, integridad o disponibilidad de datos y sistemas.
Ahí caben cámaras IP, grabadores de vídeo, lectores biométricos, controladores de puertas, interfonos conectados, sensores, servidores de gestión, aplicaciones móviles, plataformas cloud y componentes de red incluidos en una solución de seguridad física. También pueden quedar cubiertos productos aparentemente secundarios: un appliance que sincroniza credenciales, un módulo de actualización remota o un software de administración utilizado para controlar cientos de dispositivos.
La CRA no clasifica automáticamente todos estos productos como “productos importantes” o “productos críticos”. Esa distinción depende de las categorías previstas en los anexos III y IV del reglamento y de las características concretas del producto. Un sistema de gestión de eventos de seguridad puede acercarse a categorías de software de seguridad incluidas entre los productos importantes; una cámara convencional puede quedar sometida al régimen general. No conviene resolver la duda con marketing: la clasificación debe documentarse a partir de la función, la arquitectura y el uso previsto.
La consecuencia práctica es relevante. El fabricante debe asumir responsabilidad sobre el producto durante todo su ciclo de vida, no únicamente hasta el momento de la entrega. El artículo 13 del CRA exige que los productos se diseñen, desarrollen y produzcan de forma que ofrezcan un nivel adecuado de ciberseguridad, atendiendo a los riesgos previsibles y al uso previsto. También impone obligaciones sobre la gestión de vulnerabilidades, las actualizaciones y la información que acompaña al producto.
Para una empresa de seguridad física, esto desplaza el centro de gravedad del cumplimiento. Ya no basta con pasar una prueba de penetración antes del lanzamiento, entregar un manual y dejar la operación al integrador. El regulador mira ahora el proceso completo: cómo se seleccionan las librerías, quién mantiene las dependencias, cómo se reciben los avisos de vulnerabilidad, cuánto tarda la corrección, cómo se distribuye una actualización y qué ocurre cuando el producto llega al final de su vida comercial.
El calendario que separa el riesgo técnico del riesgo regulatorio
El 11 de septiembre de 2026 marca el inicio de una obligación concreta: la notificación de vulnerabilidades explotadas activamente y de incidentes graves relacionados con productos con elementos digitales. El artículo 14 del CRA establece un sistema escalonado de comunicación a través de la plataforma única de notificación gestionada por ENISA.
El fabricante debe presentar una alerta temprana en un plazo de 24 horas desde que tenga conocimiento de la vulnerabilidad explotada activamente o del incidente grave. La notificación completa debe llegar en un máximo de 72 horas. El informe final se presenta, con carácter general, en el plazo de un mes desde la notificación del incidente o de la vulnerabilidad, según el caso y las exigencias aplicables.
Esos plazos cambian la forma en que debe funcionar un centro de respuesta. El equipo no puede esperar a disponer de un análisis forense cerrado para activar el proceso. La alerta de 24 horas requiere un criterio previo sobre qué significa “tener conocimiento”, quién puede declararlo y qué información mínima se remite sin contaminar la investigación. Un proveedor que solo tiene un buzón genérico de seguridad y una reunión semanal de producto no tiene un proceso de notificación: tiene una futura explicación ante el regulador.
La obligación también rompe una separación habitual entre seguridad de producto y operaciones corporativas. Una vulnerabilidad en una librería de vídeo, en un sistema operativo embebido o en un componente de autenticación puede aparecer primero en el SOC, en un cliente o en un proveedor tecnológico. El dato debe llegar al responsable del producto, al asesor jurídico, al equipo de comunicaciones y, cuando proceda, al responsable de protección de datos. El reloj corre antes de que todos hayan encontrado la diapositiva correcta.
La aplicación general del CRA será el 11 de diciembre de 2027. A partir de esa fecha, los productos nuevos afectados deberán cumplir los requisitos del reglamento y llevar el marcado CE correspondiente cuando proceda. Las obligaciones de los fabricantes abarcan la evaluación de conformidad, la documentación técnica, la declaración UE de conformidad, la información al usuario y la gestión de vulnerabilidades durante el periodo de soporte.
El artículo 13 exige que el periodo de soporte sea, como mínimo, de cinco años o de la vida útil prevista del producto, si esta fuera superior. La cifra importa especialmente en seguridad física. Un sistema de control de accesos instalado en una infraestructura puede seguir operativo durante más de cinco años, aunque el fabricante haya dejado de vender el modelo. Si la vida útil prevista es mayor, el proveedor no puede utilizar la fecha de descatalogación comercial como atajo automático para abandonar las actualizaciones.
El problema no es solo parchear: es demostrar que se sabe qué se ha vendido
La gestión de vulnerabilidades prevista por el anexo I del CRA exige bastante más que publicar parches cuando aparece un CVE. El fabricante debe integrar procesos para identificar y corregir vulnerabilidades durante el ciclo de vida, probar las actualizaciones y distribuirlas de forma segura. También debe ofrecer un mecanismo para que terceros comuniquen vulnerabilidades y debe informar sobre los problemas relevantes y las medidas correctoras.
En tecnología de seguridad física, el inventario suele ser más complejo de lo que reconoce el catálogo comercial. Una plataforma puede incluir firmware de la cámara, un sistema operativo Linux, un servidor de base de datos, bibliotecas criptográficas, un servicio cloud, una aplicación móvil y agentes instalados en los puestos de los operadores. Cada elemento puede tener un propietario distinto y una cadencia de actualización diferente.
Por eso el análisis de composición del software, incluido el uso de una SBOM en un formato legible por máquina cuando resulte exigible o necesario para gestionar los componentes, deja de ser una práctica reservada a equipos de ingeniería maduros. Sin una relación fiable de dependencias, el fabricante tardará demasiado en responder a una vulnerabilidad que afecte a una librería común. El problema no es saber que existe un CVE; es saber qué versiones están desplegadas, en qué producto, con qué configuración y en qué cliente.
El caso de Log4Shell demostró esa dificultad en 2021. Cuatro años después, seguir preguntando internamente “¿usamos esa librería?” no es una señal de resiliencia. En un entorno regulado, la respuesta debe poder obtenerse con trazabilidad y en horas, no mediante una cadena de correos a ingeniería, soporte, compras y el integrador local.
La CRA también exige principios de seguridad desde el diseño y por defecto. En una plataforma de control de acceso, eso debería traducirse en credenciales únicas o mecanismos robustos de cambio de credenciales, interfaces de administración no expuestas innecesariamente, cifrado adecuado de las comunicaciones, separación de privilegios, registros suficientes y una actualización remota protegida contra manipulación. No todos estos controles se implementan igual en una cámara de bajo consumo que en un servidor central, pero el fabricante debe justificar la solución adoptada frente al riesgo del producto.
La eliminación segura de datos es otro punto que suele quedar fuera del folleto de ventas. Cuando una organización devuelve un dispositivo, sustituye un controlador o migra una plataforma cloud, debe poder borrar credenciales, grabaciones, claves, configuraciones y metadatos de forma razonablemente verificable. El anexo I contempla mecanismos para eliminar datos de manera segura. En una cámara que almacena vídeo localmente o en una tarjeta extraíble, no es una cuestión abstracta: puede ser la diferencia entre retirar un equipo y entregar un archivo histórico de movimientos.
La responsabilidad se reparte, pero no desaparece
La CRA coloca la responsabilidad principal en el fabricante, pero no limita sus efectos a esa figura. Los importadores y distribuidores tienen obligaciones propias en los artículos 16 y 17, entre ellas verificar determinados elementos de conformidad, la identificación del fabricante, el marcado CE y la documentación que acompaña al producto. Cuando un integrador modifica sustancialmente un producto o lo comercializa bajo su propio nombre, puede asumir obligaciones equivalentes a las del fabricante en las circunstancias previstas por el artículo 18.
Esta última posibilidad es particularmente importante en seguridad física, donde abundan las soluciones ensambladas. Un integrador puede combinar cámaras de un fabricante, software de otro, un appliance propio y servicios de monitorización para vender una plataforma única. Si además cambia componentes, altera el firmware o presenta el sistema con su propia marca, la pregunta regulatoria deja de ser “¿qué dice el fabricante original?” y pasa a ser “¿quién ha puesto este producto en el mercado y quién controla su configuración?”
Los contratos tendrán que reflejar esa distribución de funciones. Un acuerdo de suministro que solo regula disponibilidad, garantías y niveles de servicio no cubre necesariamente la obligación de notificar vulnerabilidades en 24 horas, facilitar información técnica, mantener una SBOM actualizada o colaborar en una evaluación de conformidad. Tampoco resuelve quién comunica a los clientes que una actualización puede interrumpir temporalmente el control de una puerta o afectar a la retención de vídeo.
Para los compradores, la cuestión es igual de práctica. Una organización que adquiere un sistema de videovigilancia no se convierte por ello en fabricante, pero sí puede exponerse a fallos de diligencia si contrata un producto sin soporte, sin proceso de vulnerabilidades o sin una delimitación clara de responsabilidades. Las obligaciones del CRA no sustituyen al deber de gestionar el riesgo tecnológico propio de cada entidad.
La contratación debería pedir evidencias, no promesas. Entre ellas: la categoría regulatoria asignada al producto; el periodo de soporte comprometido; el proceso de recepción y tratamiento de vulnerabilidades; los tiempos de publicación de parches; la posibilidad de desplegar actualizaciones sin credenciales compartidas; la lista de componentes de software; los resultados de pruebas de seguridad; y el procedimiento de fin de vida.
Una respuesta de proveedor del tipo “nuestro producto es seguro” tiene el mismo valor probatorio que decir que un edificio es sólido porque la recepción está limpia. La información útil es otra: versión actual, dependencias, responsables, fechas, controles y evidencias.
CRA, GDPR y NIS2: tres regulaciones mirando el mismo dispositivo
Los sistemas de seguridad física rara vez operan en un vacío regulatorio. Una cámara puede quedar dentro del CRA por ser un producto con elementos digitales, activar obligaciones del Reglamento General de Protección de Datos por tratar imágenes identificables y formar parte de una entidad sujeta a NIS2 si presta un servicio esencial o importante.
El GDPR no desaparece porque el proveedor cumpla la CRA. El artículo 25 exige protección de datos desde el diseño y por defecto; el artículo 32 obliga a aplicar medidas técnicas y organizativas adecuadas al riesgo; y el artículo 33 fija, cuando procede, la notificación de una violación de datos personales a la autoridad de control en un plazo de 72 horas desde que la organización tenga constancia. La coincidencia temporal entre el plazo de 72 horas del CRA y el del artículo 33 del GDPR no significa que sean la misma notificación ni que se active siempre por el mismo hecho.
Una vulnerabilidad en una cámara que no ha sido explotada puede exigir una respuesta de seguridad de producto sin constituir todavía una brecha de datos personales. Un acceso no autorizado a grabaciones puede activar el GDPR aunque no exista una vulnerabilidad que el fabricante deba notificar como explotada. Y un incidente contra el proveedor de un servicio de vigilancia puede tener consecuencias adicionales bajo NIS2 si afecta a una entidad incluida en su ámbito.
La coordinación debe resolverse antes del incidente. El fabricante necesita saber qué información puede compartir con clientes; el cliente debe saber qué datos puede remitir al fabricante; y ambos deben distinguir entre un fallo técnico, una violación de confidencialidad, una interrupción de servicio y un incidente de cadena de suministro. La privacidad no se gestiona enviando automáticamente todos los registros al proveedor. Tampoco se protege ocultando información que el cliente necesita para valorar el riesgo.
Para una entidad financiera, una compañía energética o un operador de transporte, la seguridad física puede ser parte de un sistema operativo crítico. Un fallo de control de accesos no tiene la misma severidad si afecta a una oficina administrativa que si permite entrar en un centro de datos, una sala de compensación o una instalación industrial. La evaluación de impacto debe considerar el uso real del producto, aunque la clasificación comercial del fabricante sea más modesta.
Qué cambia para un CISO y para un responsable de seguridad física
La llegada de la CRA obliga a unir dos conversaciones que durante años han discurrido en paralelo. El responsable de seguridad física conoce la disponibilidad de puertas, cámaras y lectores, así como los riesgos de sabotaje y acceso indebido. El CISO conoce identidades, redes, vulnerabilidades y registros. El cumplimiento no funcionará si uno compra dispositivos que el otro no puede inventariar.
La primera decisión consiste en construir un inventario técnico, no una lista de facturas. Debe recoger modelo, versión de firmware, ubicación, conectividad, propietario operativo, datos tratados, dependencia cloud, fecha de instalación, fecha prevista de retirada y relación con otros sistemas. El inventario debe distinguir el producto que el proveedor certifica del sistema que la organización realmente ha desplegado. Las configuraciones personalizadas pueden alterar de forma sustancial el riesgo.
La segunda es establecer un canal de vulnerabilidades con obligaciones medibles. Un contrato debería indicar cómo se recibe un aviso, quién lo clasifica, qué información mínima entrega el proveedor, cuándo comienza el soporte y cómo se comunica una actualización urgente. Los tiempos de respuesta deben estar alineados con las ventanas regulatorias, no solo con un SLA de soporte que prometa contestar “en horario laboral”. Las vulnerabilidades no respetan el calendario de guardias.
La tercera es probar el mecanismo de actualización. Un parche seguro que no puede desplegarse porque reinicia todos los controladores de puertas a mediodía no es una solución operativa. El comprador debe saber si existen actualizaciones firmadas, si pueden verificarse antes de la instalación, si hay rollback, qué ocurre cuando un dispositivo queda fuera de línea y cuánto tiempo puede permanecer una versión vulnerable en producción.
La cuarta es revisar las cuentas privilegiadas. En instalaciones antiguas todavía aparecen credenciales compartidas entre integrador, operador y fabricante, cuentas locales que nunca caducan y accesos remotos activados “temporalmente” durante años. La CRA no enumera una contraseña concreta para cada producto, pero sus requisitos de seguridad por diseño y de protección frente a accesos no autorizados hacen difícil defender una arquitectura basada en secretos comunes y trazabilidad inexistente.
La quinta es conservar evidencias. El fabricante tendrá que demostrar cómo ha cumplido el CRA; el comprador necesitará demostrar que evaluó el riesgo y gestionó las actualizaciones. Conviene conservar versiones de firmware, avisos de vulnerabilidad, decisiones de aceptación de riesgo, resultados de pruebas, registros de despliegue y comunicaciones con el proveedor. No como archivo ornamental, sino como reconstrucción de lo que ocurrió cuando alguien pregunte por qué un sistema seguía expuesto.
El mercado tendrá que dejar de premiar solo la funcionalidad
Durante años, las adquisiciones de seguridad física han comparado resolución de cámara, capacidad de almacenamiento, integración con sistemas existentes y precio por dispositivo. La CRA añade variables menos vistosas y bastante más decisivas: duración del soporte, transparencia de componentes, capacidad de actualización, seguridad de la cadena de suministro, respuesta ante vulnerabilidades y calidad de la documentación técnica.
Ese cambio puede favorecer a los proveedores con procesos de ingeniería sólidos, pero también dejar fuera a fabricantes pequeños que dependen de componentes sin mantenimiento o que no pueden sostener un equipo de respuesta. El reglamento prevé obligaciones proporcionales al riesgo y categorías específicas de productos, aunque la proporcionalidad no equivale a una exención general. Un producto barato instalado diez mil veces no deja de ser una fuente de riesgo porque su margen sea estrecho.
La presión también llegará a los integradores. Muchos han competido ofreciendo personalización y rapidez de despliegue, no necesariamente trazabilidad de firmware o gestión formal de vulnerabilidades. Si una modificación local convierte una combinación de componentes en una solución comercial propia, el integrador tendrá que revisar si ha cruzado la frontera entre distribución, integración y fabricación a efectos del artículo 18.
La guía de Genetec acierta al dirigir la conversación a los responsables de seguridad física, aunque una guía corporativa no sustituye al análisis jurídico ni a la clasificación técnica del producto. Su valor está en señalar dónde debe empezar la revisión: diseño, mantenimiento, soporte y capacidad del proveedor para responder durante toda la vida útil. Ahí está la prueba real de la CRA.
El 2026 no es el año para esperar a diciembre de 2027. La obligación de notificación ya ha comenzado, y el resto de requisitos exige decisiones de producto, contratos y arquitectura que no se improvisan cuando llega el marcado CE. Los compradores deben preguntar ahora quién mantiene cada componente, qué ocurre cuando aparece una vulnerabilidad crítica y cuánto tarda una actualización en llegar a una instalación real.
La conclusión es poco espectacular, pero incómoda: una cámara conectada no es segura porque grabe bien, un lector no es resiliente porque abra la puerta y una plataforma no cumple porque su proveedor entregue un certificado genérico. La Ley de Ciberresiliencia convierte esas afirmaciones en preguntas verificables. Los proveedores que puedan responderlas con evidencias tendrán una ventaja comercial. Los demás descubrirán que el soporte posventa también puede convertirse en una obligación legal.