Ley de CiberResiliencia (Cyber Resilience Act)

Ley de CiberResiliencia (Cyber Resilience Act)

IMPORTANTE: Esto no es un sitio web oficial, y esta documentación está enfocada a los servicios web de Internet.

Qué es el Cyber Resilience Act y por qué importa a las webs

Breve definición del CRA

El Cyber Resilience Act (CRA) es un Reglamento de la Unión Europea (Reglamento (UE) 2024/2847) que establece requisitos mínimos de ciberseguridad para los “productos con elementos digitales” que se ponen en el mercado de la UE. La idea central es reducir vulnerabilidades y elevar el nivel de seguridad “de base” en todo tipo de productos digitales.

Objetivo principal: seguridad por diseño y por defecto

El CRA busca que la seguridad:

  • se piense desde el principio (cuando se diseña y se desarrolla), y
  • venga activada por defecto, sin depender de que el usuario “configure bien” el sistema.

Además, introduce una responsabilidad continuada durante el ciclo de vida: no basta con sacar un producto “bien”, hay que mantenerlo seguro (por ejemplo, gestionando vulnerabilidades y publicando actualizaciones cuando toque).

Por qué no es solo “otra ley más”, sino un cambio estructural

En la práctica, el CRA convierte en obligación legal cosas que hasta ahora eran “buenas prácticas” o “recomendaciones”:

  • menos vulnerabilidades al salir al mercado,
  • parches y actualizaciones como parte del compromiso normal,
  • gestión de vulnerabilidades de forma organizada,
  • y, en ciertos casos, notificación de vulnerabilidades/incidentes a las autoridades y a ENISA.

Esto impacta directamente en cómo se conciben y operan productos digitales, especialmente los que viven “siempre conectados”, como muchas plataformas web.

Aclaración clave: el CRA sí aplica al software (y por tanto a webs y plataformas)

El CRA no va solo de “cacharros conectados”. También cubre software: productos digitales que se conectan directa o indirectamente a redes o a otros sistemas.

Llevado a ejemplos del mundo web, esto es relevante porque en la práctica muchos servicios y productos que usamos a diario entran en esa lógica de “producto digital”:

  • un CMS (por ejemplo, WordPress),
  • un plugin o un tema distribuido para ese CMS,
  • un panel de gestión (backoffice),
  • una plataforma SaaS (CRM, e-commerce, reservas, etc.),
  • una aplicación web que se ofrece a terceros como “producto/servicio” y se mantiene en el tiempo.

La conclusión para una web profesional es simple: si tu negocio desarrolla, distribuye o mantiene software web (aunque sea “solo” como parte de un servicio), el CRA es un marco que te va a condicionar, porque empuja a que la seguridad sea un requisito de producto y de operación, no un extra.

A quién afecta el Cyber Resilience Act en el mundo web

El CRA no apunta “a las webs” como tal, sino a quién pone software en el mercado de la UE y con qué papel (fabricante, distribuidor, etc.). En el sector web, eso se traduce en que afecta sobre todo a quienes desarrollan, empaquetan, venden, regalan o revenden software que se conecta a Internet o a otros sistemas.

Empresas afectadas directamente

A nivel legal, el CRA habla de “operadores económicos”: fabricante, representante autorizado, importador y distribuidor.

Proveedores de hosting

Un hosting puede verse afectado cuando, además de dar infraestructura, pone a disposición software como parte de su oferta:

  • paneles de control,
  • stacks “Managed WordPress” con componentes propios,
  • instaladores, plugins preinstalados, herramientas de seguridad, etc.

Si ese software se ofrece bajo su marca o responsabilidad, encaja más con la figura de fabricante (quien desarrolla o hace desarrollar y lo comercializa, incluso gratis).

Desarrolladores de software web

Si desarrollas y distribuyes un producto (por ejemplo, un plugin, un tema, una app web descargable, un panel), el CRA te mira como fabricante cuando lo sacas al mercado bajo tu nombre, aunque sea gratuito o monetizado indirectamente.

Ejemplo WordPress:

  • Autor de un plugin (gratis o de pago) que se distribuye con tu marca.

Empresas SaaS

El CRA incluye el producto y sus “soluciones de procesamiento remoto” cuando son necesarias para que el producto funcione. Esto encaja con muchos modelos SaaS y servicios web donde la parte “en la nube” es imprescindible.

Ejemplos típicos:

  • un plugin que depende de una API propia para funcionar,
  • una plataforma que ofrece panel + servicio remoto.

Plataformas online (marketplaces, LMS, CRMs, ERPs web)

Si la plataforma se ofrece a terceros como producto/servicio en el mercado de la UE, normalmente estás en el terreno de “producto con elementos digitales” y obligaciones asociadas (según el rol: fabricante, etc.).

Agencias que desarrollan y mantienen webs

Aquí suele haber confusión: una agencia puede estar afectada si entrega o distribuye software (por ejemplo, un “producto” repetible: un theme propio, un plugin propio, un framework propio, un portal que vendes como paquete).

Si haces una web “a medida” para un solo cliente y no la “pones en el mercado” como producto, el encaje depende mucho del caso (lo aterrizamos más en el punto 4 “qué queda fuera”). La clave es si actúas como fabricante o no.

Empresas que distribuyen software web propio

Si distribuyes un CMS, un framework, un panel o una aplicación web “empaquetada” (aunque sea open source), normalmente eres fabricante a ojos del CRA si va bajo tu marca y se ofrece en una actividad comercial, incluso gratis.

Casos típicos del entorno web

Para hacerlo práctico, estos son escenarios habituales donde el CRA puede entrar en juego:

CMS (WordPress, frameworks propios)

  • WordPress como proyecto OSS es un buen ejemplo para entender el ecosistema: “core” + extensiones + temas.
  • Si tú distribuyes una “versión” o un “pack” de CMS bajo tu marca, puedes estar actuando como fabricante.

Plugins y extensiones

  • Plugins de WordPress, módulos de PrestaShop, extensiones de navegadores, etc.
  • Aunque sean gratuitos, si los pones en el mercado bajo tu nombre, el CRA contempla ese escenario.

Temas y plantillas

  • Temas de WordPress, plantillas de CMS, plantillas de “site builders”.
  • Suelen ser producto distribuido (especialmente si hay marketplace o venta directa).

APIs públicas

  • APIs que forman parte del funcionamiento de un producto.
  • Si la API es “la parte remota” sin la cual el producto no funciona, el CRA la contempla como parte del conjunto (producto + procesamiento remoto).

Paneles de control (hosting, dashboards, backoffices)

  • Panel del hosting, panel de administración de una plataforma, backoffice de un ERP web.
  • Normalmente son superficie crítica: control de usuarios, permisos, datos, integraciones.

Aplicaciones web internas expuestas a Internet

  • Portales internos “abiertos” a clientes/proveedores (extranet), herramientas de soporte, etc.
  • Si se usan solo internamente y no se “ponen en el mercado”, puede cambiar el encaje; pero en cuanto se ofrecen como producto/servicio a terceros, la cosa se parece más a un caso CRA.

Nota rápida sobre marketplaces

El propio texto explica que un marketplace online que solo intermedia (solo “pone en contacto”) puede no ser operador económico; pero si además distribuye o vende como parte de la cadena, sí puede serlo.

Qué considera el CRA “software” (y por qué las webs entran)

Definición de “producto con elementos digitales”

El CRA usa el concepto “producto con elementos digitales” para englobar software o hardware y, además, sus “soluciones de procesamiento remoto de datos” (por ejemplo, un servicio en la nube o una API imprescindible para que el producto funcione).

Y deja claro el alcance general: aplica a productos cuyo uso previsto (o uso razonablemente esperado) incluye una conexión directa o indirecta a un dispositivo o a una red. En el mundo web, esto es el pan de cada día.

“Software” en el CRA (en sencillo)

El Reglamento define software de forma muy amplia: básicamente, código dentro de un sistema de información.

Eso hace que entren muchos “productos” típicos del entorno web:

  • un CMS (p. ej., WordPress),
  • un plugin o un tema,
  • una aplicación web “empaquetada” o distribuida,
  • un panel o herramienta de administración,
  • etc.

Software distribuido como código, servicio, descarga o acceso remoto

En el CRA lo importante no es “cómo lo entregas técnicamente”, sino que estés poniendo ese software a disposición en el mercado de la UE.

  • Como código: por ejemplo, publicas un plugin/tema de WordPress en un repositorio o marketplace.
  • Como descarga: vendes un paquete ZIP, un instalador, un panel, una app web autoalojable.
  • Como servicio / acceso remoto: cuando el “producto” funciona porque hay una parte remota imprescindible (API, backend, cloud). El propio CRA pone un ejemplo claro: una app que necesita acceder a una API o base de datos proporcionada como servicio por el fabricante; ese servicio puede entrar como “procesamiento remoto”.

