El Cyber Resilience Act (CRA) impone a partir de 2026 nuevas obligaciones de ciberseguridad a los editores de software, creadores de plugins, fabricantes de productos digitales, importadores y distribuidores activos en el mercado europeo.
Cyber resilience act (CRA): por qué el software y los plugins están directamente afectados
El Cyber Resilience Act, Reglamento (UE) 2024/2847, marca un cambio profundo en la manera de concebir, publicar y mantener los productos digitales. Adoptado el 23 de octubre de 2024 y publicado después en el Diario Oficial de la Unión Europea el 20 de noviembre de 2024, crea un marco común de ciberseguridad para los productos comportados por elementos digitales.
Hasta ahora, muchos editores trataban la seguridad como una capa de corcción después de la publicación. El CRA invierte esta lógica: un software, un plugin WordPress, un firmware o un componente conectado debe ser seguro desde su diseño, estar documentado, mantenerse y supervisarse durante su ciclo de vida.
Esta evolución afecta especialmente a las agencias web, los editores SaaS híbridos, los desarrolladores de plugins, los integradores WordPress y las empresas que comercializan aplicaciones de negocio. Una agencia como DualMedia, que interviene en proyectos web, móviles y de aplicaciones, debe integrar estas exigencias en las decisiones de arquitectura, las auditorías técnicas y los procesos de mantenimiento.
El problema que el Cyber resilience act (CRA) quiere resolver
La proliferación de objetos conectados, aplicaciones, dependencias open source y extensiones de software ha ampliado la superficie de ataque en Europa. La Comisión Europea ya estimaba el coste anual mundial de la ciberdelincuencia en 5 500 mil millones de euros en 2021, una señal forte de la magnitud del riesgo.
El mercado sufría de tres debilidades recurrentes: productos entregados con fallos conocidos, falta de transparencia para los compradores y un seguimiento poscomercialización a veces insuficiente. En el universo de los plugins, esto puede traducirse en una extensión sin mantenimiento, una biblioteca vulnerable o una función de administración demasiado permisiva.
El CRA introduce por tanto una lógica simple: si un producto digital se comercializa en el mercado europeo, su fabricante debe poder demostrar que ha evaluado los riesgos, reducido las vulnerabilidades y previsto corctivos. La seguridad pasa a ser una condición de acceso al mercado, y no un argumento de marketing secundario.
Qué productos digitales entran en el ámbito del CRA
El CRA se aplica a los productos comportados por elementos digitales. Esta noción abarca los productos de software o hardware, sus componentes, así como determinadas soluciones de tratamiento de datos a distancia lorsque están vinculadas al funcionamiento del producto.
Para un editor, el punto clave consiste en examinar no solo el producto final, sino también sus dependencias, sus módulos complementarios y sus integraciones. Un plugin WordPress comercial, una aplicación móvil conectada a una API, un firmware integrado o un módulo de software vendido por separado pueden entrar en el perímetro.
- Objetos conectados: cámaras, termostatos, cerraduras conectadas, equipos industriales, dispositivos médicos conectados hors regímenes específicos.
- Software: aplicaciones, sistemas operativos, firmwares, extensiones, plugins, herramientas de administración.
- Componentes de hardware: procesadores, tarjetas de red, módulos de comunicación, componentes integrados.
- Soluciones remotas vinculadas a un producto: tratamientos SaaS necesarios para el funcionamiento de un producto digital comercializado.
Algunos elementos están excluidos, en particular los servicios cloud puros, el software libre desarrollado en un marco no comercial, los productos de defensa o los dispositivos ya cubiertos por reglamentos sectoriales específicos. No obstante, atención: lorsque un componente open source se integra en un producto comercial, el editor o el fabricante del producto debe asumir las obligaciones asociadas.
Las categorías de productos y los niveles de conformidad
El CRA clasifica los productos según su criticidad. Esta clasificación determina el nivel de evaluación de conformidad que debe preverse, desde la autoevaluación hasta la intervención de un organismo tercero o de una certificación europea.
Para los editores de software y plugins, esta etapa es estructurante. Un plugin de galería de imágenes no tendrá el mismo nivel de riesgo que un gestor de contraseñas, una herramienta VPN o una extensión de autenticación utilizada en sitios con fort tráfico.
| Categoría | Ejemplos de productos | Evaluación esperada |
|---|---|---|
| Productos por defecto | Software de oficina, videojuegos, extensiones simples, componentes poco sensibles | Autoevaluación por parte del fabricante |
| Productos importantes de clase I | Gestores de contraseñas, VPN, routers domésticos, sistemas domóticos, juguetes conectados | Normas armonizadas o evaluación por un tercero según los casos |
| Productos importantes de clase II | Sistemas operativos, cortafuegos industriales, herramientas de detección de intrusiones, microprocesadores seguros | Evaluación obligatoria por un tercero |
| Productos críticos | Tarjetas con chip, dispositivos de firma electrónica, pasarelas de contadores inteligentes | Certificación europea de ciberseguridad |
Esta lectura por nivel de riesgo obliga a las empresas a documentar sus decisiones. En la práctica, una cartografía de los productos y plugins se convierte en el punto de partida de cualquier estrategia CRA seria.
Las obligaciones de 2026 del Cyber resilience act (CRA) para los editores de software
Las primeras obligaciones operativas del CRA llegan antes de la aplicación completa del reglamento. Los organismos de evaluación de conformidad están afectados a partir del 11 juin 2026, y después las obligaciones de notificación de las vulnerabilidades explotadas activamente y de los incidentes graves se aplican a partir del 11 septembre 2026.
El conjunto de requisitos del CRA se aplicará después a partir del 11 diciembre 2027. Este calendario deja un margen aparente, pero se reduce rápidamente para los equipos que deben revisar sus cadenas de desarrollo, sus dependencias, sus contratos y su documentación técnica.
| Fecha | Etapa reglamentaria | Impacto para los programas informáticos y plugins |
|---|---|---|
| 10 de diciembre de 2024 | Entrada en vigor del CRA | Inicio del periodo de preparación reglamentaria |
| 11 de junio de 2026 | Aplicación de las normas relativas a los organismos de evaluación | Preparación de las evaluaciones de conformidad para los productos afectados |
| 11 de septiembre de 2026 | Obligaciones de notificación de vulnerabilidades e incidentes graves | Implantación imprescindible de un proceso de detección, calificación y notificación |
| 11 de diciembre de 2027 | Aplicación completa del reglamento | Conformidad global exigida para la comercialización en el mercado europeo |
Para una empresa que publica varios plugins, el riesgo no es solo jurídico. Sin un inventario fiable, resulta difícil saber qué producto se mantiene, qué bibliotecas están expuestas y qué versiones deben corgirse con prioridad.
Seguridad desde el diseño: el nuevo reflejo de los proyectos web, móviles y WordPress
El CRA impone la seguridad desde el diseño y por defecto. En concreto, un producto no debe entregarse con vulnerabilidades explotables conocidas, contraseñas genéricas, permisos excesivos o mecanismos de actualización insuficientes.
En un proyecto WordPress, esto cambia la manera de diseñar un plugin. Los roles de usuario deben controlarse estrictamente, las entradas deben validarse, las solicitudes deben protegerse y las dependencias deben supervisarse incluso antes de la primera puesta en producción.
En una aplicación móvil, el mismo principio se aplica a las API, a los tokens de autenticación, al almacenamiento local, al cifrado y a los registros técnicos. DualMedia integra este tipo de enfoque en las fases de definición, UX técnica, desarrollo y mantenimiento para evitar que la seguridad se trate demasiado tarde.
La cuestión ya no es: ¿el producto funciona? Pasa a ser: ¿el producto funciona de forma segura, mantenible y demostrable ante una auditoría?
Gestión de vulnerabilidades: lo que los editores deben organizar antes de septiembre de 2026
La gestión de las vulnerabilidades se convierte en uno de los pilares del CRA. El fabricante debe identificar, documentar, corriger y comunicar sobre las fallas que afecten a su producto durante la vida útil prevista o durante cinco años después de la comercialización, según el período más corto.
Este requisito supone un proceso formalizado. Ya no basta con esperar a que un cliente señale un bug crítico por e-mail o a que un desarrollador corrige una dependencia lorsqu’il en a le temps.
- Implantar una vigilancia sobre las vulnerabilidades de las dependencias y componentes de terceros.
- Crear un procedimiento público de notificación de fallas, claro y accesible.
- Clasificar las vulnerabilidades según su gravedad, su explotabilidad y su impacto real.
- Difundir actualizaciones de seguridad gratuitas y en plazos adaptados al riesgo.
- Publicar avisos de seguridad lorsque las fallas corrigées deben ser conocidas por los usuarios.
- Documentar las decisiones tomadas para conservar una prueba de conformité.
Un caso típico se refiere a un plugin e-commerce que utiliza una biblioteca JavaScript vulnerable. Si esta dependencia expone los datos de pedido o permite una elevación de privilegios, el editor debe ser capaz de detectar el problema, publicar un correctif e informer a los canales competentes en los plazos previstos.
SBOM: el inventario de software se convierte en una prueba de control
El SBOM, por Software Bill of Materials, es un inventario de los componentes de software integrados en un producto. Enumera, en particular, las bibliotecas de terceros, las dependencias open source y los packages utilizados en una aplicación, un plugin o un firmware.
Su interés es evidente en cuanto aparece una falla importante en una dependencia popular. El caso Log4Shell mostró que una vulnerabilidad en un componente ampliamente difundido podía obligar a miles de organisations a verificar urgentemente su exposición.
El CRA impone a los fabricantes generar y mantener un SBOM actualizado, como mínimo a nivel de package. Este documento no tiene por qué publicarse sistemáticamente, ya que también podría proporcionar informations útiles a un atacante, pero debe estar disponible para las autorités competentes previa solicitud.
Para los equipos de desarrollo, idealmente el SBOM debe producirse automáticamente en el pipeline de integración continua. Esta automatización reduce los olvidos y facilita las auditorías, en particular lorsque varios productos comparten los mismos bloques técnicos.
Notificación de incidentes: los plazos que deben integrarse en la organisation
A partir del 11 de septiembre de 2026, el CRA impone plazos estrictos de notificación para las vulnerabilidades explotadas activamente y los incidentes graves que afecten a la seguridad del producto. El fabricante debe notificar a la ENISA en las 24 horas siguientes al descubrimiento, proporcionar un rapport más completo en un plazo de 72 horas y, después, un rapport final en un plazo de 14 días.
Estos plazos son cercanos a los que algunas organisations ya conocen con NIS2. La diferencia radica en el perímetro: el CRA se centra en el propio producto digital, mientras que NIS2 se dirige a la seguridad de los sistemas de information de las entidades afectadas.
En una empresa de software, esto exige una cadena de decisión corta. ¿Quién clasifica el incidente? ¿Quién valida la notificación? ¿Quién contacta con los clientes? ¿Quién redacta el rapport técnico? Sin una respuesta preparada, las primeras 24 horas pueden volverse caóticas.
Marcado CE ciber: una condición de acceso al mercado europeo
El marcado CE se amplía a la ciberseguridad para los productos cubiertos por el CRA. Acredita que el producto cumple los requisitos esenciales aplicables y que se ha seguido un procedimiento de conformidad adaptado a su categoría.
Para el editor o el fabricante, este marcado supone un expediente técnico, una declaración de conformidad UE y, según el nivel de criticidad, una evaluación por terceros. Para un distribuidor o un importador, se convierte en un punto de control antes de la comercialización.
Esta evolución tendrá efectos directos en las licitaciones. Un cliente profesional podrá solicitar la prueba de conformidad con el CRA, la duración del supporte de seguridad, las modalidades de actualización y, para los productos sensibles, elementos sobre la trazabilidad de los componentes.
CRA, NIS2, DORA, RGPD y reglamento de IA: cómo articular los textos
El Cyber Resilience Act no sustituye a los demás marcos europeos. Se añade a un conjunto de normas que persiguen cada una un aspecto preciso de la resiliencia digital.
NIS2 se refiere a las organizaciones esenciales e importantes, su gobernanza cibernética, su gestión de riesgos y sus obligaciones de notificación. DORA se dirige al sector financiero y a la resiliencia operativa digital de bancos, aseguradoras, proveedores de servicios financieros y proveedores TIC críticos.
El RGPD ya impone medidas de seguridad adecuadas para proteger los datos personales. El CRA reforza esta lógica a nivel del producto: un software vulnerable utilizado para tratar datos personales puede agravar el riesgo en caso de incidente o de control.
El reglamento de IA también puede cruzarse con el CRA cuandor un sistema de inteligencia artificial de alto riesgo constituye un producto comporsto por elementos digitales. En ese caso, la conformidad cibernética se convierte en una base indispensable para construir una conformidad más amplia.
| Texto | Ámbito principal | Efecto para la empresa |
|---|---|---|
| CRA | Productos digitales, software, plugins, componentes, objetos conectados | Seguridad desde el diseño, gestión de vulnerabilidades, SBOM, marcado CE |
| NIS2 | Entidades esenciales e importantes | Gobernanza cibernética, continuidad, notificación, seguridad de la cadena de suministro |
| DORA | Sector financiero y proveedores TIC críticos | Resiliencia operativa, pruebas, gestión de terceros, incidentes TIC |
| RGPD | Datos personales | Medidas de seguridad, responsabilidad, gestión de las violaciones de datos |
| Reglamento IA | Sistemas de inteligencia artificial, en particular de alto riesgo | Requisitos de conformidad, gestión de riesgos, documentación y supervisión |
El enfoque adecuado consiste en evitar los silos. Un mismo producto puede verse afectado por varios textos, pero una gobernanza común permite mutualizar las pruebas, las auditorías, los registros y los planes de acción.
Sanciones del Cyber resilience act (CRA): por qué la anticipación es indispensable
El CRA prevé sanciones significativas. El incumplimiento de los requisitos esenciales de ciberseguridad puede alcanzar 15 millones de euros o el 2,5 % del volumen de negocios anual mundial, reteniéndose el importe más elevado.
Los demás incumplimientos del reglamento pueden sancionarse hasta con 10 millones de euros o el 2 % del volumen de negocios anual mundial. El suministro de información inexacta o incompleta a las autoridades puede alcanzar 5 millones de euros o el 1 % del volumen de negocios mundial.
Las autoridades de vigilancia también podrán ordenar la retirada o la recuperación de productos no conformes. Para un editor de plugins, el impacto puede, por tanto, superar la multa: pérdida de acceso al mercado, ruptura de la confianza del cliente, interrupción de la distribución y daño duradero a la reputación.
Cómo preparar un software o un plugin para la conformidad con el CRA
La puesta en conformidad comienza con un diagnóstico. Una empresa debe identificar su papel: fabricante, editor, importador, distribuidor o simple usuario profesional de productos digitales.
Para un editor de plugins WordPress, la prioridad consiste en vincular cada extensión con su modelo económico, sus dependencias, su nivel de exposición y su criticidad. Un plugin gratuito, no comercial y comunitario no requiere el mismo análisis que una extensión premium vendida a clientes europeos.
- Cartografiar los software, plugins, API, componentes integrados y dependencias críticas.
- Clasificar cada producto según las categorías del CRA y su nivel de riesgo.
- Implementar un pipeline DevSecOps con análisis de dependencias, revisión de código y pruebas de seguridad.
- Generar un SBOM actualizado para cada producto comercializado.
- Formalizar una política de divulgación coordinada de las vulnerabilidades.
- Preparar los modelos de notificación ENISA, los rapportes técnicos y los circuitos de validación.
- Constituir el expediente técnico, la declaración de conformidad y las pruebas de evaluación.
- Anticipar la intervención de un organismo tercero para los productos de clase II o críticos.
En un proyecto acompañado por DualMedia, este enfoque puede integrarse desde la renovación técnica o la creación de un nuevo producto. El reto es transformar la conforidad en un método de desarrollo: una arquitectura más robusta, un mantenimiento más claro y una mayor confianza por parte del cliente.
Lo que deben verificar los compradores profesionales
El CRA no afecta solo a los fabricantes. Los compradores profesionales tendrán mucho interés en reforzar sus criterios de selección, sobre todo cuandoren despliegan software crítico, plugins de administración, soluciones de pago o componentes conectados.
Un servicio informático que instala un plugin en varias decenas de sitios de clientes debe verificar su mantenimiento, la capacidad de respuesta del editor y la calidad de sus correctivos. El precio o la popularidad de una extensión ya no bastan para justificar una elección técnica.
- Solicitar la duración del sorporte de seguridad antes de la compra o la renovación.
- Verificar la existencia de un proceso de notificación de vulnerabilidades.
- Controlar la frecuencia de las actualizaciones y el historrial de mantenimiento.
- Exigir los elementos de conforidad CRA cuandoro el producto sea crítico.
- Integrar la ciberseguridad en las licitaciones y contratos con proveedores.
Esta disciplina de compra reduce los riesgos de dependencia de productos abandonados. También reforrza la posición de las empresas frente a las auditorías RGPD, NIS2 o a las exigencias contractuales de grandes cuentas.
Nuestra opinión
El Cyber Resilience Act (CRA) obliga a los editores de software y de plugins a dar un salto de madurez. La seguridad ya no puede improvisarse en el momento de un fallo público o de un incidente de cliente; debe pensarse, supervisarse y documentarse desde el diseño.
Para los actores de la web, del móvil y de WordPress, esta exigencia puede convertirse en una ventaja competitiva. Un producto mejor securizado, mejor mantenido y mejor documentado inspira más confianza a los clientes, los distribuidores y los socios.
El enfoque más pragmático consiste en empezar por los productos más expuestos: plugins de autenticación, módulos e-commerce, API de negocio, aplicaciones móviles conectadas y herramientas que manipulan datos sensibles. Con un acompañamiento técnico adecuado, en particular por parte de una agencia experta como DualMedia, la conforidad CRA puede integrarse progresivamente en los ciclos de desarrollo sin bloquear la innovación.
¿Qué programas informáticos están afectados por el Cyber Resilience Act (CRA)?
Los programas comercializados en el mercado europeo pueden verse afectados por el Cyber Resilience Act (CRA). Esto incluye aplicaciones, sistemas operativos, firmwares, plugins, componentes de software y determinados servicios remotos vinculados al funcionamiento de un producto digital.
¿Está un plugin WordPress sujeto al Cyber Resilience Act (CRA)?
Un plugin comercial de WordPress puede entrar en el ámbito de aplicación del Cyber Resilience Act (CRA). El análisis depende de su modelo de distribución, de sus funcionalidades, de su nivel de riesgo y de su puesta a disposición en el mercado europeo.
¿Se aplica el CRA al software de código abierto?
El software open source no comercial no está directamente sujeto a las mismas obligaciones. Sin embargo, cuando un componente open source se integra en un producto comercial, el fabricante o el editor del producto debe gestionar las obligaciones previstas por el CRA.
¿Qué obligaciones de la CRA se aplican a partir de 2026?
Las obligaciones de notificación de las vulnerabilidades explotadas activamente y de los incidentes graves se aplican a partir del 11 de septiembre de 2026. Por tanto, las empresas deben preparar sus procesos de detección, cualificación, notificación y reporting antes de esa fecha.
¿Qué es un SBOM en el marco del CRA?
Un SBOM es el inventario de los componentes de software presentes en un producto. Permite identificar las bibliotecas, dependencias y paquetes utilizados para reaccionar rápidamente cuando una vulnerabilidad afecta a un componente de terceros.
¿Impone el Cyber Resilience Act (CRA) actualizaciones de seguridad gratuitas?
Sí, el CRA impone el suministro de actualizaciones de seguridad gratuitas durante el período de support aplicable. Esta obligación pretende evitar que los usuarios sigan expuestos a vulnerabilidades conocidas después de la compra del producto.
¿Cuáles son los plazos de notificación previstos por el CRA?
El fabricante debe notificar determinadas vulnerabilidades e incidentes a la ENISA en las 24 horas siguientes a su descubrimiento. Un rapport más completo debe seguir en un plazo de 72 horas, y luego un rapport final en un plazo de 14 días.
¿Cuál es la diferencia entre el CRA y NIS2?
La CRA se centra en la ciberseguridad de los productos digitales comercializados. NIS2 se centra más bien en la ciberseguridad de las organizaciones esenciales e importantes, sus sistemas de información, su gobernanza y sus procedimientos de notificación.
¿Qué sanciones están previstas en caso de no conformité con el CRA?
Las sanciones pueden alcanzar los 15 millones de euros o el 2,5 % de la cifra de negocios anual mundial por los incumplimientos más graves. Las autoridades también pueden solicitar la retirada o la recuperación de productos no conformes.
¿Cómo preparar un software o un plugin para el cumplimiento de la CRA?
La preparación comienza con un mapeo de los productos, dependencias y riesgos. A continuación, hay que clasificar los productos, generar SBOM, organizar la gestión de las vulnerabilidades, documentar las pruebas de seguridad y anticipar las evaluaciones de conformidad.
¿Quieres obtener una cotización detallada para una aplicación móvil o sitio web?
Nuestro equipo de expertos en desarrollo y diseño de DualMedia está listo para hacer realidad sus ideas. Contáctenos hoy mismo para obtener un presupuesto rápido y preciso: contact@dualmedia.fr