Cyber Resilience Act: qué exige al hardware

Dos fechas, y la cercana se pasa por alto

El Reglamento (UE) 2024/2847, el Cyber Resilience Act (CRA), cubre los «productos con elementos digitales» comercializados en el mercado de la Unión. En la práctica: todo lo que lleva firmware. Para el hardware de consumo y de salud, eso equivale a casi todo lo que se envía hoy.

En la mayoría de las presentaciones aparece una fecha: 11 de diciembre de 2027, cuando la conformidad plena es exigible y un producto no conforme ya no puede introducirse en el mercado. Las hojas de ruta se alinean con ella.

Antes llega otra: el 11 de septiembre de 2026, inicio de las obligaciones de notificación del artículo 14. Se pasa por alto porque no es un plazo de diseño y por tanto no aparece en ninguna planificación de hardware.

Debería aparecer. Este es el motivo.

El reloj de notificación mira hacia atrás

Desde el 11 de septiembre de 2026, un fabricante que tenga conocimiento de una vulnerabilidad explotada activamente en su producto, o de un incidente grave que afecte a su seguridad, entra en un reloj escalonado:

Fase	Plazo desde el conocimiento
Alerta temprana	24 horas
Notificación técnica	72 horas
Informe final	14 días (vulnerabilidad explotada) / 1 mes (incidente grave)

Los destinatarios son ENISA y el CSIRT nacional competente.

El párrafo que conviene leer dos veces: la obligación de notificar se aplica a productos ya comercializados en el mercado de la UE, incluidas las unidades introducidas antes del plazo. Los requisitos de diseño del anexo I afectan a los productos introducidos a partir de diciembre de 2027, y a los anteriores solo si sufren una modificación sustancial. La obligación de notificar no tiene ese corte.

Así que la pregunta práctica para una marca en septiembre de 2026 ya no es «¿es conforme mi próximo producto?». Pasa a ser:

Un dispositivo que enviamos en 2023 tiene una vulnerabilidad bajo explotación activa. ¿Nos enteraremos en 24 horas, y conocemos su contenido lo suficiente para describir el problema?

En la mayoría de las marcas de hardware, la respuesta honesta a la segunda mitad es no. Eso es un problema de registros de fabricación antes que un problema de seguridad.

→ Otro plazo europeo que se convierte en una decisión de carcasa: Reglamento europeo de baterías 2027

El periodo de soporte es una decisión de lista de materiales

El anexo I exige un periodo de soporte declarado de al menos cinco años, o la vida útil prevista si es menor, con una fecha de fin que el comprador conoce en el momento de la compra. Durante ese periodo el fabricante gestiona vulnerabilidades y entrega parches de seguridad de forma gratuita.

Léalo como una restricción de aprovisionamiento, porque eso es.

Si el módulo de radio de su diseño ejecuta un SDK del proveedor que deja de recibir parches en el tercer año, no podrá parchear lo que se apoya encima. Habrá declarado cinco años de soporte en la venta y perdido la capacidad de cumplirlo en el tercero, por una decisión tomada al elegir componentes.

Dos preguntas pasan así a formar parte de la cualificación de un módulo, junto al precio, el plazo y la segunda fuente:

• ¿Cuánto tiempo publicará este proveedor parches de seguridad para este componente?, por escrito, y qué ocurre al final de su vida.
• ¿Existe una segunda fuente con una pila a la que pudiéramos migrar sin rediseñar la placa?

Ninguna de las dos suele figurar en una revisión de lista de materiales. Ambas pertenecen a la misma conversación que el riesgo de suministro, porque es el mismo tipo de riesgo: un componente deja de estar disponible, en un caso comercialmente y en otro jurídicamente.

→ Cómo se califican las piezas y qué significa un rojo: Matriz de riesgo de suministro de componentes

El SBOM tiene que describir lo que hay realmente dentro

El anexo I parte II exige una lista de materiales de software en un formato común y legible por máquina, que cubra al menos las dependencias de primer nivel.