Webs dinámicas vs estáticas

  • Una web estática (HTML plano servido tal cual) suele tener menos “comportamiento” y, a veces, encaja más como “contenido” que como “producto software”.
  • Una web dinámica (CMS, login, formularios, panel, e-commerce, APIs, integraciones) ya se parece mucho más a un producto digital: hay software, dependencias, actualizaciones y superficie de ataque.

El CRA no dice “estáticas sí / dinámicas no” con esas palabras, pero el criterio práctico es: cuanto más sea software que prestas o distribuyes, más cerca estás del ámbito CRA (y cuanto más sea solo “contenido”, menos). El encaje fino lo remata el concepto de “poner en el mercado” del siguiente punto.

“Software web” como producto, aunque no se instale localmente

Una idea clave del CRA es que un “producto con elementos digitales” incluye el software y, cuando aplica, la parte remota necesaria para que funcione. Es decir: no hace falta que el usuario “instale algo en su ordenador” para que exista un producto software a efectos del CRA.

Ejemplos típicos:

  • Un plugin de WordPress que sin la API del proveedor no puede hacer su función (pagos, envío, analítica, etc.).
  • Un panel web que depende de un servicio cloud del propio proveedor.

Diferencia entre “uso interno” y “distribución”

Aquí está la frontera que más confunde:

  • El CRA se centra en cuando un producto se “pone en el mercado”: es decir, cuando se suministra para distribución o uso en la UE en el curso de una actividad comercial, incluso aunque sea gratis.
  • Si algo es solo para uso interno (no lo ofreces a terceros, no lo distribuyes), normalmente estás más lejos del caso típico CRA (aunque puede haber matices).

En el punto 4 (“qué queda fuera y qué no”) aterrizamos estos matices con ejemplos muy claros (agencias, webs a medida, repositorios, plugins gratuitos, etc.).

Qué queda fuera (y qué no)

Esta sección es para bajar el ruido: el CRA no es “una ley para todas las webs”. Se centra en productos con elementos digitales (software/hardware) que se ponen en el mercado de la UE en el curso de una actividad comercial (aunque sea gratis).

Webs puramente informativas sin interacción

Si hablamos de una web “escaparate” (contenido, páginas de información, formulario de contacto simple) y no está dando soporte a un producto digital como tal, normalmente no es el objetivo del CRA.

El propio texto aclara que websites que no soportan la funcionalidad de un producto con elementos digitales no entran en el alcance del Reglamento.

Ojo con el matiz: en cuanto tu web deja de ser “solo contenido” y pasa a ser una plataforma (login, panel, API, pagos, etc.) o parte esencial de un producto (por ejemplo, un servicio que depende de backend/API), ya no encaja tan bien en “fuera”.

Proyectos personales sin distribución comercial

El CRA se activa cuando hay actividad comercial, que no es solo “cobrar por el producto”. Puede haber comercialidad si hay intención de monetizar (por ejemplo, una plataforma que monetiza servicios), cobro de soporte que va más allá de cubrir costes, o condiciones de uso que implican tratamiento de datos personales con fines distintos a seguridad/compatibilidad/interoperabilidad.

En cambio, un proyecto personal que publicas sin monetizarlo (por ejemplo, un plugin de WordPress “por hobby”, sin negocio alrededor) suele estar más cerca de no ser actividad comercial a efectos del CRA.

Software usado exclusivamente de forma privada

Si el software no se “pone en el mercado” (no se suministra para distribución o uso en la UE como parte de una actividad comercial), el CRA pierde sentido práctico porque su foco es el mercado.

Ejemplo típico:

  • una herramienta interna para tu empresa (no la vendes, no la entregas como producto a clientes).

El Reglamento incluso menciona explícitamente que, en el caso de administraciones públicas, los productos desarrollados o modificados exclusivamente para su propio uso no se consideran “puestos en el mercado”. (La idea es útil como referencia conceptual también fuera del sector público).

Open Source (matices importantes)

El CRA tiene un enfoque específico para software libre / open source:

  • Solo entra en alcance el open source que se pone en el mercado (es decir, distribuido o suministrado en el curso de una actividad comercial).
  • La propia Comisión explica que si el open source no está monetizado por su fabricante, su provisión no debería considerarse actividad comercial.
  • Y añade un punto relevante: el CRA no aplica a quienes contribuyen código a un proyecto open source cuando no está bajo su responsabilidad.

Ejemplo WordPress:

  • Contribuir al “core” no es lo mismo que distribuir un plugin/tema bajo tu marca como producto (ahí puede cambiar el encaje).

En el punto 9 lo bajamos a tierra con casos WordPress muy concretos (core, plugins gratis, plugins con servicio, marketplaces, agencias, etc.).

Obligaciones clave del Cyber Resilience Act para webs y hosting

En el CRA, la idea central es: si pones “software con Internet” en el mercado (un CMS, un plugin, un panel, un SaaS, etc.), tienes que diseñarlo para ser seguro, mantenerlo seguro y corregir fallos de seguridad durante un periodo mínimo de soporte.

Seguridad desde el diseño y por defecto

Principio “secure by design”

El CRA exige que los productos con elementos digitales (también software) se diseñen, desarrollen y produzcan con un nivel adecuado de ciberseguridad según el riesgo.

Traducido a web/hosting: la seguridad deja de ser “un plugin extra” o “una opción avanzada”. Tiene que estar en el diseño.

Minimización de superficie de ataque

El Reglamento incluye de forma explícita que deben limitarse las superficies de ataque, incluyendo interfaces externas.

En la práctica web esto suele significar:

  • no exponer paneles o endpoints que no hacen falta,
  • reducir “puntos de entrada” (formularios, APIs, integraciones),
  • evitar features que abren riesgo sin aportar valor claro.

Ejemplo WordPress:

  • cuantos más plugins (sobre todo de origen dudoso), más “superficie de ataque”. El enfoque CRA empuja a instalar solo lo necesario.

Configuraciones seguras por defecto (CMS, servidores, paneles, APIs)

El CRA pide que el producto salga con configuración segura por defecto (salvo acuerdo explícito en productos “a medida” B2B).

Aplicado al mundo web:

  • CMS: no venir “abierto” por defecto (permisos, roles, opciones sensibles, etc.).
  • Servidores: accesos admin bien controlados; no dejar servicios innecesarios “de serie”.
  • Paneles: autenticación sólida y control de acceso.
  • APIs: autenticación/autorización y límites razonables.

Además, el CRA exige mecanismos para proteger contra accesos no autorizados (autenticación/gestión de accesos) y proteger confidencialidad e integridad de datos (por ejemplo, cifrado en tránsito o en reposo cuando aplique).

Gestión de vulnerabilidades

Aquí es donde el CRA “aprieta” de verdad: no basta con programar bien; hay que tener un sistema para detectar, arreglar y comunicar vulnerabilidades.

Identificación activa de vulnerabilidades

El CRA obliga a:

  • identificar y documentar vulnerabilidades y componentes del producto (incluyendo una SBOM: una lista de dependencias principales en formato estándar).
  • hacer tests y revisiones regulares de seguridad.

En web, esto se traduce en:

  • saber qué librerías usas (PHP packages, JS, etc.),
  • vigilar CVEs y avisos de seguridad,
  • revisar plugins/temas/dependencias.

Corrección en plazos razonables

El CRA exige remediar vulnerabilidades “sin demora”, incluyendo publicar actualizaciones de seguridad.

Ejemplo WordPress:

  • si un plugin tuyo tiene una vulnerabilidad, no vale con “lo arreglo cuando pueda”: tienes que tener un proceso para sacar parche rápido.

Eliminación de contraseñas por defecto (cómo encaja en web)

El texto no lo formula como “prohibidas las contraseñas por defecto” con esa frase, pero sí obliga a:

  • configuración segura por defecto,
  • protección frente a accesos no autorizados (autenticación y control de acceso).

En la práctica, eso empuja a medidas típicas:

  • no entregar credenciales “admin/admin”,
  • forzar cambio de contraseña en el primer uso,
  • MFA/2FA cuando sea razonable (especialmente en paneles).

Gestión de dependencias (librerías, frameworks)

El CRA obliga a diligencia debida al integrar componentes de terceros (incluido open source), para que no comprometan la seguridad.

