Ley de Ciberresiliencia (CRA) y videoconferencia: alcance y cumplimiento

Las expectativas regulatorias para los productos digitales en Europa no han parado de endurecerse. La seguridad ya no es una característica opcional ni una ventaja comercial: ya es un requisito básico integrado en el diseño, la entrega y el mantenimiento del software.

La Ley de Ciberresiliencia (CRA, del inglés Cyber Resilience Act) es uno de los pasos más significativos en esa dirección. Refuerza la seguridad de los productos conectados en el mercado de la UE con obligaciones claras para fabricantes y proveedores de software. El reglamento entró en vigor el 10 de diciembre de 2024. Los fabricantes deberán notificar a ENISA las vulnerabilidades explotadas activamente a partir del 11 de septiembre de 2026, y el cumplimiento total de todos los requisitos será obligatorio desde el 11 de diciembre de 2027.

Antes de continuar, conviene aclarar algo que muchos resúmenes de la CRA pasan por alto: la mayoría de los servicios de videoconferencia en modo SaaS no entran dentro del alcance de la CRA. Pero hay matices importantes, sobre todo si construyes sobre un SDK de vídeo embebido o si integras hardware con funcionalidad de vídeo. Y los principios de la CRA siguen siendo el listón de seguridad razonable, te aplique formalmente o no. Este artículo te explica cómo separar lo que te corresponde de lo que no.

Índice

1. Por qué la ciberseguridad importa para la videoconferencia
2. ¿Qué es la Ley de Ciberresiliencia?
3. Alcance y cobertura de la CRA
4. Cumplimiento de la CRA: requisitos principales
5. Certificación y conformidad
6. Preparación para el cumplimiento
7. Cómo Digital Samba se alinea con los principios de la CRA
8. Conclusión

Por qué la ciberseguridad importa para la videoconferencia

Las plataformas de videoconferencia son piezas clave en el funcionamiento de muchas organizaciones. Se utilizan en educación, sanidad, procedimientos judiciales y colaboración empresarial, lo que significa que tratan una cantidad considerable de datos sensibles: flujos de audio y vídeo, información personal y metadatos sobre participantes e interacciones.

Eso las convierte en objetivos atractivos. Los retos concretos incluyen proteger los medios en tiempo real frente a la interceptación, impedir el acceso no autorizado a las sesiones y mantener las grabaciones y transcripciones a buen recaudo. Los datos deben tratarse conforme a la normativa aplicable.

En España, INCIBE registró 97.348 incidentes de ciberseguridad en 2024, un 16,6 % más que el año anterior. La presión para reforzar la seguridad de las herramientas de comunicación es especialmente alta, y la transposición de la Directiva NIS2 añade otra capa de obligaciones sobre las que conviene tener claridad.

¿Qué es la Ley de Ciberresiliencia?

La CRA es un marco regulatorio cuyo objetivo es que los productos digitales sean seguros a lo largo de todo su ciclo de vida. Se aplica a productos de hardware y software conectados a redes, incluidas aplicaciones utilizadas en entornos empresariales y de consumo.

El reglamento traslada la responsabilidad hacia los fabricantes y proveedores de software. En lugar de que sean los usuarios u organizaciones quienes tengan que proteger los sistemas que compran, la CRA exige que los productos se construyan de forma segura desde el principio y se mantengan con atención continua.

El reglamento se articula en torno a cuatro principios:

• Seguridad por diseño y por defecto. Los controles de seguridad deben integrarse desde las primeras fases del diseño y activarse automáticamente, no añadirse a posteriori ni dejarse como opciones que el usuario tiene que activar.
• Gestión continua de vulnerabilidades. Los fabricantes deben vigilar, identificar y corregir vulnerabilidades de forma activa durante todo el ciclo de vida del producto. No solo en el lanzamiento.
• Transparencia en la gestión de riesgos. Los usuarios y las partes interesadas deben tener información clara sobre cómo se detectan, divulgan y gestionan los riesgos de seguridad.
• Responsabilidad más allá del despliegue. La responsabilidad en materia de seguridad se extiende a las actualizaciones, los periodos de soporte y la eventual retirada del producto del mercado.

