CRA Artículo 14: Tiene 24 horas para notificar y la plataforma aún no está operativa

La mayoría de los equipos GRC archivaron el Cyber Resilience Act bajo dos palabras: «producto» y «2027».

Ambas son incorrectas.

La obligación de notificación del artículo 14 se aplica a partir del 11 de septiembre de 2026. No diciembre de 2027. Esa es la fecha que todos recuerdan, y es la equivocada.

Tres semanas.

Y no cubre únicamente lo que se comercialice el año que viene. Cubre lo que ya se ha comercializado. Un producto puesto en el mercado de la UE en 2018 y todavía disponible hoy está en el ámbito de la notificación desde el día en que la obligación entra en vigor.

Si su organización vende en la UE cualquier cosa con elementos digitales, este es su proceso de gestión de incidentes, no el papeleo del equipo de producto.

Qué exige realmente el artículo 14

Dos detonantes, tres plazos, un canal.

Los detonantes:

• una vulnerabilidad explotada activamente en el producto
• un incidente grave con impacto en la seguridad del producto

Los plazos:

• 24 horas: alerta temprana, desde el momento en que se toma conocimiento
• 72 horas: notificación completa, incluidas las medidas correctivas o de mitigación adoptadas
• 14 días: informe final, una vez disponible una medida correctiva para una vulnerabilidad explotada activamente
• 1 mes: informe final para un incidente grave, una vez gestionado

El canal:

Una única comunicación a través de la Single Reporting Platform de ENISA, dirigida al CSIRT del establecimiento principal, puesta simultáneamente a disposición de ENISA.

Observe lo que no figura ahí. Esto no significa «notificar cada CVE». El detonante es la explotación activa en la naturaleza, o un incidente grave. Esa distinción es la diferencia entre un proceso viable y un equipo que se ahoga en la segunda semana.

Desglosemos lo que hay que hacer bien.

1. La fecha es 2026. La que memorizaron es 2027.

El CRA (Reglamento (UE) 2024/2847) entró en vigor el 10 de diciembre de 2024. El grueso de las obligaciones (seguridad por diseño, documentación técnica, evaluación de la conformidad, marcado CE) se aplica desde el 11 de diciembre de 2027.

El artículo 71(2) extrae las obligaciones de notificación y las adelanta quince meses.

A continuación, el artículo 69(3) cierra la vía de escape. Las disposiciones transitorias que permiten que los productos existentes permanezcan en el mercado hasta diciembre de 2027 sin conformidad plena no se extienden a la notificación.

Por tanto, el universo en alcance el 11 de septiembre no es la hoja de ruta de 2027. Es toda la base instalada.

Consejo: Si el inventario de productos solo recoge lo que está en desarrollo activo, no es un inventario de productos. Es un backlog.

2. El reloj arranca en «toma de conocimiento». Nadie ha definido eso.

Aquí es donde todo esto se salva o se hunde, y no es una cuestión jurídica.

Veinticuatro horas no es mucho tiempo. Es un día laborable, o una noche de sábado. El reloj no arranca cuando el equipo legal conviene en que hay un problema. Arranca cuando la organización toma conocimiento.

Entonces, ¿quién es «la organización»?

• un técnico de soporte que ve un ticket extraño a las 19:00
• un investigador que envía un correo a la dirección genérica security@
• un feed de inteligencia de amenazas que señala el nombre del producto
• el SOC de un cliente que llama al gestor de cuenta

Cualquiera de estos puede ser el momento de toma de conocimiento. Si ninguno sabe qué hacer a continuación, las 24 horas se consumen mientras un correo espera sin leer.

Antes de septiembre hay que tener por escrito tres cosas:

• qué evento constituye toma de conocimiento, en lenguaje claro
• quién está autorizado a declararla, con un sustituto nombrado
• dónde se registra el reloj, para poder demostrar cuándo arrancó

Este último punto importa más de lo que la gente espera. Si un regulador pregunta por qué la alerta temprana llegó en la hora 31, «tomamos conocimiento más tarde de lo que usted cree» solo es una respuesta válida si se puede demostrar.

Anécdota: Todos hemos visto esto suceder con el GDPR. Una brecha se declara tres semanas tarde, y no porque alguien ocultara algo. Soporte la registró como un bug. IT la llamó problema de configuración. Nadie en la cadena había acordado jamás qué contaba realmente como brecha de datos personales, así que el reloj nunca arrancó. Legal se enteró cuando un cliente hizo una pregunta.

El mismo mecanismo bajo el CRA, con una ventana más estrecha. Las definiciones son la parte aburrida. También son la parte que decide si se llegó tarde.

3. El CRA exige notificar antes de exigir escuchar

Este es el problema de orden que nadie señala, y es el que atrapará a los equipos más cuidadosos.

El artículo 13(8) exige que los fabricantes dispongan de políticas y procedimientos, incluida la política de divulgación coordinada de vulnerabilidades establecida en el Anexo I, Parte II, punto (5), para tramitar y remediar las vulnerabilidades notificadas desde fuentes internas o externas.

