Notificación de incidentes y vulnerabilidades en virtud del CRA

01Qué debe notificarse

El artículo 14 del Cyber Resilience Act establece dos obligaciones de notificación para los fabricantes de productos con elementos digitales. Son más acotadas de lo que parece a primera vista: los fallos rutinarios y los parches ordinarios no están dentro del ámbito. Art. 14

• Vulnerabilidades explotadas activamente; una vulnerabilidad de su producto respecto de la cual existen pruebas fiables de que un actor malicioso la ha explotado en un sistema sin permiso del propietario. Una vulnerabilidad que usted descubra y corrija antes de que sea explotada se gestiona a través de su proceso de gestión de vulnerabilidades, no este canal de notificación.
• Incidentes graves; un incidente que afecta negativamente, o puede afectar negativamente, a la capacidad del producto para proteger la disponibilidad, la autenticidad, la integridad o la confidencialidad de datos o funciones. Los criterios de gravedad figuran en el artículo 14(5).

Las obligaciones no se limitan a los fabricantes comerciales. Responsables de software de código abierto asumen sus propias obligaciones de notificación en la medida en que intervengan en productos con elementos digitales. Art. 24(3)

02Los tres plazos

Cada notificación se desarrolla en tres etapas, medidas desde el momento en que usted tenga conocimiento de la vulnerabilidad explotada o del incidente grave. Los plazos son ajustados, por lo que la preparación importa. Art. 14(2)–(4)

• En el plazo de 24 hAviso temprano. Una primera notificación de que se ha producido una vulnerabilidad explotada activamente o un incidente grave, incluido, para los incidentes, si se sospecha que ha sido causado por actos ilícitos o maliciosos.
• En el plazo de 72 hNotificación de vulnerabilidad / incidente. Una descripción más completa: la naturaleza general de la vulnerabilidad y del exploit, una evaluación inicial y las medidas correctoras o mitigadoras adoptadas, además de las que pueden adoptar los usuarios.
• Informe finalInforme final. Para una vulnerabilidad, a más tardar 14 días después de que esté disponible una medida correctora o mitigadora. Para un incidente grave, en el plazo de un mes desde la notificación de 72 horas. Expone la descripción completa, la gravedad, el impacto y la subsanación aplicada.

Repare en la asimetría de la última fila: el reloj de la vulnerabilidad se activa por la existencia de una corrección; el del incidente, por la notificación anterior. Son mecánicas distintas y conviene recogerlas por separado en su manual de actuación.

03Cuándo comienza

Las obligaciones de notificación son la primera parte importante del CRA en entrar en vigor. Mientras que la mayoría de las disposiciones son aplicables desde el 11 de diciembre de 2027, el artículo 14 es aplicable desde el 11 de septiembre de 2026; 21 meses después de la entrada en vigor del Reglamento. ENISA abrió la Plataforma Única de Notificación en esa misma fecha. Art. 71

04A quién se notifica

Las notificaciones se dirigen a ENISA y al CSIRT designado como coordinador, a través de un único punto de entrada y no mediante presentaciones separadas ante cada autoridad nacional. Ese punto de entrada es la Plataforma Única de Notificación, que ENISA establece, gestiona y mantiene en virtud del artículo 16. Art. 14 · 16

Qué CSIRT le corresponde depende de su establecimiento principal en la Unión o, si no está establecido en la UE, del de su representante autorizado. El CSIRT receptor difunde después la notificación a los CSIRT de los Estados miembros en los que el producto está disponible y, cuando proceda, a las autoridades de vigilancia del mercado. Art. 14(7) · 18

La lista de coordinadores se publicó el 4 de septiembre de 2026

Hasta el 4 de septiembre de 2026 no había una respuesta publicada a la pregunta más práctica de esta página: qué equipo nacional recibe realmente su presentación. ENISA ha publicado ahora una lista de los CSIRT designados como coordinadores que da una o varias URL de contacto para cada uno de los 27 Estados miembros, y la refechó el 10 de septiembre de 2026, así que vuelva a comprobar su fila antes de fiarse de una copia tomada antes. Irlanda remite a una página del NCSC dedicada al CRA; España ofrece dos vías separadas del INCIBE, una para incidentes y otra para la coordinación de vulnerabilidades.

