El Cyber Resilience Act para fabricantes
El Reglamento (UE) 2024/2847 impone requisitos de ciberseguridad a quien introduce en el mercado europeo productos con elementos digitales. Esta página es el punto de entrada: qué abarca el reglamento, qué decisiones técnicas obliga a tomar, y cuándo.
- Publicado
- Actualizado
El reglamento se aplica a productos con elementos digitales, desde dispositivos conectados hasta software comercializado como producto. Las obligaciones recaen sobre el fabricante, incluidas las empresas que integran componentes digitales en productos físicos; importadores y distribuidores tienen obligaciones propias.
La diferencia frente a regímenes anteriores es el eje temporal: las obligaciones no terminan con la introducción en el mercado. La gestión de vulnerabilidades, las actualizaciones de seguridad y la comunicación durante el período de soporte forman parte del producto.
Calendario del CRA
414 díashasta Aplicación plena para fabricantes (11 dic 2027)
- 10 dic 2024El Cyber Resilience Act entra en vigor. Las obligaciones para fabricantes solo pasan a ser aplicables más tarde, por fases. Reglamento (UE) 2024/2847
- 27 jul 2026La Comisión Europea publica orientaciones no vinculantes sobre la aplicación del CRA: ámbito, modificación sustancial, período de soporte, notificación y evaluación de riesgos. Comisión Europea, Comunicación C(2026) 5252 (orientaciones con arreglo al artículo 26)
- 11 sep 2026Pasan a ser aplicables las obligaciones de notificación: notificación de alerta temprana en 24 horas y notificación de vulnerabilidad o de incidente en 72 horas, para vulnerabilidades aprovechadas activamente e incidentes graves. Las notificaciones se presentan a través de la plataforma única de notificación de la ENISA, operativa desde la misma fecha. Reglamento (UE) 2024/2847, artículo 14
- 11 dic 2027El CRA pasa a ser plenamente aplicable. A partir de aquí, los productos con elementos digitales introducidos en el mercado deben cumplir los requisitos esenciales de ciberseguridad. Reglamento (UE) 2024/2847
Calendario completo, con el contexto portugués
El calendario de arriba muestra los hitos principales del CRA. Esta tabla añade los demás y el contexto regulatorio portugués, que corre en paralelo.
| Fecha | Hito | Fuente |
|---|---|---|
| 10 dic 2024 | CRA en vigor El Cyber Resilience Act entra en vigor. Las obligaciones para fabricantes solo pasan a ser aplicables más tarde, por fases. | Reglamento (UE) 2024/2847 |
| 3 abr 2026 | Decreto-ley 125/2025 (NIS2 PT) Entra en vigor el Decreto-ley 125/2025, que transpone la directiva NIS2 en Portugal. Se aplica a entidades esenciales e importantes, incluidos los fabricantes medianos o grandes de las divisiones 26 a 30 de la NACE (anexo II), y regula la seguridad de sus redes y sistemas, no la de los productos que comercializan. | Decreto-ley 125/2025, artículo 11 |
| 11 jun 2026 | Capítulo IV aplicable Pasa a aplicarse el capítulo IV del CRA (artículos 35 a 51), con las normas de notificación de los organismos de evaluación de la conformidad. Se dirige a los Estados miembros y a los organismos, no a los fabricantes. | Reglamento (UE) 2024/2847, artículo 71, apartado 2 |
| 23 jun 2026 | Marco Nacional de Referencia Entra en vigor el Reglamento 756/2026 del CNCS, de ejecución del Régimen Jurídico de la Ciberseguridad portugués; entre otras materias, aprueba el Marco Nacional de Referencia de Ciberseguridad (QNRCS). | Reglamento 756/2026 (CNCS) |
| 27 jul 2026 | Orientaciones de la Comisión La Comisión Europea publica orientaciones no vinculantes sobre la aplicación del CRA: ámbito, modificación sustancial, período de soporte, notificación y evaluación de riesgos. | Comisión Europea, Comunicación C(2026) 5252 (orientaciones con arreglo al artículo 26) |
| 11 sep 2026 | Notificación 24h / 72h Pasan a ser aplicables las obligaciones de notificación: notificación de alerta temprana en 24 horas y notificación de vulnerabilidad o de incidente en 72 horas, para vulnerabilidades aprovechadas activamente e incidentes graves. Las notificaciones se presentan a través de la plataforma única de notificación de la ENISA, operativa desde la misma fecha. | Reglamento (UE) 2024/2847, artículo 14 |
| 11 dic 2026 | Organismos notificados Fecha hasta la cual los Estados miembros deben procurar disponer de organismos notificados en número suficiente para la evaluación de la conformidad por terceros. La meta corresponde a los Estados miembros y no crea obligaciones para los fabricantes. | Reglamento (UE) 2024/2847, artículo 35, apartado 2 |
| 11 dic 2027 | Aplicación plena El CRA pasa a ser plenamente aplicable. A partir de aquí, los productos con elementos digitales introducidos en el mercado deben cumplir los requisitos esenciales de ciberseguridad. | Reglamento (UE) 2024/2847 |
Los siete puntos que deciden un proyecto
Cada uno de estos es un artículo de fondo, ya publicado.
- 01
SBOM para firmware embebido: lo que pide el CRA y cómo se genera sin mentir
La lista de materiales de software que exige el CRA no se escribe a mano. Para firmware, la única SBOM creíble sale del sistema de build, y el escaneo de binarios sirve para lo que no construimos nosotros.
- 02
La notificación de 24h y 72h: cómo funciona la obligación aplicable desde el 11 de septiembre de 2026
Desde el 11 de septiembre de 2026, un fabricante que sepa de una vulnerabilidad aprovechada activamente en su producto tiene 24 horas para el primer aviso. Qué se notifica, a quién, por dónde, y qué conviene tener listo.
- 03
Clasificación del producto en el CRA: la decisión que define el coste de todo lo demás
Por defecto, importante clase I, importante clase II o crítico. La categoría del producto determina si la conformidad es una autoevaluación o un organismo notificado, y la diferencia se mide en decenas de miles de euros y meses de calendario.
- 04
Período de soporte: la promesa más cara que el CRA obliga a hacer
El CRA obliga a cada fabricante a declarar durante cuánto tiempo da soporte al producto: como mínimo, por regla general, cinco años. Es una decisión de ingeniería, de contratos y de proveedores disfrazada de campo en un formulario.
- 05
CRA y RED: el dispositivo con radio vive hoy bajo dos regímenes
Desde agosto de 2025, el equipo radioeléctrico conectado a internet tiene que cumplir los requisitos de ciberseguridad de la RED. El CRA viene a sustituirlos, pero hasta diciembre de 2027 los dos regímenes coexisten, y el trabajo hecho en uno no vale automáticamente en el otro.
- 06
Lo que el automóvil ya aprendió, y el resto de la industria aprenderá de aquí a 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.
- 07
CRA para quien hace software: el reglamento no es solo para quien suelda placas
El equívoco más común sobre el CRA es creer que se dirige a fabricantes de dispositivos. El software vendido como producto está dentro. El SaaS puro está fuera, con una excepción que atrapa a mucha gente. Y 'gratis' no significa 'no comercial'.
Lecturas complementarias
Artículos de fondo que profundizan en uno de estos puntos o lo aplican a un caso concreto.
Divulgación coordinada de vulnerabilidades: el canal que el CRA obliga a mantener abierto
Las obligaciones de notificación a las autoridades ya son aplicables, pero son la mitad del circuito. El anexo I, Parte II, exige la otra mitad: un canal público para recibir informes de vulnerabilidades, con política, punto de contacto y proceso detrás. Cuesta poco montarlo, y hay norma para casi todo.
PHP2Shell y Node.js: lo que piden a quien fabrica equipos
El 21 de octubre de 2026, PHP y Node.js publicaron correcciones de seguridad graves. Quien fabrica equipos con panel web, gateways o ejecutables Node tiene tres preguntas que responder: si el producto incluye el componente, si hay obligación de notificar en virtud del artículo 14 y cómo llega la corrección a las unidades que ya están en campo.
El resto de la pila: kernel Linux, Python y certificados
La semana de PHP2Shell trajo también correcciones para el kernel Linux, para Python y para el almacén de certificados. Para quien fabrica, la pregunta es la misma en las tres capas: por qué camino, y con qué retraso, llega la corrección a los aparatos ya vendidos.
Dónde se convierte esto en trabajo
Preparar un producto para el CRA no es rellenar un dosier al final. Las decisiones que cuestan caro se toman pronto: qué componentes de terceros entran en el firmware y cómo se van a seguir, qué superficie de actualización expone el dispositivo, cuánto tiempo se compromete la empresa a soportar el producto, y quién recibe y responde a un informe de vulnerabilidad que llega de fuera.
Qué hacemos describe cómo entramos en ese proceso. El punto de partida es una primera lectura sin coste y por escrito, con la clasificación probable del producto y las decisiones más urgentes.
Sin promesas de conformidad. Ningún consultor puede garantizar la conformidad de un producto — quien la declara es el fabricante, bajo su responsabilidad. Trabajamos en la preparación y en la reducción del riesgo técnico.