Alcance y cobertura de la CRA

Qué cubre la CRA (y qué no)

Vamos por partes, porque aquí es donde muchos resúmenes de la CRA se equivocan.

La CRA es una regulación de producto. Se dirige a los «productos con elementos digitales», es decir, hardware y software de productos o software con instalación propia, puestos en el mercado de la UE. No es una regulación de servicios.

Las plataformas SaaS puras están generalmente excluidas del alcance de la CRA. Un servicio de videoconferencia prestado íntegramente a través de un navegador o API, sin instalación local, queda fuera del reglamento tal como está redactado. La Comisión Europea argumentó que los proveedores de SaaS puro ya están cubiertos por la NIS2, una directiva separada centrada en las obligaciones de ciberseguridad para proveedores de servicios digitales y operadores de servicios esenciales.

La única excepción es acotada: un servicio en la nube entra en el alcance de la CRA cuando es esencial para el funcionamiento de un producto de software o hardware, y fue desarrollado por el mismo fabricante. Por ejemplo, un dispositivo inteligente que no puede funcionar sin su servicio cloud asociado. Ese servicio cloud queda dentro del alcance porque es inseparable del producto en sí. Un servicio SaaS de videoconferencia independiente no cumple esa definición.

En cualquier caso, los principios de la CRA (desarrollo seguro por diseño, seguridad del ciclo de vida, gestión de vulnerabilidades) representan buenas prácticas independientemente de qué regulación se aplique.

¿Y si construyes sobre un SDK de vídeo embebido?

Aquí es donde la situación cambia para muchos de los equipos que leen esto.

Si integras un SDK de videoconferencia, como el de Digital Samba, en una aplicación de escritorio (por ejemplo, con Electron), en una app nativa para iOS o Android, o en cualquier producto que se distribuye como archivo instalable (.exe, .dmg, .apk, .ipa), tu producto sí es un «producto con elementos digitales» y sí entra en el ámbito de la CRA. El hecho de que el backend sea SaaS no cambia eso: lo que la CRA mira es si tu cliente descarga e instala algo.

En ese escenario, tú eres el fabricante a ojos de la CRA. Y las disposiciones sobre cadena de suministro del reglamento te obligan a evaluar los componentes de terceros que integras, incluido el SDK de vídeo. Eso convierte al proveedor del SDK en un eslabón directo de tu cumplimiento: necesitas saber cómo gestiona sus vulnerabilidades, cómo comunica los parches y qué prácticas de seguridad sigue en el desarrollo.

Elegir un proveedor de SDK que ya trabaja con estos principios no solo es una buena práctica; es parte de tu propia diligencia debida bajo la CRA.

Productos que la CRA sí cubre

Para los productos dentro del alcance, el reglamento se aplica de forma amplia:

• Aplicaciones de software entregadas localmente o a través de la nube cuando forman parte integral de un producto con elementos digitales
• Dispositivos conectados y productos IoT: dispositivos físicos con software embebido que se conectan a redes
• Componentes integrados en sistemas más amplios, incluidos módulos de software o bibliotecas individuales

Obligaciones del ciclo de vida del software

La CRA contempla el ciclo de vida de la seguridad en su conjunto. Las obligaciones no terminan cuando el producto sale al mercado.

Los fabricantes deben integrar consideraciones de seguridad durante todo el desarrollo. Los productos deben monitorizarse en busca de vulnerabilidades. Las debilidades identificadas deben parchearse con rapidez. Y los fabricantes deben declarar durante cuánto tiempo un producto recibirá actualizaciones de seguridad.

Consideraciones sobre la cadena de suministro

El reglamento también establece expectativas sobre la seguridad de la cadena de suministro. Se espera que los fabricantes tengan visibilidad sobre los componentes en los que se apoya su software, evalúen las bibliotecas de terceros en términos de riesgo de seguridad y estado de mantenimiento, y aseguren que sus proveedores sigan prácticas de seguridad reconocidas.

Un matiz importante: el software libre y de código abierto no comercial está exento de la CRA. Sin embargo, cuando componentes open source se integran en un producto comercial, el fabricante de ese producto sigue siendo responsable de la seguridad de dichos componentes.