La lista le dice quién es el coordinador de cada Estado miembro. No le dice cuál es el suyo, y el criterio del artículo 14(7) es más estricto de lo que suponen la mayoría de las organizaciones. Su establecimiento principal es el Estado miembro en el que las decisiones sobre la ciberseguridad de sus productos con elementos digitales se toman de forma predominante, que puede ser un centro de desarrollo y no un domicilio social o la mayor operación comercial. Cuando no pueda determinarse, el criterio subsidiario es el Estado miembro en el que tenga el mayor número de empleados en la UE. Si no hay ningún establecimiento en la UE, el orden es: el Estado miembro en el que su representante autorizado actúe para el mayor número de productos, después el importador que introduzca más productos en el mercado, después el distribuidor que comercialice más, y después el Estado miembro con más usuarios. Dado que esto fija el destinatario de todas sus presentaciones futuras, resuélvalo por adelantado, con apoyo jurídico, y deje constancia escrita del razonamiento.

Existe apoyo por ambas partes. ENISA gestiona un servicio de asistencia, con especial atención a las pymes, y los CSIRT designados como coordinadores deben prestar también asistencia sobre las obligaciones del artículo 14. ENISA además incorpora las vulnerabilidades corregidas a la Base de Datos Europea de Vulnerabilidades, y publica cada dos años un informe técnico de tendencias, el primero de los cuales debe presentarse en los 24 meses siguientes al inicio de las obligaciones de notificación. Art. 17(6)

La difusión de una vulnerabilidad notificada puede suspenderla el CSIRT, pero no usted

El CSIRT receptor puede retrasar o retener la difusión posterior por motivos justificados de ciberseguridad, durante el tiempo estrictamente necesario; por ejemplo, cuando una vulnerabilidad se encuentra dentro de un procedimiento de divulgación coordinada. La Comisión precisó las condiciones en el Reglamento Delegado (UE) 2026/881, adoptado el 11 de diciembre de 2025. Cuando un CSIRT retiene una notificación debe comunicarlo de inmediato a ENISA, con una justificación y una indicación de cuándo procederá a difundirla.

Por separado, en circunstancias particularmente excepcionales puede marcar una de las condiciones restringidas del artículo 16(2) en su notificación de 72 horas: que la explotación se circunscribe al Estado miembro de su CSIRT, que una difusión ulterior sería contraria a los intereses esenciales de ese Estado miembro, o que la difusión plantea un riesgo elevado e inminente para la ciberseguridad. Si lo hace, ENISA recibe únicamente información limitada (que se ha realizado una notificación, información general sobre el producto, la naturaleza general del exploit y que se han invocado motivos de seguridad) hasta que el CSIRT libere la notificación completa.

05Registro en la plataforma

La orientación de ENISA sobre el registro, refechada el 10 de septiembre de 2026, y su orientación sobre la interfaz, refechada el 9 de septiembre de 2026, muestran las pantallas reales. El registro se abrió junto con la plataforma el 11 de septiembre de 2026, de modo que ahora es un recorrido que puede hacer y no solo leer. Aun así, ENISA le pide que no se registre de forma preventiva, por la razón que se expone más abajo, lo que hace que conocer el recorrido de antemano sea más útil y no menos: la primera vez que lo siga bien puede ser con un reloj de 24 horas en marcha.

Designe a dos personas antes de necesitarlas

La plataforma otorga a cada fabricante dos tipos de cuenta de usuario, y hoy puede decidir quién los ocupa. Un representante principal se registra primero y crea la entrada del fabricante en la plataforma. Esa persona invita después a un representante secundario , que desempeña una función de reserva frente al mismo fabricante y puede presentar en su nombre. Ambos son personas designadas por su nombre en su empresa. Dado que el envío es manual, un único notificante designado que esté de vacaciones, dormido o que se haya marchado es un riesgo operativo real, así que trate el segundo puesto como necesario y no como opcional.

EU Login es la credencial, y ambas personas pueden crearla hoy mismo