En web: controlar dependencias de PHP/JS, plugins, SDKs de terceros, etc.

Actualizaciones y parches de seguridad

Obligación de ofrecer parches

El CRA exige que las vulnerabilidades se puedan resolver mediante actualizaciones de seguridad, incluso con actualizaciones automáticas (cuando aplique) activadas por defecto y con opción clara de desactivarlas.

También exige mecanismos para distribuir actualizaciones de forma segura y que las actualizaciones de seguridad se difundan sin demora y, en general, gratis (salvo acuerdos específicos B2B a medida).

Ejemplo WordPress:

  • el “core” ya tiene auto-updates de seguridad; el CRA refuerza ese enfoque como expectativa general de mercado.

Periodo mínimo de soporte

El CRA define un “support period” durante el cual el fabricante debe gestionar vulnerabilidades. Ese periodo debe ser:

  • el tiempo que el producto se espera que esté en uso, y
  • mínimo 5 años, salvo que el producto esté previsto para durar menos (entonces, ese tiempo).

Además, cada actualización de seguridad publicada durante ese periodo debe seguir disponible al menos 10 años o hasta el final del support period (lo que sea más largo).

Actualizaciones sin “romper” seguridad (y sin mezclarlo todo)

El CRA indica que, cuando sea técnicamente posible, las actualizaciones de seguridad deberían ir separadas de actualizaciones de funcionalidad (para que no tengas que “tragarte” features nuevas solo para estar parcheado).

Casos prácticos en CMS y SaaS

  • CMS (WordPress): parches de seguridad rápidos, avisos claros, y control de dependencias (plugins/temas) para no introducir riesgos.
  • SaaS: aunque el usuario no “instale nada”, si tu servicio depende de una parte remota para funcionar, el enfoque CRA sigue siendo: vulnerabilidades identificadas, parcheadas y comunicadas; y con soporte continuado. (La lógica de mantenimiento y actualización es la misma.)

Requisitos específicos para proveedores de hosting

Primero, una idea clave para no mezclar conceptos: el CRA regula productos con elementos digitales (incluido software). Un hosting queda “dentro” cuando ofrece software como parte de su servicio (por ejemplo, un panel propio, un stack “Managed WordPress”, un instalador, un WAF/antimalware integrado, un plugin propio, etc.). En ese caso, ese software debe cumplir los requisitos esenciales del CRA.

A partir de ahí, lo que sigue es cómo se traduce en hosting (en lenguaje web).

Infraestructura segura

Para el hosting, “infraestructura segura” suele significar que lo que tú controlas (plataforma, panel, automatizaciones, imágenes base, herramientas de gestión) está diseñado para:

  • proteger frente a accesos no autorizados (autenticación y control de acceso),
  • proteger confidencialidad e integridad de datos en tránsito y en reposo cuando aplique (por ejemplo, TLS y cifrado “state of the art” donde tenga sentido),
  • garantizar disponibilidad de funciones esenciales incluso tras incidentes (medidas de resiliencia / mitigación DoS).

Ejemplo en “Managed WordPress”: el panel y automatismos que gestionan actualizaciones, credenciales, copias, staging, etc. son parte de la “experiencia producto”. Si están mal diseñados, el riesgo no lo “compensa” el CMS.

Aislamiento entre clientes

El CRA exige minimizar impacto y proteger disponibilidad/funciones esenciales. En hosting multi-tenant, eso empuja a reforzar el aislamiento para evitar efectos dominó:

  • que un cliente comprometido no pueda saltar a otro (aislamiento de cuentas, permisos, procesos, redes, almacenamiento),
  • que un abuso de recursos de un cliente no tumbe el servicio de otros (límites y mitigaciones).

(El Reglamento no usa la palabra “multi-tenant”, pero el objetivo encaja con disponibilidad, minimizar impacto y limitar superficies de ataque).

Hardening de servicios

“Hardening” es dejar lo mínimo necesario y bien cerrado. El CRA lo conecta con:

  • secure by default (configuración segura por defecto),
  • limitar superficies de ataque, incluidas interfaces externas.

Para hosting, ejemplos típicos:

  • paneles y endpoints no expuestos si no hacen falta,
  • servicios desactivados por defecto,
  • configuraciones seguras en plantillas/imágenes base (por ejemplo, PHP, SSH, bases de datos, etc.).

Protección frente a accesos no autorizados

Aquí el CRA es bastante directo: pide mecanismos apropiados de control, incluyendo autenticación y gestión de identidades/accesos.

En hosting, normalmente implica:

  • MFA/2FA en panel y cuentas privilegiadas,
  • separación de roles (soporte vs admin real),
  • “least privilege” en automatizaciones,
  • registros de acceso y cambios relevantes.

Además, el CRA pide registrar/monitorizar actividad interna relevante, como accesos o modificaciones, con opción de “opt-out” para el usuario.

Gestión segura de backups

El CRA no “ordena backups” literalmente, pero sí exige proteger disponibilidad de funciones esenciales, incluso después de un incidente, y hablar de resiliencia/mitigación.

En hosting, los backups suelen ser una medida práctica para cumplir ese objetivo, siempre que sean seguros:

  • copias aisladas (para resistir ransomware),
  • controles de acceso estrictos,
  • restauración verificada,
  • y, si contienen datos sensibles, cifrado y trazabilidad.

Control de accesos administrativos

Esto es donde más se mira a un proveedor de hosting, porque el “admin” lo ve todo.

El CRA encaja aquí por dos vías:

  • protección contra accesos no autorizados (PAM/gestión de accesos privilegiados, autenticación fuerte, etc.),
  • registro y monitorización de actividad relevante (quién accedió, qué cambió, cuándo).

En un WordPress gestionado, esto afecta a:

  • accesos de soporte al filesystem/BD,
  • cambios masivos (reset passwords, disable plugins),
  • despliegues y plantillas.

Responsabilidad compartida vs responsabilidad directa

En hosting siempre hay responsabilidad compartida, pero el CRA introduce un matiz importante:

  • Si el hosting solo da infraestructura y el cliente instala lo suyo, el cliente asume gran parte de la seguridad “de aplicación” (plugins, credenciales, configuración del CMS).
  • Pero si el hosting pone software como producto (panel, herramientas, instaladores, “Managed WordPress” con componentes propios), entonces el hosting pasa a tener responsabilidad directa sobre ese software: secure by default, updates, control de acceso, logging, etc.

La idea de “shared responsibility” es el marco habitual en cloud: proveedor protege la base y el cliente su configuración/datos; es útil para explicarlo en una landing sin entrar en legalismos.

CRA y desarrollo web profesional (agencias y developers)

La idea práctica del CRA para quien hace web es simple: si desarrollas y distribuyes software (por ejemplo, un plugin o un tema de WordPress, un panel, un “pack” instalable, una plataforma), tienes que trabajar con un estándar mínimo: seguro por diseño, seguro por defecto, y con mantenimiento real (parches y gestión de vulnerabilidades). (eur-lex.europa.eu)

Durante el desarrollo

Buenas prácticas “obligatorias” (en términos CRA)

El CRA exige que el producto se diseñe y desarrolle para asegurar un nivel adecuado de ciberseguridad, y que se ponga en el mercado sin vulnerabilidades conocidas explotables y con configuración segura por defecto.

En web, eso se traduce en hábitos concretos:

  • Limitar superficie de ataque: no exponer endpoints, rutas, paneles o funciones que no aporten valor.
  • Control de acceso bien hecho: autenticación y permisos claros (roles), sobre todo en admin/panel/API.
  • Cifrado cuando toca: usar TLS y proteger datos sensibles en tránsito y, si aplica, en reposo.
  • Logs útiles: registrar actividad relevante (accesos, cambios importantes) para poder investigar incidentes.

Ejemplo WordPress:

  • un plugin que añade un endpoint REST: si lo dejas público “por comodidad”, estás ampliando superficie de ataque; si además no validas permisos, estás regalando el problema.

Revisión de código

No se trata de “hacer auditorías carísimas” siempre, sino de tener un mínimo proceso que ayude a cumplir que no sales al mercado con fallos evitables.
El CRA también obliga a aplicar tests y revisiones regulares de seguridad del producto.

Ejemplos realistas:

  • revisión de cambios antes de publicar versiones (PRs, checklist básico),
  • tests automáticos (unit/integration) y algún control de seguridad (por ejemplo, linters o reglas básicas).

Uso de librerías mantenidas (y dependencias controladas)

El CRA exige identificar y documentar componentes (dependencias) y vulnerabilidades, incluyendo una SBOM (lista de componentes) al menos de dependencias principales.

