El reloj del CRA empieza a correr el 11 de septiembre

 

El 11 de septiembre no hay que presentar nada. Y precisamente por eso va a pillar a mucha gente

Dentro de unos días entra en juego la primera obligación real del Reglamento de Ciberresiliencia (CRA). No hay formulario que rellenar, ni registro, ni declaración. Simplemente, a partir del 11 de septiembre de 2026, si un fabricante detecta que una vulnerabilidad de su producto está siendo explotada activamente, o sufre un incidente grave que afecta a la seguridad del producto, tiene 24 horas para dar el aviso temprano, 72 para la notificación completa y 14 días para el informe final. Los incidentes graves, un mes.

Ese es el problema. Los plazos con fecha se preparan. Los plazos que se activan con un evento hay que tenerlos montados antes, porque el día que suena el teléfono ya no da tiempo a montar nada.

Y hay un detalle que se pasa por alto con demasiada frecuencia: esa obligación no aplica solo a los productos nuevos. Aplica a todo lo que esté en el mercado, incluidas las máquinas que se vendieron hace ocho años y siguen produciendo en una planta de Navarra o de Gipuzkoa.

He estado leyendo los últimos documentos de CECIMO y de la posición conjunta de las asociaciones de maquinaria (CECE, CECIMO, EGMF, FEM y CEMA), y creo que merece la pena poner en orden lo que dicen, porque el mensaje es bastante más incómodo de lo que parece.

Lo que dicen los documentos, en corto

La guía de CECIMO sobre el CRA deja claro el alcance: cualquier producto con elementos digitales que se ponga en el mercado europeo, incluidas máquinas, componentes industriales, software, hardware y cuasi máquinas. Cuando esos componentes se ensamblan en una máquina, la máquina también tiene que evaluarse y notificar sus vulnerabilidades. Si el fabricante usa componentes de terceros, tiene que asegurarse de que cumplen y reportar al proveedor lo que encuentre.

Además: documentación técnica accesible al menos diez años, periodo de soporte mínimo de cinco años o la vida útil del producto, actualizaciones de seguridad gratuitas, punto de contacto para recibir reportes, y evaluación de riesgos en diseño, desarrollo, producción, entrega y mantenimiento. Las sanciones llegan a 15 millones de euros o el 2,5 % de la facturación mundial.

Una buena noticia para el sector: las máquinas-herramienta no entran en las categorías de productos "importantes" ni "críticos", así que en general basta la autoevaluación. Ojo con la lectura fácil de eso. Autoevaluación no significa que no haya que hacer nada, significa que no viene un tercero a validarte. La documentación, el SBOM, el proceso de vulnerabilidades y la notificación siguen siendo obligatorios exactamente igual.

La posición de CECIMO para el Digital Omnibus pide tres cosas muy razonables: dos años más de transición para los integradores, una ventanilla única de notificación bajo el artículo 16 del CRA que valga a la vez para CRA, NIS2 y RGPD, y armonizar la aplicación de NIS2 entre estados miembros. El argumento de fondo es sólido: un fabricante de máquina no puede empezar a cumplir hasta que sus proveedores de componentes cumplan, y ensamblar, validar y probar una máquina lleva entre 12 y 24 meses.

La posición sobre la revisión del Cybersecurity Act insiste en algo que llevamos años diciendo desde el mundo OT: que ENISA necesita un mandato específico para la tecnología de operación, que la guía europea va demasiado sesgada al mundo IT, y que la certificación debería ser voluntaria, admitir aprobación a nivel de componente y alinearse con IEC 62443. También pide un SBOM adaptado a la fabricación y formación práctica para operadores y técnicos, que es donde está el agujero real.