Las cuentas de la plataforma se autentican mediante EU Login, el servicio de inicio de sesión compartido de la Comisión Europea utilizado en sus sistemas en línea. Cree una para el representante principal y otra para el secundario en ecas.ec.europa.eu, utilizando direcciones de correo electrónico corporativas que sigan existiendo dentro de un año. La autenticación multifactor es obligatoria: ENISA exige MFA en la cuenta de EU Login antes del primer acceso a la plataforma, así que si su gente ya tiene cuentas de EU Login simples, haga que activen la MFA ahora y no durante un incidente. Las cuentas de EU Login son personales, y ENISA no opera ninguna autenticación corporativa distinta por encima de ellas. En sus páginas sobre identidad digital de confianza la Comisión explica qué es EU Login y cómo encaja en su marco de identidad más amplio.

El flujo de registro

En el primer acceso a la plataforma selecciona su función, elige su CSIRT designado en un desplegable, se autentica mediante EU Login, lee y acepta el acuerdo jurídico, confirma sus datos personales precargados (nombre, apellidos, correo electrónico, denominación legal) y a continuación introduce el nombre, la dirección y la información adicional del fabricante. Omitir un campo obligatorio del fabricante bloquea el flujo. Al finalizar, el estado de su cuenta es "Active" y "AR Primary User" es la función que usted tiene, recibe un correo de confirmación y la entidad del fabricante queda creada en la plataforma.

El secundario se une mediante invitación por correo electrónico del principal, confirma los datos personales y del fabricante precargados y queda registrado con la función "AR Backup User" frente al mismo fabricante. Esa invitación caduca a los 7 días, tras lo cual el registro se marca como "Invitation Expired" y debe enviarse una nueva. Configure la cuenta de reserva en la misma sesión que la principal; una invitación caducada descubierta en plena incidencia es un problema evitable.

El CSIRT comprueba a su representante de forma manual, pero eso no le impide presentar

Alguien tiene que confirmar que una persona determinada puede realmente notificar en nombre de un fabricante determinado, y esa comprobación corresponde al CSIRT designado como coordinador, al que ENISA abrevia ahora como CDaC. Es un paso manual, el procedimiento varía entre CSIRT y cada CSIRT define su propio enfoque. Y lo esencial: se produce tras su primer acceso a la plataforma y se ejecuta en paralelo con su notificación. En su actualización de 3 de agosto de 2026 ENISA lo dejó fuera de toda duda: la validación por el CDaC no es un requisito previo para cumplir la obligación de notificación del CRA, y no afecta a su capacidad de presentar notificaciones. Una cuenta no validada puede presentar igualmente dentro del plazo de 24 horas.

Esa es también la razón por la que ENISA aconseja registrarse e iniciar la validación solo cuando realmente necesite presentar, en lugar de preinscribir a todo el mercado y saturar a los CSIRT con comprobaciones especulativas. La preparación que se hace por adelantado son las cuentas de EU Login y la decisión sobre quién ocupa los dos puestos, no el registro en la plataforma en sí.

Una cuenta puede tener varios fabricantes

La misma orientación establece la gestión de los dos puestos. Un representante principal invita a uno de reserva mediante su dirección de correo electrónico, lo que crea un registro marcado como "Pending Invitation" sin función hasta que se acepta. Un representante secundario puede solicitar la promoción a principal, solicitud que se remite al CDaC para su revisión. La ENISA formalizó esto el 17 de septiembre de 2026, marcando la pregunta 9 de las preguntas frecuentes como «[ACTUALIZADA]» para indicar que un AR secundario «no tiene los mismos permisos administrativos que el AR principal, pero puede reclamar el rol de AR principal, sujeto a revisión y aprobación por el CSIRT designado». Cualquiera de los dos puede eliminar una asociación, que entonces se marca como "Deleted". Y una sola cuenta puede mantener asociaciones con varios fabricantes, cada una añadida mediante Association Management y verificada por separado.

Este último punto importa a los grupos con varias entidades fabricantes y a las empresas que actúan en virtud del artículo 18 para fabricantes establecidos fuera de la UE. Es también donde más muerde la trampa de denominación que se explica más abajo.

06Presentar una notificación

La notificación se gestiona desde un panel de control. Usted crea una notificación y después añade información al mismo registro en cada etapa, en lugar de presentar tres documentos separados. Cada etapa tiene su propia pestaña y cada una puede guardarse antes como borrador. El panel de control permite buscar por identificador de notificación, fabricante o título, ordenar por título o por última actualización, y filtrar por Estado miembro, tipo de envío o por un indicador Action Required correspondiente.

