Hoy se aplican las obligaciones de notificación del CRA: qué hace un proveedor de plugins

Hoy es 11 de septiembre de 2026, y con esta fecha se aplica el artículo 14 del Cyber Resilience Act. Su título oficial es obligaciones de notificación del fabricante. Que se aplique justo desde hoy está en el artículo 71 del Reglamento (UE) 2024/2847.

Sobre el CRA se ha escrito mucho, y casi todo a la misma altura: hay una obligación de notificar, hay plazos, prepárate a tiempo. Falta la parte que cuenta cuando llega de verdad un correo en el que alguien describe un fallo explotado en tu plugin. Qué organismo, qué plazo desde qué momento, y qué anotas en las horas siguientes.

Eso es lo que viene aquí. Es una lectura del estado de la investigación a 21 de agosto de 2026 y no es asesoramiento jurídico. Donde un dato era incierto, se dice.

A quién se refiere esto en realidad

Dos definiciones sostienen todo el asunto. Un producto con elementos digitales es, según el artículo 3 número 1, un producto de software o hardware junto con su tratamiento de datos a distancia, incluidos de forma expresa los componentes que se introducen en el mercado por separado. Un plugin que se distribuye por su cuenta encaja en esa redacción. Fabricante es, según el artículo 3 número 13, quien desarrolla esos productos o los manda desarrollar y los comercializa con nombre o marca propios, sea a cambio de pago, de monetización o de forma gratuita. También un plugin gratuito que está en el directorio con tu nombre te convierte en fabricante según la letra del texto.

La parte honesta: esa lectura se sostiene bien sobre las definiciones primarias, pero hasta hoy no hay ninguna declaración de una autoridad ni de la Comisión que mencione los plugins de WordPress de forma expresa.

Tres fechas, y solo una es hoy

El CRA llega por etapas, y ahí está la confusión más frecuente en las conversaciones sobre él. El artículo 71 nombra tres fechas:

• 11 de junio de 2026: se aplica el capítulo IV, las normas sobre los organismos notificados. Para un proveedor de plugins sin evaluación de la conformidad no cambia nada.
• 11 de septiembre de 2026: se aplica el artículo 14, las obligaciones de notificación. Es hoy.
• 11 de diciembre de 2027: se aplica el resto del reglamento. Ahí entran el marcado CE, la documentación técnica, la evaluación de la conformidad y la lista de materiales de software del anexo I parte II.

Lo que empieza hoy es la obligación de notificar cuando pasa algo. Lo que empieza en 2027 es la obligación de demostrar de forma permanente cómo desarrollas. Quien compra hoy herramientas de SBOM está comprando para dentro de dos años.

Dos vías de notificación con plazos separados

La fórmula de 24 horas, 72 horas y 14 días aparece en casi todos los artículos de resumen. Describe exactamente uno de los dos casos que regula el artículo 14. El segundo caso comparte las dos primeras etapas y termina en un plazo distinto.

Vía 1: vulnerabilidad explotada de forma activa

Vía 2: incidente grave de seguridad

Hay dos cosas que la fórmula corta se deja fuera. La primera: en el incidente el informe final vence al mes, y no a los 14 días. La autoridad alemana BSI cita ese plazo de un mes en sus propias páginas. La segunda: los plazos no arrancan todos en el mismo sitio. Las 24 y las 72 horas corren desde el momento en que tienes conocimiento, los 14 días corren desde el momento en que hay una medida correctora disponible, y el mes corre desde el momento en que presentaste la notificación de las 72 horas.

En la práctica esto significa que el informe final de la vía de la vulnerabilidad puede vencer semanas después de la alerta temprana. Su entrada en el calendario nace cuando está el fix.

Qué activa la obligación y qué no

Una vulnerabilidad explotada de forma activa presupone indicios sólidos de que un atacante la está explotando de verdad. Un incidente grave de seguridad es un suceso que afecta o puede afectar de forma negativa a la capacidad del producto para proteger la disponibilidad, la autenticidad, la integridad o la confidencialidad de los datos.

Un fallo corriente no activa ninguna notificación, y un update de rutina tampoco. Un agujero que te comunica un investigador de seguridad y que nadie explota va por la vía normal de corrección. Quien recibe indicios de una explotación en curso y se lo piensa tres días ya ha perdido el primer plazo. Esa distinción es la primera pregunta que respondes cuando pasa algo.

La segunda obligación, la que suele quedar tapada

El artículo 14 apartado 8 obliga al fabricante a informar a los usuarios del producto sobre la vulnerabilidad o el incidente y, cuando proceda, sobre las medidas que pueden adoptar ellos mismos, en formato legible por máquina cuando sea necesario.