En web esto pega fuerte porque:

  • plugins/temas suelen depender de librerías PHP/JS,
  • frameworks y SDKs cambian rápido,
  • y muchas vulnerabilidades entran “por debajo”, no por tu código.

Ejemplo WordPress:

  • si tu plugin mete una librería JS vieja con una vulnerabilidad conocida, el riesgo lo heredas tú.

Gestión de secretos y credenciales

El CRA pide protección frente a accesos no autorizados (autenticación y gestión de accesos).
En desarrollo web, “secretos” = claves de API, tokens, credenciales de BD, claves de firma, etc.

Buenas prácticas que encajan:

  • no hardcodear secretos en el repo,
  • rotación y revocación (si se filtran),
  • separar credenciales por entorno (dev/staging/prod),
  • mínimo privilegio (una API key no debería poder “hacer de todo”).

Durante el mantenimiento

Aquí el CRA es especialmente claro: hay que gestionar vulnerabilidades y parchear sin demora.

Monitorización de vulnerabilidades

El CRA obliga a identificar/documentar vulnerabilidades y componentes (SBOM) y, en general, a tener un proceso de gestión.

En práctica:

  • vigilar avisos de seguridad (CVE, proveedores, repositorios),
  • revisar dependencias (Composer, npm, librerías incluidas),
  • y tener un canal para que terceros reporten fallos (esto se detalla más en documentación, punto 11).

Actualizaciones continuas (parches)

El CRA exige que las vulnerabilidades se puedan resolver mediante actualizaciones de seguridad, que se distribuyan de forma segura y sin demora; y pide, cuando sea posible, separar parches de seguridad de actualizaciones “de funcionalidades”.

Ejemplo WordPress:

  • sacar una versión del plugin solo para parchear (sin meter features nuevas) ayuda a que el usuario actualice sin miedo.
  • si tu producto puede auto-actualizarse de forma segura, el CRA contempla incluso actualizaciones automáticas activadas por defecto con opción clara de desactivarlas (cuando aplique).

Respuesta ante incidentes

Además de arreglar, el CRA introduce obligaciones de notificación en casos concretos: vulnerabilidades activamente explotadas e incidentes graves que afecten a la seguridad del producto. La Comisión resume plazos: aviso inicial en 24h, notificación completa en 72h, e informe final según corresponda. (digital-strategy.ec.europa.eu)

En web, esto implica que tu operativa debería tener, como mínimo:

  • forma de detectar que “algo raro” pasa (logs/monitorización),
  • capacidad de sacar un parche rápido,
  • y un flujo interno claro de “triage” (qué es grave, a quién avisar, qué comunicar).

Plugins, themes y software reutilizable

En WordPress (y en la web en general), plugins, temas y librerías reutilizables son de lo más delicado, porque son piezas que se instalan “encima” de otra cosa y, si fallan, abren la puerta a ataques.

La pregunta clave para el CRA no es “¿es pequeño o grande?”, sino:

  1. ¿Es software (código)?
  2. ¿Lo estás poniendo a disposición en el mercado de la UE como parte de una actividad comercial (aunque sea gratis)?

Cuándo un plugin o un tema es un “producto digital” (CRA)

El CRA define “producto con elementos digitales” como un producto software o hardware y, además, sus soluciones de procesamiento remoto (si son necesarias para que funcione).
Y define “software” como código.

En WordPress, un plugin o un tema es software casi siempre. El salto a “producto CRA” ocurre cuando lo pones en el mercado:

  • “Poner en el mercado” = primera puesta a disposición en la UE.
  • “Poner a disposición en el mercado” = suministrarlo para distribución o uso en la UE en el curso de una actividad comercial, con pago o gratis.

Ejemplos típicos (WordPress):

  • Plugin en tu web con descarga / venta, o en un marketplace: normalmente sí.
  • Tema “premium” con licencia: sí.
  • Plugin gratuito, pero parte de un negocio (p. ej., freemium o “gratis para captar clientes”): puede ser sí, porque el CRA cubre actividad comercial incluso sin pago directo.

Responsabilidad del autor: cuándo pasas a ser “fabricante”

El CRA llama “fabricante” a quien desarrolla (o encarga desarrollar) y comercializa bajo su nombre o marca, con pago, monetización o gratis.

Traducción práctica:

  • Si publicas un plugin “Marca X”, tú eres el responsable principal de que cumpla (seguridad por defecto, gestión de vulnerabilidades, parches, etc.).
  • Si coges un plugin de otro y lo vendes bajo tu marca, o lo modificas “a lo grande” y lo redistribuyes, puedes acabar tratado como fabricante (esto existe como regla general para importadores/distribuidores que lo ponen bajo su marca o hacen una modificación sustancial).

Marketplaces de plugins y temas: qué papel juegan

Un marketplace normalmente actúa como distribuidor (pone un producto a disposición sin cambiar sus propiedades).
En ese rol, el CRA exige “debida diligencia” y cooperación, y si detectan vulnerabilidades deben informar al fabricante “sin demora”.

En la práctica web:

  • Un marketplace puede pedir ciertos requisitos (por ejemplo, buenas prácticas mínimas, canal de reporte de fallos, versiones firmadas, etc.).
  • Si el marketplace reempaca o vende bajo su marca, el riesgo regulatorio sube, porque podría acercarse a obligaciones de fabricante.

Distribución gratuita vs comercial (lo que suele confundir)

Regla general del CRA: si lo pones a disposición como actividad comercial, entra aunque sea gratuito.

Pero en open source hay un matiz importante (lo desarrollamos más en el punto 9):

  • La Comisión explica que solo el software libre/open source que se pone en el mercado (actividad comercial) entra en alcance, y que el software open source no monetizado por su fabricante no debería considerarse actividad comercial.
  • Y el CRA no aplica a quien solo contribuye código a un proyecto open source que no está bajo su responsabilidad.

Muchos plugins/temas actuales no son “solo PHP”: dependen de un servicio remoto (API, backend, SaaS). Aquí el CRA es muy relevante:

  • Si tu plugin necesita tu API para funcionar, esa parte remota puede considerarse “procesamiento remoto” dentro del producto, cuando sin ella el producto no puede hacer una de sus funciones.

Consecuencia práctica:

  • Ya no es solo “el ZIP del plugin”: también importa la seguridad de la API, autenticación, control de acceso, y cómo gestionas incidentes y vulnerabilidades.

Software reutilizable (librerías) y la cadena de dependencias

El CRA introduce la idea de controlar componentes y dependencias (por ejemplo, SBOM: lista de componentes/dependencias).
Y en los considerandos aclara algo muy específico: los componentes open source pensados para integrarse en otros productos se consideran “puestos a disposición en el mercado” solo si el componente está monetizado por su fabricante original.

Para plugins/temas WordPress, el mensaje práctico es:

  • cuanto más dependas de librerías externas, más necesitas saber qué llevas dentro, mantenerlo actualizado y reaccionar rápido si sale una vulnerabilidad.

Open Source y Cyber Resilience Act (en contexto web)

En open source, el CRA intenta evitar un efecto “manta” sobre quien mantiene software por hobby, pero a la vez pone foco en el open source que acaba siendo parte de productos y servicios comerciales.

Open Source no comercial

La Comisión lo resume así: solo el software libre/open source que se pone a disposición en el mercado (es decir, para distribución o uso en el curso de una actividad comercial) entra en el CRA. Y remarca que el open source no monetizado por su fabricante no debería considerarse actividad comercial.

Además, el CRA no aplica a quien solo contribuye código a un proyecto open source que no está bajo su responsabilidad.

Ejemplo WordPress (core):

  • Contribuir al core de WordPress o enviar parches a un repositorio OSS, sin “poner tú el producto en el mercado”, suele encajar en este escenario (con el matiz de “bajo tu responsabilidad”).

Open Source con servicios asociados (la trampa típica en web)

En web es muy habitual que el “open source” sea solo una parte y lo importante esté en el servicio:

  • plugin gratuito + API/SaaS de pago,
  • tema gratuito + suscripción a plantillas/bloques,
  • proyecto OSS + hosting gestionado / soporte comercial.

Aquí, aunque el código sea open source, ya hay una actividad comercial alrededor y suele ser más fácil que el CRA “entre”, porque el producto se está suministrando como parte de un negocio (aunque el ZIP sea gratis). La definición de “fabricante” incluye comercializar gratis o monetizado, no solo vendido.

Empresas que monetizan OSS

