Lo que el automóvil ya aprendió, y el resto de la industria va a aprender hasta 2027
El sector del automóvil fue el primero obligado a tratar la ciberseguridad como propiedad del producto a lo largo del ciclo de vida, con la UNECE R155/R156 y la ISO/SAE 21434. Los vehículos quedan fuera del CRA precisamente por eso, y también por eso sirven de anticipo.
- Publicado
Hay un sector donde las ideas centrales del Cyber Resilience Act (seguridad como propiedad del producto, gestión de riesgo a lo largo del ciclo de vida, actualizaciones gestionadas, responsabilidad del fabricante después de la venta) no son novedad de 2027. Son obligación de homologación desde 2022. Trabajamos en ese sector, y es esa experiencia la que más informa la forma en que leemos el CRA.
El régimen del automóvil en dos piezas
UNECE R155 condiciona la homologación de vehículos a la existencia de un Cyber Security Management System (CSMS) certificado en el fabricante: procesos organizativos que cubren la identificación y gestión de riesgos de ciberseguridad del vehículo, de la fase de desarrollo a la fase posproducción, incluida la monitorización de amenazas y la respuesta a incidentes en la flota en circulación. No se homologa un vehículo nuevo en la UE sin esto; la exigencia pasó a ser aplicable a todos los vehículos nuevos vendidos a partir de julio de 2024.
UNECE R156 hace lo mismo para las actualizaciones de software: un Software Update Management System (SUMS), con control de versiones, evaluación de impacto de cada actualización (incluido sobre la homologación) y, para actualizaciones over-the-air, garantías de ejecución segura.
Debajo de las dos, la ISO/SAE 21434 aporta la ingeniería: análisis de amenazas y evaluación de riesgo (TARA), requisitos de ciberseguridad en cascada por la cadena de suministro, validación, y actividades de monitorización y respuesta posdesarrollo.
Quien conoce el Anexo I del CRA reconoce el mapa: evaluación de riesgos del producto, requisitos esenciales de diseño, gestión de vulnerabilidades a lo largo del soporte, actualizaciones seguras. La estructura es la misma; cambian la escala y el vocabulario. Y es porque los vehículos ya tienen régimen propio por lo que el CRA los excluye expresamente de su ámbito, igual que excluye los productos sanitarios y la aviación, los otros sectores con regulación de producto preexistente.
Cinco lecciones que al automóvil le costaron caras
El valor de mirar al automóvil está menos en la teoría que en los errores que la industria ya pagó y que el resto del mercado puede evitar:
- La cadena de suministro es el proyecto. Un OEM no escribe la mayor parte del software del coche; lo escriben los Tier 1 y 2. La R155 obligó a empujar requisitos de ciberseguridad hacia abajo por los contratos de suministro, y la lección fue que hacerlo tarde es carísimo. En el CRA, el equivalente es la diligencia debida sobre componentes de terceros: el fabricante responde por el producto entero, incluido lo que no escribió.
- La TARA solo es útil si está viva. Los primeros análisis de riesgo del automóvil fueron documentos de homologación, hechos una vez. Los que funcionan son artefactos mantenidos, que se actualizan cuando la arquitectura cambia o surge una nueva clase de ataque.
- La monitorización posventa necesita órgano propio. La R155 forzó a los fabricantes a montar capacidad permanente de vigilancia de amenazas sobre producto en campo, el embrión del PSIRT. Es exactamente la capacidad que el artículo 14 del CRA presupone cuando da 24 horas para el primer aviso.
- Actualizar una flota es un producto en sí. El automóvil aprendió que OTA no es una funcionalidad, es una infraestructura con gestión de claves, despliegue por fases, rollback y telemetría de éxito. Cualquier fabricante de IoT que declare cinco años de soporte va a redescubrir esto.
- Certificar procesos es distinto de garantizar productos. El CSMS certifica que la organización tiene procesos; no impide un mal producto. La tentación de gestionar la conformidad como ejercicio documental existe en todos los regímenes, y la vigilancia del mercado del CRA, a diferencia de la homologación, puede llamar a la puerta después de la venta.
Qué significa esto para quien fabrica
Para un fabricante fuera del automóvil, la lectura práctica: el CRA no pide nada que una industria entera no haya ya operacionalizado, incluidos proveedores de tamaño medio. Esa es la buena noticia. La mala es el corolario: los argumentos de imposibilidad (“no se pueden gestionar vulnerabilidades durante años”, “no se puede exigir SBOM a los proveedores”) ya fueron refutados en la práctica por un sector con márgenes ajustados y cadenas de suministro bastante más complejas que las de la mayoría de los productos IoT.
La ventaja de quien empieza ahora: puede copiar la forma final sin pagar las iteraciones. TARA viva, requisitos en cascada en los contratos, capacidad de respuesta permanente, actualización como infraestructura. El automóvil tardó una década en llegar aquí, y el diseño está público.
Fuentes
- UNECE, Regulation No. 155 — Cyber security and cyber security management system — https://unece.org/transport/documents/2021/03/standards/un-regulation-no-155-cyber-security-and-cyber-security
- UNECE, Regulation No. 156 — Software update and software update management system — https://unece.org/transport/documents/2021/03/standards/un-regulation-no-156-software-update-and-software-update
- ISO/SAE 21434:2021, Road vehicles — Cybersecurity engineering — https://www.iso.org/standard/70918.html
- Reglamento (UE) 2024/2847, artículo 2 (exclusiones de ámbito, incl. vehículos al amparo del Reg. (UE) 2019/2144) — https://eur-lex.europa.eu/eli/reg/2024/2847/oj