Es una obligación propia, al lado de la notificación a las autoridades, y para un proveedor de plugins es la parte más visible del reglamento, porque la ve cada cliente. Sin preparación, esta es la parte que falla antes: si repartes tu plugin gratis por wordpress.org, no conoces a tus usuarios. Tienes el canal de updates, las notas de versión y el readme. Quien deja los updates sin instalar tampoco recibe la información aunque la envíes bien, y ahí empieza otro asunto, el de actualizar los plugins de WordPress.

Adónde va la notificación, y por qué eso hoy todavía chirría

Se notifica a la vez al CSIRT coordinador y a ENISA, a través de la plataforma única de notificación del artículo 16, la Single Reporting Platform. El CSIRT que recibe reparte la notificación a los CSIRT de los demás Estados miembros donde se distribuye tu producto.

Eso dice el reglamento. El estado real a 21 de agosto de 2026 era este:

• La plataforma no era accesible al público. ENISA lo formulaba en futuro: a partir del 11 de septiembre de 2026 la usarán los CSIRT y los fabricantes para las notificaciones obligatorias.
• No había enlace público de registro. La dirección productiva de la plataforma seguía sin publicarse.
• Sí había documentos guía de ENISA para el registro y para presentar notificaciones, actualizados por última vez en julio y agosto de 2026, y una dirección de soporte: cra-srp-helpdesk@enisa.europa.eu.
• Según esas guías, el acceso va por EU Login. En el primer acceso se piden el rol, el CSIRT competente, un acuerdo jurídico y los datos del fabricante.

Una actualización de ENISA del 3 de agosto de 2026 quita algo de presión. La validación de tu cuenta por el CSIRT coordinador no es requisito para tener cumplida la obligación de notificar; corre en paralelo, así que una cuenta todavía sin liberar no te pone por sí sola en infracción. El reenvío a los CSIRT de otros Estados miembros se hace a mano. Y ENISA recomienda crear la cuenta de EU Login por adelantado y dejar el registro en la plataforma para cuando tengas una notificación concreta. Estos puntos vienen de una fuente secundaria, los documentos guía de ENISA no eran de acceso libre.

La parte nacional: a qué organismo notificas

Se notifica al CSIRT del Estado miembro donde tienes tu establecimiento principal. Cuál es ese organismo cambia de un país a otro, porque lo designa cada Estado miembro. Averigua cuál te corresponde antes de necesitarlo y anótalo al lado de tu dirección de seguridad.

Alemania sirve de ejemplo, porque allí la designación ya está publicada: el BSI con CERT-Bund. El BSI confirma en sus propias páginas la escala de plazos, incluido el informe final al mes, y remite a ENISA para la plataforma. La ley alemana de aplicación todavía no estaba en vigor el 21 de agosto de 2026. El proyecto figura como documento del Bundestag 21/6134 de 26 de mayo de 2026, primera lectura el 11 de junio de 2026, después traslado a la comisión de interior, sin objeciones del Bundesrat. No crea obligaciones nuevas, reparte competencias. En otros Estados miembros la aplicación nacional lleva su propio calendario.

La comparación con el AI Act es reveladora. Allí la ley alemana de aplicación está en vigor desde el 29 de julio de 2026. En el CRA sigue en trámite, mientras el reglamento se aplica hoy de forma directa. Un reglamento no espera a la ley nacional que lo acompaña, y eso vale en cualquier Estado miembro donde estés establecido.

Lo que cuesta la notificación que no se hace

El artículo 64 apartado 2 prevé, para las infracciones de los requisitos esenciales del anexo I y de las obligaciones de los artículos 13 y 14, multas de hasta 15.000.000 de euros o, en el caso de las empresas, de hasta el 2,5 por ciento del volumen de negocios anual mundial total del ejercicio anterior, según cuál de los dos importes sea mayor. Esa última frase se cae a menudo, y al caerse le da la vuelta al sentido. No es una opción para pagar menos.

Para situarlo: el artículo 64 apartado 3 prevé hasta 10.000.000 de euros o el 2 por ciento para otras obligaciones, y el apartado 4 hasta 5.000.000 de euros o el 1 por ciento por dar información incorrecta, incompleta o engañosa a organismos notificados y a autoridades de vigilancia del mercado.

Y luego está el artículo 64 apartado 10, con una excepción que casi nadie cita. Las multas no se aplican a los fabricantes que sean microempresas o pequeñas empresas en lo que toca al incumplimiento del plazo del artículo 14 apartado 2 letra a o del artículo 14 apartado 4 letra a. Son las dos alertas tempranas de 24 horas. También quedan fuera de las multas de esa disposición los administradores de software libre, los open-source software stewards.

La excepción es estrecha y se lee demasiado ancha con frecuencia. Alcanza al plazo de la alerta temprana. No libera de la obligación de notificar, no cubre la notificación de las 72 horas y no cubre el informe final. Un proveedor pequeño que simplemente no notifica está en el mismo marco sancionador que uno grande.