En realidad hay tres obligaciones jurídicamente distintas ahí, y en la mayoría de las empresas un único buzón sirve para las tres:

• una política CVD, redactada, publicada y aplicada
• una dirección de contacto para notificar vulnerabilidades en los productos propios y en los componentes de terceros que se comercializan
• un punto de contacto único a través del cual los usuarios puedan llegar directamente a una persona

El momento en que se aplican. Esas obligaciones están en el Anexo I, Parte II. El Anexo I pasa a ser jurídicamente vinculante el 11 de diciembre de 2027. La notificación del artículo 14 pasa a ser vinculante el 11 de septiembre de 2026.

Léase de nuevo. Durante quince meses, la ley exige notificar vulnerabilidades explotadas activamente en los productos, sin exigir todavía operar el canal a través del cual se tomaría conocimiento de ellas.

Un equipo que siga las fechas al pie de la letra pasará esos quince meses con un reloj de 24 horas sin una vía fiable para saber que ha arrancado. Porque la respuesta honesta a «¿cómo descubren la mayoría de los fabricantes la explotación activa de su propio producto?» es: alguien se lo dice.

Hay una segunda razón para hacer esto ahora. De todo lo que contiene el CRA, la política CVD y la dirección de contacto son las dos cosas visibles desde fuera de la organización. Una autoridad de vigilancia del mercado que se forme una primera impresión de la postura revisará el sitio web antes de solicitar ningún documento.

Cómo debe verse:

• política en una URL pública y estable, no enterrada en una página legal
• un archivo security.txt en el dominio
• un buzón monitorizado con un responsable nombrado y un sustituto, no un alias que nadie lee
• alcance declarado, tiempos de respuesta esperados, qué pruebas están dentro y fuera de los límites, cómo se gestiona el crédito y la publicación
• cada notificación registrada, porque aplicar la política es en sí mismo la obligación

Consejo: No hace falta inventar nada. ISO/IEC 29147 e ISO/IEC 30111 son los estándares de referencia para la divulgación y el tratamiento, y el toolkit de divulgación de vulnerabilidades del NCSC es un sólido punto de partida gratuito. Publicar algo funcional en tres semanas es mejor que publicar algo perfecto en diciembre de 2027.

4. No se puede notificar lo que no se puede nombrar

La fase de las 72 horas solicita el tipo y la clasificación del producto. Eso significa que se necesita, antes de un incidente y no durante uno:

• la lista de productos con elementos digitales que se ponen en el mercado de la UE
• para cada uno, si es por defecto, importante (Anexo III, Clase I o II) o crítico (Anexo IV)
• un SBOM en un formato legible por máquina de uso común

La clasificación sigue la función principal del producto, y cuando más de una clase encaja, se aplica la más estricta.

El SBOM es la parte que los equipos subestiman. El artículo 14 exige notificar una vulnerabilidad en el producto. Si el producto incluye un framework al final de su vida útil que no está inventariado, la explotación activa no se detectará mediante la telemetría propia. Se sabrá por un cliente, o por las noticias, que es una forma muy cara de arrancar un reloj de 24 horas.

Consejo: Haga el ejercicio al revés. Elija un componente que sepa que está en tres de sus productos. ¿Puede producir esa lista en menos de una hora, hoy, sin preguntarle a ingeniería? Si no, ese es el primer gap.

5. La plataforma no está operativa. Regístrese de todas formas.

Esta es la parte que convierte esto en una historia real y no en una nota de cumplimiento.

La Single Reporting Platform, establecida por el artículo 16 y operada por ENISA, está previsto que sea operativa el 11 de septiembre de 2026. No antes. A mediados de agosto, la URL de acceso público no había sido publicada. Se prometieron vídeos cortos y un webinar dos semanas antes del lanzamiento.

La obligación es fija. La herramienta no lo es. Esa brecha corresponde asumirla al fabricante, no al regulador.

Tres cosas no dependen de que la plataforma exista:

Crear las cuentas EU Login ahora. El registro se realiza a través de EU Login en ecas.ec.europa.eu. La cuenta puede crearse hoy. Hacerlo en medio de un incidente, con un reloj de 24 horas en marcha, es un retraso autoinfligido.

Configurar dos accesos, no uno. Existe un Primary Assigned Representative que se registra seleccionando el rol, eligiendo el CSIRT coordinador, aceptando el acuerdo e introduciendo los datos del fabricante. El sustituto, o Secondary AR, recibe una invitación por correo electrónico, y esa invitación caduca a los siete días. Envíela y confírmela. Una invitación no aceptada no es un sustituto.

No esperar a la validación del CSIRT. La validación del AR por el CSIRT coordinador se produce tras el registro. Corre en paralelo y no bloquea la notificación. Los equipos que asuman que necesitan luz verde antes de poder notificar perderán horas que no tienen.

