El reloj de 24 horas del CRA arranca el 11 de septiembre de 2026: asegúrate de que alguien conteste

Desde el 11 de septiembre de 2026, el Reglamento europeo de Ciberresiliencia da a los fabricantes 24 horas para enviar una alerta temprana, en un navegador y sin API. Así se convierte ese disparador en una llamada telefónica con Echobell, y esto es lo que una alerta más ruidosa sigue sin resolver.

Índice

El 11 de septiembre de 2026 empiezan a aplicarse las obligaciones de notificación del Reglamento europeo de Ciberresiliencia (CRA). Desde esa fecha, un fabricante que tenga conocimiento de una vulnerabilidad explotada activamente en un producto con elementos digitales —o de un incidente grave que le afecte— dispone de 24 horas para enviar una alerta temprana a su CSIRT coordinador y a ENISA (Comisión Europea, Reglamento (UE) 2024/2847).

Ese plazo tiene una propiedad que la mayoría de los plazos de cumplimiento no tiene: corre en horas de reloj. No hay excepción por días hábiles, no se detiene el fin de semana y no espera a que tu responsable de notificación baje del avión. Y la plataforma por la que se presenta, la Plataforma Única de Notificación (SRP) de ENISA, es un formulario web: «no se proporcionarán interfaces de programación de aplicaciones en esta fase» (FAQ de ENISA). Una persona concreta tiene que iniciar sesión y enviarlo.

Eso convierte la regla de las 24 horas en un problema de alertas antes que en un problema de papeleo. Esta guía explica cómo llevar el momento del conocimiento hasta un teléfono que suena, usando Echobell, y es honesta sobre la gran parte de la preparación para el CRA que ninguna herramienta de notificación toca.

¿Qué empieza exactamente el 11 de septiembre de 2026?

Los fabricantes de productos con elementos digitales deben notificar las vulnerabilidades explotadas activamente y los incidentes graves a través de una única plataforma europea, con un reloj escalonado que arranca en el momento en que tienen conocimiento. Todo lo demás del CRA —marcado CE, requisitos esenciales del anexo I, evaluación de la conformidad— se aplica desde el 11 de diciembre de 2027. La notificación llega quince meses antes y afecta también a productos que ya están en el mercado, no solo a lo que envíes después de esa fecha (cyberresilienceact.eu).

El artículo 14 define dos vías paralelas con la misma forma:

EtapaVulnerabilidad explotada activamente — art. 14(2)Incidente grave — art. 14(4)
Alerta tempranaEn 24 horas desde el conocimientoEn 24 horas desde el conocimiento
NotificaciónEn 72 horas desde el conocimientoEn 72 horas desde el conocimiento
Informe finalA más tardar 14 días después de que exista una medida correctora o mitigadoraEn un mes desde la notificación de las 72 horas

La redacción es «sin demora indebida y, en cualquier caso, en el plazo de 24 horas desde que el fabricante tenga conocimiento de ella» (artículo 14). Veinticuatro horas es el techo, no el objetivo.

El artículo 14(5) fija el umbral de «grave»: un incidente lo es cuando afecta negativamente, o es capaz de afectar negativamente, a la capacidad del producto de proteger la disponibilidad, autenticidad, integridad o confidencialidad de datos o funciones sensibles o importantes, o cuando ha dado lugar —o puede dar lugar— a la introducción o ejecución de código malicioso. Ese «es capaz de» importa: puedes tener que notificar antes de que algo haya salido mal de verdad para un cliente.

El artículo 14(8) añade una segunda obligación en paralelo: también debes informar a los usuarios afectados del producto sobre la vulnerabilidad o el incidente y, cuando sea necesario, sobre las medidas correctoras que pueden adoptar. Es un destinatario distinto del CSIRT, por su propia vía.

¿Quién está realmente obligado?

Los fabricantes de productos con elementos digitales, estén establecidos donde estén, más los administradores (stewards) de software libre de forma más acotada. Una empresa fuera de la UE que vende en la Unión no escapa a la obligación; el reglamento espera que un operador económico en la UE sea responsable de las obligaciones pertinentes (cyberresilienceact.eu).

Notificas al CSIRT designado como coordinador en el Estado miembro donde tengas tu establecimiento principal en la Unión, y simultáneamente a ENISA, pero presentas una sola vez a través de la Plataforma Única de Notificación, que lo encamina a ambos (Comisión Europea).