Las primeras 24 horas, en la práctica

Lo que sigue es una plantilla de trabajo y no la reproducción de un formulario legal. El reglamento nombra plazos y destinatarios. Qué campos pide de verdad el formulario de la plataforma no era consultable en público el 21 de agosto de 2026. Aquí está lo que de todos modos tienes que reunir para notificar.

Hora cero. Llega el aviso, por correo a tu dirección de seguridad, por el foro de soporte o por una plataforma de divulgación. Anota fecha y hora al minuto. Ahí empieza el plazo, y es el dato que después ya no puedes reconstruir.

Primera hora. Una persona decide qué vía. ¿Hay indicios de explotación real, entradas de log, instalaciones comprometidas, un exploit público? Entonces vía 1. ¿Ha pasado algo que rompe la función protectora del producto, un update manipulado o una entrada en tu infraestructura de compilación? Entonces vía 2. Las dos a la vez son posibles, y en caso de duda vale la vía más estricta. La decisión se anota por escrito.

Hasta la hora cuatro. Determinar el alcance: qué producto, qué versiones, desde cuándo, qué configuración está afectada, si hay una medida paliativa sin necesidad de update. En paralelo, mantener el contacto con quien avisó para que no publique mientras tanto.

Hasta la hora 24. Presentar la alerta temprana. Se llama alerta temprana y no análisis, y puede contener puntos abiertos.

Qué necesitas para la alerta temprana

• Nombre del producto, versiones afectadas, datos del fabricante.
• Momento y fuente de tu conocimiento.
• Descripción breve de lo ocurrido y de qué deduces que hay explotación.
• Primera valoración del impacto y de cuánta difusión tienen las versiones afectadas.
• Los Estados miembros donde el producto está disponible. En un plugin del directorio abierto, toda la Unión.
• Qué está ya en marcha y para cuándo esperas una corrección.

Qué va en tu propio registro

El registro es la mitad menos vistosa y más útil del trabajo. Es lo que después responde a la pregunta de si cumpliste los plazos. Basta un archivo de texto en el repositorio, mientras alguien lo lleve.

• Momento y fuente del conocimiento.
• La decisión sobre la vía, con dos frases de motivo.
• Momento de la alerta temprana, de la notificación de las 72 horas y del informe final, cada uno con su destinatario.
• Momento desde el que hubo una medida correctora disponible. Desde ahí cuentas los 14 días en la vía de la vulnerabilidad.
• La versión del aviso a clientes tal como salió, y cuándo.
• Versiones afectadas y versión que lleva la corrección.

Cómo es el aviso a clientes

Corto, objetivo, sin paños calientes. Nombrar las versiones afectadas, decir qué debe hacer ahora un usuario, decir a partir de qué versión está resuelto. Si hay una medida provisional, va arriba del todo. En un plugin de WordPress el sitio para esto es el readme con su entrada de changelog y el propio update, más la página de seguridad y, si tienes lista de clientes, un correo. La parte legible por máquina del artículo 14 apartado 8 es, en un plugin, la indicación de versión en el canal de updates.

Qué tiene que estar antes para no buscarlo en plena urgencia

• Un contacto de seguridad publicado, mejor un buzón propio que el foro de soporte.
• Un /.well-known/security.txt según RFC 9116, para que quien avise encuentre el camino sin adivinar.
• Una política de divulgación coordinada: qué prometes, qué pides, cuál es el alcance.
• Una forma de llegar a todos los usuarios afectados. En plugins gratuitos del directorio es el canal de updates con el readme, en productos de pago la lista de clientes.
• Un sitio fijo para el registro, creado antes de necesitarlo.

Todo esto no lleva ni un fin de semana. En mitad de un incidente lleva demasiado. Qué herramientas ayudan a vigilar tus instalaciones es materia de otra comparativa de plugins de seguridad.

Dónde estamos nosotros

Porque una guía que solo exige vale poco: aquí hay una página de seguridad con contacto de seguridad publicado, tiempos de respuesta comprometidos, alcance definido y la política de divulgación coordinada, más un /.well-known/security.txt según RFC 9116 que remite a esa página. Detrás está la autodeclaración con los datos del fabricante, redactada para que quien avise no tenga que preguntar por dónde entrar.

Lo que aquí todavía no está también cabe en este párrafo. De nuestros plugins gratuitos en el directorio de WordPress, por ejemplo Wellenbrecher, no conocemos las instalaciones. Nuestro camino hacia esos usuarios es el canal de updates y el readme, nada más. Registrarse en la plataforma de notificación todavía no es posible, solo se puede preparar la cuenta de EU Login. Y nuestro registro de incidentes está interno, no es una página pública.

Preguntas frecuentes