Es una de las preguntas que más se repiten en cuanto un producto conectado lleva unos meses en el mercado: hemos sacado una versión nueva de firmware, ¿sigue valiendo el marcado CE? La respuesta corta es que depende de qué haya cambiado. La larga es más interesante, porque encierra una contradicción aparente que casi nadie explica.
Por un lado, modificar un producto ya evaluado puede obligarte a reevaluar su conformidad. Por otro, la propia normativa europea te obliga a poder actualizarlo para corregir vulnerabilidades. Las dos cosas son ciertas a la vez, y la forma de resolverlo no es regulatoria: es de arquitectura.
La idea en una frase: el problema no es actualizar, es no haber decidido de antemano qué puede tocar una actualización y qué no.
Tabla de contenidos
El marcado CE cubre un producto, no una versión de firmware
Cuando declaras la conformidad de un producto, lo que estás declarando es que ese producto, tal y como se comercializa, cumple los requisitos esenciales que le aplican. El expediente técnico describe una configuración concreta: un hardware, unos parámetros y un comportamiento que se midieron y documentaron.
El firmware forma parte de esa configuración. No es un accesorio: en un producto conectado es justamente lo que decide cómo se comporta la radio, cómo se gestionan las credenciales y qué hace el equipo ante un fallo. Por eso una actualización no es automáticamente inocua, aunque tampoco sea automáticamente un problema.
Si aún no tienes claro qué implica el proceso completo, conviene empezar por la base: lo explicamos en la guía sobre costes y precertificación del marcado CE.
Cuándo una actualización es una modificación sustancial
El criterio de referencia es el de la Guía Azul de la Comisión Europea, que distingue entre modificaciones triviales y sustanciales.
La diferencia entre trivial y sustancial
Una modificación es trivial cuando no puede afectar al cumplimiento de los requisitos esenciales. Es sustancial cuando sí puede afectarlos, y entonces el producto modificado debe tratarse, a efectos prácticos, como un producto nuevo.
Fijate en el matiz: el criterio no es si el cambio afectó, sino si puede afectar. Eso desplaza la carga hacia ti: tienes que ser capaz de justificar por qué un cambio concreto no compromete lo que se evaluó.
Quién asume las obligaciones si es sustancial
Cuando la modificación es sustancial, quien la introduce asume las mismas obligaciones que el fabricante original: reevaluar la conformidad, preparar la documentación técnica correspondiente, redactar una nueva declaración UE de conformidad y responder del marcado.
En firmware esto tiene una consecuencia incómoda. Si distribuyes por OTA un cambio sustancial a equipos que ya están en casa de tus clientes, no estás solo modificando producto futuro: estás modificando producto ya comercializado.
Qué cambios de firmware afectan de verdad a la conformidad
En la práctica, la lista de cambios problemáticos es bastante corta y bastante previsible.
Parámetros de radio
Son los primeros sospechosos, porque son exactamente lo que se midió en el laboratorio:
- Potencia de transmisión. Subirla es el caso de manual: el ensayo se hizo con un valor y el producto sale con otro.
- Bandas y canales. Habilitar canales que no estaban activos en el ensayo, o cambiar la región regulatoria configurada.
- Ciclo de trabajo. Relevante en bandas con límites de ocupación; un firmware que transmite más a menudo puede sacarte del límite.
- Modulación o tasa de datos, cuando cambian el ancho de banda ocupado o el espectro emitido.
Funciones de seguridad
Si el firmware implementa una función con papel en la seguridad del producto —una protección térmica, un corte por sobrecorriente, una parada, la gestión de carga de una batería— tocarla es tocar directamente un requisito esencial. Aquí el listón para considerar el cambio sustancial es mucho más bajo.
Caso típico: una actualización que ajusta el perfil de carga de la batería para exprimir autonomía. Suena a mejora de producto y es, en realidad, un cambio en una función de seguridad.
Lo que casi nunca afecta
La mayor parte del trabajo diario de firmware no entra en este terreno: corrección de errores que no tocan seguridad ni radio, cambios de interfaz de usuario, traducciones, telemetría, integraciones de nube, optimizaciones de consumo que no alteran parámetros de transmisión. Son modificaciones triviales y no obligan a nada más que a mantener el registro ordenado.
La paradoja: la normativa te obliga a poder actualizar
Aquí está la parte que rara vez se cuenta. Mientras un lado de la normativa te pide cuidado al modificar, otro te exige poder hacerlo.
EN 18031 y la actualización segura
Desde el 1 de agosto de 2025 son exigibles los requisitos de ciberseguridad del acto delegado 2022/30 de la directiva RED para equipos radio conectados a internet. Las normas armonizadas EN 18031, publicadas por CEN-CENELEC, tratan la actualización del software como un mecanismo de seguridad: hay que poder distribuir correcciones, y hacerlo de forma auténtica y verificable.
Dicho de otro modo: un producto conectado que no se pueda actualizar es, hoy, un producto con un problema de conformidad.
El Cyber Resilience Act lo refuerza
El Reglamento (UE) 2024/2847 va más allá y extiende la obligación a lo largo de la vida útil del producto, con obligaciones de notificación de vulnerabilidades desde septiembre de 2026 y aplicación plena en diciembre de 2027.
La conclusión práctica es que no puedes resolver el dilema dejando de actualizar. Tienes que resolverlo diseñando qué puede cambiar una actualización.
Cómo se gestiona esto en la práctica
Sacar los parámetros regulatorios del alcance del OTA
La solución más limpia es arquitectónica: separar la configuración con relevancia regulatoria —potencia, bandas, límites de carga, umbrales de protección— del código que se actualiza por OTA. Si esos valores viven en una capa que la actualización no toca, el firmware funcional puede evolucionar sin arrastrar el expediente detrás.
Es una decisión que cuesta poco al principio del proyecto y mucho después, igual que ocurre con las decisiones de EMC en el desarrollo del producto.
Versionado y trazabilidad en el expediente
El expediente técnico debe describir el producto que está en el mercado. Con firmware que evoluciona, eso significa mantener:
- qué versión de firmware corresponde a la configuración que se ensayó,
- un registro de cambios por versión,
- y una valoración, aunque sea breve, de si cada versión toca algo con relevancia regulatoria.
Ese tercer punto es el que casi nadie hace y el que resuelve el problema. Una línea por versión diciendo «no afecta a parámetros de radio ni a funciones de seguridad» convierte una duda en una evidencia.
Cuándo toca volver al laboratorio
Cuando el cambio sí toca parámetros medidos, normalmente no hace falta repetir toda la campaña: se repiten los ensayos afectados. Si has cambiado potencia de transmisión, vuelves a los ensayos de radio, no a los de seguridad eléctrica. Por eso conviene saber exactamente qué se midió y con qué configuración.
Cómo lo planteamos en RobotUNO
Como siempre en este terreno, conviene ser claros: no somos laboratorio acreditado ni organismo notificado, y no decidimos por ti si una modificación es sustancial. Esa valoración es del fabricante y, cuando hay dudas serias, del laboratorio.
Lo que hacemos es la parte de diseño, que es la que evita el problema:
- Separar en la arquitectura del firmware lo que tiene relevancia regulatoria de lo que no.
- Implementar actualización segura —firmada y verificada— compatible con los requisitos de EN 18031.
- Dejar montado un esquema de versionado y de registro de cambios que sirva en el expediente técnico.
- Revisar, antes de publicar una versión, si toca algo de lo que se ensayó.
Es parte natural del trabajo en cualquier dispositivo conectado que vaya a estar años en el mercado.
Regla práctica: si antes de publicar una versión no sabes responder «¿esto toca radio o seguridad?», el problema no es la actualización. Es que el firmware no está organizado para poder responder.
Preguntas frecuentes
¿Cada actualización de firmware obliga a recertificar el producto?
No. La inmensa mayoría de actualizaciones son modificaciones triviales: corrigen errores, mejoran la interfaz o añaden funciones que no tocan nada de lo que se evaluó. Solo hay que reevaluar la conformidad cuando el cambio puede afectar a los requisitos esenciales que se demostraron en su momento.
¿Qué cambios de firmware obligan a repetir ensayos de radio?
Los que tocan parámetros que se midieron en el laboratorio: potencia de transmisión, bandas o canales utilizados, ciclo de trabajo, tipo de modulación o el comportamiento de la antena. Si el ensayo de radio se hizo con unos valores y el firmware los cambia, el informe deja de describir el producto que estás vendiendo.
¿Tengo que actualizar el expediente técnico con cada versión?
El expediente tiene que reflejar el producto que está en el mercado. No hace falta rehacerlo con cada parche, pero sí mantener un registro de versiones que permita saber qué firmware corresponde a la configuración evaluada y qué cambió en cada una.
¿La normativa obliga a que el producto se pueda actualizar?
Para equipos radio conectados a internet, los requisitos de ciberseguridad exigibles desde agosto de 2025 implican en la práctica poder distribuir actualizaciones de seguridad de forma auténtica y verificable. El Cyber Resilience Act refuerza esa obligación durante toda la vida útil del producto.
¿Puedo bloquear los parámetros de radio para evitar el problema?
Sí, y es la solución de diseño más limpia. Si la configuración de radio vive en una capa que el OTA no puede modificar, las actualizaciones funcionales dejan de ser un riesgo regulatorio. Es una decisión de arquitectura, y hay que tomarla antes de escribir el gestor de actualizaciones.
¿Tienes un producto conectado que va a seguir evolucionando?
Podemos revisar cómo está organizado el firmware y dejarlo preparado para que las actualizaciones no se conviertan en un problema regulatorio.