Para una aplicación web eso es una salida de las herramientas de compilación. Para un producto físico es una cuestión de ensamblaje, porque el firmware rara vez es todo suyo. Un dispositivo de consumo conectado típico lleva:

• el firmware de aplicación escrito para este producto
• un SDK del proveedor que llegó con el módulo de radio
• una pila de protocolo (Bluetooth, Wi-Fi, Thread) entregada como binario
• un sistema operativo en tiempo real
• bibliotecas de código abierto arrastradas por cualquiera de los anteriores

La marca suele poseer el primer punto y no tiene visibilidad sobre el resto, porque llegó a través de la fábrica y de sus proveedores de módulos. Componer un SBOM real implica preguntar a la fábrica, y que la fábrica pregunte a sus proveedores.

Esa petición sale mucho más barata durante el desarrollo que después de un incidente. Además revela si su proveedor de módulos está dispuesto a decir qué hay en su binario, un dato que conviene tener antes de integrarlo.

Seguro por defecto, y capaz de actualizarse

Otros dos requisitos del anexo I caen sobre decisiones de hardware muy tempranas.

Seguro por defecto significa que el producto sale con una configuración segura: sin contraseñas por defecto compartidas, sin servicios ni puertos abiertos innecesarios, con la superficie de ataque reducida. Son valores por defecto del firmware, y los fija normalmente quien escribe el firmware. Si es su fabricante, la implementación es suya y la especificación es de usted.

Actualizaciones de seguridad gratuitas durante el periodo de soporte presuponen que el producto pueda recibirlas. Que pueda o no, no es una cuestión de software:

• Presupuesto de flash. Un esquema de dos particiones para actualizaciones remotas seguras duplica aproximadamente el espacio necesario. Descubrirlo tras congelar la lista de materiales deja solo cambiar la memoria o renunciar a la actualización remota.
• Conectividad. Un dispositivo sin camino a Internet solo se actualiza en campo o mediante una aplicación compañera, ambos con tasas de finalización muy por debajo de lo que supone una obligación de cinco años.
• Energía. Una actualización que arranca con la batería baja y deja el aparato inservible es peor que ninguna actualización: la lógica de actualización necesita un umbral de carga, que necesita un medidor.

Nada de esto se añade barato después. Todo se decide en la revisión de ingeniería, antes del molde.

→ La revisión donde estas restricciones salen a la luz: Revisión de riesgo DFX antes del molde

Qué cambia de verdad en un proyecto

Para un producto que entra ahora en desarrollo y se venderá en la Unión, cambian tres cosas:

1. La cualificación de módulos gana una pregunta sobre la vida de los parches. Pida por escrito el compromiso de soporte del proveedor, y trate «eso no lo publicamos» por lo que es: una respuesta.
2. El SBOM pasa a ser un entregable. Nómbrelo en el contrato de desarrollo junto a planos e informes de ensayo, para que llegue con el producto en lugar de reconstruirse bajo un reloj de 24 horas.
3. La actualizabilidad se especifica antes del molde. Reserva de flash, esquema de particiones y vía de actualización cuestan poco en fase de concepto y mucho una vez que existe la carcasa.

Para los productos ya en el mercado la pregunta a corto plazo es más estrecha y más urgente: ¿puede averiguar qué llevan dentro, y en cuánto tiempo?

Nota sobre el alcance

Esto es una lectura de normativa publicada, no asesoramiento jurídico, y los detalles de aplicación del CRA se siguen concretando mediante normas y guías. Confirme con asesoría cualificada cómo aplica a su clase de producto y a sus mercados antes de construir un plan sobre ello. Lo bastante asentado para diseñar es la dirección: el soporte de seguridad se ha convertido en un compromiso declarado y fechado, y las decisiones que lo hacen posible o imposible se toman en el hardware, pronto.

→ El detalle a nivel de placa, del esquemático a la línea SMT: Fabricación por contrato de electrónica de consumo