Cyber Resilience Act (CRA) 2026–2027: lo que ya sabemos, lo que aún falta y cómo preparar realmente el producto, antes de que aparezcan las normas armonizadas

Qué sabemos hoy con certeza (y por qué no es un «tema para 2027»)

Cyber Resilience Act puede parecer otro documento «de Bruselas» que se puede dejar para más adelante. Es una reacción natural, sobre todo si la empresa funciona al ritmo de los proyectos: prototipo, implantación, producción en serie, servicio. A menudo, las regulaciones llegan como un «requisito final»: algo que se cierra al final. El CRA cambia esa lógica, porque no se limita a lo que se ve en el producto el día de la venta. Trata de si el fabricante es capaz de mantener la seguridad del producto a lo largo del tiempo y demostrar que lo hizo de forma consciente, y no por casualidad.

El hecho más importante es sencillo, pero tiene consecuencias estratégicas: el CRA es una regulación de producto, integrada en la mecánica del mercado de la UE (incluido el marcado CE). La Comisión Europea indica explícitamente que los productos deben llevar el marcado CE como señal de conformidad con el CRA, y que la aplicación recae en las autoridades de vigilancia del mercado. Por tanto, no es un «estándar de TI» que pueda tratarse como un programa interno de mejora. Es un marco que afecta a la posibilidad de vender.

Fechas que ordenan el enfoque

En el propio texto del Reglamento (UE) 2024/2847 se aprecia una aplicación por etapas. El CRA se aplica a partir del 11 de diciembre de 2027, pero con excepciones claras. El artículo 14 (notificación) se aplica desde el 11 de septiembre de 2026, y el capítulo sobre la notificación de los organismos de evaluación de la conformidad (capítulo IV) desde el 11 de junio de 2026. Son tres fechas que conviene tratar como «hitos», porque corresponden a tres tipos distintos de preparación: operativa, institucional y de producto.

La Comisión lo comunica de forma aún más simple: el CRA entró en vigor el 10 de diciembre de 2024, las obligaciones principales a partir del 11 de diciembre de 2027 y la notificación a partir del 11 de septiembre de 2026. Si alguien en la empresa dice «tenemos tiempo hasta 2027», normalmente se refiere a los requisitos de diseño y a la evaluación de la conformidad. Pero la notificación es anterior y se refiere a hechos que no esperan al calendario.

Notificación: una obligación que exige un proceso (y no un documento)

El requisito de notificación es un buen indicador, porque muestra cómo entiende el CRA la «ciberseguridad del producto». No es una declaración de intenciones ni una «política». Es un proceso que debe funcionar en una situación de estrés: cuando aparece una vulnerabilidad explotada activamente o un incidente grave.

La Comisión lo describe de forma inequívoca: el fabricante debe notificar vulnerabilidades explotadas activamente y incidentes graves que afecten a la seguridad del producto. Se exige un «aviso temprano» en 24 horas desde que se tiene conocimiento, una notificación completa en 72 horas y un informe final: hasta 14 días después de que esté disponible la medida correctiva para vulnerabilidades explotadas activamente y en el plazo de un mes para incidentes graves.

En la práctica, esto significa que la organización necesita algo más que una checklist. Necesita un mecanismo que responda a tres preguntas: cómo sabremos que el problema existe; quién determina si ya es «explotada activamente» o «grave»; y cómo organizaremos la comunicación de la información y la corrección en un plazo que no deja margen para la improvisación.

Si en las formaciones aparece el caos, a menudo es porque el CRA cae en el vacío entre TI y el producto. Para TI, un «incidente» puede ser un evento en la infraestructura. Para un fabricante, un «incidente» es un evento que afecta al producto en casa del cliente, a la versión, a la configuración, a la forma de implantación. El CRA obliga a unir esos mundos en una única responsabilidad.

Qué abarca el CRA: el producto como relación con la red, no como «un dispositivo sobre la mesa»

En la práctica, al aprender evaluaciones de riesgos de máquinas, entendimos que el riesgo no es una característica de la propia máquina: surge en la relación persona–máquina. En el CRA hay un cambio de perspectiva similar: la seguridad no existe «en el dispositivo», sino en la relación del producto con el entorno digital, el modo de uso y la capacidad del fabricante para reaccionar.

La Comisión, al resumir el CRA, llama la atención sobre la definición de «productos con elementos digitales» y sobre el hecho de que las obligaciones de notificación se aplican a todos esos productos puestos a disposición en el mercado de la UE, también a los introducidos antes del 11 de diciembre de 2027. Esta precisión es clave, porque desmonta un mito frecuente: «para los productos antiguos no importa». La notificación sí importa.

Qué falta todavía (normas armonizadas) y por qué no debería paralizarnos

En conversaciones sobre el CRA aparece a menudo la frase: «todavía no hay normas armonizadas, así que no se puede hacer nada». Suena lógico, pero encierra una trampa. Las normas armonizadas son una herramienta que facilita demostrar la conformidad (presunción de conformidad), pero no son la única vía para construir una seguridad real del producto. Y tampoco son un requisito para empezar a diseñar correctamente.

