El pasado 11 de septiembre entró en vigor la primera obligación real del Cyber Resilience Act (CRA): el Artículo 14, el que obliga a reportar vulnerabilidades explotadas activamente e incidentes de seguridad graves. Y no, no es una ley pensada solo para fabricantes de «cacharritos» conectados o para grandes empresas de software (en mis chalas WordPress sobre esto, siempre he usado las neveras como ejemplo). También nos toca a quienes escribimos plugins de WordPress, aunque sean gratuitos y los publiquemos casi por amor al arte.
Yo soy de esos. Llevo años publicando plugins de WordPress, la mayoría totalmente gratuitos y sin ningún ánimo de lucro, pero también tengo algunos de pago. Es decir: a ojos del CRA soy, según el plugin, open source steward o fabricante. Las dos cosas a la vez. Y esto ha cambiado mi manera de mirar mi propio trabajo.
En este post voy a intentar explicar qué pide exactamente el Artículo 14, quién está obligado, qué plazos hay que cumplir y cómo se hace el reporte en la práctica. Sin alarmismo, pero sin edulcorar tampoco la parte fea.
Qué es el CRA y por qué importa a las webs
Por si alguien llega aquí sin contexto: el CRA es el Reglamento (UE) 2024/2847, la norma europea que establece requisitos mínimos de ciberseguridad para los «productos con elementos digitales» que se ponen en el mercado de la UE. La idea de fondo es que la seguridad se piense desde el diseño, venga activada por defecto y se mantenga durante toda la vida del producto: no basta con sacar algo «bien», hay que seguir parcheándolo.
Durante meses, el CRA ha sido un tema de charlas y artículos teóricos. Pero desde el 11 de septiembre de 2026 ya no es teoría: la primera obligación concreta está en vigor, y afecta también a software que llevaba años en el mercado.
Si quieres el contexto completo, yo mismo mantengo una página dedicada al tema: LeyDeCiberresiliencia.com, enfocada al mundo web. Ahí está todo el marco explicado con calma. Este post es la parte que me toca a mí de cerca: la del autor de plugins.
Qué pide exactamente el Artículo 14
El Artículo 14 obliga a reportar dos cosas:
- Vulnerabilidades que los atacantes están explotando activamente en tus productos.
- Incidentes de seguridad graves que afecten a tus productos.
Los reportes van a las autoridades nacionales de ciberseguridad y a ENISA, la agencia europea, a través de una única plataforma común. Y los plazos son cortos, muy cortos.
Los tres formularios y sus plazos
Cada reporte se compone de tres formularios, cada uno con su propio plazo:
| Formulario | Plazo |
|---|---|
| Aviso temprano (early warning) | 24 horas desde que tienes conocimiento |
| Notificación completa (con evaluación inicial) | 72 horas desde que tienes conocimiento |
| Informe final | 14 días tras disponer del parche (vulnerabilidades) / 1 mes tras la notificación de 72 h (incidentes) |
Además, el fabricante debe informar a los usuarios afectados de lo ocurrido y de cómo protegerse. No basta con reportar hacia arriba: hay que comunicar hacia abajo.
Quién está obligado: fabricante vs open source steward
Aquí está la parte que más me toca, y la que más confusión genera en la comunidad WordPress. Vamos con el ejemplo típico: un plugin de WordPress.
Todo plugin de WordPress es open source y tiene licencia GPL. Pero eso no significa que todos sean iguales a ojos del CRA:
- Si el plugin tiene una versión premium o cualquier otra vía de generar ingresos para su autor, ese autor es un fabricante (manufacturer).
- Si el plugin es 100% FOSS, sin ningún ánimo comercial, pero lo mantiene una entidad legal (por ejemplo, una empresa que paga a empleados para mantenerlo), entonces es un open source steward.
Y aquí viene lo importante: el Artículo 14 aplica a ambos. Los dos tienen la obligación de reportar. La diferencia está en las consecuencias:
- Los fabricantes pueden ser multados por incumplimiento.
- Los open source stewards no pueden ser multados, pero la UE puede usar otros medios para retirar del mercado un producto no conforme.
Que no te engañen: «no te pueden multar» no significa «no te puede pasar nada». La retirada del mercado de un plugin es, para un mantenedor, prácticamente una sentencia de muerte del proyecto.
Mi caso: steward y fabricante a la vez
Yo soy las dos cosas. Tengo una buena colección de plugins gratuitos, sin versión premium y sin monetización alguna: esos, en principio, caen del lado del open source steward. Pero también tengo plugins de pago, con su versión comercial: esos me convierten en fabricante.
La consecuencia práctica es que no puedo elegir un único sombrero. Para unos proyectos tengo la obligación de reportar sin riesgo de multa; para otros, la misma obligación pero con la espada de Damocles de las sanciones encima. Y en ambos casos, el trabajo administrativo de reportar es idéntico.
Esto es algo que creo que muchos autores de plugins no han interiorizado todavía: el CRA no distingue entre «mi hobby» y «mi negocio» cuando el producto está en el mercado. Distingue entre steward y fabricante, pero ambos tienen que reportar.
Un detalle que duele: la retroactividad
Hay un matiz que conviene subrayar porque se pasa por alto: el Artículo 14 aplica a todos los productos y software, incluso a los que se pusieron en el mercado antes del 11 de septiembre de 2026.
Es decir, no vale el «esto lo publiqué en 2019, no me afecta». Si tu plugin lleva años ahí, con usuarios instalándolo en la UE, la obligación de reportar existe desde el primer día de vigencia. Tus plugins antiguos no están exentos: están, si acaso, más expuestos, porque llevan más tiempo acumulando superficie de ataque.
Cómo se reporta en la práctica
Aquí es donde la teoría choca con la realidad, y la realidad es bastante confusa para un mantenedor voluntario.
Los reportes van a la Plataforma Única de Reporte (SRP) de ENISA. Para acceder necesitas:
- Una cuenta EU Login personal.
- Autenticación multifactor (MFA) obligatoria.
Y aquí viene lo que más me chirría como desarrollador: la plataforma no tiene API, y cada reporte requiere rellenar tres formularios manualmente. Con un plazo de 24 horas para el primero.
Traducción: cuando descubres que una vulnerabilidad de tu plugin está siendo explotada activamente, no puedes automatizar el reporte. Tienes que sentarte, entrar en la plataforma, y teclear tres formularios a mano mientras el reloj corre. En medio de un incidente de seguridad, que es precisamente cuando menos tiempo tienes para burocracia.
Mi consejo práctico, y lo digo en serio: crea tu cuenta EU Login ya, antes de necesitarla. Configura el MFA, entra una vez en la plataforma, familiarízate con los formularios. Cuando llegue el incidente (y llegará, porque a quien publica software le llega tarde o temprano), no querrás estar peleándote con el alta de una cuenta europea a las dos de la mañana con el cronómetro corriendo.
Qué puedes hacer: reportar tú o delegar
Tienes dos caminos.
Opción 1: hacerlo tú. Es viable si tienes pocos productos y poco volumen de vulnerabilidades. Pero asumes toda la carga administrativa, los plazos y el riesgo de equivocarte en el proceso.
Opción 2: delegar en un Representante Asignado (AR). El CRA permite que un tercero actúe como tu representante ante la plataforma y gestione los reportes por ti. Ya existen servicios que hacen esto, algunos incluso gratuitos para mantenedores de open source. La idea es que ellos vigilan la explotación activa de vulnerabilidades, recogen la evidencia y presentan los formularios dentro de plazo.
No voy a recomendar ninguna marca concreta aquí, porque no es el objetivo del post. Pero sí te diré que, si publicas varios plugins y no quieres vivir pendiente de plazos de 24 horas, merece la pena mirar seriamente la opción del AR. Es exactamente el tipo de tarea que no debería caer sobre los hombros de un mantenedor voluntario.
Lo que esto significa para la comunidad WordPress
Y ahora permíteme un momento de reflexión, porque creo que es lo más importante de todo esto.
El ecosistema WordPress funciona gracias a miles de personas que publican plugins y temas, muchas veces gratis, muchas veces sin más recompensa que el reconocimiento de la comunidad. El CRA, con su Artículo 14, les pide ahora una tarea nueva: reportar vulnerabilidades e incidentes con plazos de 24 horas, en una plataforma sin API, con formularios manuales.
No digo que la obligación sea injusta en general. Que se reporten los exploits activos es razonable y hasta deseable: beneficia a todos los usuarios. El problema es la proporcionalidad. Pedirle a un mantenedor voluntario de un plugin gratuito la misma disciplina de reporte que a una empresa con un departamento de compliance es, como mínimo, discutible.
Y hay un efecto colateral que podría ser preocupante: el riesgo de que esto espante a gente con talento. Publicar software libre ya era una actividad con responsabilidad; ahora se le suma una capa de burocracia regulatoria con plazos estrictos. Algunos decidirán que no merece la pena, y eso sería una pérdida para todo el ecosistema.
Por eso creo que es importante que quienes publicamos software hablemos de esto, lo entendamos bien y nos preparemos. Cuanto mejor preparados estemos, menos dolorosa será la transición. Y cuanto más visible sea la carga real que supone, más presión habrá para que la UE simplifique el proceso (por ejemplo, con una API, que no sería tan difícil de construir).
Conclusión (si es que la hay)
El Artículo 14 del CRA ya está en vigor desde el 11 de septiembre de 2026, y afecta a fabricantes y a open source stewards por igual, incluidos los autores de plugins de WordPress. Hay que reportar vulnerabilidades explotadas activamente e incidentes graves, con plazos de 24 horas, 72 horas y un informe final, todo ello en la plataforma de ENISA, sin API y con formularios manuales.
Si publicas software, mi recomendación es clara:
- Crea ya tu cuenta EU Login con MFA y familiarízate con la plataforma.
- Decide tu estrategia: reportar tú o delegar en un Representante Asignado.
- Ten un plan para cuando aparezca la primera vulnerabilidad explotada activamente, porque aparecerá.
Yo, que soy steward y fabricante a la vez, he empezado por el paso 1 (ya tenía cuenta para otras cosas, pero no mi cuenta personal). Y te confieso que, aunque el proceso me parezca desproporcionado en algunos puntos, hay algo reconfortante en saber que, si algún día un exploit activo golpea uno de mis plugins, al menos sabré exactamente qué tengo que hacer y dónde tengo que hacerlo.
Deja una respuesta