Cumplimiento de la CRA: requisitos principales

Para los fabricantes de productos dentro del alcance, alcanzar el cumplimiento implica alinear los procesos internos con un conjunto definido de expectativas. Estos requisitos no son puramente técnicos; también cubren gobernanza, documentación y prácticas operativas.

Prácticas de desarrollo seguro. Los fabricantes deben implementar metodologías de desarrollo seguro: modelado de amenazas desde el diseño, estándares de codificación segura, revisiones de código y pruebas, y seguridad integrada en los pipelines de CI/CD.

Gestión de vulnerabilidades. Un requisito central es la capacidad de detectar, gestionar y comunicar vulnerabilidades. Esto implica establecer un proceso de divulgación coordinada, monitorizar nuevas amenazas, responder dentro de plazos definidos y dar información clara a usuarios y partes interesadas.

Documentación. El reglamento da mucho peso a la transparencia a través de la documentación: una descripción técnica de las funciones de seguridad, instrucciones para la configuración y el uso seguros, y registros de evaluaciones de riesgos con las medidas de mitigación adoptadas.

Gestión de riesgos. La gestión de riesgos bajo la CRA es continua: identificar amenazas y vectores de ataque potenciales, evaluar probabilidad e impacto, aplicar mitigaciones y revisar las evaluaciones periódicamente.

Certificación y conformidad

Certificación vs. autoevaluación

No todos los productos necesitan certificación de terceros. La CRA usa un enfoque basado en riesgo con cuatro categorías:

• Los productos de riesgo estándar pueden seguir un proceso de autoevaluación.
• Los productos de mayor riesgo (Clase I, Anexo III Parte I) pueden usar autoevaluación si se aplican normas armonizadas; si no, se requiere evaluación de terceros.
• Los productos de mayor riesgo (Clase II, Anexo III Parte II) requieren evaluación obligatoria de terceros por un organismo notificado.
• Los productos críticos (Anexo IV) enfrentan los requisitos más estrictos y pueden requerir certificación europea de ciberseguridad.

Acceso al mercado y sanciones

El cumplimiento está directamente vinculado al acceso al mercado. Los productos que no cumplan los requisitos de la CRA a partir de diciembre de 2027 pueden ver restringida su distribución en la UE.

Las sanciones económicas son significativas. Las infracciones de los requisitos esenciales de ciberseguridad pueden resultar en multas de hasta 15 millones de euros o el 2,5 % de la facturación anual global, lo que sea mayor. Otras infracciones conllevan multas de hasta 10 millones de euros o el 2 % de la facturación global.

En España, la AEPD, el CCN-CERT e INCIBE son las autoridades de referencia en materia de protección de datos y ciberseguridad respectivamente. Además de la CRA, las organizaciones tendrán que prestar atención a la transposición nacional de la NIS2. La fecha límite europea era octubre de 2024, pero España aún no ha completado el proceso: la Comisión Europea envió en mayo de 2025 un dictamen motivado, paso previo a una posible denuncia ante el Tribunal de Justicia de la UE. Mientras tanto, sigue aplicándose el Real Decreto-ley 12/2018 (transposición de la Directiva NIS1). Las organizaciones deberían prepararse como si la NIS2 fuera a entrar en vigor en breve, porque lo hará.

Etiquetado de conformidad

La CRA introduce el marcado CE para señalar la conformidad. Indica a clientes y equipos de compras que un producto cumple los requisitos de seguridad y facilita las decisiones de adquisición.

Preparación para el cumplimiento

Si tu organización fabrica productos dentro del alcance de la CRA, prepararte implica tanto disposición técnica como organizativa. Los pasos habituales incluyen:

• Hacer un análisis de brechas frente a los requisitos
• Revisar los procesos de desarrollo y despliegue
• Mapear las dependencias de software y los riesgos de la cadena de suministro
• Establecer flujos de trabajo de gestión de vulnerabilidades
• Actualizar la documentación y los marcos de gobernanza

Para muchas organizaciones, el apoyo externo puede acelerar este proceso. La Comisión Europea mantiene una página de orientación actualizada sobre la CRA en digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act. Codific también ofrece orientación estructurada sobre estrategias de implementación en complycra.eu.

