Si tu nombre o marca aparece en un producto con elementos digitales introducido en el mercado de la UE, la Ley de Ciberresiliencia normalmente te trata como fabricante. Esta página explica las principales obligaciones del fabricante CRA: diseño seguro, documentación técnica, evaluación de la conformidad, marcado CE, deberes del período de soporte, gestión de vulnerabilidades y notificación obligatoria.
Resumen
- ¿Eres tú el fabricante? Normalmente eres fabricante cuando desarrollas, fabricas o encargas el producto y lo comercializas con tu propio nombre o marca. La marca es la prueba decisiva; el contrato de suministro no desplaza por sí solo el rol CRA.
- ¿Qué debe estar listo antes de la introducción en el mercado? Evaluación del riesgo de ciberseguridad, mapeo de los requisitos esenciales de ciberseguridad, documentación técnica, evaluación de la conformidad, declaración UE de conformidad, marcado CE, datos del fabricante y de contacto, e instrucciones para el usuario.
- ¿Qué continúa después de la introducción en el mercado? Gestión de vulnerabilidades, actualizaciones de seguridad, comunicación del período de soporte, medidas correctoras, cooperación con las autoridades de vigilancia del mercado y conservación documental. Las actualizaciones de seguridad permanecen disponibles al menos 10 años desde su emisión o durante el resto del período de soporte, lo que sea mayor.
- ¿Qué debe notificarse? Las vulnerabilidades activamente explotadas y los incidentes graves se canalizan a través de la plataforma única de notificación de ENISA con una cadencia de 24h / 72h / informe final. Las dos vías tienen plazos de informe final distintos, detallados en la sección de notificación más abajo.
- ¿Cuándo se aplica? La notificación de vulnerabilidades e incidentes comienza el 11 sep 2026; el resto del régimen del fabricante sigue después. Consulta el cronograma de implementación más abajo para la cadena completa de hitos.
- Exposición a sanciones: las infracciones del tramo superior pueden alcanzar 15.000.000 EUR o el 2,5% de la facturación mundial anual total, lo que sea mayor. Microempresas y pequeñas empresas reciben un alivio limitado únicamente respecto de los plazos de aviso temprano de 24 h. Consulta sanciones y aplicación para la escala de multas artículo por artículo.
Cuatro cifras que enmarcan la exposición del fabricante: 21 requisitos esenciales divididos entre producto y proceso, dos plazos de notificación por vía y la multa del tramo superior.
¿Quién es fabricante según el CRA?
En la práctica, el fabricante CRA es el titular de la marca o el productor responsable de introducir el producto en el mercado con su nombre o marca. La definición cubre a las entidades que desarrollan, fabrican o mandan diseñar, desarrollar o fabricar un producto, y después lo comercializan con su propio nombre o marca, ya sea de manera remunerada, monetizada o gratuita.
La externalización no desplaza el rol: si un OEM o contratista construye el producto pero tu nombre figura en él, sigues siendo el fabricante. Si el producto no está bajo tu nombre o marca, puede ser que seas importador, distribuidor, representante autorizado o modificador sustancial. Para el árbol completo de decisión de roles, consulta quién debe cumplir el CRA.
Obligaciones principales del fabricante
Los deberes del fabricante se agrupan en cuatro bloques: diseño seguro y propiedades del producto evaluadas por riesgo; procesos de gestión de vulnerabilidades operados durante el período de soporte; artefactos previos al mercado que deben existir antes de la introducción en el mercado (documentación técnica, evaluación de la conformidad, declaración UE de conformidad, marcado CE); y obligaciones post-mercado (medidas correctoras, cooperación con la vigilancia del mercado, comunicación del período de soporte, notificación de cese). La tabla siguiente asigna cada deber al apartado específico del Artículo 13 que lo fundamenta.
| Deber | Punto clave | Fuente |
|---|---|---|
| Diseñar y producir conforme a los requisitos esenciales | Los requisitos esenciales son obligatorios, modulados por la evaluación del riesgo de ciberseguridad. | Artículo 13, apartado 1 |
| Evaluación del riesgo de ciberseguridad | Documentada, actualizada durante todo el período de soporte, incluida en la documentación técnica. | Artículo 13, apartado 2 |
| Diligencia debida sobre componentes | Incluye los componentes libres y de código abierto. Actúa con diligencia debida al integrar componentes; cuando tengas conocimiento de una vulnerabilidad en alguno, documéntala, notifícala aguas arriba al mantenedor del componente y remédiala en tu propio producto. | Artículo 13, apartado 5; Artículo 13, apartado 6 |
| Período de soporte | Al menos 5 años, o el período de uso previsto si fuera menor. Documentado en la documentación técnica. Incluye obligaciones de gestión de vulnerabilidades y de política CVD. | Artículo 13, apartado 8 |
| Disponibilidad de actualizaciones de seguridad | Cada actualización de seguridad permanece disponible al menos 10 años desde su emisión, o durante el resto del período de soporte, lo que sea mayor. | Artículo 13, apartado 9 |
| Versiones de software sustancialmente modificadas | La regla de remediación de vulnerabilidades puede aplicarse solo a la versión más reciente cuando los usuarios tengan acceso libre a ella. Se permiten archivos públicos de versiones sin soporte con avisos de riesgo. | Artículo 13, apartado 10, Artículo 13, apartado 11 |
| Documentación técnica previa al mercado + evaluación de la conformidad + CE. Controles de la producción en serie | Elabora la documentación técnica. Realiza la evaluación de la conformidad o haz que se realice. Redacta la declaración UE de conformidad y coloca el marcado CE. Mantén procedimientos para que la producción en serie siga siendo conforme. | Artículo 13, apartado 12 |
| Conservación | Documentación técnica y declaración UE de conformidad a disposición de las autoridades de vigilancia del mercado durante al menos 10 años o el período de soporte, lo que sea mayor. | Artículo 13, apartado 13 |
| Identificación del producto + identificación del fabricante | Número de tipo, lote o serie. Nombre del fabricante, nombre comercial o marca, dirección postal, contacto digital, también reproducidos en la información que acompaña al producto. | Artículo 13, apartado 15, Artículo 13, apartado 16 |
| Punto único de contacto | Permite a los usuarios elegir su medio de comunicación preferido. No puede limitarse a herramientas automatizadas. | Artículo 13, apartado 17 |
| Información de acompañamiento para usuarios | Información e instrucciones en una lengua fácilmente comprensible para usuarios y vigilancia del mercado, accesibles en línea durante el mismo período de conservación. | Artículo 13, apartado 18 |
| Fecha de fin del período de soporte | Especificada en el momento de la compra, indicando al menos el mes y el año. Mostrar al usuario el aviso de fin de soporte cuando sea técnicamente viable. | Artículo 13, apartado 19 |
| Entrega de la declaración UE de conformidad | Bien la declaración completa, bien una declaración simplificada con la dirección de internet exacta donde puede consultarse la declaración completa. | Artículo 13, apartado 20 |
| Medidas correctoras post-mercado + cooperación | Retirar, recuperar o restablecer la conformidad al tener conocimiento de la no conformidad. Facilitar toda la información a la vigilancia del mercado a petición motivada. | Artículo 13, apartado 21, Artículo 13, apartado 22 |
| Cese de actividad | Informar a la vigilancia del mercado y, por todos los medios disponibles, a los usuarios, antes de que el cese surta efecto. | Artículo 13, apartado 23 |
| Formato de SBOM + evaluaciones de dependencias | La Comisión podrá especificar el formato de SBOM mediante actos de ejecución. El ADCO podrá realizar evaluaciones de dependencias a escala de la Unión. | Artículo 13, apartado 24, Artículo 13, apartado 25 |
Requisitos esenciales de ciberseguridad
Los fabricantes deben cumplir dos conjuntos de requisitos esenciales de ciberseguridad: requisitos de seguridad del producto y requisitos de gestión de vulnerabilidades. El primer conjunto rige cómo se diseña, desarrolla y produce el producto. El segundo rige los procesos que el fabricante debe operar durante el período de soporte.
Evaluación del riesgo de ciberseguridad
Los fabricantes realizan una evaluación del riesgo de ciberseguridad para determinar qué requisitos esenciales de ciberseguridad vinculan a su producto concreto. La evaluación se documenta una vez y se mantiene actualizada durante todo el período de soporte. Vive dentro de la documentación técnica, y cuando un requisito no sea aplicable la evaluación lleva la justificación escrita.
Requisitos de seguridad del producto
Antes de la introducción en el mercado, el producto debe diseñarse, desarrollarse y producirse para proporcionar un nivel adecuado de ciberseguridad basado en el riesgo. La evaluación del riesgo de ciberseguridad del fabricante determina qué controles de la lista siguiente se aplican, y cuando un control no sea aplicable la documentación técnica debe incluir una justificación clara.
- (a) Comercializados sin vulnerabilidades explotables conocidas
- (b) Configuración segura por defecto; restablecimiento al estado original disponible (los productos a medida para usuarios profesionales pueden acordar otra cosa)
- (c) Vulnerabilidades subsanables mediante actualizaciones de seguridad; actualizaciones automáticas instaladas en un plazo adecuado por defecto, con opción de exclusión y de aplazamiento, cuando proceda
- (d) Protección frente al acceso no autorizado (autenticación, gestión de identidades o accesos, notificación de posibles accesos no autorizados)
- (e) Confidencialidad de los datos almacenados, transmitidos y tratados, incluido el cifrado en reposo o en tránsito mediante mecanismos del estado de la técnica
- (f) Protección de la integridad de datos, órdenes, programas y configuración; notificación de corrupciones
- (g) Minimización de datos: tratar únicamente los datos adecuados, pertinentes y limitados a la finalidad prevista
- (h) Disponibilidad de las funciones esenciales y básicas, también tras un incidente; resiliencia frente a la denegación de servicio
- (i) Minimizar el impacto negativo en la disponibilidad de los servicios prestados por otros dispositivos o redes
- (j) Limitar las superficies de ataque, incluidas las interfaces externas
- (k) Reducir el impacto de los incidentes mediante mecanismos y técnicas de mitigación de la explotación
- (l) Facilitar información de seguridad mediante el registro y la supervisión de la actividad interna pertinente, con opción de exclusión por el usuario
- (m) Permitir a los usuarios eliminar de forma segura y sencilla todos los datos y configuraciones; garantizar la transferencia segura de datos cuando proceda
El matiz "cuando proceda" de varios elementos anteriores se rige por la evaluación del riesgo, no por la preferencia del fabricante.
Requisitos de gestión de vulnerabilidades
Por separado de los controles de seguridad del producto, el fabricante debe operar procesos de gestión de vulnerabilidades durante el período de soporte: documentación de componentes, SBOM, pruebas, remediación, divulgación coordinada de vulnerabilidades, canales de notificación, distribución segura de actualizaciones y avisos a usuarios.
- (1) Identificar y documentar vulnerabilidades y componentes, incluida una lista de materiales de software (SBOM) en un formato legible por máquina ampliamente utilizado que cubra al menos las dependencias de primer nivel
- (2) Abordar y remediar vulnerabilidades sin demora mediante actualizaciones de seguridad. Cuando sea técnicamente viable, separar las actualizaciones de seguridad de las de funcionalidad
- (3) Aplicar pruebas y revisiones eficaces y periódicas de la seguridad del producto
- (4) Una vez disponible una actualización de seguridad, compartir y divulgar públicamente información sobre las vulnerabilidades corregidas (descripción, productos afectados, impactos, gravedad, orientaciones de remediación). Puede demorarse la divulgación pública en casos debidamente justificados hasta que los usuarios puedan aplicar el parche
- (5) Establecer y aplicar una política de divulgación coordinada de vulnerabilidades (CVD)
- (6) Facilitar el intercambio de información sobre vulnerabilidades potenciales (incluidas las de componentes de terceros) proporcionando una dirección de contacto para la notificación de vulnerabilidades
- (7) Mecanismos para distribuir actualizaciones de forma segura, de modo que las vulnerabilidades se subsanen en un plazo razonable y, cuando proceda, automáticamente
- (8) Difundir las actualizaciones de seguridad sin demora. De forma gratuita, salvo acuerdo en otro sentido con un usuario profesional para productos a medida. Con mensajes informativos a los usuarios
Los requisitos de gestión de vulnerabilidades anteriores se aplican desde la introducción en el mercado y durante todo el período de soporte. Las actualizaciones de seguridad permanecen disponibles al menos 10 años desde su emisión o durante el resto del período de soporte, lo que sea mayor.
Diligencia debida sobre componentes
La diligencia debida sobre componentes se aplica con independencia de que el componente sea comercial o libre y de código abierto. El fabricante documenta las vulnerabilidades de componentes de las que tiene conocimiento, las aborda en su propio producto y comparte la información pertinente con el mantenedor del componente (incluido, cuando proceda, el código o la documentación pertinentes en formato legible por máquina). La superficie de documentación es el SBOM y el expediente de documentación técnica.
Artefactos previos al mercado: qué debe existir antes de la introducción del producto en el mercado
Cuatro artefactos deben existir antes de la introducción del producto en el mercado. Cada uno se ancla en un artículo concreto del CRA y produce un acto de conformidad concreto: el expediente que el fabricante conserva, la evaluación que realiza, la declaración que firma y la marca que coloca.
| Artefacto | Qué contiene o exige |
|---|---|
| Documentación técnica | Descripción del producto, información de diseño y desarrollo, la evaluación del riesgo de ciberseguridad, las normas armonizadas o especificaciones comunes aplicadas, la vía y el resultado de la evaluación de la conformidad, la declaración UE de conformidad y el proceso de gestión de vulnerabilidades. Conservada durante al menos 10 años o el período de soporte, lo que sea mayor. |
| Evaluación de la conformidad | Autoevaluación según el módulo A para productos de clase por defecto y para productos importantes de clase I cuando se apliquen plenamente normas armonizadas, especificaciones comunes o un esquema de certificación de ciberseguridad. Los productos importantes de clase II usan rutas de organismo notificado (módulo B+C o H) o un esquema europeo de certificación de ciberseguridad con un nivel de garantía al menos «sustancial». Los productos críticos usan un esquema europeo de certificación de ciberseguridad cuando sea aplicable. En caso contrario, usan rutas de organismo notificado. |
| Declaración UE de conformidad | Bien la declaración completa entregada con el producto, bien una declaración simplificada con la dirección de internet exacta de la declaración completa. El contenido de la declaración: nombre y dirección del fabricante, identificación del producto, declaración de conformidad con los requisitos esenciales de ciberseguridad, normas aplicadas con números de referencia y fechas, nombre y número del organismo notificado cuando proceda, referencia del certificado, fecha, firma, nombre y función del firmante. |
| Marcado CE | Colocado de forma visible, legible e indeleble sobre el producto; habida cuenta de la naturaleza del producto con elementos digitales, la altura del marcado CE colocado en él podrá ser inferior a 5 mm, siempre y cuando siga siendo visible y legible. Cuando la naturaleza del producto no lo permita, en el embalaje y la declaración UE de conformidad. Cuando un organismo notificado intervenga en la evaluación de la conformidad según el Módulo H (aseguramiento total de la calidad), su número de identificación de cuatro dígitos seguirá al marcado CE. |
La elección del módulo de evaluación de la conformidad es la decisión más consecuente de esta sección. La tabla y el diagrama de decisión que figuran a continuación ofrecen el detalle fila a fila.
| Módulo | Cuándo |
|---|---|
| A control interno de la producción | Productos de clase por defecto; productos importantes de clase I cuando se apliquen plenamente normas armonizadas, especificaciones comunes o un esquema europeo de certificación de ciberseguridad con un nivel de garantía al menos «sustancial» |
| B + C examen UE de tipo + control de la producción | Ruta para importantes clase II. Clase I cuando no se aplique norma armonizada, especificación común ni esquema europeo de certificación de ciberseguridad relevante. Productos críticos cuando se encaminen por una evaluación de organismo notificado. |
| H aseguramiento total de la calidad | Alternativa para productos importantes. Productos críticos cuando se encaminen por una evaluación de organismo notificado. |
Consulta la guía de documentación técnica, la guía de evaluación de la conformidad, la guía de clasificación de productos y la guía de declaración de conformidad para los detalles de cada artefacto.
Notificación de vulnerabilidades e incidentes graves
Los fabricantes tienen dos vías de notificación. Ambas se dirigen simultáneamente al CSIRT designado como coordinador y a ENISA a través de la plataforma única de notificación. Las dos vías comparten la cadencia de 24h/72h pero tienen plazos distintos para el informe final, un punto que con frecuencia se malinterpreta.
El reloj de aviso previo de 24 horas se aplica únicamente a vulnerabilidades activamente explotadas. El incidente grave tiene su propio supuesto y su propia cadencia de 24h/72h/1 mes.
| Vía | Aviso temprano 24h | Notificación 72h | Informe final |
|---|---|---|---|
| Vulnerabilidad activamente explotada | En las 24h siguientes al conocimiento | En las 72h siguientes al conocimiento | 14 días después de que se disponga de una medida correctora o paliativa |
| Incidente grave | En las 24h siguientes al conocimiento | En las 72h siguientes al conocimiento | Un mes después de la notificación de 72h |
El reloj del informe final de la vulnerabilidad arranca cuando el parche está listo, no cuando se tuvo conocimiento; el lapso puede ser de semanas o meses. El reloj del informe final del incidente grave queda fijado en la notificación de 72h, es decir, en la práctica, el día 33 desde el conocimiento. Consulta la guía del clúster de notificación de vulnerabilidades para el flujo operativo, las reglas de enrutamiento al CSIRT coordinador (incluida la cascada de respaldo para fabricantes no comunitarios), el deber de notificación a usuarios y la mecánica de la plataforma única de notificación.
Período de soporte y obligaciones post-mercado
Las cifras de cabecera (período mínimo de soporte de 5 años, disponibilidad de actualizaciones de seguridad de 10 años) aparecen en la tabla de bloques de deberes anterior. Los criterios de determinación, la comunicación de la fecha de fin en el momento de la compra, el deber de notificación de fin de vida útil y las reglas para versiones de software sustancialmente modificadas se tratan en la guía del clúster del período de soporte.
Dos deberes post-mercado del fabricante conviven con el régimen del período de soporte y no tienen una página de clúster propia. Al tener conocimiento de que el producto ya no se ajusta a los requisitos esenciales de ciberseguridad, el fabricante adopta inmediatamente medidas correctoras, o retira o recupera el producto cuando proceda, y a petición motivada de una autoridad de vigilancia del mercado facilita toda la información necesaria para demostrar la conformidad en una lengua que la autoridad comprenda. El fabricante que cese su actividad informa a las autoridades de vigilancia del mercado pertinentes antes de que el cese surta efecto e informa a los usuarios por todos los medios disponibles y en la medida de lo posible.
¿Fabricante o modificador sustancial?
La modificación sustancial es una vía distinta hacia obligaciones de nivel fabricante. Se aplica cuando un tercero modifica un producto después de la introducción en el mercado y comercializa el producto modificado. El Artículo 22 dice:
"A los efectos del presente Reglamento, se considerará fabricante a una persona física o jurídica, distinta del fabricante, el importador o el distribuidor, que lleve a cabo una modificación sustancial de un producto con elementos digitales y comercialice dicho producto."
El régimen de modificación sustancial excluye expresamente a fabricantes, importadores y distribuidores. Se aplica a terceros fuera de la cadena de roles: integradores de sistemas, distribuidores de valor añadido, departamentos de TI corporativos que modifican productos del proveedor antes de redistribuirlos. Su alcance es nítido: quien modifica se considera fabricante respecto de la parte del producto afectada por la modificación sustancial, o respecto de todo el producto si la modificación tiene impacto en la ciberseguridad del producto en su conjunto. La "modificación sustancial" es un cambio posterior a la introducción en el mercado que afecta al cumplimiento de los requisitos esenciales de ciberseguridad o modifica la finalidad prevista para la que se evaluó el producto.
| Caso | Clasificación |
|---|---|
| Ingeniería original, marca original | Fabricante |
| Marca original, un tercero añade funcionalidades de firmware tras la introducción en el mercado que cambian la superficie de ataque | El fabricante original sigue siéndolo. El tercero también es fabricante respecto de la parte modificada como modificador sustancial. |
| Reetiquetado de marca blanca de un producto extracomunitario por una entidad de la UE | La entidad de la UE es el fabricante a través del puente de reetiquetado para importadores y distribuidores. No se trata de un caso de modificación sustancial por un tercero. Si comenzó como importador de la UE, consulte la guía del cluster del importador para lo que cambia cuando cruza al régimen de fabricante. |
| Un integrador de la UE empaqueta productos compatibles sin modificar sus componentes internos | Distribuidor, no modificador sustancial. Consulte la guía del cluster del distribuidor para el conjunto de obligaciones del distribuidor. |
| TI corporativa instala una versión personalizada de firmware en dispositivos del proveedor y los revende | Modificador sustancial. Tratado como fabricante respecto del producto modificado. |
La consecuencia práctica de quedar atrapado por el régimen de modificación sustancial: obligaciones plenas de fabricante respecto de la parte modificada o del producto completo, incluidos un nuevo expediente técnico, una nueva declaración UE de conformidad, un nuevo marcado CE bajo la responsabilidad del modificador y la cadencia de notificación indicada arriba.
Cronograma de implementación
- Hito pasado
- Aplicación próxima
- Fecha límite final
- Hito del ecosistema
Errores comunes
| Afirmación | Por qué falla |
|---|---|
| "Realmente no somos el fabricante; un OEM en otro país lo construye." | El titular de la marca es el fabricante, con independencia de quién construya el producto. Externalizar la fabricación no transfiere la obligación. |
| "Nuestra política de seguridad es suficiente; no necesitamos hacer una evaluación de requisitos esenciales." | La evaluación del riesgo de ciberseguridad es obligatoria y debe vivir dentro de la documentación técnica. |
| "Nuestros clientes no piden un SBOM, así que no lo hacemos." | Se exige un SBOM en un formato legible por máquina ampliamente utilizado, que cubra al menos las dependencias de primer nivel. El interés del cliente es irrelevante. |
| "Nuestro chatbot es el punto único de contacto." | Los usuarios deben poder elegir su medio de comunicación preferido. El canal no puede limitarse a herramientas automatizadas. |
| "Cinco años desde el lanzamiento del producto bastan para el período de soporte." | El período de soporte corre desde la introducción en el mercado de cada unidad, no desde el lanzamiento. Las unidades introducidas en el año 4 arrastran obligaciones de soporte hasta el año 9. |
| "El plazo de informe final de 14 días también se aplica a incidentes." | No. Las vulnerabilidades tienen 14 días tras disponer de una medida correctora; los incidentes graves tienen un mes desde la notificación de 72h. |
| "Nuestro SLA ya cubre vulnerabilidades; no necesitamos notificar a ENISA." | La notificación va simultáneamente al CSIRT coordinador y a ENISA, a través de la plataforma única de notificación. Los SLA con clientes no la sustituyen. |
| "Tenemos seguro frente a brechas." | Las multas administrativas no son asegurables en la mayoría de los Estados miembros. La transferencia de riesgo no puede sustituir al cumplimiento. |
| "La notificación solo se aplica cuando tengamos una entidad europea." | Los fabricantes no comunitarios se enrutan a través de una cascada de CSIRT basada en la ubicación del representante autorizado, importador, distribuidor o usuario. El deber de notificación comienza el 11 sep 2026 en cualquier caso. |
| "Demoramos la divulgación pública de toda vulnerabilidad hasta la siguiente versión trimestral." | La demora solo se permite en casos debidamente justificados hasta que los usuarios puedan aplicar el parche. El agrupamiento trimestral rutinario no cumple ese estándar. |
El CRA país por país en la UE
Las obligaciones anteriores son las mismas en todos los Estados miembros. Lo que cambia en cada país es la cadena institucional: qué autoridad ejecuta, qué CSIRT recibe tus notificaciones y en qué idioma debe entregarse la documentación dirigida al usuario. Varias designaciones nacionales aún se están cerrando, así que cada resumen señala qué está confirmado y qué sigue pendiente.
- Francia: ANSSI como autoridad notificante, ANFR para la vigilancia del mercado y notificación a través de CERT-FR.
- Alemania: BSI como autoridad combinada de vigilancia del mercado y notificante, con notificación a través de CERT-Bund.
- Italia: ACN como autoridad nacional única, con acreditación de ACCREDIA.
- Países Bajos: notificación al NCSC y vigilancia del mercado prevista a cargo del RDI.
- Polonia: enrutamiento por el CSIRT NASK y acreditación del PCA.
- España: notificación al INCIBE-CERT y reparto entre CCN y ENAC para los organismos notificados.
Preguntas frecuentes
¿Cuáles son las principales obligaciones de un fabricante según el CRA?
Cuatro bloques de obligaciones. La notificación de vulnerabilidades e incidentes comienza el 11 sep 2026; el régimen completo se aplica desde el 11 dic 2027.
- Antes de la introducción en el mercado. Evaluación del riesgo, diseño de los requisitos esenciales de ciberseguridad, documentación técnica, evaluación de la conformidad, declaración UE de conformidad, marcado CE.
- Durante todo el período de soporte. Gestión de vulnerabilidades, SBOM, remediación, divulgación coordinada de vulnerabilidades, actualizaciones seguras. Al menos cinco años por unidad.
- Punto único de contacto. Canal no automatizado al alcance de los usuarios.
- Notificación de vulnerabilidades e incidentes. Cadencia 24h, 72h e informe final al CSIRT coordinador y a ENISA mediante la plataforma única de notificación.
¿Qué es un fabricante según el CRA?
El titular de la marca. Un fabricante es la entidad que desarrolla o encarga un producto (incluso a una fábrica externalizada) y lo comercializa con su propio nombre o marca, de pago o gratuito. La marca del producto, no la ubicación de la línea de producción, decide quién es el fabricante. Los administradores de software de código abierto son una categoría separada y más ligera. La reventa exclusiva al consumidor sin marca propia es distribución, no fabricación.
¿Soy fabricante o importador?
Depende de qué marca aparece en el producto.
- Tu propio nombre o marca en el producto. Ruta de fabricante, con independencia de dónde se construya el producto. Conjunto completo de obligaciones del régimen de fabricante.
- La marca de otra persona (no comunitaria) en un producto que tú introduces en el mercado de la Unión. Ruta de importador. Solo conjunto de verificaciones.
Fabricante frente a representante autorizado: ¿cuál es la diferencia?
El representante autorizado es un apoderado documental, no un sustituto del fabricante. Designarlo es opcional.
- Lo que hace el representante autorizado, en virtud de mandato escrito. Mantiene la declaración UE de conformidad y la documentación técnica a disposición de la vigilancia del mercado, responde a peticiones motivadas y coopera en acciones de ejecución.
- Lo que permanece en el fabricante. La ingeniería, la evaluación del riesgo, la gestión de vulnerabilidades, la evaluación de la conformidad, los deberes de producción en serie y la introducción del producto en el mercado.
¿Existen exenciones para pymes para los fabricantes?
Las obligaciones sustantivas se aplican con independencia del tamaño. No hay exención de las propias obligaciones.
- Concesión para pymes, de alcance reducido. Las microempresas y pequeñas empresas quedan exentas de las multas vinculadas específicamente a los plazos de aviso temprano de 24 horas, y nada más.
- Factor de graduación. Las autoridades deben tener debidamente en cuenta el tamaño del infractor (incluidas pymes y empresas emergentes) al fijar el importe de las multas.
- Categoría de administradores de OSS, separada. Los administradores de software de código abierto disponen de una exención más amplia de multas administrativas, pero no son pymes.
¿Cuándo se aplican las obligaciones del fabricante en el CRA?
Dos fechas escalonadas.
- Notificación de vulnerabilidades e incidentes. Comienza el 11 sep 2026. Los fabricantes que introduzcan productos en el mercado de la UE necesitan tener operativa la capacidad de notificación en 24 horas, 72 horas e informe final para esa fecha, aunque su programa completo de conformidad todavía esté en construcción.
- El resto del régimen del fabricante. Comienza el 11 dic 2027. Abarca el conjunto completo de deberes del fabricante: los requisitos esenciales de ciberseguridad, la evaluación de la conformidad, la declaración UE de conformidad, el marcado CE y la documentación técnica.
¿Qué es el período de soporte y cómo se determina?
Al menos cinco años desde la introducción en el mercado de cada unidad, o el período previsto de uso si fuera más corto.
- Cómo determina el fabricante el período. Considera las expectativas razonables de los usuarios, la naturaleza y la finalidad prevista del producto, el Derecho de la Unión sobre la vida útil de los productos, los períodos de soporte de productos comparables, la disponibilidad del entorno operativo, los períodos de soporte de los componentes integrados de terceros, las orientaciones del ADCO y las orientaciones de la Comisión. El análisis se incluye en la documentación técnica.
- Comunicación en el momento de la compra. Fecha de fin con al menos mes y año.
- Disponibilidad de actualizaciones de seguridad tras el fin del período. Cada actualización de seguridad emitida permanece disponible al menos 10 años desde su emisión, o durante el resto del período de soporte si fuera mayor.
¿Cuál es la diferencia entre una "vulnerabilidad activamente explotada" y un "incidente grave"?
Definiciones distintas, plazos de informe final distintos. Ambas vías comparten la cadencia de aviso temprano en 24 horas y notificación en 72 horas.
- Vulnerabilidad activamente explotada. Aquella respecto de la cual existe evidencia fiable de que un actor malicioso la ha explotado sin permiso del titular del sistema. Informe final: 14 días después de que se disponga de una medida correctora o paliativa.
- Incidente grave. Ya sea (a) aquel que afecta o puede afectar negativamente a la capacidad del producto de proteger la disponibilidad, autenticidad, integridad o confidencialidad de datos o funciones sensibles o importantes, o (b) aquel que ha conducido o puede conducir a la introducción o ejecución de código malicioso en el producto o en la red de un usuario. Informe final: un mes desde la notificación de 72 horas.
¿Los componentes de código abierto en nuestro producto afectan a las obligaciones del fabricante?
Sí. El fabricante ejerce la diligencia debida sobre cada componente integrado de terceros, incluidos los de código abierto no comerciales.
- Vulnerabilidad en un componente. Notifícala a la entidad que mantiene el componente y remediala en tu propio producto.
- Compartir correcciones aguas arriba. Cuando el fabricante haya desarrollado una corrección, comparte el código o la documentación pertinentes con el mantenedor del componente cuando proceda, en formato legible por máquina cuando sea aplicable.
- Cobertura del SBOM. Al menos las dependencias de primer nivel.
- Los administradores de OSS son una categoría distinta. Régimen más ligero, no el régimen del fabricante.