¿Soy fabricante? La pregunta del CRA que nadie responde.
Quien publica un plugin quiere saber si el Reglamento de Ciberresiliencia lo convierte en fabricante. Las fuentes dan dos respuestas distintas.
La pregunta cabe en una frase. Has creado un plugin de WordPress, está en el directorio abierto, cualquiera puede descargarlo y, al lado, vendes una versión Pro. ¿Eso te convierte en fabricante a efectos del Reglamento de Ciberresiliencia, el Reglamento (UE) 2024/2847?
La respuesta honesta es incómoda. Depende, las fuentes se contradicen justo en ese punto, y parte de las voces más audibles del mercado vende las herramientas que prometen resolverlo. En agosto de 2026 revisamos la afirmación de que los plugins gratuitos con versión Pro caen automáticamente bajo el CRA y la contrastamos de forma sistemática con las fuentes disponibles. El resultado no es un sí limpio ni un no limpio.
Por eso aquí no vas a leer una respuesta que no existe. Vas a leer qué dice el reglamento, qué dice la Comisión sobre él, dónde se separan los dos y con qué preguntas puedes ordenar tu propia situación. Esto es una explicación y no asesoramiento jurídico.
La frase que hace encogerse a la mayoría
Empieza por la definición. La excepción viene después. El artículo 3, punto 1 del CRA describe el producto con elementos digitales como "a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately". Llevado a nuestro caso: un módulo de software que se distribuye por separado está incluido. Un plugin es un módulo de software que se distribuye por separado.
El artículo 3, punto 13 define después al fabricante: quien desarrolla o manda desarrollar productos con elementos digitales y los comercializa bajo su propio nombre o marca, "whether for payment, monetisation or free of charge". Esa última fórmula es donde la discusión suele terminar antes de empezar. Dice que el precio no forma parte de la definición del fabricante: cobrar, monetizar de otra manera o entregar gratis dan lo mismo. Lo que cuenta es comercializar bajo nombre propio.
Aquí va una reserva que afecta a todo el artículo: durante nuestra investigación, EUR-Lex no devolvió contenido en ninguna de las formas de URL que probamos. Las citas de los artículos proceden de reproducciones del texto íntegro que coincidían entre sí. Por eso las dejamos en inglés y las explicamos al lado en vez de traducirlas: una traducción propia aparentaría una exactitud que no podemos acreditar. Si vas a reutilizar una cita literal, compruébala antes en EUR-Lex.
El contrapeso está en la guía de la Comisión
A finales de julio de 2026 la Comisión Europea publicó una guía de aplicación del CRA, referencia C(2026) 5252, compuesta por una comunicación y un anexo con las instrucciones propiamente dichas. Unas 80 páginas, 67 ejemplos prácticos, diagramas de flujo y las microempresas y pymes como destinatarias expresas. Una nota pequeña sobre exactitud: la Comisión fecha el documento en Bruselas, 27 de julio de 2026, mientras que heise online informa de una publicación el 28 de julio de 2026. Probablemente fecha de emisión frente a fecha de publicación. Por eso escribimos finales de julio y damos la referencia.
En cuanto al fondo, la guía dice sobre el código abierto lo contrario de lo que muchos esperan tras leer el artículo 3: el software de código abierto de libre disposición queda en principio fuera del ámbito de aplicación del CRA mientras no se comercialice. Como actividad comercial cuentan según la guía, entre otras cosas, la venta del software, las ediciones enterprise de pago, la monetización de servicios a través del programa, la exigencia de datos personales más allá de los fines de seguridad e interoperabilidad y las donaciones que de hecho son condición de acceso.
Expresamente no comerciales son, según la guía, las aportaciones voluntarias, la financiación pública y el patrocinio por sí solos. Los servicios de soporte de pago no someten un proyecto al CRA de forma automática mientras el software en sí siga siendo de libre disposición.
Fíjate en lo que falta en el reglamento: el CRA no define el concepto de actividad comercial de forma autónoma en el articulado. Los criterios salen de los considerandos y de esta guía. De ahí nace justo el espacio en el que las interpretaciones se separan.
El administrador es un régimen más ligero, no una vía libre
Entre el fabricante y quien no participa hay un tercer papel. El artículo 3, punto 14 del CRA define al administrador de software de código abierto (open-source software steward) como la persona jurídica que no es fabricante y cuyo fin consiste en apoyar de forma sostenida y sistemática el desarrollo de determinados productos con elementos digitales que se consideran software libre y de código abierto y están destinados a actividades comerciales.
Lo que se sigue de ahí está en el artículo 24. El apartado 1 exige una política de ciberseguridad documentada que fomente el desarrollo seguro y el tratamiento de vulnerabilidades, incluida la notificación voluntaria del artículo 15. El apartado 2 exige cooperación con las autoridades de vigilancia del mercado y, previa solicitud motivada, la entrega de la documentación en una lengua fácilmente comprensible para la autoridad. El apartado 3 declara aplicable a los administradores el artículo 14, apartado 1 respecto de los productos en cuyo desarrollo participan, y el artículo 14, apartados 3 y 8 en la medida en que los incidentes graves afecten a su propia infraestructura de desarrollo.
Quédate con la combinación: a los administradores les alcanza un deber de notificación desde el 11 de septiembre de 2026, pero según el artículo 64, apartado 10 ninguna multa administrativa. Quien oye "está dentro del ámbito del CRA" y piensa en sanciones tiene la imagen equivocada para este papel. Lo que rige para los fabricantes desde el 11 de septiembre de 2026 y qué plazos corren está desarrollado en el artículo sobre las obligaciones de notificación del CRA.
Aquí se separan las fuentes
El caso central es el plugin gratuito en el directorio abierto y, al lado, una versión Pro de pago del mismo proveedor. Hay dos lecturas y llevan a resultados distintos.
Lectura A: la versión gratuita se juzga por sí sola
Según esta lectura, la versión libre se examina aparte. Si ella misma no se monetiza, es decir, si no hace falta comprar nada, si no hay bloqueo de acceso ni de actualizaciones contra pago y si no hay tratamiento de datos más allá de los fines de seguridad e interoperabilidad, entonces no queda automáticamente sujeta a las obligaciones completas del fabricante solo porque el mismo proveedor venda al lado una versión Pro. La Open Regulatory Compliance Working Group resume la guía en el sentido de que una persona jurídica puede asumir a la vez papeles distintos, incluso para versiones distintas del mismo software, edición comunitaria y edición monetizada incluidas. Lo respalda el considerando 18 del reglamento, según el cual el suministro de productos que se consideran software libre y de código abierto y que sus fabricantes no monetizan no debe considerarse actividad comercial. El considerando 18 añade que la mera existencia de versiones periódicas y el mero apoyo económico por parte de fabricantes no bastan por sí solos para dar carácter comercial a la actividad.
Lectura B: la versión Pro tiñe a la gratuita
Varios proveedores especializados en conformidad con el CRA lo formulan de manera más general. Quien vende el plugin, ofrece una versión Pro, presta soporte de pago o lo monetiza de cualquier forma estaría suministrando en el marco de una actividad comercial y estaría dentro del ámbito de aplicación, con independencia de la licencia GPL. Curiosamente, uno de esos mismos proveedores matiza en otro lugar y atiende a si el producto gratuito sirve como instrumento de venta de una oferta de pago.
Y ahora la declaración que acompaña a esta postura: estos proveedores venden herramientas y consultoría de conformidad con el CRA a quienes desarrollan plugins. No cabe descartar un interés económico en una interpretación lo más amplia posible del ámbito de aplicación, porque más personas afectadas significan más clientes. No es una acusación y no convierte su afirmación en falsa. Solo significa que esa formulación no procede de la guía. Es la interpretación de la guía por parte de agentes del mercado con interés propio. Quien pondera una fuente, pondera también su interés.
Otra reserva que casi nadie acompaña: el anexo de C(2026) 5252 no se pudo procesar por medios automáticos. Todas las afirmaciones de contenido sobre código abierto de este artículo proceden de la nota de prensa de la Comisión, de medios especializados y de blogs de organizaciones. No hemos releído los 67 ejemplos ni los criterios exactos de delimitación. Quien te diga que sabe con exactitud qué pone en la página 41 tiene más acceso que nosotros o cuenta más de lo que sabe.
A esto se añade que no existe ninguna declaración de una autoridad ni de la Comisión que mencione expresamente los plugins de WordPress. La calificación de los plugins como producto con elementos digitales se sostiene bien a través del artículo 3, puntos 1 y 13. Las fuentes que llaman a los plugins por su nombre son, sin excepción, blogs de proveedores que venden herramientas de conformidad.
Siete preguntas para situar tu propio caso
Las preguntas siguientes no sustituyen el examen de tu caso por alguien con habilitación. Son una rejilla para ordenarte, construida con los criterios que la guía y los considerandos nombran según las fuentes evaluadas. Cuantas más veces la columna derecha apunte hacia lo comercial, más sentido tiene comportarse por precaución como un fabricante.
| Pregunta sobre tu propio producto | Qué significa la respuesta |
|---|---|
| ¿El acceso a la versión gratuita está ligado a un pago, aunque sea de forma encubierta mediante un registro con compra obligatoria? | Cobrar un precio por el software o por los archivos precompilados cuenta como actividad comercial según la guía. Una descarga libre sin contraprestación, no. |
| ¿La versión gratuita recibe actualizaciones de seguridad solo contra pago? | Bloquear las actualizaciones detrás de un pago es, según la lectura evaluada, uno de los argumentos más fuertes para considerar monetizada la propia versión libre. |
| ¿Exiges datos personales más allá de los fines de seguridad e interoperabilidad? | La guía nombra justo eso como actividad comercial. Recoger una dirección de correo para la descarga es por tanto un factor de riesgo, no un detalle. |
| ¿La versión gratuita es funcionalmente autónoma o es un muro de pago delante de la función de verdad? | Un producto utilizable por sí mismo habla a favor de la lectura A. Una cáscara gratuita que sin compra no hace nada habla a favor del acoplamiento funcional con la venta. |
| ¿Monetizas otros servicios a través del programa, por ejemplo publicidad o recogida de datos? | El software como plataforma para monetizar otros productos cuenta como actividad comercial según la guía, aunque el software en sí sea gratuito. |
| ¿Las donaciones son de hecho condición para acceder al software o a las actualizaciones? | Las donaciones voluntarias sin ánimo de lucro no cuentan como comerciales. Las donaciones que de facto son condición de acceso, sí. |
| ¿Comercializas bajo tu propio nombre o tu propia marca? | Ese es el elemento del artículo 3, punto 13 que se aplica con independencia del precio. No responde por sí solo a la pregunta del fabricante, pero es la puerta por la que esa pregunta entra. |
Si quieres traducir el resultado a algo utilizable: la parte que tiene sentido al margen de la calificación es un archivo security.txt con datos de contacto públicos para notificar vulnerabilidades. Eso puedes dejarlo listo hoy, sin haber resuelto antes la pregunta del fabricante.
Cómo nos situamos nosotros
hafenstudios es exactamente el caso que se discute. Tenemos varios plugins con versión gratuita y versión Pro de pago, entre ellos Wellenbrecher, que está en el directorio de WordPress desde el 21 de agosto de 2026. Con el tema Hafen tenemos además software sin ninguna edición de pago. Todo está bajo GPLv2 o posterior.
Nuestra postura: nos comportamos como un fabricante. Es la hipótesis prudente y nos cuesta menos de lo que costaría habernos equivocado llegado el caso. En la práctica significa vías de contacto documentadas para notificar vulnerabilidades, un procedimiento para los plazos del artículo 14 y la preparación para el programa completo de obligaciones desde el 11 de diciembre de 2027, cuando entren en juego 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.
Decimos con claridad que la cuestión no está zanjada. Tenemos pendiente una cita con un abogado. Eso es más honesto que afirmar aquí una certeza que las fuentes no dan. Y otra vez, en el punto donde importa: este artículo es una explicación y no asesoramiento jurídico. Para una valoración vinculante de tu caso necesitas a alguien con habilitación.
La incertidumbre es el daño real
Ahora la opinión por la que se ha escrito este artículo. El problema de esta situación no es la regulación en sí. Exigir seguridad a un software que corre en cientos de miles de sitios web se justifica sin esfuerzo. El problema es que nadie puede decir de forma fiable quién está dentro.
Esa incertidumbre se reparte de manera desigual. Una gran empresa tiene un departamento jurídico que redacta una valoración y un presupuesto que sobrevive a una valoración equivocada. Un negocio de dos personas tiene una tarde y una lista de resultados en la que los cinco primeros vienen de proveedores que quieren venderle una suscripción. El coste de la falta de claridad lo paga el pequeño, aunque la guía se escribiera expresamente para microempresas y pymes.
El marco nacional tampoco tranquiliza, y ahí te toca mirar tu propio país. La notificación va al CSIRT del Estado miembro del establecimiento principal, y la aplicación nacional se ha resuelto de forma distinta en cada Estado miembro. En Alemania, donde estamos nosotros, el destinatario es el BSI con CERT-Bund, y la ley alemana de aplicación del CRA todavía no estaba en vigor el 21 de agosto de 2026: figura como documento del Bundestag 21/6134 de 26 de mayo de 2026, primera lectura el 11 de junio de 2026. No crea obligaciones nuevas, designa competencias. El artículo 14 rige el 11 de septiembre de 2026 con independencia de eso. Si tu establecimiento principal está en otro Estado miembro, la autoridad competente y el calendario nacional los tienes que comprobar allí.
Lo que se sigue de todo esto es poco espectacular. Compórtate por precaución como un fabricante si varias de las siete preguntas apuntan hacia lo comercial. Documenta cómo llegaste a tu calificación. Y desconfía de cualquier fuente que te responda a esta pregunta en dos frases, sobre todo si en la tercera te vende algo.
Lo que publicamos sobre seguridad y vías de notificación
En nuestra página de seguridad explicamos cómo notificar una vulnerabilidad en uno de nuestros plugins, cómo la tratamos y en qué plazos. Es la parte que un proveedor debe cumplir al margen de la pregunta del fabricante.
Preguntas frecuentes
¿Entregar el software gratis me convierte de verdad en fabricante?
Según el artículo 3, punto 13 del CRA el precio no cuenta. Es fabricante quien desarrolla o manda desarrollar un producto con elementos digitales y lo comercializa bajo su propio nombre o marca, con la fórmula inglesa "whether for payment, monetisation or free of charge", es decir cobrando, monetizando de otro modo o gratis. Si esa comercialización ocurre en el marco de una actividad comercial es la segunda pregunta, la discutida. El CRA no define ese concepto en el articulado.
¿Mi plugin gratuito cae automáticamente bajo el CRA porque existe una versión Pro?
Según las fuentes que se ocupan de la propia guía, no de forma automática. Describen un examen caso por caso: una versión autónoma y no monetizada se queda en el régimen más ligero o fuera del ámbito, salvo que esté monetizada ella misma o acoplada funcionalmente a la venta. Los proveedores comerciales de conformidad defienden la lectura amplia. La cuestión no está zanjada.
¿Qué es un administrador de software de código abierto?
El artículo 3, punto 14 del CRA describe una persona jurídica que no es fabricante y cuyo fin consiste en apoyar de forma sostenida y sistemática el desarrollo de determinados productos de código abierto destinados a actividades comerciales. El artículo 24 exige una política de ciberseguridad documentada, cooperación con las autoridades y un deber de notificación limitado. Según el artículo 64, apartado 10 los administradores quedan exentos de las multas administrativas de esa disposición.
¿Es vinculante la guía de la Comisión?
No. La propia Comisión aclara que solo el Tribunal de Justicia de la Unión Europea puede interpretar el Derecho de la Unión con efecto vinculante. C(2026) 5252 no cambia ninguna obligación ni ninguna fecha. Para las autoridades de vigilancia del mercado será igualmente un punto de referencia en la práctica, por eso conviene conocerla sin tomarla por ley.
¿Desde cuándo rige cada cosa?
El capítulo IV sobre los organismos notificados rige desde el 11 de junio de 2026. El artículo 14 con las obligaciones de notificación de los fabricantes rige desde el 11 de septiembre de 2026. El resto del reglamento rige desde el 11 de diciembre de 2027, incluidos 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. Las tres fechas salen del artículo 71 del CRA.