• Aviso tempranoInicie una nueva notificación desde el panel de control, cumplimente los campos obligatorios y seleccione un fabricante existente o añada uno. Al enviarla, queda accesible para su CSIRT designado y, automáticamente, para ENISA. Las confirmaciones por correo electrónico y por alerta se envían al CSIRT, a ENISA y a cada representante registrado para ese fabricante, no solo a la persona que la envió.
• 72 horasSolo disponible una vez que existe un aviso temprano. Abra la misma notificación y cumplimente la pestaña de 72 horas. ENISA la recibe automáticamente, salvo que invoque las condiciones del artículo 16(2), en cuyo caso el registro queda marcado como "72h Submitted under PEC" y la visión de ENISA permanece limitada hasta que el CSIRT lo libere.
• Informe finalSolo disponible una vez que existen las dos etapas anteriores. ENISA lo recibe automáticamente, salvo que se hayan invocado las condiciones del artículo 16(2).

Qué es obligatorio, y cuándo

ENISA ha publicado qué campos son obligatorios en cada etapa. La tabla corrige de manera útil una suposición extendida: el aviso temprano de 24 horas es una alerta, no una investigación.

• A las 24 horas; el tipo y el nivel de la notificación, el nombre del fabricante o del responsable, el producto y un título. Para los incidentes, si se sospecha de actos ilícitos o maliciosos. Los Estados miembros en los que el producto está disponible solo se exigen si ya dispone de ese dato.
• A las 72 horas; la naturaleza general de la vulnerabilidad y del exploit, las medidas correctoras o mitigadoras adoptadas y las medidas que pueden adoptar los usuarios. Para los incidentes, cuándo se detectó y cuándo se produjo, además de una evaluación inicial. La sensibilidad se señala aquí.
• En el informe final; la descripción completa, la gravedad y el impacto, la fecha en que estuvo disponible una medida correctora y el detalle de la actualización de seguridad. Para los incidentes, la causa raíz probable y las mitigaciones en curso.

Entre los campos opcionales que conviene registrar de todos modos están el CVE ID y el EUVD ID, ambos disponibles desde la primera etapa.

Cada campo tiene un límite de caracteres, y uno de ellos es muy corto

El Glosario de la SRP de ENISA, dimensionado por primera vez en la versión 1.1 de 5 de septiembre de 2026 y ahora en la versión 1.3 de 10 de septiembre de 2026, es el documento de ENISA que publica el tamaño de cada casilla. Redacte sus plantillas internas conforme a estos límites en lugar de descubrirlos a las dos de la madrugada:

• 4000 caracteres para los campos narrativos: el resumen, la información general sobre la vulnerabilidad o el incidente, las medidas correctoras que pueden adoptar los usuarios, las descripciones completas de gravedad e impacto, la evaluación inicial y, para los incidentes, las medidas de mitigación aplicadas y en curso.
• 2000 caracteres para las medidas correctoras o mitigadoras que ya haya adoptado, y para el detalle de la actualización de seguridad o de la medida correctora en el informe final.
• 800 caracteres para la justificación en texto libre que acompaña a una solicitud PEC en la notificación de vulnerabilidad de 72 horas.
• 255 caracteres para el título, el nombre del producto, el intervalo de versiones del producto, el nombre del componente, el vector de ataque, la justificación de sensibilidad y la causa raíz probable.
• 100 caracteres para el actor malicioso que explotó la vulnerabilidad. Eso es aproximadamente una línea, así que prevea nombrar al actor o remitir a una referencia de indicador en lugar de describir la campaña.

El glosario confirma además una pequeña comodidad: el campo Estados miembros en los que el producto está disponible llega precumplimentado con su propio CSIRT coordinador, y usted añade los demás mercados.

La edición, y el punto de no retorno

Una notificación enviada puede actualizarse, y la plataforma envía automáticamente una alerta y un correo electrónico a su CSIRT, a ENISA y a los CSIRT que ya la hayan recibido por difusión. Se aplican dos límites: una notificación cerrada no puede actualizarse, y el registro pasa a ser no editable una vez enviado el informe final.