El CRA separa con bastante intención “desarrollo” y “suministro”:

  • Si tu open source está monetizado (venta, licencias, suscripciones, servicios asociados, etc.), estás más cerca de “actividad comercial”.
  • Si recibes donaciones o apoyo puntual, eso no convierte automáticamente el proyecto en comercial (el propio texto dice que el apoyo financiero o contribuciones de fabricantes no determinan por sí solos el carácter comercial).
  • En componentes OSS pensados para integrarse en productos de terceros, el CRA indica que esa “puesta a disposición en el mercado” se considera tal solo si el componente está monetizado por su fabricante original.

Ejemplo práctico (ecosistema WordPress):

  • librería OSS incluida en un plugin: la obligación “gorda” recae sobre quien pone el producto final en el mercado (el autor del plugin/empresa), no sobre cada mantenedor voluntario de dependencias, salvo que estén actuando comercialmente en el sentido del CRA.

Responsabilidades cuando se redistribuye (o se “re-empaqueta”)

Dos reglas del CRA muy útiles para casos web:

  1. “Poner a disposición en el mercado” es suministrar un producto para uso/distribución en la UE en una actividad comercial, incluso gratis.
  2. Si un importador o distribuidor lo pone bajo su nombre/marca o hace una modificación sustancial y lo vuelve a ofrecer, pasa a considerarse fabricante y asume obligaciones de fabricante.

Ejemplos típicos:

  • Un hosting que ofrece un “WordPress optimizado” propio (repack + herramientas + configuración): si va bajo su marca y hay cambios relevantes, puede acercarse a rol de fabricante respecto a ese “producto” empaquetado.
  • Una agencia que toma un plugin OSS, lo modifica para clientes y lo redistribuye como “Plugin Agencia X”: riesgo de quedar como fabricante.

La figura nueva: “open-source software steward”

El CRA introduce una categoría específica: open-source software stewards (entidades que sostienen proyectos OSS importantes, muchas veces fundaciones). La Comisión lo describe como un régimen “ligero” y adaptado.

El propio texto explica la idea: cuando el OSS es clave para la ciberseguridad y está “publicado” pero no necesariamente “puesto en el mercado”, quienes lo sostienen de forma continuada y lo hacen viable pueden entrar en este encaje.

Puntos prácticos:

  • Un steward no es un fabricante por defecto (es “otra cosa”).
  • Aun así, tiene obligaciones específicas (política de ciberseguridad, handling de vulnerabilidades, cooperación y ciertos reportes), recogidas en el artículo de obligaciones de stewards.
  • Y el texto contempla que los stewards no estén sujetos a multas administrativas por infracciones del CRA.

Casos típicos en WordPress, PHP y JS

WordPress core

  • Contribuir código al core (sin “ponerlo tú en el mercado” bajo tu responsabilidad) suele quedar fuera del CRA para el contribuidor individual.

Plugins/temas gratis “de hobby”

  • Si no hay monetización ni actividad comercial alrededor, la Comisión indica que no debería considerarse actividad comercial.

Plugins/temas “freemium” o con SaaS

  • Plugin gratis + servicio/API de pago: normalmente ya hay actividad comercial y el autor/empresa encaja mejor como fabricante (según el rol real).

Frameworks PHP/JS y librerías

  • Los mantenedores voluntarios no deberían quedar arrastrados sin más; pero si la entidad que mantiene el proyecto actúa como steward o lo monetiza, cambia el análisis.

Redistribución por hosting/agencia

  • Re-empaquetar, vender bajo tu marca o modificar sustancialmente y redistribuir puede convertirte en fabricante.

Gestión de incidentes y notificación

En el CRA, “gestionar incidentes” no es solo arreglar cosas: también incluye avisar a las autoridades (y a los usuarios) cuando pasa algo serio o cuando una vulnerabilidad ya se está explotando de verdad.

Importante: estas obligaciones de reporte empiezan a aplicar el 11 de septiembre de 2026.

Qué es un “incidente de seguridad” (en lenguaje CRA)

El CRA se apoya en definiciones claras:

  • Incidente: se remite a la definición de la Directiva NIS2.
  • Incidente que impacta en la seguridad del producto: cualquier incidente que afecta (o puede afectar) a la capacidad del producto de proteger disponibilidad, autenticidad, integridad o confidencialidad de datos o funciones.

Y cuando habla de lo “serio”:

  • Vulnerabilidad activamente explotada: hay evidencia fiable de que un actor malicioso la ha explotado en un sistema sin permiso del propietario.
  • Incidente severo (a efectos de reporte CRA): se considera severo si afecta (o puede afectar) a datos/funciones sensibles o importantes, o si ha llevado (o puede llevar) a introducir o ejecutar código malicioso en el producto o en sistemas del usuario.
    Además, el CRA pone el foco en incidentes que tocan la cadena de desarrollo/producción/mantenimiento del fabricante (por ejemplo, comprometer el canal de actualizaciones).

Plazos de notificación (lo más “operativo” del CRA)

Para vulnerabilidades activamente explotadas y incidentes severos, el CRA establece un flujo en fases:

Qué ocurrePrimer avisoNotificación completaInforme final
Vulnerabilidad activamente explotada≤ 24h≤ 72h≤ 14 días desde que hay medida correctiva/mitigadora
Incidente severo≤ 24h≤ 72h≤ 1 mes desde la notificación completa

Esto aparece tanto en el texto del Reglamento como en la guía de la Comisión.

A quién se notifica (y cómo)

Cuando eres fabricante a efectos CRA (por ejemplo: autor/empresa que distribuye un plugin/tema, una plataforma SaaS, un panel, un “Managed WordPress” con software propio), debes notificar:

  • A la CSIRT coordinadora (equipo nacional de respuesta a incidentes) y a ENISA, a la vez, usando la plataforma única de reporte (“single reporting platform”).
  • La notificación se envía normalmente al endpoint del país donde está tu “establecimiento principal” en la UE (donde se toman principalmente las decisiones de ciberseguridad del producto).

Impacto en proveedores de servicios web (hosting, SaaS, ecosistema WordPress)

En web, el efecto más claro es que obliga a tener un procedimiento de “incidente → análisis → aviso → parche → comunicación”.

Casos típicos donde un proveedor web se acerca a obligaciones CRA:

  • Plugin/tema distribuido (gratis o de pago) bajo tu marca.
  • SaaS con API imprescindible para el funcionamiento del producto.
  • Hosting gestionado que incluye software propio (panel, instaladores, herramientas, automatizaciones).

Además, el CRA exige que, al enterarte de una vulnerabilidad explotada o un incidente, informes a los usuarios afectados (y, si procede, a todos) y les des medidas claras para mitigar el impacto, incluso en formato estructurado/machine-readable cuando sea apropiado.

Ejemplos de incidentes comunes en web (y cómo “encajan” en CRA)

La clave es separar vulnerabilidad (el fallo) de incidente (el evento real).

SQL injection (SQLi)

  • Vulnerabilidad: existe un fallo que permite inyectar SQL.
  • Vulnerabilidad activamente explotada: tienes evidencia de que ya la han usado (por ejemplo, accesos a datos o consultas maliciosas reales).
  • Qué hace CRA: si está activamente explotada, entra en el circuito 24h/72h y final.

XSS

  • Igual patrón: el XSS “en abstracto” es vulnerabilidad; si hay evidencia de explotación real, es “activamente explotada”.

Credenciales expuestas (API keys, tokens, contraseñas)

  • Si provoca acceso no autorizado o riesgo real sobre datos/funciones, puede ser incidente con impacto en seguridad.
  • Si deriva en ejecución/introducción de código malicioso o afecta datos/funciones sensibles/clave, puede encajar como incidente severo.

Brechas en APIs (SaaS / plugins que dependen de API)

  • Si tu plugin de WordPress depende de tu API y esa API se compromete, el impacto puede ser directo en usuarios.
  • CRA: si el incidente afecta la capacidad de proteger disponibilidad/integridad/confidencialidad, es “incidente con impacto”; si cumple los criterios, “severo”.

Compromiso de la cadena de suministro (lo más “CRA”)

Ejemplo muy directo del texto: un atacante mete código malicioso en el canal de publicación de actualizaciones. Esto es el tipo de “incidente severo” que el CRA quiere ver reportado rápido.

Nota importante: no todo fallo se reporta “sí o sí”

El CRA distingue vulnerabilidades explotadas de hallazgos “en buen comportamiento”. El propio texto indica que vulnerabilidades descubiertas sin intención maliciosa (investigación, test, corrección responsable) no deberían estar sujetas a notificación obligatoria como “activamente explotadas”.