Los administradores de software libre entran en un subconjunto definido: la obligación del artículo 14(1) se aplica en la medida en que participen en el desarrollo de productos con elementos digitales, y los artículos 14(3) y (8) en la medida en que los incidentes graves afecten a los sistemas de redes e información que proporcionan para ese desarrollo. Si administras un proyecto ampliamente utilizado, lee el artículo 24 junto con el 14 en lugar de asumir cualquiera de los dos extremos.

El artículo 15 permite además la notificación voluntaria —de vulnerabilidades, ciberamenazas, incidentes y cuasi incidentes— por parte de fabricantes y de cualquier otra persona. La notificación voluntaria no crea obligaciones nuevas, pero usa la misma plataforma y tiene el mismo problema de «alguien tiene que estar despierto».

¿Por qué un plazo de 24 horas es un problema de alertas?

Porque el reloj arranca cuando tienes conocimiento, y el conocimiento rara vez llega en horario de oficina. El disparador es que un hecho llegue a tu organización, no una decisión que tu organización tome.

Mira de dónde suele venir ese hecho. Un investigador escribe a security@ a las 23:40 de un sábado. Un cliente aguas abajo abre un ticket describiendo explotación. Un feed de CVE o KEV se enciende sobre un componente que distribuyes. Tu propio EDR detecta ejecución en un sistema de compilación. La nota de preparación de DLA Piper señala expresamente la versión de cadena de suministro de esto: los fabricantes rara vez son los primeros en enterarse, y la información llega por importadores, distribuidores, investigadores o proveedores de componentes (DLA Piper).

Todos esos caminos terminan en una notificación que tu configuración actual probablemente entrega en silencio: un correo en un buzón compartido, un mensaje en un canal de Slack que nadie mira de madrugada, un ticket en una cola que se triará el lunes. Ninguna falla. Todas se entregan correctamente, a nadie.

Tres detalles agrandan la brecha más de lo que parece:

  • No hay API. ENISA afirma claramente que no se proporcionarán API de notificación en esta fase. No puedes dejar un script que presente la alerta temprana mientras todo el mundo duerme.
  • El acceso se configura persona a persona y con antelación. Los representantes autorizados se registran con una cuenta EU Login y el CSIRT coordinador designado valida su autoridad tras el primer acceso. Hay un representante principal y un suplente, y la invitación al suplente caduca a los siete días (FAQ de ENISA, cyberresilienceact.eu). Si la única persona que puede presentar está ilocalizable, el plazo no lo tiene en cuenta.
  • El tramo sancionador es el alto. El artículo 64 sitúa el incumplimiento de las obligaciones de los artículos 13 y 14 en la banda de multas administrativas de «hasta 15 000 000 EUR o, si el infractor es una empresa, hasta el 2,5 % de su volumen de negocios total anual mundial del ejercicio financiero anterior, si esta cuantía fuese superior» (artículo 64).

Una matización honesta sobre este último punto, porque cambia el cálculo para equipos pequeños: el artículo 64 excluye a los fabricantes que sean microempresas o pequeñas empresas de las multas administrativas por incumplir el plazo del artículo 14(2)(a) o 14(4)(a), es decir, precisamente la alerta temprana de 24 horas. La obligación de notificar sigue en pie, y la exclusión no se extiende a la notificación de 72 horas ni al resto del artículo 14. Lee el artículo y busca asesoramiento, en vez de fiarte de un blog para saber dónde encaja tu empresa.

¿Qué contiene realmente la alerta temprana de 24 horas?

Muy poco, y ese es el punto. La guía de ENISA describe un conjunto reducido de campos obligatorios en la fase de alerta temprana: tipo de notificación (vulnerabilidad o incidente), nivel de notificación, hora de notificación, datos del notificante, nombre del fabricante o administrador, el producto, un título y, para incidentes, si se sospechan actos ilícitos o malintencionados. Entre los campos opcionales de esa fase están el CVE ID o el EUVD ID.

El cuadro técnico más completo —la naturaleza general de la vulnerabilidad o del exploit, una evaluación inicial, las medidas correctoras y mitigadoras— corresponde a la notificación de 72 horas, no a las primeras 24.

Así que la alerta temprana no es un proyecto de investigación. Es un formulario corto que una persona preparada rellena en minutos. La restricción vinculante no es el formulario, sino si una persona registrada, autorizada y despierta se entera a tiempo. Eso es un problema de enrutado de notificaciones, y se puede resolver hoy.