Vigile la pestaña Alerts, también el fin de semana

Cada cuenta tiene una pestaña Alerts con código de color: las alertas no leídas aparecen en azul claro y pasan a gris una vez abiertas, y las alertas de color rojo solo aparecen cuando ha ocurrido algo excepcional. El ejemplo que da ENISA es el de un CSIRT designado que ha invalidado un envío. Por tanto, la presentación no es el final del intercambio, y ningún plazo del artículo 14 se mueve porque una notificación vuelva a usted. Quien vigile esa pestaña tiene que vigilarla fuera del horario laboral, lo que es un argumento más para poner un buzón de equipo supervisado detrás de los dos puestos en lugar de dos direcciones personales.

El contador de 72 horas de la plataforma no cuenta desde el conocimiento

Las preguntas frecuentes revelan cómo se comportan realmente las cuentas atrás en pantalla, y no siguen el plazo legal. ENISA actualizó las preguntas frecuentes el 10 de septiembre de 2026, el día anterior a la apertura, y dejó esta respuesta en pie, de modo que el comportamiento aquí descrito es el comportamiento que entró en servicio. En la versión actual, el contador de 72 horas muestra una fecha de vencimiento 48 horas después de que se envíe el informe de 24 horas, no 72 horas después de que usted tuviera conocimiento. ENISA afirma con claridad que, por tanto, una notificación puede aparecer como vencida antes de que hayan transcurrido 72 horas desde el conocimiento, y que la lógica se cambiará en una versión posterior para contar desde el campo «fecha y hora en que tuvo conocimiento», tanto para las vulnerabilidades como para los incidentes.

Los contadores del informe final vuelven a ser distintos. Para un incidente grave el contador muestra un mes después de la notificación de 72 horas. Para una vulnerabilidad explotada activamente no hay ningún contador, porque el plazo depende de cuándo esté disponible una medida correctora, algo que la plataforma no puede saber.

En el lanzamiento la plataforma no registra cuándo tuvo conocimiento

El 5 de septiembre de 2026 ENISA sustituyó su Glosario de la SRP campo por campo por la versión 1.1, y dos notas a pie de página que contiene importan más que ninguna otra cosa de la página. Para una vulnerabilidad explotada activamente, el campo Date/time when you become aware lleva la nota de que estará disponible en la próxima versión de la plataforma. Para un incidente grave, la nota indica que en la versión actual el campo equivalente se denomina Date/time the incident was detected.

Puesto junto a la lógica del contador anterior, esto cierra el círculo. Las preguntas frecuentes decían que el contador de 72 horas se corregiría una vez que llegara el campo de conocimiento; el glosario decía que el campo llega en una versión posterior. Ninguno de los dos se movió antes de la apertura: ENISA revisó de nuevo el glosario a la versión 1.3 el 10 de septiembre de 2026 y dejó ambas notas a pie de página intactas. Así, desde el primer día la plataforma no captura ninguna marca temporal de conocimiento para las vulnerabilidades, y para los incidentes captura el momento de la detección, que no es el momento del conocimiento.

07Qué puede hacer hoy

Cumplir una ventana de 24 horas es un problema operativo, no de papeleo. Ahora que la plataforma está abierta, la lista siguiente ya no es preparación para un acontecimiento futuro; el deber está en marcha, y todo lo que aquí no haya hecho es una exposición y no un plan.