Documentación y trazabilidad exigida

En el CRA, “cumplir” no es solo hacer las cosas bien: también es poder demostrarlo con documentación. Para un negocio web (hosting, SaaS, plugins, temas, paneles…), esto se traduce en tener papeles, registros y procesos que puedas enseñar si te los piden.

Qué documentación hay que mantener

Documentación técnica (“technical documentation”)

El Reglamento exige preparar una documentación técnica que explique cómo cumples los requisitos de ciberseguridad y qué procesos usas para conseguirlo. Debe existir antes de poner el producto en el mercado y mantenerse actualizada durante el periodo de soporte.

Además, debe incluir (como mínimo) lo que marca el Anexo VII.

En un producto web, típicamente incluye:

  • descripción del producto (por ejemplo, “plugin de WordPress para X”, “panel de hosting”, “SaaS de reservas”),
  • cómo se diseña y desarrolla (arquitectura a alto nivel),
  • evaluación de riesgos de ciberseguridad (y por qué aplicas unas medidas u otras),
  • cómo gestionas actualizaciones y vulnerabilidades (ver siguiente punto).

Documentación de gestión de vulnerabilidades (muy importante)

El CRA obliga a tener políticas y procedimientos para procesar y corregir vulnerabilidades, incluyendo política de divulgación coordinada (CVD).

Y, dentro de la documentación técnica, se mencionan elementos muy concretos como:

  • el SBOM (lista de componentes/dependencias),
  • la política de CVD,
  • un contacto para reportar vulnerabilidades,
  • y cómo distribuyes actualizaciones de forma segura.

Ejemplo WordPress:

  • si mantienes un plugin, deberías poder decir “qué dependencias lleva”, “dónde reportar fallos”, y “cómo publicas parches”.

SBOM (lista de dependencias)

El CRA define el SBOM y lo exige como parte del control de componentes: al menos dependencias “top-level” en un formato habitual y legible por máquinas.
No significa “publicarlo siempre”: las autoridades pueden pedirlo para comprobar cumplimiento.

Declaración UE de conformidad y trazabilidad tipo “CE”

El enfoque CRA va ligado al modelo de conformidad: documentación técnica + evaluación de conformidad + declaración UE de conformidad (y CE). La Comisión lo resume de forma práctica para fabricantes.

Evidencias de cumplimiento (lo que conviene poder enseñar)

Piensa en “pruebas” de que lo anterior no es teoría:

  • Resultados de pruebas relevantes (tests, revisiones de seguridad, evidencias de que aplicas medidas).
  • Registro de decisiones: por qué una medida aplica o no aplica (por ejemplo, “esta función no existe, así que este requisito no aplica”).
  • Evidencia del proceso de updates: cómo publicas actualizaciones y cómo aseguras su distribución.

Historial de cambios y parches

El CRA no te pide “release notes bonitas”, pero sí exige trazabilidad y actualización continua de la documentación técnica durante el soporte.

En web, lo sensato es mantener:

  • historial de versiones (qué cambió y cuándo),
  • parches de seguridad separados cuando sea posible,
  • referencias internas a incidencias/vulnerabilidades corregidas.

Ejemplo WordPress:

  • changelog del plugin + notas específicas de seguridad cuando hay fix crítico.

Registro de vulnerabilidades

A nivel operativo, necesitas un registro mínimo:

  • fecha de descubrimiento/reporte,
  • severidad e impacto,
  • si está explotada o no,
  • solución (parche/mitigación) y fechas,
  • comunicación a usuarios (si aplica).

Esto encaja con la obligación de tener procesos de vulnerabilidades (CVD) y de poder demostrarlos.

Cuánto tiempo hay que guardarlo

El Reglamento indica que hay que conservar la documentación técnica y la declaración UE de conformidad a disposición de las autoridades al menos 10 años desde que el producto se puso en el mercado o durante el periodo de soporte, lo que sea más largo.

Contratos con terceros (cómo encaja en la práctica)

El CRA pone la responsabilidad de cumplimiento en quien actúa como “fabricante” del producto, aunque subcontrate partes. Por eso, si dependes de terceros (desarrollo, mantenimiento, SOC, proveedores de librerías/SDK, etc.), los contratos deberían ayudarte a poder cumplir con:

  • tiempos de parcheo,
  • canal y tiempos de aviso de vulnerabilidades,
  • soporte para SBOM/dependencias,
  • acceso a evidencias (logs, pruebas, auditorías),
  • obligaciones de notificación/coordinarse en incidentes.

Sanciones y riesgos legales

El CRA no se queda en “recomendaciones”: si un producto software no cumple, puede haber multas, medidas para retirarlo del mercado y efectos legales/contractuales.

Multas económicas (administrativas)

El Reglamento fija tres niveles máximos (según el tipo de incumplimiento), por cada Estado miembro que aplique sanciones en su ámbito:

  • Hasta 15.000.000 € o el 2,5% del volumen de negocio anual mundial (lo que sea mayor): incumplir requisitos esenciales de ciberseguridad y obligaciones “núcleo” del CRA.
  • Hasta 10.000.000 € o el 2%: incumplir otras obligaciones del Reglamento.
  • Hasta 5.000.000 € o el 1%: información falsa/engañosa o no facilitar la información requerida a las autoridades.

Traducción a web: un “producto” puede ser un plugin/tema, un panel, un instalador, un SaaS con API imprescindible, etc.

Retirada de productos y otras medidas

Además de multar, las autoridades de vigilancia de mercado pueden exigir medidas correctivas: que soluciones el incumplimiento, que dejes de distribuir el producto, o incluso retirada/recall.

En el mundo web esto suele verse como:

  • bloquear una versión insegura (por ejemplo, un plugin/tema),
  • obligar a publicar parches,
  • o impedir que se “ponga en el mercado” (que se distribuya) hasta que cumpla.

Responsabilidad civil (y contractual)

El CRA marca el marco “de producto y mercado”. Si hay un daño (caída de servicio, fuga de datos, fraude, etc.), pueden aparecer además:

  • reclamaciones contractuales (SLA, condiciones con clientes, indemnizaciones),
  • y responsabilidad civil según el derecho nacional aplicable.

El CRA no sustituye esas vías: se suma. (Aquí, en empresas web, el contrato y el seguro suelen ser tan importantes como la parte técnica).

Daño reputacional (el golpe más rápido)

En software web, muchas veces lo que más duele no es la multa:

  • pérdida de confianza,
  • churn (clientes que se van),
  • caída de ventas del plugin/tema/SaaS,
  • retirada de marketplaces o bloqueos preventivos.

Y, si además hay que notificar incidentes o vulnerabilidades explotadas, el impacto público puede ser inmediato.

Ejemplos aplicables a software web

Ejemplo A: plugin de WordPress con SQLi explotada

  • Se descubre que están explotando una SQL injection y el autor tarda en parchear o no tiene proceso.
  • Riesgo: incumplimiento de obligaciones de gestión de vulnerabilidades y actualizaciones; además, si aplica, obligaciones de notificación por vulnerabilidad explotada/incidente severo.

Ejemplo B: SaaS con brecha en API

  • La API permite acceder a datos de otros clientes (fallo de autorización).
  • Riesgo: incidente que afecta confidencialidad/integridad; si es severo o explotado, entra el circuito de reporte.

Ejemplo C: hosting con panel propio vulnerable

  • Un fallo en el panel permite tomar control de cuentas o desplegar código malicioso.
  • Riesgo: además de multas potenciales, la autoridad puede exigir medidas y restringir disponibilidad/puesta en el mercado del software afectado si no se corrige.

Cómo prepararse para el Cyber Resilience Act

La forma más práctica de prepararse es asumir que el CRA te va a pedir dos cosas: hacer seguridad de forma sistemática y poder demostrarlo (con procesos y documentación). Además, hay un calendario claro: las obligaciones de reporte aplican desde el 11 de septiembre de 2026 y el resto de obligaciones principales desde el 11 de diciembre de 2027.

Checklist inicial para webs y hosting

Paso 1: Define si “estás dentro” y con qué rol

  • ¿Tienes un “producto” software? (plugin/tema, panel, instalador, SaaS, pack de WordPress gestionado).
  • ¿Lo distribuyes/ofreces en la UE como actividad comercial (aunque sea gratis)?
  • ¿Actúas como fabricante (lo ofreces bajo tu marca) o como distribuidor? (Esto cambia responsabilidades).