La Comisión aborda el tema de los estándares de forma explícita a través de la página «CRA Standardisation» e informa de que ha adoptado la solicitud de normalización M/606, que abarca un conjunto de 41 estándares de apoyo al CRA, tanto horizontales como verticales (de producto). Esto es importante porque muestra que la UE entiende el problema del mercado: sin estándares, las empresas construirán la conformidad cada una a su manera, y la vigilancia del mercado lo tendrá más difícil.

Estándares horizontales y verticales: qué significa para el fabricante

En pocas palabras:

• los estándares horizontales deben describir el «cómo» construir y mantener la seguridad del producto con independencia de la categoría (procesos, métodos, enfoque basado en el riesgo),
• los estándares verticales deben concretar los requisitos para clases específicas de productos (allí donde los riesgos y las arquitecturas son típicos).

Esta distinción tiene consecuencias prácticas. Si desarrollas un producto industrial en el que parte del entorno es «OT» y el ciclo de vida es largo, necesitarás estándares que no estén escritos para una aplicación SaaS. Y precisamente por eso los estándares verticales importan: ayudan a bajar del nivel de principios generales a lo que hay que controlar en arquitecturas reales.

Calendario de trabajos: los estándares llegarán por fases, no «en un paquete antes de 2027»

La Comisión, en sus materiales sobre la implementación del CRA, muestra que el CRA se despliega por etapas y que los estándares deben apoyar ese proceso a lo largo del tiempo. En cuanto a los hechos que hoy son seguros: tenemos un reglamento formalmente adoptado y tenemos en marcha el mecanismo de normalización (M/606).

Lo más importante para la práctica es entender una frase: incluso cuando un estándar sea elaborado por las organizaciones de normalización, la «presunción de conformidad» en sentido jurídico solo aparece cuando la referencia a la norma se publica como norma armonizada en el Diario Oficial de la UE. Esta es la mecánica común del enfoque de armonización de la UE: los estándares son el puente entre el derecho y la práctica de ingeniería, pero ese puente debe ser «reconocido» formalmente por la UE.

Desde la perspectiva del fabricante, esto significa que los años 2026–2027 serán un periodo en el que parte de las empresas actuará basándose en sus propios métodos para demostrar la conformidad (basado en el riesgo + evidencias), y otra parte ya estará mapeándose contra los estándares que vayan apareciendo. Y eso es normal.

«Que no haya normas» no significa «que no haya obligación»: significa más peso de las evidencias

Aquí aparece una consecuencia clave: si no hay normas que ofrezcan la vía más sencilla para demostrar la conformidad, aumenta la importancia de lo que, en la práctica de auditoría, siempre resulta decisivo: un rastro de decisiones coherente.

¿Qué riesgos evaluamos? ¿Qué escenarios asumimos como realistas? ¿Cómo seleccionamos las medidas de protección? ¿Cómo gestionamos las vulnerabilidades? ¿Durante cuánto tiempo damos soporte al producto? ¿Cómo informamos al cliente? El CRA no exige que el fabricante «adivine futuras normas EN». Exige que el fabricante sepa demostrar que sus decisiones no fueron aleatorias, sino basadas en el riesgo y en el estado de la técnica.

Cómo preparar de verdad un producto para el CRA (hoja de ruta para el fabricante y el integrador)

El mayor valor del CRA es que obliga a madurar: la ciberseguridad deja de ser un añadido al producto y pasa a ser una propiedad del propio producto. Solo que la madurez no nace de una declaración. Nace de un proceso lo bastante preciso como para funcionar en la práctica y lo bastante simple como para que la ingeniería no empiece a esquivarlo.

En la evaluación de riesgos de máquinas, las mejores decisiones de diseño aparecen cuando dejamos de preguntar «qué peligros tiene la máquina» y empezamos a preguntar «en qué tareas y estados está expuesta la persona». En el CRA ocurre algo análogo: dejamos de preguntar «qué vulnerabilidades tiene el producto» y empezamos a preguntar «en qué condiciones el producto queda expuesto y qué es capaz de hacer entonces el fabricante». Este cambio de enfoque ordena el trabajo.

Paso 1: Define el producto como un sistema (y no como un dispositivo)

Empieza por definir qué es, en tu caso, un «producto con elementos digitales». No solo el hardware y el firmware, sino también lo que a menudo se pasa por alto porque no cabe en la caja: componentes, bibliotecas, mecanismos de actualización, servicios sin los cuales el producto no cumple su función. En el CRA esto es importante, porque la responsabilidad del fabricante se refiere a lo que llega al mercado como producto, y no solo a lo que ha fabricado el departamento de mecánica.

Este es también el primer momento en el que los integradores deberían ser honestos consigo mismos: si integras componentes y los configuras de un modo que crea un «producto final» a ojos del cliente, no eres solo alguien que «implanta». Eres cocreador del riesgo y cocreador de la responsabilidad.

Paso 2: Realiza la evaluación de riesgos del CRA de manera que sea una herramienta de decisión