¿Cómo pongo un teléfono que suena delante del reloj de 24 horas?

Echobell convierte una llamada webhook o un correo en una alerta que suena y vibra como una llamada entrante, que es lo que le permite atravesar el modo Concentración y No molestar de iOS (ver cómo saltarse el modo Concentración). La configuración siguiente convive con el proceso de tickets y PSIRT que ya tengas: no lo sustituye.

Paso 1 — Crea un canal de llamada reservado a candidatos CRA

En la aplicación, crea un canal y pon el tipo de notificación en Llamada (tipos de notificación). Nómbralo por la decisión que dispara, no por la fuente de datos: «CRA — puede haber arrancado el reloj de 24 h» es mejor que «Alertas de seguridad».

Este canal tiene que permanecer callado. Si suena por cada aviso, cada escaneo fallido y cada actualización de dependencia, la gente dejará de contestar y habrás gastado tu único canal ruidoso en ruido. Enruta eso a otro sitio: la guía sobre la fatiga de alertas explica el reparto.

Copia la URL del webhook desde los detalles del canal; tiene el aspecto https://hook.echobell.one/t/<channel-token>. Trátala como un secreto, porque quien la tenga puede hacer sonar los teléfonos de tu equipo (guía de webhooks).

Configura plantillas legibles en la pantalla de bloqueo a las 02:00 por alguien medio dormido:

Título: Posible notificación CRA — {{product}}
Cuerpo: {{kind}} — {{summary}} (conocido desde {{time}} UTC)

{{time}}, {{date}}, {{hour}} y las demás variables de tiempo del sistema se inyectan siempre en UTC, así que la notificación registra una marca temporal aunque el emisor no la envíe. Esa marca no es prueba legal de cuándo empezó el conocimiento, pero sí un anclaje útil cuando después reconstruyas la cronología.

Paso 2 — Apunta tus vías de detección al canal

Cualquier sistema que pueda llamar a un webhook puede disparar el canal. Los campos que envíes se convierten en variables de plantilla:

curl -X POST https://hook.echobell.one/t/<channel-token> \
  -H "Content-Type: application/json" \
  -d '{
    "product": "Acme Gateway 4.x",
    "kind": "vulnerabilidad explotada activamente",
    "summary": "informe de investigador, exploit funcional adjunto",
    "craCandidate": true,
    "externalLink": "https://issues.internal.example/PSIRT-4412"
  }'

La variable especial externalLink se convierte en un enlace pulsable en el registro de la notificación, así que contestar la llamada deja a quien responde a un toque del ticket con los detalles.

Merece la pena conectar, más o menos por orden de frecuencia con que son la primera señal:

  • Tu cola de PSIRT o de entrada de seguridad: un webhook cuando una incidencia se etiqueta como candidata CRA.
  • Avisos de seguridad de GitHub y alertas de Dependabot en los repositorios que construyen productos distribuidos (integración con GitHub).
  • Tu SIEM, EDR o WAF, para detecciones contra la infraestructura de compilación, publicación o firma: el artículo 14(5) alcanza expresamente a incidentes que puedan derivar en la introducción de código malicioso.
  • Los feeds de inteligencia de vulnerabilidades que ya consumes, filtrados a los componentes que aparecen en tus propios SBOM.

Paso 3 — Usa condiciones para que solo suenen candidatos plausibles

Este paso decide si el canal mantiene su credibilidad. Las condiciones de Echobell evalúan las mismas variables y cabeceras HTTP que usan tus plantillas, y el canal solo se dispara cuando la expresión es verdadera:

craCandidate == true && confirmed == true

O filtra por una cabecera si el sistema emisor no puede dar forma al cuerpo:

header["x-cra-severity"] == "reportable"

Pon el umbral en «una persona competente debería mirar esto dentro de una hora», no en «esto es notificable con seguridad». Decidir si el artículo 14 entra en juego es un juicio que exige a una persona con los hechos delante; el trabajo del canal es llevar rápido a esa persona hasta los hechos. Filtrar de más aquí es el error caro, porque una notificación que nunca empezaste es peor que una llamada que no hacía falta.

Paso 4 — Captura los sistemas que solo mandan correo

El primer contacto desde fuera de la empresa suele llegar por correo: el investigador, el cliente, el CSIRT nacional, el proveedor de componentes. Cada canal de Echobell puede tener su propia dirección, así que una regla de reenvío en security@ convierte esos mensajes en llamadas (disparadores por correo).

