Reglamento de Ciberresiliencia y plugins WordPress: qué hacer

Si vende un plugin o un tema premium de WordPress a clientes de la UE, el Reglamento de Ciberresiliencia (CRA, por sus siglas en inglés) ya le afecta. Desde el 11 de septiembre de 2026 debe notificar las vulnerabilidades aprovechadas activamente y los incidentes graves que afecten a sus productos, empezando por una alerta temprana en un plazo de 24 horas. El bloque más amplio de obligaciones, que va de los requisitos de seguridad y la lista de materiales de software (SBOM) a las actualizaciones de seguridad y el marcado CE, se aplica a partir del 11 de diciembre de 2027.

Esta guía explica quién se considera fabricante, qué supone notificar en la práctica y qué conviene hacer ya. El texto legal es el Reglamento (UE) 2024/2847.

¿Es usted fabricante según el Reglamento de Ciberresiliencia?

El CRA se aplica a los «productos con elementos digitales» que se comercializan en el mercado de la UE en el transcurso de una actividad comercial. Un plugin o tema premium de WordPress vendido a clientes de la UE es uno de esos productos, y la persona o empresa que lo desarrolla y lo vende con su propio nombre es su fabricante. Da igual que esté establecida dentro o fuera de la UE.

Plugins gratuitos, freemium y de pago

El software libre y de código abierto que no se monetiza queda, en general, fuera del régimen de los fabricantes. Un plugin hecho por afición y publicado en WordPress.org sin ninguna modalidad de pago, o el código con el que usted contribuye al proyecto de otra persona, son ejemplos típicos.

Los modelos freemium están menos claros. Los considerandos del CRA enumeran indicios de actividad comercial: cobrar un precio por el producto, cobrar por el soporte más allá de la recuperación de costes, monetizarlo a través de una plataforma u otros servicios, exigir datos personales como condición de uso por motivos ajenos a la seguridad, la compatibilidad o la interoperabilidad, y aceptar donaciones que superen los costes. Por eso, un plugin «lite» gratuito que existe sobre todo para vender una versión Pro o un servicio de pago puede considerarse comercial. Si eso describe su negocio, planifique como fabricante y pida asesoramiento jurídico sobre los detalles.

Administradores de software de código abierto

El CRA introduce también la figura del «administrador de software de código abierto»: personas jurídicas, como las fundaciones, que apoyan de forma sistemática el desarrollo de software libre y de código abierto destinado a actividades comerciales sin ser su fabricante. Los administradores tienen un régimen más ligero, y sus obligaciones de notificación se aplican a partir del 11 de diciembre de 2027.

Por qué su sitio web no es un producto del CRA

Un sitio web o un servicio alojado, como tal, no es en general un «producto» a efectos del CRA. El tratamiento de datos a distancia solo queda cubierto cuando es esencial para que un producto funcione. Su web corporativa, su tienda y su portal de clientes no son, por tanto, productos del CRA en general, y tener un sitio WordPress no le convierte en fabricante. Un servicio en la nube sin el que su plugin no puede funcionar es un caso que conviene examinar con atención.

Para los propietarios de sitios, el CRA actúa de forma indirecta, a través de las obligaciones de quienes les venden plugins y temas. Sus propias obligaciones derivan del RGPD y, en algunos casos, de la NIS2.

El calendario del CRA para quienes venden plugins de WordPress

• 10 de diciembre de 2024: el CRA entró en vigor.
• 11 de junio de 2026: se aplican las disposiciones sobre los organismos de evaluación de la conformidad.
• 11 de septiembre de 2026: se aplican las obligaciones de notificación de los fabricantes.
• 11 de diciembre de 2027: se aplican las obligaciones principales, entre ellas los requisitos esenciales de ciberseguridad, la evaluación de la conformidad y el marcado CE.

Notificaciones desde el 11 de septiembre de 2026: 24 horas, 72 horas, 14 días

La obligación de notificar abarca dos tipos de hechos. Una vulnerabilidad aprovechada activamente es aquella de la que existen pruebas fiables de que un agente malintencionado la ha explotado en un sistema sin permiso de su propietario. Un incidente grave afecta a la seguridad de su producto, por ejemplo porque provoca, o puede provocar, la introducción de código malicioso en su producto o en los sistemas de sus usuarios. Para quien vende plugins, un servidor de actualizaciones o de licencias comprometido que distribuye una versión con puerta trasera es un ejemplo claro.

La obligación se aplica también a los productos introducidos en el mercado antes del 11 de diciembre de 2027 (art. 69, apartado 3). Dicho de otro modo: cubre las versiones del plugin que sus clientes usan hoy.

Los plazos empiezan a contar cuando usted tiene conocimiento de la vulnerabilidad o del incidente. Las notificaciones se presentan a través de la Plataforma Única de Notificación del CRA de ENISA, operativa desde el 11 de septiembre de 2026, y llegan al CSIRT del Estado miembro donde tenga su establecimiento principal en la UE (si no lo tiene, se aplican otras reglas). ENISA las recibe al mismo tiempo. También debe informar a los usuarios afectados y, cuando proceda, a todos los usuarios, del problema y de las medidas de mitigación que pueden adoptar.