• Cree sus cuentas de EU Login, con la MFA activada. Para el notificante principal y al menos una persona de reserva. Se tarda unos minutos en ecas.ec.europa.eu, y la plataforma no dejará entrar a nadie sin autenticación multifactor, de modo que activarla forma parte de la tarea y no es un refinamiento de ella.
• Identifique su CSIRT designado. ENISA publicó la lista de coordinadores para los 27 Estados miembros el 4 de septiembre de 2026, de modo que ahora es una tarea que puede terminar. Aplique el criterio de establecimiento principal del artículo 14(7), elija su fila y deje constancia escrita del razonamiento.
• Cree internamente el formulario de 24 horas. Una plantilla breve que refleje los campos obligatorios de aviso temprano de ENISA, para que su primera presentación real sea transcripción y no redacción. Guárdela en un lugar que puedan abrir ambos representantes, porque los borradores de la plataforma solo son visibles para quien los creó.
• Designe a las personas, también fuera del horario laboral. Decida quién determina que procede una notificación, quién la redacta y quién la envía. Como no hay API, el último paso es una persona concreta ante un teclado.
• Mantenga un SBOM preciso. No puede notificar sobre un componente que no sabía que había incluido. Mantenga una lista de materiales de software y actualícela a medida que cambien las versiones.
• Monitorícelo de forma continua. Coteje sus componentes con fuentes de vulnerabilidades conocidas para que un fallo explotado activamente aflore en horas, no en semanas. Nuestro SBOM y analizador de vulnerabilidades coteja su lista de materiales con el NVD y la base de datos de vulnerabilidades de la UE (EUVD).
• Confirme qué está realmente dentro del ámbito. La etapa de 72 horas pide el tipo de producto y la categoría del anexo III o IV, así que resuelva la clasificación antes de necesitarla. La herramienta de clasificación responde a eso, y la matriz de cumplimiento vincula la notificación a las obligaciones más amplias de gestión de vulnerabilidades del Anexo I en las que se encuadra.
• Decida quién lee la pestaña Alerts fuera del horario laboral. Un CSIRT designado puede invalidar un envío, y la alerta que lo indica llega a la plataforma y no solo a su bandeja de entrada. Ponga un buzón supervisado detrás de los dos puestos de representante.
• No confíe en la cuenta atrás de la plataforma. Registre usted mismo la marca de hora de su conocimiento. El contador de 72 horas en pantalla corre desde el envío del informe de 24 horas, no desde el conocimiento, por lo que puede marcar una presentación como vencida antes de que haya pasado el plazo legal.
• Read the AR User Manual, and watch the tutorial video. ENISA published the manual at launch and added the AR User Tutorial Video within days, so between the two, plus the guidance pages, you have the fullest available description of the live platform.
• Compruebe que ha elegido el coordinador correcto antes de presentar. ENISA advierte ahora de que seleccionar el CSIRT designado como coordinador equivocado puede provocar que la notificación quede invalidada, dejándole que vuelva a presentarla ante el correcto con el reloj aún en marcha.

08Sígalo en la fuente

Esta página refleja la situación a 11 de septiembre de 2026, el día en que se abrió la plataforma. Seguirá moviéndose, y ENISA edita sus páginas discretamente en lugar de anunciar cada cambio. En la semana previa al lanzamiento, las preguntas frecuentes se reescribieron el 4 de septiembre de 2026 y se actualizaron de nuevo el 10 de septiembre de 2026, la lista de coordinadores apareció el 4 de septiembre de 2026 y se refechó el 10 de septiembre de 2026, el glosario alcanzó la versión 1.1 el 5 de septiembre de 2026 y la versión 1.3 el 10 de septiembre de 2026, la orientación sobre circunstancias particularmente excepcionales llegó el 9 de septiembre de 2026, y el AR User Manual y los términos y condiciones de la plataforma se publicaron el 10 de septiembre de 2026. Desde el lanzamiento, las preguntas frecuentes se actualizaron de nuevo el 12 de septiembre de 2026 (el vídeo tutorial de usuario AR se publicó y la ficha informativa de la SRP se publicó en nueve idiomas adicionales) y el 17 de septiembre de 2026, cuando la pregunta 9 se marcó como «[ACTUALIZADA]» para documentar que un AR secundario puede reclamar el rol de AR principal, sujeto a revisión por el CDaC. Para consultas de asistencia, ENISA publica una dirección de servicio de asistencia en la página central, cra-srp-helpdesk [at] enisa.europa.eu. Estas son las fuentes primarias; todo lo anterior es nuestra lectura de ellas.