Los disparadores por correo exponen from, to, subject, text y html como variables, así que puedes filtrar sin analizar nada:

subject != "" && (from == "cert@vendor.example" || subject == "[EXPLOITED]")

Acuerda con tus notificantes habituales y proveedores clave un marcador en el asunto y filtra por él. Es un detalle contractual pequeño que convierte un buzón sin estructura en una señal enrutable.

Paso 5 — Pon en el canal a todos los representantes registrados

Comparte el canal con todos los que puedan presentar de verdad: el representante autorizado principal, el suplente y el responsable de seguridad que pueda tomar la decisión del artículo 14. Cada suscriptor elige su tipo de notificación, así que quien esté de guardia puede estar en Llamada y el resto en Urgente.

Ese es el sentido del ejercicio. La SRP exige una persona física registrada y validada. Si solo una persona de tu empresa está registrada, tu plazo de 24 horas tiene un punto único de fallo con batería de móvil.

Paso 6 — Ensaya antes del 11 de septiembre, no después

Dos ensayos, ambos recomendables este mes:

  1. La vía de la alerta. Lanza el curl anterior con No molestar realmente activado, en el teléfono que de verdad estará en la mesilla. Activa Reintentar llamada fallida en la app para que una llamada que falle se intente de nuevo. Una vía de escalado sin probar es una suposición.
  2. La vía de presentación. Recorre una notificación sobre el papel con las guías paso a paso de registro y envío de ENISA, actualizadas a lo largo de agosto de 2026 (SRP de ENISA). Crea ya las cuentas EU Login, confirma qué CSIRT es tu coordinador y envía pronto la invitación al representante suplente: caduca a los siete días.

El segundo ensayo tiene un matiz que conviene conocer: en la guía de julio de ENISA, la URL pública de la plataforma todavía figuraba como «se proporcionará en el lanzamiento», así que aún no era posible una prueba real de extremo a extremo (cyberresilienceact.eu). ENISA se ha comprometido a que la plataforma esté operativa el 11 de septiembre de 2026. Ensaya todo lo que dependa de ti y no conviertas la preparación de la plataforma en una excusa para retrasar la tuya.

Lo que Echobell no hace

Ser específico aquí importa más de lo habitual, porque el asunto es regulatorio:

  • No te hace cumplidor. Echobell es un canal de notificación. Delimitar tus productos, mantener un proceso de gestión de vulnerabilidades, decidir si se activa el artículo 14, registrarte en la SRP y presentar a tiempo son cosa tuya. Ninguna herramienta de alertas ha satisfecho jamás una obligación de notificación.
  • No presenta nada. No hay API por la que presentar y, si la hubiera, Echobell no sería quien la llamara. Hace sonar un teléfono; el resto lo hace una persona registrada.
  • No es una marca temporal legal. La variable {{time}} registra cuándo llegó el disparador a Echobell, en UTC. Cuándo empezó el «conocimiento» es una cuestión fáctica sobre tu organización, y lo que la documenta es tu registro de incidentes, no una notificación push.
  • No tiene políticas de escalado ni acuse de recibo. No existe «si nadie contesta en diez minutos, llama al siguiente», ni rotaciones, ni traza de auditoría de quién confirmó qué. Para eso necesitas una plataforma de incidentes: ver alternativas a Opsgenie.
  • No garantiza la entrega. Una llamada depende de la infraestructura de push, la red y un teléfono cargado. Trátalo como la capa que acorta la distancia entre que un hecho llega y una persona lo sabe, no como un control que enseñar en una auditoría.
  • No sigue la hora local. Las variables de tiempo integradas son solo UTC y no siguen el horario de verano. Las condiciones que acotan una ventana horaria requieren ajuste manual dos veces al año.

Preguntas frecuentes

¿Usar Echobell nos hace cumplir el CRA?

No. El CRA impone obligaciones a los fabricantes y ninguna aplicación de notificaciones puede satisfacerlas. Lo que Echobell aborda es un modo de fallo concreto: que la alerta temprana de 24 horas se pierda porque la persona que podía presentarla no se enteró hasta el siguiente día laborable. Es un fallo real y frecuente, pero es una pieza de un programa de cumplimiento mucho mayor.

¿Cuándo arranca de verdad el reloj de 24 horas?

Cuando el fabricante tiene conocimiento de la vulnerabilidad explotada activamente o del incidente grave. El reglamento no define un instante exacto, y el conocimiento depende de los hechos y de la rapidez con que puedan establecerse (DLA Piper). En la práctica eso aboga por un triaje rápido y documentado: cuanto mayor sea el hueco entre que llega una señal y alguien la evalúa, más difícil será explicarlo después.