Un escenario realista: un investigador de seguridad o una empresa de hosting le avisa de que un fallo de su plugin se está usando en ataques. Desde ese momento corre el plazo de 24 horas. Nuestra guía sobre plugins vulnerables de WordPress muestra lo rápido que se explotan estos fallos una vez que se hacen públicos. Si además quedaron expuestos datos personales, por ejemplo en su propio servidor de licencias, se aplican en paralelo las normas del RGPD sobre brechas de datos; consulte la notificación de brechas del RGPD en 72 horas.

Lo que se aplica a partir del 11 de diciembre de 2027

A partir de diciembre de 2027, las obligaciones completas del fabricante se aplican a los plugins y temas que introduzca en el mercado. Los productos introducidos antes de esa fecha solo quedan cubiertos si se modifican sustancialmente después (art. 69, apartado 2). Las principales obligaciones son:

• Seguridad desde el diseño y ninguna vulnerabilidad aprovechable conocida en el momento del lanzamiento.
• Configuración segura por defecto.
• Un período de soporte durante el que usted gestiona las vulnerabilidades. En general es de al menos cinco años, salvo que se prevea que el producto se use durante menos tiempo, y su fecha de fin (como mínimo, mes y año) debe quedar clara en el momento de la compra.
• Actualizaciones de seguridad distribuidas sin demora, de forma gratuita y acompañadas de avisos. Revise cómo encaja esto con un modelo de licencias en el que las actualizaciones se cortan al terminar la suscripción.
• Un proceso de gestión de vulnerabilidades y una política de divulgación coordinada de vulnerabilidades (CVD), además de un punto único de contacto al que los usuarios puedan dirigirse con rapidez.
• Una SBOM en un formato legible por máquina que cubra al menos las dependencias de primer nivel. En un plugin, piense en los paquetes de Composer y npm y en cualquier biblioteca incluida.
• Documentación técnica, una evaluación de la conformidad y el marcado CE.

Algunos tipos de producto figuran en el anexo III como «productos importantes», con normas de evaluación de la conformidad más estrictas. Entre ellos están el software que busca, elimina o pone en cuarentena software malicioso, los gestores de contraseñas y el software de gestión de identidades y de gestión de accesos privilegiados (clase I), así como los cortafuegos y los sistemas de detección y prevención de intrusiones (clase II). Si su plugin es un producto de seguridad, revise estas categorías con atención.

Multas según el artículo 64

Incumplir los requisitos esenciales de ciberseguridad o las obligaciones del fabricante, incluida la de notificar, puede acarrear multas de hasta 15 millones de euros o el 2,5 % del volumen de negocios anual mundial, si esta cifra es superior. Un alivio para los pequeños desarrolladores: a las microempresas y pequeñas empresas no se las puede multar por incumplir el plazo de 24 horas de la alerta temprana, y a los administradores de software de código abierto no se les puede imponer ninguna multa en virtud del CRA. Para los fabricantes micro y pequeños, la notificación de 72 horas y todas las demás obligaciones siguen siendo exigibles.

Lista de tareas para quienes venden plugins de WordPress

• Haga una lista de todos los plugins, temas y complementos de pago y de los productos freemium que ofrece a clientes de la UE, y determine en cuáles es usted el fabricante.
• Organice una recepción de avisos de vulnerabilidades que responda en 24 horas: una dirección de contacto de seguridad, un archivo security.txt en su web, un buzón vigilado y un suplente designado para las vacaciones.
• Ponga por escrito su procedimiento de notificación: quién decide si una vulnerabilidad se está aprovechando activamente, quién la notifica en la Plataforma Única de Notificación y quién redacta el aviso a los usuarios.
• Prepare plantillas para la alerta temprana, la notificación de 72 horas y el informe final.
• Publique una política de divulgación coordinada de vulnerabilidades.
• Genere una SBOM para cada versión (CycloneDX y SPDX son formatos habituales) y guárdela junto con la compilación.
• Proteja su cadena de publicación: autenticación multifactor en todas las cuentas que puedan publicar código, y servidores de actualizaciones y de licencias bastionados.
• Defina un período de soporte para cada producto y planifique cómo recibirán los parches de seguridad los clientes con licencias caducadas.
• Empiece la documentación técnica: arquitectura, flujos de datos, evaluación de riesgos y resultados de pruebas.
• Compruebe si alguno de sus productos entra en el anexo III.

Como comprobación adicional antes de publicar una versión, el plugin gratuito Security Audit & Compliance de secaudit.eu incluye un análisis de vulnerabilidades del código (análisis de taint) de plugins y temas. Complementa su propia revisión de código y sus pruebas; no las sustituye.

Preguntas frecuentes

¿Se aplica el CRA a los plugins gratuitos de WordPress.org?

En general no, si el plugin no se monetiza. Si la versión gratuita sirve de embudo hacia un producto o servicio de pago, puede considerarse actividad comercial, así que pida asesoramiento.

Solo creo webs para clientes. ¿Soy fabricante?

No en lo que respecta al sitio web: un sitio web como tal no es, en general, un producto del CRA. Si además vende un plugin o un tema en el mercado de la UE, usted es el fabricante de ese producto.

Este artículo es información general, no asesoramiento jurídico.