CRA: Notificación de Vulnerabilidades en 24 h
El Cyber Resilience Act exige desde el 11 de septiembre de 2026 notificar vulnerabilidades en 24 horas. Guía técnica para fabricantes y proveedores.
El 11 de septiembre de 2026 cambió las reglas del juego
Hasta hace apenas cuatro días, la divulgación de vulnerabilidades en productos de software e IoT era, en gran medida, una práctica voluntaria. Las empresas podían tomarse semanas o meses antes de comunicar a cualquier autoridad la existencia de una brecha conocida. El Cyber Resilience Act (CRA) de la Unión Europea puso fin a esa era de discrecionalidad el pasado 11 de septiembre de 2026, cuando entraron en vigor las obligaciones de notificación temprana de vulnerabilidades, una de las piezas más exigentes de la legislación de ciberseguridad aprobada en los últimos años.
Este artículo técnico desglosa qué obliga exactamente el CRA, cómo se relaciona con otros marcos regulatorios europeos, qué sistemas técnicos necesita implementar tu organización y cuál es la hoja de ruta para los próximos dieciocho meses hasta que el reglamento alcance su plena aplicación en 2027.
Contexto: ¿Qué es el Cyber Resilience Act?
El CRA (Reglamento UE 2024/2847) fue adoptado formalmente en octubre de 2024 y publicado en el Diario Oficial de la UE en diciembre de ese mismo año. Su objetivo central es garantizar que los productos con elementos digitales —desde termostatos inteligentes hasta sistemas ERP empresariales— cumplan requisitos esenciales de ciberseguridad antes de ser comercializados en el mercado único europeo.
La estructura temporal del reglamento se puede resumir así:
| Hito | Fecha | Obligación activada |
|---|---|---|
| Publicación en DOUE | Diciembre 2024 | Inicio del período transitorio |
| Notificación de vulnerabilidades | 11 septiembre 2026 | Activa hoy (24 h a ENISA y CSIRT) |
| Notificación de incidentes | 11 septiembre 2026 | Activa hoy (incidentes graves) |
| Plena aplicación (requisitos de diseño) | 11 diciembre 2027 | Marcado CE obligatorio y SBOM |
El desfase entre la plena aplicación y la activación anticipada de las obligaciones de notificación no es un error legislativo: el Parlamento Europeo lo hizo deliberadamente para que ENISA pudiera construir la infraestructura de recepción y para que los fabricantes comenzaran a desarrollar sus programas de divulgación antes de la fecha límite definitiva.
Para conocer cómo los atacantes automatizan ataques en cadenas de suministro, consulta nuestro análisis sobre ataques agentivos con IA a repositorios de software.
La obligación de 24 horas: qué exige exactamente el artículo 14
El artículo 14 del CRA establece tres plazos escalonados para los fabricantes ante una vulnerabilidad activamente explotada:
- Alerta temprana (24 horas): Notificación inicial a ENISA y al CSIRT nacional de coordinación. Debe incluir: identificador del producto, versión afectada, naturaleza de la vulnerabilidad (sin detalles técnicos que faciliten la explotación) y si hay mitigación disponible.
- Notificación técnica (72 horas): Notificación actualizada con información técnica detallada, incluida la evaluación de impacto (CVSS v4.0, CWE) y cualquier medida de mitigación adoptada.
- Informe final (14 días): Informe completo con descripción de causa raíz, parche disponible o plan de remediación con fechas comprometidas.
Es fundamental entender qué se considera "activamente explotada": el CRA la define como cualquier vulnerabilidad para la que existe evidencia de explotación en entornos de producción reales, independientemente de si el fabricante es el primero en detectarla. Fuentes externas como CISA KEV, informes de threat intelligence o notificaciones de clientes pueden ser el detonante.
Tabla comparativa: CRA vs NIS2 vs RGPD
Las organizaciones en la UE deben coordinar sus procesos para cumplir simultáneamente con tres marcos normativos:
| Dimensión | Cyber Resilience Act (CRA) | Directiva NIS 2 | Reglamento General (RGPD) |
|---|---|---|---|
| Ámbito principal | Productos de hardware y software conectado | Operadores de servicios esenciales e importantes | Protección de datos personales |
| Gatillo de reporte | Vulnerabilidad explotada o incidente grave | Incidente operativo significativo | Brecha de datos con riesgo para individuos |
| Plazo inicial | 24 horas (Alerta temprana) | 24 horas (Alerta temprana) | 72 horas |
| Destinatario | ENISA Single Platform & CSIRTs nacionales | CSIRTs nacionales / Autoridad competente | Autoridad de Protección de Datos (AEPD) |
| Sanción máxima | Hasta 15 M€ o 2,5 % facturación global | Hasta 10 M€ o 2 % facturación global | Hasta 20 M€ o 4 % facturación global |
| Sanción de mercado | Retirada del producto y prohibición de venta | Suspensión temporal de funciones directivas | Prohibición temporal de tratamiento de datos |
Para entender el marco legal en privacidad ante nuevas tecnologías, revisa nuestra guía sobre políticas de privacidad adaptadas a la inteligencia artificial.
Ejemplo técnico: Webhook de notificación automatizada
Para cumplir con la ventana estricta de 24 horas sin depender de cadenas manuales de correo:
import os
import requests
from datetime import datetime, timezone
def enviar_notificacion_temprana_cra(cve_id, producto, versiones, score_cvss):
payload = {
"notification_type": "CRA_ARTICLE_14_EARLY_WARNING",
"timestamp_utc": datetime.now(timezone.utc).isoformat(),
"fabricante": {
"organizacion": "TecnoCrypter Security Labs",
"contacto_seguridad": "[email protected]"
},
"vulnerabilidad": {
"cve": cve_id,
"producto_afectado": producto,
"versiones_impactadas": versiones,
"cvss_v4": score_cvss,
"evidencia_explotacion_activa": True,
"mitigacion_disponible": False
}
}
endpoint_enisa = os.getenv("ENISA_REPORTING_GATEWAY_URL")
headers = {
"Authorization": f"Bearer {os.getenv('EU_CYBER_PLATFORM_API_KEY')}",
"Content-Type": "application/json"
}
resp = requests.post(endpoint_enisa, json=payload, headers=headers, timeout=10)
if resp.status_code == 201:
print(f"[OK] Notificación CRA enviada exitosamente para {cve_id}")
return True
else:
raise RuntimeError(f"Fallo en envío de alerta CRA: {resp.status_code}")
Lista de verificación técnica para fabricantes
Para asegurar el cumplimiento operativo del CRA y prevenir sanciones de mercado:
- Publicar security.txt: Implementa el estándar RFC 9116 en dominios corporativos con claves PGP públicas y canales de contacto directo.
- Automatizar generación de SBOM: Integra la exportación continua de CycloneDX o SPDX en cada fase de compilación CI/CD.
- Establecer SLA de triaje de 12 horas: Configura alertas en tiempo real para evaluar zero-days antes del límite legal de 24 horas.
- Rotar credenciales de infraestructura: Utiliza nuestro generador de contraseñas de alta seguridad para proteger credenciales de despliegue.
Para asegurar canales de comunicación y verificación de cifrado, consulta nuestras herramientas de cifrado y descifrado online.