La posición conjunta sobre el Reglamento de Máquinas es la más cruda. El Reglamento (UE) 2023/1230 se aplica desde el 20 de enero de 2027, con requisitos de ciberseguridad en el 1.1.9 (protección contra la corrupción) y el 1.2.1 f) (seguridad y fiabilidad de los sistemas de mando). Las normas armonizadas no se esperaban antes de finales de 2026. El CRA llega menos de once meses después. Resultado: doble ciclo de conformidad. Las estimaciones que aportan sus asociados hablan de más de un millón de euros por arquitectura de plataforma, y de hasta cinco millones en fabricantes con muchas gamas. De ese sobrecoste, según sus propios números, en torno al 70 % es genérico e inevitable.

Por eso piden alinear las fechas del 1.1.9 y del 1.2.1 f) con la del CRA, el 11 de diciembre de 2027.

El dato que cambia la planificación

A día de hoy ese aplazamiento no se ha concedido. El Omnibus digital que se publicó en julio (Reglamento 2026/1744) tocó la parte de inteligencia artificial y movió el Reglamento de Máquinas dentro de los anexos del Reglamento de IA, pero no aplazó los requisitos de ciberseguridad. El 20 de enero de 2027 sigue en pie.

Traducido: si alguien está planificando su hoja de ruta asumiendo que Bruselas le va a regalar once meses, está apostando. Y tampoco existe presunción automática de conformidad entre el CRA y el Reglamento de Máquinas. Las sinergias hay que demostrarlas caso por caso.

Mi lectura

El debate se está contando como un problema regulatorio y no lo es del todo. El fondo es industrial: la mayoría de los fabricantes no sabe con precisión qué hay dentro de sus propias máquinas. Qué versiones de firmware, qué librerías, qué PLC de qué fabricante con qué CVE abiertos, qué se puede actualizar y qué no sin parar la línea. Sin eso, ni SBOM, ni gestión de vulnerabilidades, ni notificación en 24 horas. Nada de esto se compra, se construye.

La otra parte de la lectura es más optimista, y es la que a mí me parece la útil. Si el 70 % del esfuerzo es genérico, es que se puede hacer una sola vez y que sirva para el Reglamento de Máquinas, para el CRA, para NIS2 y para IEC 62443 a la vez. El coste explota cuando se hace tres veces, en tres proyectos distintos, con tres consultoras distintas y tres documentos que no hablan entre sí. Eso sí que es evitable.

Dónde podemos ayudar desde TITANIUM

Lo digo sin adornos, que para eso es mi empresa y se me ve el plumero:

• Saber qué tienes. Inventario y topología de activos industriales, con SBOM y vulnerabilidades asociadas. Es el paso cero de todo lo anterior y es literalmente para lo que construimos Rutile, que además cubre gestión de backups de configuración y despliegue controlado de parches.
• Saber cuánto te falta. Análisis de brecha frente a IEC 62443 y frente a los requisitos esenciales del Anexo I del CRA, con un plan que priorice por riesgo y no por catálogo.
• Montar el proceso de las 24 horas. Quién detecta, quién decide si una vulnerabilidad está "activamente explotada", quién firma, quién habla con el CSIRT y con ENISA, y qué se le cuenta al cliente. Con nuestro SOC industrial detrás cuando hace falta vigilancia continua.
• Seguridad de producto. Pentest y evaluación de dispositivos embebidos y máquina conectada, incluida la revisión de diseño antes de que el problema esté fabricado en serie.
• Cadena de suministro. Due diligence de componentes de terceros y requisitos de ciberseguridad que se puedan meter en los pliegos y contratos con proveedores, que es donde de verdad se gana o se pierde esta batalla.
• Formación. La de verdad, para ingeniería y mantenimiento, no la del vídeo de phishing de doce minutos.

Si eres fabricante de maquinaria y todavía no tienes claro quién descuelga el teléfono el día que haya que notificar algo en 24 horas, empieza por ahí. El resto del calendario se ordena solo cuando esa pregunta tiene respuesta.

Y si quieres que le demos una vuelta juntos, aquí estamos.

https://www.titaniumindustrialsecurity.com

#CiberseguridadIndustrial #CRA #ReglamentoDeMáquinas #NIS2 #IEC62443 #OTSecurity