• ENISA · La propia Plataforma Única de Notificación (operativa desde el 11 de septiembre de 2026); seleccione el rol Assigned Representative e inicie sesión a través de EU Login con autenticación multifactor. Aquí es donde se presentan las notificaciones.portal.cra-srp.enisa.europa.eu
• ENISA · Plataforma Única de Notificación; la página central, con la ficha informativa, el manual de usuario, la dirección del servicio de asistencia y enlaces a todas las páginas de orientación.enisa.europa.eu/topics/product-security/single-reporting-platform-srp
• ENISA · Preguntas frecuentes sobre la SRP (actualizadas el 10 de septiembre de 2026); base jurídica, plazos, encaminamiento, tabla de campos, lógica de los contadores, qué hacer durante una interrupción y la dirección de la plataforma. Reescritas el 4 de septiembre y ampliadas el día anterior al lanzamiento. La más actual de las páginas de la SRP de ENISA, y la que conviene preferir cuando entren en conflicto.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions
• ENISA · CRA SRP AR User Manual (10 de septiembre de 2026); el manual del día del lanzamiento para los Assigned Representatives, y la descripción individual más completa de la plataforma tal como se abrió realmente.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-ar-user-manual
• ENISA · Lista de los CSIRT designados como coordinadores (publicada el 4 de septiembre de 2026, actualizada el 10 de septiembre de 2026); puntos de contacto para los 27 Estados miembros. Identifique su fila con el criterio del artículo 14(7) de la sección 04.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/list-of-csirts-designated-as-coordinators
• ENISA · Glosario CRA SRP (versión 1.3, 10 de septiembre de 2026); orientación campo por campo sobre lo que significa cada campo de notificación, cómo cumplimentarlo, su formato esperado, su límite de caracteres y la fase en la que se aplica. Atención a la dirección: ENISA trasladó el glosario a una URL glossary2 y la anterior sigue enlazada desde algunas de sus propias páginas, así que compruebe la línea de versión de la parte superior antes de fiarse de una copia.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-glossary2
• ENISA · Orientación sobre el registro de usuarios en la SRP; el flujo de registro paso a paso para usuarios principales y de reserva, con capturas de la interfaz.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-guidance-ar-user-registration
• ENISA · Orientación sobre el envío de notificaciones en la SRP; cómo se presentan y actualizan el aviso temprano, la notificación de 72 horas y el informe final, y qué desencadena cada estado.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-guidance-ar-notification-submission-and-update
• ENISA · Orientación sobre las funciones de la interfaz de la SRP (9 de septiembre de 2026); ajustes, asociaciones con fabricantes, el panel de control y la pestaña de alertas. Refechada el mismo día del lanzamiento, ahora coincide con las preguntas frecuentes en que una asociación no verificada puede presentar hasta 20 notificaciones.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-guidance-ar-interface-functions
• ENISA · Términos y condiciones de la CRA SRP (versión 1.0, 10 de septiembre de 2026); las condiciones que acepta al registrarse en la plataforma, publicadas el día anterior a su apertura.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-single-reporting-platform-terms-and-conditions
• ENISA · Orientación sobre las circunstancias particularmente excepcionales en la SRP (9 de septiembre de 2026); cuándo se aplica el PEC, el interruptor y los motivos de retraso del formulario de 72 horas, y qué hace el CSIRT coordinador con la justificación. La quinta página de orientación y la única que aborda directamente el PEC.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-guidance-particular-exceptional-circumstances-pec
• Comisión Europea · Obligaciones de notificación del CRA; la página de política, incluidas las preguntas frecuentes sobre la aplicación del CRA, cuya sección 5 aborda la notificación. La Comisión actualizó esta página el 11 de septiembre de 2026 para confirmar que la plataforma ya está operativa, y el documento de preguntas frecuentes independiente de la Comisión se actualizó por última vez el 4 de septiembre de 2026.digital-strategy.ec.europa.eu/en/policies/cra-reporting
• Comisión Europea · Orientación de aplicación del CRA (27 de julio de 2026); el punto 9.1 expone las obligaciones de notificación de los fabricantes y de los responsables de código abierto. Nuestro resumen de la orientación cubre el resto.digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation
• EU Login; cree la cuenta que utiliza la plataforma y active en ella la autenticación multifactor. Hágalo ahora.ecas.ec.europa.eu/cas/login

Para el texto vinculante, los artículos 14 a 17 establecen el ecosistema de notificación y el artículo 16 crea la plataforma; léalos en nuestro lector del Reglamento. Las fechas clave se recogen en la página situación actual de nuestro sitio.

09Preguntas frecuentes