Somos una empresa pequeña. ¿Estamos exentos?

De notificar, no. El artículo 64 excluye a microempresas y pequeñas empresas de las multas administrativas específicamente por incumplir el plazo de 24 horas del artículo 14(2)(a) o 14(4)(a). La obligación de notificar sigue, la notificación de 72 horas y el informe final no se ven afectados, y las definiciones de microempresa y pequeña empresa no son algo que puedas dar por supuesto. Trátalo como una mitigación estrecha, no como un salvoconducto.

Nuestro buzón de seguridad se vigila en horario laboral. ¿No basta?

Solo si aceptas perder hasta dos tercios de la ventana en un fin de semana normal. Un informe que llega el viernes a las 18:00 te deja un plazo que vence el sábado a las 18:00. Vigilar en horario laboral es un valor por defecto razonable para casi todo lo demás; el reloj de 24 horas es justo el caso que no cubre.

Sí, y deberían. Comparte un canal y todos los suscriptores reciben el mismo disparador, cada uno con su urgencia. El ingeniero que confirma la explotación y la persona que va a enviar el formulario tienen que empezar en el mismo minuto, no en secuencia.

¿Ayuda esto con el deber del artículo 14(8) de informar a los usuarios?

Indirectamente. El artículo 14(8) exige informar a los usuarios afectados sobre la vulnerabilidad o el incidente y, cuando sea necesario, sobre las medidas correctoras. Eso es comunicación con clientes y necesita tus propios canales. Echobell puede despertar a la vez a quien gestiona esa comunicación y a quien gestiona la presentación, de modo que ambos flujos arranquen juntos.

Ya notificamos bajo NIS2 o DORA. ¿Es lo mismo?

No, aunque las formas riman. NIS2 y DORA imponen deberes a entidades según el sector y la criticidad; el CRA los impone a fabricantes según los productos que introducen en el mercado de la UE. Una misma organización puede estar sujeta a los tres, con relojes y destinatarios distintos. Si esos regímenes también te aplican, ver alertas de notificación de incidentes DORA y NIS2: la capa de alertas puede compartirse aunque las obligaciones no.

¿La llamada atraviesa de verdad el modo No molestar?

Las notificaciones de tipo Llamada se entregan como alertas de llamada, y eso es lo que les permite atravesar el modo Concentración en iOS. No es magia: sigue dependiendo de los ajustes del sistema, la red y un teléfono cargado. Pruébalo en el dispositivo real, con el modo Concentración realmente activo, antes de confiar en ello, y activa Reintentar llamada fallida.

¿Esto es solo para iOS?

No. Echobell está en iOS y en Android vía Google Play (lanzamiento en Android). El comportamiento de las alertas tipo llamada difiere entre plataformas, así que prueba en el dispositivo que la persona de guardia vaya a llevar de verdad.

¿Qué deberíamos poner en el payload del webhook?

Lo mínimo para decidir si levantarse: el producto, el tipo de señal, una línea de contexto y un externalLink al ticket con el detalle. Echobell guarda el contenido y el historial de notificaciones en el dispositivo y solo cuentas, canales y suscripciones en el servidor (modelo de privacidad), pero el hábito correcto con material sensible sigue siendo enviar un puntero, no el contenido.

Relacionados

Artículos relacionados

Alertas de trading nocturno: el mercado deja de cerrar el 6 de diciembre

La renta variable estadounidense pasa a una jornada de 23 horas el 6 de diciembre de 2026, y los derivados cripto de CME cotizan 24/7 desde mayo. Así se convierte una alerta nocturna en una llamada con Echobell, y esto es lo que una alerta más ruidosa sigue sin arreglar.

Leer más

Tu agente de IA te está esperando: convierte las aprobaciones en llamadas

Los agentes autónomos se detienen y esperan en silencio cuando necesitan a una persona. Nada en el stack de agentes hace sonar tu teléfono. Así se conectan las pausas de aprobación y los fallos con Echobell.

Leer más

Notificación de incidentes DORA y NIS2: recibe una llamada antes de que se agote el plazo

DORA te da 4 horas desde la clasificación. NIS2, 24 horas desde el conocimiento. Ningún reloj se detiene de noche. Así se convierte una alerta de detección en una llamada real con Echobell.

Leer más