CRA y NIS2: donde se superponen las regulaciones de ciberseguridad para empresas de productos
Entendiendo cómo interactúan CRA y NIS2. Una guía práctica para organizaciones que fabrican productos y operan servicios críticos.
En este artículo
- Resumen ejecutivo
- CRA vs NIS2: diferencia fundamental
- ¿Quién enfrenta ambas regulaciones?
- Requisitos superpuestos
- Comparación de notificaciones
- Cómo gestionar un solo programa de seguridad para CRA y NIS2
- Diferencias en la aplicación de CRA y NIS2
- Interacción de cronología de cumplimiento
- Lista de verificación de coordinación práctica
- Casos límite con doble alcance que requieren definición de ámbito
- Preguntas frecuentes sobre CRA y NIS2 para fabricantes de productos
- Próximos pasos
Fabricas dispositivos IoT para el sector energético. Estás sujeto tanto a NIS2 (como operador de servicios esenciales) como a CRA (como fabricante de productos). Dos regulaciones, requisitos superpuestos, un presupuesto de cumplimiento.
Esta guía explica cómo interactúan CRA y NIS2 y cómo gestionar el cumplimiento de ambas.
Resumen ejecutivo
- CRA regula productos; NIS2 regula organizaciones/servicios
- Muchas empresas enfrentan ambas: fabricantes que también son entidades esenciales/importantes
- Superposiciones clave: gestión de vulnerabilidades, notificación de incidentes, seguridad de la cadena de suministro
- Ámbitos diferentes: CRA = ciclo de vida del producto; NIS2 = ciberseguridad organizacional
- Oportunidad de coordinación: Procesos de seguridad unificados que sirven a ambas regulaciones
CRA vs NIS2: diferencia fundamental
CRA: regulación de productos
Qué regula: Productos con elementos digitales colocados en el mercado de la UE
A quién aplica: Fabricantes, importadores, distribuidores de productos con elementos digitales
Enfoque: Seguridad del producto durante todo el ciclo de vida
- Diseño y desarrollo seguros
- Gestión de vulnerabilidades de productos
- Actualizaciones de seguridad para productos
- Notificación de incidentes a nivel de producto
NIS2: regulación organizacional
Qué regula: Ciberseguridad de entidades esenciales e importantes
A quién aplica: Organizaciones en sectores especificados que cumplen umbrales de tamaño
Enfoque: Ciberseguridad organizacional
- Gobernanza y gestión de riesgos
- Gestión de incidentes de servicios
- Seguridad de la cadena de suministro
- Continuidad del negocio
La zona de superposición
ÁMBITO NIS2 ÁMBITO CRA
+----------------------+ +----------------------+
| - Sistemas TI | | - Productos que |
| - Servicios | | fabricas |
| - Operaciones | | - Productos que |
| - Cadena de | | importas |
| suministro | | - Productos que |
| (como comprador) | | distribuyes |
+----------+-----------+ +-----------+----------+
\ /
\ /
+----------------------------+
| SUPERPOSICIÓN |
| |
| - Gestión de vuln. |
| - Notif. de incidentes |
| - Seguridad de cadena |
| - Gobernanza de seguridad |
+----------------------------+
¿Quién enfrenta ambas regulaciones?
Escenario 1: entidad esencial que fabrica productos
Ejemplo: Empresa energética que fabrica componentes de red inteligente
- NIS2 aplica: Entidad del sector energético por encima del umbral
- CRA aplica: Fabricante de productos con elementos digitales
Ambas regulaciones requieren:
- Gestión de riesgos de ciberseguridad
- Gestión de vulnerabilidades
- Notificación de incidentes (a diferentes organismos, diferentes disparadores)
- Seguridad de la cadena de suministro
Escenario 2: entidad importante que fabrica IoT
Ejemplo: Empresa manufacturera que fabrica sensores IoT industriales
- NIS2 aplica: Entidad del sector manufacturero por encima del umbral
- CRA aplica: Fabricante de productos con elementos digitales
Escenario 3: proveedor de infraestructura digital
Ejemplo: Proveedor de nube que también vende dispositivos de hardware
- NIS2 aplica: Proveedor de infraestructura digital
- CRA aplica: Fabricante de productos de hardware
Escenario 4: fabricante de productos sanitarios
Ejemplo: Empresa de dispositivos médicos adyacentes (dispositivos no cubiertos por MDR)
- NIS2 aplica: Entidad del sector sanitario
- CRA aplica: Productos no cubiertos por la exclusión MDR
Requisitos superpuestos
Gestión de vulnerabilidades
| Aspecto | Requisito CRA | Requisito NIS2 |
|---|---|---|
| Ámbito | Vulnerabilidades del producto | Sistemas organizacionales |
| Descubrimiento | Monitorizar vulnerabilidades del producto | Monitorizar todos los sistemas |
| Respuesta | Parchear productos sin demora | Remediar vulnerabilidades |
| Notificación | ENISA (si explotada) | CSIRT nacional (si incidente) |
Oportunidad de coordinación: Programa unificado de gestión de vulnerabilidades cubriendo tanto productos como sistemas organizacionales.
Notificación de incidentes
| Aspecto | Requisito CRA | Requisito NIS2 |
|---|---|---|
| Disparador | Vulnerabilidad explotada activamente en producto | Incidente significativo que afecta servicios |
| Cronología | 24h → 72h → 14/30d | 24h → 72h → 1 mes |
| Destinatario | ENISA + CSIRT nacional | Autoridad competente nacional/CSIRT |
| Ámbito | Seguridad del producto | Disponibilidad/integridad del servicio |
Distinción clave: Una vulnerabilidad en tu producto puede disparar la notificación CRA incluso si tus servicios no están afectados. Una interrupción del servicio puede disparar la notificación NIS2 incluso si no existe vulnerabilidad del producto.
Seguridad de la cadena de suministro
| Aspecto | Requisito CRA | Requisito NIS2 |
|---|---|---|
| Enfoque | Componentes en tus productos | Proveedores de tu organización |
| evaluación | Diligencia debida técnica | evaluación de seguridad de proveedores |
| Monitorización | SBOM, seguimiento de vulnerabilidades | Gestión continua de riesgo de proveedores |
Oportunidad de coordinación: Gestión integrada de proveedores cubriendo tanto componentes de productos como proveedores organizacionales.
Comparación de notificaciones
Ruta de notificación CRA
VULNERABILIDAD DEL PRODUCTO (explotada activamente)
│
▼
ALERTA TEMPRANA 24 HORAS
A: Plataforma Única de Notificación ENISA
│
▼
NOTIFICACIÓN DETALLADA 72 HORAS
A: ENISA + CSIRTs relevantes
│
▼
INFORME FINAL 14 DÍAS (vulnerabilidad)
INFORME FINAL 30 DÍAS (incidente)
Ruta de notificación NIS2
INCIDENTE SIGNIFICATIVO (Qué afecta servicios)
│
▼
ALERTA TEMPRANA 24 HORAS
A: Autoridad competente nacional o CSIRT
│
▼
NOTIFICACIÓN DE INCIDENTE 72 HORAS
A: Autoridad competente nacional o CSIRT
│
▼
INFORME FINAL 1 MES
A: Autoridad competente nacional o CSIRT
Cuando aplican ambas
Un único evento podría disparar ambas:
Ejemplo: Un zero-day en tu producto es explotado activamente, afectando a clientes que son entidades esenciales (como empresas energéticas usando tu equipo de red inteligente).
Notificación CRA: Tú notificas la vulnerabilidad activamente explotada (eres el fabricante)
Notificación NIS2: Tus clientes afectados pueden notificar el incidente (ellos son las entidades esenciales)
Tu notificación interna: Si también eres una entidad esencial usando tus propios productos, podrías notificar bajo ambas
Cómo gestionar un solo programa de seguridad para CRA y NIS2
Gobernanza de seguridad unificada
En lugar de programas de cumplimiento CRA y NIS2 separados:
GOBERNANZA DE CIBERSEGURIDAD UNIFICADA
Nivel de Consejo:
- Supervisión única de riesgo de ciberseguridad
- Informes combinados a la dirección
Nivel Operacional:
- Un programa de gestión de vulnerabilidades
├── Vulnerabilidades de productos (enfoque CRA)
└── Vulnerabilidades de sistemas (enfoque NIS2)
- Una capacidad de respuesta a incidentes
├── Incidentes de productos (notificación CRA)
└── Incidentes de servicios (notificación NIS2)
- Un programa de seguridad de cadena de suministro
├── Componentes de productos (SBOM, CRA)
└── Proveedores de servicios (NIS2)
Mapeo de procesos
| Proceso | Aplicación CRA | Aplicación NIS2 |
|---|---|---|
| evaluación de riesgos | evaluación de riesgos del producto | Gestión de riesgos organizacionales |
| Escaneo de vulnerabilidades | Escaneo de producto/componentes | Escaneo de infraestructura |
| Gestión de parches | Actualizaciones de productos | Parches de sistemas |
| Respuesta a incidentes | Gestión de incidentes de productos | Gestión de incidentes de servicios |
| Pruebas de seguridad | Pruebas de seguridad de productos | Pruebas de penetración |
| Formación de concienciación | Formación en desarrollo seguro | Concienciación general de seguridad |
Eficiencia de documentación
Alguna documentación puede servir para ambas:
| Documento | Uso CRA | Uso NIS2 |
|---|---|---|
| Política de seguridad | Sección de política de seguridad del producto | Política de seguridad organizacional |
| Registro de riesgos | Riesgos del producto | Riesgos organizacionales |
| Plan de respuesta a incidentes | Procedimientos de incidentes de productos | Procedimientos de incidentes de servicios |
| evaluación de proveedores | Diligencia debida de proveedores de componentes | evaluación de proveedores de servicios |
Diferencias en la aplicación de CRA y NIS2
Aplicación CRA
- Autoridades de vigilancia del mercado monitorizan productos
- Enfoque en cumplimiento del producto
- Sanciones hasta €15M o 2,5% de facturación global
- Posible retirada/retiro del producto
Aplicación NIS2
- Autoridades competentes nacionales supervisan entidades
- Enfoque en cumplimiento organizacional
- Sanciones hasta €10M o 2% de facturación global
- Posible responsabilidad personal de la dirección
¿Doble exposición?
Un único fallo podría teóricamente disparar aplicación bajo ambas:
Ejemplo: Una mala gestión de vulnerabilidades lleva a productos sin parchear Y sistemas internos sin parchear.
- CRA: Incumplimiento de requisitos de gestión de vulnerabilidades
- NIS2: Incumplimiento de medidas de gestión de riesgos
En la práctica: Los reguladores deberían coordinarse. Demostrar cumplimiento unificado ayuda.
Interacción de cronología de cumplimiento
Cronología NIS2
- Octubre 2024: Fecha límite de transposición NIS2
- 2024-2025: implementación por Estados miembros
- En curso: Cumplimiento requerido
Cronología CRA
- Septiembre 2026: Comienzan obligaciones de notificación
- Diciembre 2027: Cumplimiento completo requerido
- En curso: Obligaciones del ciclo de vida del producto
Enfoque coordinado
2024 2025 2026 2027
│ │ │ │
▼ ▼ ▼ ▼
┌───────────────────────────────────────────────────────────────────────┐
│ NIS2: Cumplimiento organizacional requerido durante todo el período │
└───────────────────────────────────────────────────────────────────────┘
│ │
▼ ▼
┌───────────────────────────────┐
│ CRA: Notif. │ CRA: Completo │
└───────────────────────────────┘
RECOMENDACIÓN:
Construir programa de ciberseguridad unificado ahora qué sirva a ambas.
No construir programas de cumplimiento CRA y NIS2 separados.
Lista de verificación de coordinación práctica
Integración de gobernanza
LISTA DE VERIFICACIÓN DE GOBERNANZA DUAL
ORGANIZACIONAL:
[ ] Estructura única de gobernanza de ciberseguridad
[ ] Supervisión a nivel de consejo cubre seguridad de productos y servicios
[ ] Estrategia combinada de ciberseguridad
[ ] Asignación presupuestaria unificada
GESTIÓN DE RIESGOS:
[ ] evaluación de riesgos integrada (productos + servicios)
[ ] Registro de riesgos combinado
[ ] Proceso unificado de tratamiento de riesgos
[ ] Marco único de informes de riesgo
GESTIÓN DE VULNERABILIDADES:
[ ] Un canal de entrada de vulnerabilidades
[ ] Proceso combinado de triaje
[ ] Flujo de remediación integrado
[ ] Métricas e informes unificados
RESPUESTA A INCIDENTES:
[ ] Plan combinado de respuesta a incidentes
[ ] Enrutamiento claro para notificación CRA vs NIS2
[ ] Procedimientos de comunicación integrados
[ ] Revisión post-incidente unificada
Integración de notificaciones
MATRIZ DE NOTIFICACIÓN DUAL
Tipo de Evento Notificar Bajo
─────────────────────────────────────────────────────────────
Vuln. producto (no explotada) Ninguna (solo proceso CVD)
Vuln. producto (explotada) CRA → ENISA
Incidente servicio (sin producto) NIS2 → Autoridad nacional
Ambos (vuln. producto → servicio) Ambas (coordinar)
─────────────────────────────────────────────────────────────
Escalado Interno:
1. Equipo de seguridad evalúa evento
2. Determinar: ¿Impacto en producto? ¿Impacto en servicio?
3. Enrutar a ruta(s) de notificación apropiada(s)
4. Coordinar si aplican ambas
Integración de cadena de suministro
SEGURIDAD UNIFICADA DE CADENA DE SUMINISTRO
Para Componentes de Productos (enfoque CRA):
- SBOM mantenido
- Monitorización de vulnerabilidades de componentes
- Cuestionario de seguridad de proveedores
- Diligencia debida técnica
Para Proveedores de Servicios (enfoque NIS2):
- evaluación de riesgo de proveedores
- Requisitos de seguridad en contratos
- Monitorización continua
- Cláusulas de notificación de incidentes
ENFOQUE INTEGRADO:
- Sistema único de gestión de proveedores
- Marco combinado de evaluación de riesgos
- Requisitos unificados de seguridad contractual
- Programa coordinado de monitorización
Casos límite con doble alcance que requieren definición de ámbito
Sistemas de control industrial
Los IACS (Sistemas de Automatización y Control Industrial) enfrentan complejidad particular:
- CRA: Si fabricas IACS para entidades esenciales (NIS2), es Clase Importante II
- NIS2: Si operas IACS como entidad esencial, están en ámbito
Doble requisito: El producto debe cumplir CRA; la operación debe cumplir NIS2.
Servicios cloud + productos
Proveedores de nube vendiendo dispositivos de hardware:
- NIS2: Operaciones del servicio cloud
- CRA: Dispositivos de hardware vendidos
Ejemplo: El dispositivo firewall de un proveedor de nube debe cumplir con CRA; sus operaciones de servicio cloud deben cumplir con NIS2.
Adyacentes a sanidad
Los fabricantes de dispositivos médicos podrían tener:
- Algunos productos bajo MDR (excluidos de CRA)
- Algunos productos bajo CRA (no cubiertos por MDR)
- Organización bajo NIS2 (entidad del sector sanitario)
Definición de ámbito cuidadosa requerida: Mapear cada producto a la regulación aplicable.
Preguntas frecuentes sobre CRA y NIS2 para fabricantes de productos
¿Cuándo un mismo evento activa las obligaciones de notificación de CRA y NIS2?
Cuando una vulnerabilidad explotada activamente en tu producto también causa un incidente significativo que afecta a tus servicios. La notificación CRA se activa por la vulnerabilidad del producto explotada: presentas una alerta temprana de 24 horas ante ENISA, seguida de una notificación de 72 horas. La notificación NIS2 se activa por separado si tus servicios se ven interrumpidos: presentas ante tu autoridad competente nacional o CSIRT con el mismo calendario de 24/72 horas. Los dos informes cubren materias distintas. CRA se centra en el producto y la vulnerabilidad. NIS2 se centra en el impacto sobre el servicio y tu respuesta. Ambos pueden ser obligatorios ante el mismo evento origen.
¿Quién presenta el informe si el fabricante también es una entidad esencial?
Los presentas tú, y los presentas por separado. Como fabricante del producto, notificas la vulnerabilidad explotada a ENISA en virtud del CRA. Como entidad esencial, notificas el incidente de servicio a tu autoridad competente nacional o CSIRT en virtud de NIS2. Las dos notificaciones son independientes: formularios distintos, destinatarios distintos, plazos en algunos casos distintos. Designa un responsable nominado para cada ruta de notificación antes de que se produzca un incidente. No asumas que un informe satisface al otro.
¿Puede un único registro de riesgos servir tanto para CRA como para NIS2?
Sí, si separa los riesgos de producto de los riesgos organizacionales. Estructura el registro de forma que los riesgos a nivel de producto (vulnerabilidades de componentes, fallos de actualización, brechas de conformidad) queden claramente diferenciados de los riesgos organizacionales (continuidad del servicio, fallos de gobernanza, interrupciones de la cadena de suministro). Ambos conjuntos de riesgos pueden coexistir en el mismo documento y compartir una metodología de puntuación común. Lo que no puede fusionarse es el tratamiento: el tratamiento de riesgos CRA conduce a controles de producto y actualizaciones del expediente técnico; el tratamiento de riesgos NIS2 conduce a medidas organizacionales y cambios de política. Mantén las entradas diferenciadas para que cada auditoría pueda encontrar lo que necesita.
¿Cómo debe diferir la diligencia debida de proveedores entre componentes y proveedores de servicios?
Para los componentes de producto en virtud del CRA, la diligencia debida es técnica: necesitas un SBOM que cubra el componente, evidencia de monitorización de vulnerabilidades por parte del proveedor, y una obligación contractual de notificarte de vulnerabilidades explotables dentro de un plazo definido. Para los proveedores de servicios en virtud de NIS2, la diligencia debida es organizacional: evalúas su gobernanza de seguridad, capacidad de respuesta ante incidentes, continuidad de negocio, y si cumplen las medidas de seguridad NIS2 aplicables a tu sector. Ambos tipos pueden compartir una plantilla de cuestionario común, pero los criterios de evaluación y las cláusulas contractuales son distintos.
¿Qué evidencias deben conservarse para demostrar cumplimiento coordinado de ambos regímenes?
Conserva tres cosas. Primero, un documento de mapeo que muestre qué procesos internos sirven a qué obligación regulatoria, de modo que un auditor pueda trazar cualquier requisito de CRA o NIS2 hasta un control específico. Segundo, registros de incidentes que demuestren que ambas rutas de notificación se activaron correctamente cuando los eventos lo requerían, con marcas temporales y confirmaciones de los destinatarios. Tercero, informes a la dirección o al consejo que cubran tanto la seguridad de productos como la seguridad organizacional bajo una única estructura de gobernanza, demostrando que la supervisión es unificada. Si eres auditado bajo CRA y NIS2 en el mismo año, esta evidencia es lo que demuestra que gestionas un único programa, no dos desconectados.
¿Cómo afectan las diferencias de transposición nacional de NIS2 a un fabricante que opera en varios países?
NIS2 es una directiva, no un reglamento, lo que significa que cada Estado miembro de la UE la transpone a su legislación nacional. Las obligaciones principales (gestión de riesgos, notificación de incidentes, seguridad de la cadena de suministro) son coherentes, pero la autoridad competente, los umbrales sectoriales y en ocasiones la estructura de sanciones varían según el país. Un fabricante que opera en Alemania, Francia y Polonia debe identificar qué autoridad nacional supervisa cada entidad, registrarse ante el organismo correcto en cada jurisdicción y dirigir los informes de incidentes NIS2 al CSIRT nacional correspondiente. El CRA, por el contrario, es un reglamento y se aplica de forma uniforme en toda la UE. Si vendes un producto en cualquier país de la UE, se aplican las mismas obligaciones CRA.
Próximos pasos
Comienza por confirmar si tu empresa es al mismo tiempo fabricante de productos y entidad esencial o importante en virtud de NIS2. Usa la guía de clasificación de productos para asignar cada producto a su clase CRA. A continuación, mapea los riesgos de producto y los riesgos de servicio por separado en un único registro que los mantenga diferenciados. Define los disparadores internos de notificación para CRA frente a NIS2 y asigna un responsable nominado para cada ruta. Unifica los flujos de trabajo de entrada de proveedores y vulnerabilidades para que ambos tipos de proveedores fluyan por un único proceso. Para una visión completa de los plazos CRA, consulta el cronograma de implementación CRA. Después realiza un ejercicio de simulación conjunto que reproduzca un incidente de producto que también afecte a tus servicios: esto pondrá al descubierto las carencias en tu respuesta de doble alcance antes de que lo haga un evento real.
Este artículo es solo para fines informativos y no constituye asesoramiento legal. Para orientación específica de cumplimiento, consulte con asesoría legal cualificada.
Artículos Relacionados
ECSMAF v3.0 explicado: cómo ENISA mapea el mercado europeo de ciberseguridad
¿Se aplica el CRA a tu producto?
Responde 6 preguntas sencillas para saber si tu producto está dentro del ámbito del Reglamento de Ciberresiliencia de la UE. Obtén tu resultado en menos de 2 minutos.
¿Listo para lograr el cumplimiento del CRA?
Empieza a gestionar tus SBOMs y documentación de cumplimiento con CRA Evidence.