Arquitectura de firmware para el Cyber Resilience Act

El 11 de septiembre de 2026 entró en vigor el primer plazo firme del Cyber Resilience Act de la UE: cualquier fabricante que ponga un «producto con elementos digitales» en el mercado de la UE ahora debe reportar a ENISA las vulnerabilidades explotadas activamente dentro de las 24 horas siguientes a enterarse de ellas. El cumplimiento total, incluido el marcado CE bajo las nuevas reglas, no vence hasta diciembre de 2027. Pero el reloj de reporte ya está corriendo, y tomó a muchas empresas pequeñas de hardware sin respuesta a la pregunta que ahora les hace un distribuidor, un inversionista o un cliente: ¿qué hay en tu firmware y cómo lo parchas?

Si fabricas un producto conectado y lo vendes en Europa, esto no es un problema de trámites que puedas pasarle a un consultor después. Es un conjunto de decisiones de ingeniería — arquitectura del bootloader, firma de actualizaciones, seguimiento de dependencias — que son baratas mientras la placa todavía está en esquemático y caras de añadir cuando ya se envió.

Qué cambió realmente, y cuándo

Las obligaciones del CRA llegan por etapas, y es fácil confundirlas:

Fecha	Qué entra en vigor
11 de septiembre de 2026	Los fabricantes deben reportar a ENISA las vulnerabilidades explotadas activamente y los incidentes graves dentro de las 24 horas siguientes a enterarse de ellos
11 de diciembre de 2027	Cumplimiento total: marcado CE bajo el CRA, documentación técnica, evaluación de conformidad y las obligaciones más amplias de seguridad desde el diseño

La brecha entre esas dos fechas es donde está la mayor parte de la confusión actual. A las empresas se les dice, correctamente, que tienen hasta finales de 2027 para cumplir del todo — y concluyen, incorrectamente, que todavía no se les exige nada. La obligación de reporte ya está vigente, y reportar una vulnerabilidad que no puedes parchar (porque no hay una ruta de actualización firmada, o no hay registro de qué versión de biblioteca corre en campo) convierte un requisito de divulgación en una conversación mucho peor con un regulador.

A quién le habla realmente la ley

Las obligaciones del CRA recaen en el «fabricante» — la entidad que pone el producto en el mercado de la UE con su propio nombre o marca. Si una startup diseña un sensor conectado, contrata la escritura del firmware y lo vende con su propia marca, esa startup es el fabricante, sin más, sin importar quién escribió el código. Un socio de diseño o de manufactura por contrato no es el fabricante legal a menos que también sea quien pone su nombre en la caja y vende en la UE.

Esa distinción importa para cómo leer cualquier cosa escrita sobre esto, incluida esta nota. Tampoco cambia la realidad de ingeniería: quien termine siendo legalmente responsable de una divulgación en 24 horas y de un compromiso de actualizaciones por más de cinco años necesita que exista la capacidad de fondo — una lista de materiales del software y una forma de enviar una corrección firmada. Si esa capacidad no se diseñó dentro del producto, resolverlo es problema del fabricante, pero es la arquitectura del firmware la que determina si resolverlo toma un fin de semana o un rediseño del hardware.

Tres cosas que son casi imposibles de adaptar después

Una lista de materiales del software. El CRA exige un registro legible por máquina de lo que hay en el software del producto — versión del RTOS, HAL del fabricante, cualquier biblioteca de terceros, incluso el código generado por una herramienta como STM32CubeMX o MCUXpresso. Producirlo después significa reconstruir, de memoria y con commits viejos, exactamente qué versión de FreeRTOS, lwIP o mbedTLS se incluyó en una placa que salió hace dieciocho meses. Producirlo como parte del build — un script que recorre el árbol de dependencias y emite un archivo CycloneDX o SPDX en cada build — cuesta casi nada cuando está desde el primer commit.

Una ruta de actualización firmada y segura ante fallas. Esta es la que realmente requiere una decisión de hardware, no solo un parche de firmware. Partes como las familias STM32L5/U5/H5 con TrustZone-M, el nRF5340 de Nordic con sus núcleos de aplicación y de red separados, o las partes i.MX RT de NXP con EdgeLock tienen una cadena de arranque seguro documentada y están hechas para guardar dos imágenes de firmware de modo que una actualización fallida regrese a una imagen buena conocida. A una placa diseñada alrededor de una parte sin ese soporte, con un solo banco de flash y un bootloader que confía en lo que llegue por el puerto de depuración, no se le puede añadir después una ruta de actualización firmada de doble imagen sin más flash, otra ROM de arranque o, en el peor caso, un MCU nuevo. Eso es un rediseño, no un release de firmware.

Un proceso para vigilar dependencias. Una lista de materiales del software solo sirve si alguien la compara con las fuentes de CVE del RTOS y las bibliotecas que lista, y existe una forma repetible de compilar, firmar y publicar una imagen parchada cuando aparece algo. Un plan único de «lo resolvemos si pasa» es lo que convierte una ventana de reporte de 24 horas en una ventana perdida.

Lo que revisa un ingeniero cuidadoso, haya plazo o no

Nada de esto requiere estar seguro de que hoy estás dentro del alcance del CRA. Vale la pena revisarlo de todos modos, porque los mismos hábitos reducen fallas en campo que no tienen nada que ver con la regulación:

• ¿El MCU elegido tiene una ruta de arranque seguro documentada en su manual de referencia, o «seguro» significa «todavía no hemos revisado el puerto de depuración»?
• ¿La flash está particionada para al menos dos imágenes de firmware, con un bootloader que verifica una firma antes de saltar a cualquiera de ellas?
• ¿El build produce una lista de componentes automáticamente, o alguien tiene que acordarse de actualizar una hoja de cálculo?
• ¿Quién, específicamente, vigila las fuentes de CVE de las dependencias con las que sale este producto, seis meses después de que salió por la puerta?
• Si mañana se necesitara una corrección crítica, ¿cuántas placas en campo podrían recibirla realmente, y cómo sabrías que la recibieron?

Un «no» a cualquiera de estas es una decisión de diseño tomada una vez, temprano, que se encarece cada mes que el producto se envía sin ella.

Cómo lo abordamos

Cuando diseñamos firmware para un producto conectado, elegimos el MCU y particionamos la flash con una ruta de actualización firmada de doble imagen y una lista de componentes automatizada desde el principio, haya salido o no el CRA en la conversación. Si ya tienes una placa en campo y quieres saber qué haría falta para añadir una ruta de actualización real o generar una SBOM precisa sin rediseñar el hardware, envíanos el esquemático y el repositorio del firmware y te diremos qué falta.