Cómo Digital Samba se alinea con los principios de la CRA

Digital Samba es una plataforma de videoconferencia europea con sede en Barcelona. Como servicio SaaS puro, la CRA no le aplica de la misma forma que a un fabricante que vende un producto con elementos digitales. La evaluación de conformidad formal y el marcado CE solo serán legalmente exigibles a partir de diciembre de 2027 para productos dentro del alcance, y no se ha completado dicha evaluación.

Si estás construyendo sobre el SDK de Digital Samba e integrándolo en un producto instalable, tú eres el fabricante que la CRA tiene en la mira. En ese caso, lo que importa es saber cómo trabaja tu proveedor: si el SDK que integras sigue prácticas de seguridad por diseño, si comunica las vulnerabilidades con transparencia y si mantiene el producto de forma continua.

La plataforma de Digital Samba refleja un enfoque de desarrollo estrechamente alineado con los principios de la CRA. Tres puntos concretos:

Arquitectura con alojamiento europeo. Toda la infraestructura de procesamiento de vídeo está alojada en la UE, en servidores de Leaseweb (NL y DE) y Scaleway (FR). El único subprocesador fuera de la UE es HubSpot, que se utiliza exclusivamente para tickets de soporte y formularios de feedback y es un componente opcional que los clientes B2B europeos pueden excluir contractualmente. Los datos de sesión y media nunca se procesan ahí. Esto respalda los requisitos estrictos de residencia de datos y reduce la exposición a marcos legales conflictivos.

Cifrado en múltiples capas. Más allá del cifrado de transporte estándar de WebRTC, Digital Samba ofrece cifrado de extremo a extremo a nivel de aplicación como capa opcional que los clientes pueden activar. Cuando el E2EE está habilitado, los flujos de medios y los datos asociados son inaccesibles para los intermediarios, incluidos los proveedores de infraestructura. En sesiones estándar sin E2EE activado, el servidor de medios sí gestiona los flujos para poder enrutarlos.

Desarrollo iterativo con actualizaciones frecuentes. La plataforma sigue un ciclo de publicaciones continuo, lo que permite responder con rapidez a vulnerabilidades emergentes. Esto se alinea con las expectativas de la CRA sobre mantenimiento continuo de la seguridad.

Además de estos tres puntos, la plataforma ofrece control granular sobre las funciones que generan datos (grabaciones, transcripciones, otras salidas), control de acceso basado en roles, mecanismos de autenticación para la gestión de sesiones y visibilidad operativa a través del panel de control y la API para facilitar la documentación y la preparación para auditorías.

Para los equipos que construyen sobre una plataforma de vídeo, elegir un proveedor que ya trabaja con estos principios facilita el cumplimiento de sus propios requisitos de seguridad y normativa.

Conclusión

La Ley de Ciberresiliencia cambia la forma en que se regula la seguridad digital en Europa, y las obligaciones que introduce son reales. Para los fabricantes de productos conectados, el cumplimiento implica construir la seguridad desde el inicio, mantenerla a lo largo del tiempo y documentarla bien.

Para las organizaciones que despliegan plataformas de comunicación SaaS, la situación es distinta: la CRA no aplica directamente, pero la NIS2 sí puede hacerlo, dependiendo del tamaño de la organización (la directiva se aplica a empresas medianas y grandes con 50 o más empleados o más de 10 millones de euros de facturación). Las dos regulaciones funcionan junto al RGPD, y en España junto a la LOPDGDD y el ENS, sin sustituirlo. Saber qué marco te corresponde es el primer paso para actuar.

Si desarrollas productos sobre un SDK de vídeo embebido, la ecuación cambia: en ese caso sí eres fabricante bajo la CRA, y la seguridad de los componentes que integras forma parte de tu responsabilidad. La seguridad debe estar en el diseño, respaldada con procesos continuos y documentada con claridad. Eso aplica igual si la obligación viene de la CRA, de la NIS2 o de las dos.

¿Quieres saber más? Contacta con nuestro equipo comercial o crea una cuenta Starter gratuita con 10.000 minutos al mes.

Preguntas frecuentes (FAQ)