Paso 2: Haz inventario de lo que realmente mantienes

  • Lista de productos y versiones (ej.: plugin X, theme Y, panel Z).
  • Qué depende de qué (APIs, servicios externos, librerías PHP/JS).
  • En hosting: qué software “propio” incluye el servicio (panel, scripts, automatizaciones).

Paso 3: Define el “periodo de soporte” que vas a dar

  • Qué productos vas a mantener, cuánto tiempo y con qué política de parches.
  • Objetivo: que nadie en tu empresa tenga que improvisar “¿esto lo seguimos soportando?”.

Paso 4: Asegura un canal de seguridad

  • Un email o formulario tipo security@ o página de “Security” para reportar vulnerabilidades.
  • Un proceso interno mínimo para recibir, priorizar y corregir.

Auditoría de seguridad básica (sin volverse loco)

Una auditoría “base” para un producto web suele incluir:

  • Accesos
    • ¿Quién puede entrar al panel/admin?
    • ¿Hay MFA/2FA para cuentas privilegiadas?
    • ¿Hay roles y permisos claros?
  • Superficie de ataque
    • ¿Hay endpoints/API que no se usan?
    • ¿Admin expuesto innecesariamente?
    • ¿Plugins/temas que sobran en WordPress?
  • Datos
    • TLS activo y correcto.
    • Datos sensibles protegidos (y logs sin secretos).
  • Logs y detección
    • Registro de accesos, cambios relevantes y errores de seguridad.
    • Alertas básicas (picos de logins, errores 403/401, cambios de archivos, etc.).
  • Backups (hosting / managed)
    • Copias aisladas, restauración probada, accesos controlados.

Revisión del stack tecnológico (lo que más suele fallar)

Dependencias

  • Haz una lista de dependencias principales (PHP/Composer, JS/npm, librerías incluidas “a mano”).
  • Revisa si hay dependencias abandonadas o con historial de vulnerabilidades.
  • En WordPress: revisa plugins “imprescindibles” vs “comodidad”.

Componentes de terceros

  • SDKs, servicios de login, pasarelas de pago, analítica, CDNs, etc.
  • Decide qué haces si un tercero tiene un incidente (y cómo te enteras).

Plan de actualización (parches sin drama)

Un plan realista suele tener:

  • Cadencia
    • Ventana regular de mantenimiento (semanal/quincenal) para updates normales.
    • Fast-track para seguridad (horas/días, no “cuando pueda”).
  • Separación
    • Siempre que puedas, parches de seguridad separados de cambios funcionales (reduce miedo a actualizar).
  • Distribución segura
    • Firma/verificación de artefactos cuando aplique.
    • Control del pipeline (CI/CD) para evitar “supply chain” (actualización maliciosa).

Ejemplo WordPress (plugin):

  • Mantén changelog claro.
  • Publica un fix de seguridad como versión pequeña y rápida.
  • Evita meter features nuevas en el mismo release del parche.

Formación interna (lo mínimo que marca la diferencia)

No necesitas “todos expertos”, pero sí un estándar común:

  • Para desarrollo:
    • validación de entradas (SQLi/XSS),
    • control de permisos,
    • gestión de secretos (nunca en repos).
  • Para operaciones/hosting:
    • gestión de accesos privilegiados,
    • hardening básico,
    • respuesta a incidentes y preservación de evidencias.
  • Para producto/negocio:
    • qué es “vulnerabilidad explotada” y qué se reporta,
    • cómo comunicar a clientes sin improvisar.

Y un punto práctico: prepara desde ya el flujo de notificación (quién decide, quién redacta, qué datos se incluyen) para llegar a septiembre de 2026 con músculo, porque los plazos son cortos (24h/72h).

CRA vs otras normativas (GDPR, NIS2)

En el mundo web es normal que se mezclen, porque un mismo problema (por ejemplo, una vulnerabilidad en un plugin o una brecha en una API) puede activar varias obligaciones a la vez. La clave es entender qué regula cada norma.

Diferencias con GDPR (protección de datos)

GDPR (RGPD) va de datos personales: cuándo los puedes tratar, cómo los proteges y qué haces si hay una brecha de datos personales.

  • Si ocurre una brecha de datos personales, el responsable del tratamiento debe notificar a la autoridad de control en un máximo de 72 horas desde que es consciente (salvo que sea improbable que haya riesgo para las personas).
  • El GDPR no te pide “hacer software seguro como producto”, sino asegurar medidas técnicas y organizativas para proteger los datos y gestionar incidentes de datos.

CRA, en cambio, va de ciberseguridad del producto software (por ejemplo, un plugin/tema, un panel, un SaaS, una plataforma): que salga seguro por diseño y por defecto, que tenga gestión de vulnerabilidades, parches, y obligaciones de reporte cuando toca.

Ejemplo web claro

  • Vulnerabilidad XSS en un plugin de WordPress:
    • CRA: te preocupa aunque aún no haya fuga de datos, porque es un fallo del producto y puede estar siendo explotado.
    • GDPR: solo entra con fuerza si esa XSS acaba en brecha de datos personales (acceso/filtración de datos de usuarios, por ejemplo).

Relación con NIS2 (seguridad y notificación para entidades)

NIS2 es una Directiva orientada a organizaciones/entidades (no a productos) y a su gestión de riesgos e incidentes en sectores “esenciales” o “importantes”. Incluye obligaciones de notificación de incidentes significativos.

NIS2 define un esquema de notificación típico:

  • aviso temprano en 24 horas,
  • notificación en 72 horas,
  • informe final en un mes.

CRA también usa tiempos cortos para reportar, pero el foco es distinto: reporta vulnerabilidades activamente explotadas y incidentes severos que afecten a la seguridad del producto, y lo hace hacia ENISA y el CSIRT coordinador mediante la plataforma de reporte.

Ejemplo web

  • Un proveedor de hosting o SaaS puede:
    • estar bajo NIS2 como entidad (dependiendo del tipo/tamaño/sector),
    • y además estar bajo CRA como fabricante de un panel o software que distribuye.

Por qué el CRA va más allá de la protección de datos

Porque el CRA no se limita a “si hay datos personales”. Se centra en seguridad del software como producto:

  • Una vulnerabilidad que permite ejecutar código malicioso, crear una botnet, tumbar servicios o comprometer un canal de actualizaciones puede ser gravísima aunque no haya datos personales implicados.
  • Por eso el CRA introduce obligaciones de diseño, mantenimiento, parches y (en casos concretos) reporte a ENISA/CSIRT, aunque no exista “brecha de datos” en sentido GDPR.

Complementariedad (cómo conviven en la práctica)

En una empresa web, lo normal es que convivan así:

  • CRA: “Nuestro plugin/panel/SaaS es un producto; debemos mantenerlo seguro, parchear y tener procesos/documentación.”
  • GDPR: “Tratamos datos personales; si hay brecha de datos personales, notificamos a la autoridad y, si procede, a los afectados.”
  • NIS2: “Si somos entidad cubierta, tenemos obligaciones de gestión de riesgos y notificación de incidentes significativos a CSIRT/autoridad.”

Caso típico de solapamiento
Una brecha en una API de un SaaS que expone datos de clientes:

  • CRA puede aplicar por ser un incidente severo o una vulnerabilidad explotada del producto.
  • GDPR aplica por brecha de datos personales (72h).
  • NIS2 puede aplicar si la empresa entra como entidad cubierta (24h/72h/1 mes).

Conclusión: el CRA como oportunidad para el sector web

El CRA es un cambio de enfoque: la seguridad deja de ser “un extra” y pasa a ser un requisito de producto para el software que se pone en el mercado de la UE.
Visto así, no es solo una obligación legal: es una oportunidad para que el sector web suba el nivel.

Cumplir el CRA significa tener:

  • seguridad por diseño y por defecto,
  • gestión real de vulnerabilidades,
  • parches y soporte durante un periodo definido,
  • y capacidad de responder y reportar incidentes cuando corresponda.

Esto, en la práctica, reduce:

  • “incendios” continuos,
  • actualizaciones por pánico,
  • y dependencias sin control.

Ventaja competitiva

En un mercado donde muchos proveedores se parecen, “cumplimos CRA de forma seria” se puede convertir en:

  • argumento comercial (B2B especialmente),
  • diferenciador frente a competidores “baratos” pero inseguros,
  • y requisito para entrar en clientes exigentes (empresas, sector público, etc.).

En plugins y SaaS, también puede significar:

  • menos devoluciones/cancelaciones por incidentes,
  • menos tickets de soporte por compromisos de seguridad,
  • mejor reputación en marketplaces.

Mejora de calidad y confianza