No se trata de una «matriz» en unas diapositivas. Se trata de una evaluación de riesgos que conduce a decisiones de diseño y que es repetible.

En la práctica, un buen enfoque de la CRA empieza con una pregunta sencilla: ¿cuáles son los escenarios reales de uso indebido en el entorno del cliente, y no solo en el laboratorio? ¿Quién tiene acceso de servicio? ¿Cómo es la red? ¿Con qué frecuencia actualizamos? ¿Cuáles son las consecuencias de una parada? En la industria, estas preguntas son más incómodas que en IT, porque las respuestas a menudo son: «no podemos actualizar cada semana» o «no tenemos telemetría». Y precisamente por eso hay que plantearlas. La CRA es un requisito legal, pero sus efectos son de diseño.

Paso 3: Construye el «vulnerability handling» como un proceso de producto, no como una reacción de crisis

Los requisitos de notificación descritos por la Comisión (24h/72h/14 días/mes) son implacables para una organización que no tiene un proceso. Si quieres estar listo para el 11 de septiembre de 2026, debes tratar el «vulnerability handling» como parte del ciclo de vida del producto, y no como una «tarea del equipo de security».

Esto significa:

• un único canal para recibir notificaciones (CVD policy + contacto),
• un triaje con responsable y criterios,
• un mecanismo para construir y entregar security updates,
• un modelo de comunicación con los clientes que no sea improvisado,
• preparación para la notificación (quién reporta, con qué datos, con qué rapidez).

Todo esto suena a trabajo «organizativo». En la práctica, es trabajo de producto, porque afecta a versiones, compatibilidad, arquitectura de actualizaciones y estrategia de soporte.

Paso 4: Elige el support period como una decisión de negocio, no como un requisito mínimo

Si tus productos permanecen en la industria durante 10–15 años, el support period es estratégico. La CRA obliga a que el soporte no sea una promesa sin respaldo. Esto significa que el support period debe derivarse de un análisis: cuánto tiempo se usará el producto, cómo es la cadena de suministro de componentes, durante cuánto tiempo podrás entregar correcciones. En la práctica, el support period empieza a «tirar» de todo el ecosistema: contratos con proveedores, disponibilidad del build environment, mantenimiento de toolchains e incluso decisiones sobre si el producto tiene funciones remotas o está aislado.

Si tratas el support period como una formalidad, como muy tarde en 2027 entrarás en conflicto: el cliente espera soporte y tú ya no tienes recursos ni dependencias para proporcionarlo. La CRA no crea este problema; la CRA solo lo pone en evidencia.

Paso 5: Ordena la cadena de suministro: hablar con los proveedores es parte del cumplimiento

En la CRA no hay «magia» que haga que los componentes externos se vuelvan seguros. Si tu dispositivo se basa en bibliotecas, módulos de comunicación, sistema operativo, SDK o componentes de hardware, tu riesgo depende directamente de la calidad de las prácticas del proveedor.

Por eso conviene introducir ya una conversación sobre aspectos que no suenan a marketing, sino a ingeniería:

• si el proveedor puede informar sobre vulnerabilidades de forma predecible,
• cuál es su tiempo de respuesta,
• si dispone de un proceso de publicación de correcciones,
• si puede mantener el componente durante un periodo coherente con tu support period.

Aquí es donde la CRA realmente toca el negocio: un proveedor que no sabe gestionar vulnerabilidades no es «más barato». Es un riesgo regulatorio.

Paso 6: Construye la documentación como un rastro coherente: derecho → riesgo → decisión → evidencia

En las auditorías de conformidad siempre gana la coherencia. Si de la evaluación de riesgos se desprende que una interfaz es crítica y la documentación no describe cómo la proteges; si declaras que las actualizaciones son seguras y no puedes mostrar cómo garantizas la integridad de los paquetes; si dices que tienes un proceso de gestión de vulnerabilidades y no puedes mostrar cómo haces el triaje de los reportes, eso no es «falta de papeles». Es falta de evidencia de que el proceso funciona.

En la CRA, ante la ausencia de normas armonizadas, este rastro es especialmente importante. Porque será la base de la conversación con la autoridad de vigilancia del mercado, con el cliente enterprise y, en algunas categorías de productos, también con la entidad de evaluación de la conformidad. Y, lo que es igual de importante: será la base de la estabilidad interna. El equipo sabe por qué hacemos algo, y no solo «que tenemos que hacerlo».

Conclusión: la CRA como un nuevo requisito de diseño, no como un «proyecto de compliance»

Si tuviera que quedarme con una sola idea que conecte las tres partes: la CRA no es un problema que se resuelve al final. Es un marco que cambia la forma de pensar el producto. Igual que ISO 12100 enseña que el riesgo surge en la relación hombre–máquina, la CRA enseña que la ciberseguridad surge en la relación producto–entorno–ciclo de vida del fabricante.

Las normas armonizadas llegarán y simplificarán ciertos caminos. Pero su ausencia no es motivo para quedarse inmóvil. Es motivo para centrarse en lo que la CRA evalúa siempre: en las decisiones, las evidencias y la capacidad de actuar en la realidad, no en una presentación.