La orientación de ENISA se ha actualizado dos veces en el mismo mes. Las guías de registro y notificación se volvieron a fechar el 3 de agosto; la guía de interfaz apareció el 14 de agosto. Todo está marcado como sujeto a cambios. Construya el proceso interno sobre los campos obligatorios, no sobre las capturas de pantalla.

6. Todavía no existen normas armonizadas

El 13 de agosto de 2026, ETSI sometió a consulta pública 17 borradores finales de normas de producto CRA. Ninguna es una norma armonizada. El plazo de comentarios cierra a mediados de septiembre, con la aprobación extendiéndose hasta noviembre según el sector.

Los organismos notificados llegan en diciembre de 2026.

La posición honesta es esta: la infraestructura de conformidad del CRA sigue construyéndose, y la obligación de notificación llega antes de todas formas.

Si el plan era «empezaremos cuando se publiquen las normas», la ventana de notificación ya se ha perdido. Las normas indican cómo demostrar que el producto cumple los requisitos esenciales. No indican quién presenta la alerta temprana un domingo.

7. La notificación bajo NIS2 y DORA no cubre esto

Veo este supuesto constantemente, y es peligroso porque es casi correcto.

Puede que ya exista un músculo de 24/72 horas gracias a NIS2 o DORA. Bien. No es la misma obligación.

Un mismo evento puede activar ambas obligaciones. Un incidente grave en un producto que se fabrica y también se opera genera dos notificaciones, dos destinatarios, dos trazas documentales.

El reflejo que hay que construir ahora no es un proceso nuevo. Es un punto de decisión al inicio del proceso existente: ¿qué regímenes toca este evento? Responder eso en el minuto cinco, no en la hora veinte.

Anécdota: Seré directo sobre el estado del mercado. Casi ninguno de mis clientes está preguntando ahora por el CRA, porque todavía no están tomando NIS2 suficientemente en serio como para llegar a ese punto. Tres semanas. Esa es la imagen honesta.

El ejemplo que puedo dar es el propio. En Mobilexpense, donde ejerzo como CISO, es exactamente lo que estamos construyendo: un proceso de incidentes único con dos ramas. Misma entrada, mismas primeras preguntas, y después una bifurcación en el punto en que se decide si el evento es un asunto de entidad, de producto, o de ambos. La bifurcación es barata de diseñar ahora. Es muy cara de improvisar en la hora tres.

8. Qué se puede terminar realmente antes del 11 de septiembre

Tres semanas no son suficientes para construir un programa. Son suficientes para construir la parte que se activa primero.

Semana uno:

• crear las cuentas EU Login, principal y sustituta
• enviar y confirmar la invitación del Secondary AR antes de que caduque
• identificar el CSIRT coordinador
• iniciar la revisión legal de la política CVD, porque es el plazo más largo

Semana dos:

• publicar la política CVD, la dirección de contacto y el security.txt
• cerrar la lista de productos en alcance, incluidos los heredados
• asignar una clasificación a cada uno
• redactar la definición de «toma de conocimiento» y nombrar a las dos personas que pueden declararla

Semana tres:

• construir la alerta temprana de 24 horas como un formulario interno breve que recoja los campos obligatorios
• añadir la pregunta de enrutamiento de régimen al inicio del proceso de incidentes
• ensayarlo en papel. Un escenario, una noche de sábado, un cronómetro

Este último paso es el que todos omiten y el único que demuestra si los otros once funcionaron.

Reflexión final

La incómoda verdad del 11 de septiembre es que el regulador llega antes que su propio soporte tecnológico, y eso no cambia nada respecto a la posición del fabricante.

No se puede presentar una alerta temprana con un certificado ISO 27001. No se puede clasificar un producto con una política. Y no se puede arrancar un reloj de 24 horas con un proceso que solo existe en un documento que nadie ha ejecutado.

Los fabricantes que gestionen bien esto en septiembre no serán los que tengan el mejor análisis de brechas CRA. Serán los que, cuando el ticket llegue a las 19:00 de un sábado, tengan a una persona concreta que sabe que está autorizada a pulsar el botón.

Todo lo demás es preparación para ese único momento.

Las sanciones por incumplimiento de los requisitos esenciales y de las obligaciones del fabricante alcanzan los 15 millones de euros o el 2,5 % del volumen de negocio mundial anual total, la cuantía que sea mayor. Pero la multa no es el riesgo. El riesgo es descubrir, el día del incidente, que tomar conocimiento no era responsabilidad de nadie.

Si quiere construir correctamente el músculo de 24/72 horas (detonantes, escalada, evidencias y el enrutamiento regulatorio que decide qué regímenes toca un evento), eso es exactamente lo que trabajamos en el ISO/IEC 27035 Lead Incident Manager. Cinco días, alineado con DORA, NIS2 y ahora con el artículo 14 del CRA. Certificado o reembolsado.