El CRA empuja a prácticas que mejoran el producto incluso aunque no existiera la norma:

  • menos superficie de ataque,
  • mejores controles de acceso,
  • actualizaciones más limpias,
  • y transparencia razonable en seguridad.

En ecosistemas como WordPress, donde un plugin vulnerable puede afectar a miles de webs, profesionalizar parches y comunicación aumenta la confianza de usuarios y empresas.

Profesionalización del desarrollo web y hosting

Para agencias, autores de plugins/temas, SaaS y hosting, el CRA empuja a estandarizar:

  • procesos (revisiones, releases, soporte),
  • documentación y trazabilidad,
  • y respuesta a incidentes.

Eso eleva el listón del sector: menos “proyectos que dependen de una persona”, más productos mantenibles, y equipos que funcionan con método.

FAQ orientada a webs, agencias y hosting

¿Afecta a WordPress?

Depende de cómo se use y quién lo “ponga en el mercado”:

  • WordPress como proyecto open source, publicado y sin que un “fabricante” lo monetice directamente: la Comisión explica que el CRA solo cubre el software libre/open source si se pone en el mercado como parte de una actividad comercial, y que el software open source no monetizado por su fabricante no debería considerarse actividad comercial.
  • Si tú (empresa) distribuyes WordPress como parte de un producto/servicio comercial (por ejemplo, un “WordPress empaquetado” con componentes propios, o un SaaS basado en WordPress, o una distribución con tu marca): ahí ya estás en terreno de “poner software en el mercado” y puede entrar en CRA.

Idea práctica: WordPress “core” no te convierte automáticamente en sujeto CRA; tu modelo de negocio alrededor sí puede hacerlo.

¿Afecta a una web corporativa?

En muchos casos, no.

El propio texto del CRA aclara que “websites that do not support the functionality of a product with digital elements” quedan fuera de su alcance.

Pero ojo: si esa “web” en realidad es una aplicación web (por ejemplo, un portal de clientes, un CRM web, un LMS, una plataforma con login y funciones) que se ofrece a terceros como servicio/solución, ya no es una web informativa: es software y puede encajar en el marco del CRA.

¿Afecta a un plugin gratuito?

Otra vez: depende de si hay actividad comercial alrededor.

  • Si el plugin se publica como open source sin actividad comercial / sin monetización por el “fabricante”, el enfoque de la Comisión es que no debería considerarse que entra por CRA (por no ser “comercial”).
  • Si el plugin “gratuito” es parte de un negocio (freemium, upsells, soporte de pago, versión Pro, bundling con hosting, distribución bajo marca, etc.), es más fácil que se entienda como software “puesto en el mercado” dentro de una actividad comercial.

Regla mental para WordPress: gratis no siempre significa fuera de CRA; lo que manda es la comercialidad y quién asume la responsabilidad del producto.

¿Quién es responsable: el hosting, la agencia o el desarrollador?

No es “uno u otro” por defecto: depende de quién actúa como “fabricante” o como quien pone el software en el mercado.

  • Autor del plugin/tema/SaaS: normalmente es el más parecido al “fabricante” del software (quien lo desarrolla y lo ofrece).
  • Agencia:
    • si desarrolla una web a medida y la entrega solo a un cliente, la responsabilidad CRA puede variar según si eso se considera “poner en el mercado” (y cómo se distribuya).
    • si la agencia vende un producto repetible (plantillas propias, plugins propios, un “pack” de WordPress), se parece más a “fabricante”.
  • Hosting:
    • no es automáticamente responsable por el software del cliente.
    • pero si el hosting distribuye software bajo su marca (por ejemplo, un panel propio, un plugin propio, una imagen “WordPress gestionado” con componentes propios) puede asumir obligaciones como fabricante o incluso como “fabricante” por re-etiquetado/puesta en mercado bajo su nombre. (EUR-Lex)

Resumen útil: quien controla el producto que se entrega al mercado (y su ciclo de parches/soporte) suele ser quien carga con más responsabilidad CRA.

¿Cuál es la responsabilidad del desarrollador?

Depende de si el desarrollador solo programa o si además pone el software en el mercado (lo distribuye/ofrece en la UE como actividad comercial, incluso gratis). El CRA define “fabricante” como quien desarrolla (o encarga desarrollar) y comercializa bajo su nombre o marca, con pago, monetización o gratis.

Si el desarrollador actúa como fabricante (típico: autor de plugin/tema, SaaS, panel, “pack” instalable), su responsabilidad principal es:

  • Diseñar y desarrollar el producto cumpliendo requisitos de ciberseguridad.
  • Tener gestión de vulnerabilidades y parches durante el periodo de soporte (mínimo 5 años, salvo que el producto se espere usar menos tiempo).
  • Mantener políticas y procedimientos (incluida divulgación coordinada de vulnerabilidades) y documentación asociada.

Ejemplo WordPress: si publicas un plugin bajo tu marca (en tu web o marketplace), lo normal es que estés en el rol “fabricante”.

¿Cuál es la responsabilidad de la agencia?

Una agencia puede estar en tres escenarios típicos:

  1. Web a medida para un único cliente (sin “producto” redistribuido)
    Muchas veces no encaja como “poner un producto en el mercado” (depende del modelo de entrega), pero si la agencia sí distribuye componentes propios reutilizables (plugins/temas/plantillas) ya se parece a fabricante.
  2. Agencia que vende un producto repetible (tema, plugin, framework propio, “kit” instalable)
    Aquí suele actuar como fabricante (porque lo comercializa bajo su marca).
  3. Agencia que modifica “de forma sustancial” y redistribuye
    Si la agencia hace una modificación sustancial a un producto ya en el mercado y lo vuelve a poner disponible, el CRA dice que pasa a ser considerada fabricante para lo afectado (o para todo, si impacta globalmente).

Ejemplo WordPress: si la agencia coge un plugin OSS, lo “re-empaqueta” con cambios importantes y lo distribuye como “Plugin Agencia X”, puede acabar con obligaciones de fabricante.

¿Cuál es la responsabilidad del que hace los mantenimientos?

El CRA pone el peso en quien es fabricante del producto. Si tú haces mantenimiento (updates, hardening, monitorización) de una web o un WordPress ya desplegado, normalmente:

  • No te convierte automáticamente en “fabricante” del producto.
  • Pero tu trabajo suele ser clave para que el fabricante/cliente cumpla (parches a tiempo, gestión de vulnerabilidades, evidencias).

Hay dos puntos donde el mantenimiento puede “cambiar de rol”:

  • Si el mantenimiento incluye una modificación sustancial y además se hace disponible en el mercado (por ejemplo, conviertes esa web en un producto que vendes/redistribuyes), el CRA dice que quien hace esa modificación y lo pone disponible pasa a ser fabricante.
  • Si el “mantenedor” en realidad distribuye software (por ejemplo, publica el plugin/tema que mantiene bajo su marca), vuelve a entrar la lógica de fabricante.

¿Cuál es la responsabilidad del hosting?

Depende de si el hosting solo da infraestructura o si además distribuye software.

1) Hosting “solo infraestructura”
Normalmente no es fabricante del WordPress del cliente. Aun así, puede tener obligaciones por otras normas (contratos, GDPR, NIS2 si aplica), pero eso es otra capa.

2) Hosting que distribuye software bajo su marca (panel propio, instalador propio, herramientas propias, “Managed WordPress” con componentes propios)
Aquí el hosting sí puede ser fabricante de ese software (lo comercializa bajo su marca).

3) Hosting que “re-empaqueta” o modifica sustancialmente software y lo redistribuye
Si lo pone en el mercado bajo su marca o hace una modificación sustancial, el CRA indica que puede pasar a ser considerado fabricante.

4) Hosting que actúa como distribuidor de productos de terceros (por ejemplo, ofrece plugins/temas/paneles de terceros como parte del servicio)
El CRA define “distribuidor” como quien hace disponible un producto en el mercado sin afectar sus propiedades, y exige “debida diligencia”: no distribuir si cree que no cumple, e informar al fabricante si detecta vulnerabilidades, entre otras obligaciones.

¿Cuándo entra en vigor?

Fechas clave (con días concretos):

  • Entrada en vigor: 20 días tras su publicación en el DOUE; en la práctica, el CRA ya está en vigor desde diciembre de 2024.
  • Aplicación general (la “gran fecha”): 11 de diciembre de 2027.
  • Obligaciones de notificación (vulnerabilidades explotadas e incidentes severos): 11 de septiembre de 2026.
  • Conformidad / organismos de evaluación (capítulo IV): 11 de junio de 2026.

Enlaces de interés