Cyber Resilience Act
ENISA detalla el acceso de fabricantes al SRP del CRA justo cuando empieza la obligación de notificar
17 min lectura
Imagen generada por IALa guía que ENISA actualizó el 9 de septiembre de 2026 no cambia el Cyber Resilience Act. Hace algo menos vistoso y bastante más útil: explica cómo deben moverse los representantes autorizados de los fabricantes dentro de la Single Reporting Platform (SRP), la plataforma europea para comunicar vulnerabilidades explotadas e incidentes graves.
La fecha importa. Desde el 11 de septiembre de 2026 se aplican las obligaciones de notificación del artículo 14 del Reglamento (UE) 2024/2847, aunque la mayor parte del CRA será aplicable el 11 de diciembre de 2027. Dicho de otro modo: el mercado acaba de entrar en la fase en la que reportar ya no es solo preparar procedimientos para el futuro. La ventanilla está abierta.
La página de ENISA describe funciones concretas de la interfaz: consultar y actualizar los datos del fabricante, invitar a un representante autorizado secundario, añadir asociaciones con otros fabricantes, solicitar el cambio de representante secundario a principal y trabajar con estados como “Active”, “Verified” y “Unverified”. Parece gestión de usuarios. En realidad, es la infraestructura administrativa que decide quién puede notificar en nombre de un fabricante y con qué autoridad.
Aquí está el quid. En un incidente con una ventana de 24 horas, una cuenta sin validar, un representante único de vacaciones o una asociación que todavía figura como “Unverified” no son pequeños inconvenientes de portal. Son riesgos de cumplimiento.
La guía llega cuando el reloj del artículo 14 ya corre
El artículo 14 del CRA obliga a los fabricantes a notificar a ENISA, mediante la SRP, las vulnerabilidades explotadas activamente y los incidentes graves que afecten a la seguridad de productos con elementos digitales. La regulación no espera a que el fabricante termine su análisis forense, cierre todas las preguntas técnicas o consiga una presentación impecable para el comité de riesgos.
Para una vulnerabilidad explotada activamente, el artículo 14 establece una alerta temprana en un plazo de 24 horas desde que el fabricante tiene conocimiento de ella. La notificación de vulnerabilidad debe seguir dentro de las 72 horas. El informe final llega después, una vez disponible la información exigida por el régimen aplicable y adoptadas las medidas correctivas correspondientes.
Los incidentes graves tienen igualmente una primera comunicación en 24 horas y una notificación posterior en 72 horas. El detalle práctico es incómodo: la organización debe ser capaz de decidir si el hecho entra en una de esas categorías mientras todavía está recopilando evidencias. El CRA no convierte la incertidumbre inicial en una exención automática.
La aplicación escalonada añade una trampa habitual. Que el conjunto del Reglamento sea aplicable en diciembre de 2027 no significa que todas sus obligaciones esperen hasta entonces. La propia previsión temporal del artículo 14 adelanta el régimen de notificación al 11 de septiembre de 2026. Una empresa que haya aparcado el SRP bajo la etiqueta “cumplimiento CRA en 2027” está trabajando con un calendario equivocado.
La guía de ENISA no es una norma nueva ni sustituye al texto legal. Es una instrucción de uso. Pero precisamente por eso revela dónde puede atascarse el cumplimiento: no en la redacción abstracta de la obligación, sino en la identidad, la asociación entre cuenta y fabricante, la verificación por el CSIRT designado como coordinador (CDaC) y la continuidad del acceso.
Qué resuelve realmente la interfaz del representante autorizado
El SRP no está pensado únicamente para que un fabricante entre, rellene un formulario y pulse “enviar”. La interfaz de AR —Authorised Representative, representante autorizado— gestiona una relación jurídica y operativa entre tres actores: el fabricante, su representante y el coordinador designado que valida la asociación.
La guía parte de una condición básica: el usuario debe tener estado “Active”, haber iniciado sesión y disponer del rol y de la asociación adecuados. El acceso al dashboard no es universal. Depende de la identidad del usuario y de las restricciones de rol y asociación aplicables al fabricante.
Desde “Settings”, el usuario puede consultar sus datos personales y actualizar la información del fabricante siguiendo pasos equivalentes a los de registro. Esto parece una función administrativa menor hasta que se considera su impacto en una investigación. Un nombre legal desactualizado, un identificador corporativo incorrecto o una dirección de contacto que ya no controla el equipo de seguridad pueden complicar la atribución del fabricante y la trazabilidad de sus notificaciones.
La página también permite gestionar asociaciones adicionales. El usuario activo entra en “Association Management”, selecciona “Add Manufacturer”, introduce los datos requeridos y guarda la solicitud. El sistema crea el registro del fabricante y la asociación con estado “Unverified”, remitiendo la petición al CDaC para su validación.
La guía incluye un límite operativo especialmente relevante: un representante autorizado con asociación no verificada puede presentar hasta 20 notificaciones. No es una licencia para operar indefinidamente con una asociación provisional. Es un margen limitado para que la organización no quede completamente bloqueada mientras espera la validación. El número debería formar parte de los controles internos del fabricante: si el equipo no sabe cuántas notificaciones ha presentado bajo una asociación no verificada, tampoco sabe cuánto margen operativo conserva.
El representante secundario deja de ser una formalidad
ENISA permite al representante autorizado principal invitar a un representante secundario o de respaldo mediante la opción “Invite Backup”. La función solo está disponible cuando se cumplen tres condiciones: el usuario está activo, tiene el rol de representante principal y la asociación con el fabricante aparece como “Verified”.
El procedimiento exige introducir la dirección de correo que el futuro representante secundario utiliza para registrarse en EU Login. El SRP envía una invitación, crea un nuevo registro de usuario asociado a los datos del fabricante y asigna el rol cuando el proceso de registro se completa.
La precisión sobre EU Login no es decorativa. El control de identidad no termina en el correo corporativo del candidato. La dirección introducida debe coincidir con la cuenta empleada en el sistema europeo de autenticación. Si una compañía invita a una dirección genérica, a una cuenta antigua o a un buzón que no coincide con el registro EU Login del representante, habrá generado una intención de continuidad, no una continuidad funcional.
Para los equipos de compliance, la lección es sencilla: el representante secundario debe existir antes de que se produzca el incidente, no cuando el principal ya está intentando notificar desde un aeropuerto. El control debería incluir una prueba real de acceso, no solo la evidencia de que se envió una invitación.
La dependencia de un único representante es además una mala arquitectura de control. La obligación de notificar recae en el fabricante, pero el canal de comunicación puede depender de una persona concreta, de su cuenta y de una asociación validada. Un procedimiento que diga “el representante autorizado notificará a ENISA” está incompleto si no responde a cuatro preguntas: quién le sustituye, cómo se activa la sustitución, qué permisos tiene y cuándo se probó por última vez.
Qué significa estar “Verified” o “Unverified”
La distinción entre estados es uno de los elementos más importantes de la guía. Una asociación “Verified” indica que el vínculo entre el representante autorizado y el fabricante ha sido validado por el CSIRT designado como coordinador. Una asociación “Unverified” indica que la solicitud existe, pero la validación todavía está pendiente.
La diferencia no es cosmética. El representante principal solo puede invitar a un secundario cuando la asociación está verificada. El usuario con una asociación no verificada puede presentar hasta 20 notificaciones, pero trabaja con una capacidad limitada y pendiente de confirmación. La verificación también aporta una base más sólida para acreditar que la persona que comunicó el hecho estaba autorizada a actuar por cuenta del fabricante.
El flujo introduce una tensión operativa inevitable. La necesidad de registrar una asociación puede aparecer antes de que el CDaC la haya validado, especialmente si el fabricante descubre una vulnerabilidad en un producto que acaba de incorporarse al perímetro regulado. Esperar a tener todos los vínculos perfectos puede consumir el tiempo disponible para la alerta. Notificar con una asociación no verificada preserva la capacidad inicial, pero deja una dependencia pendiente que debe seguirse hasta su resolución.
La respuesta correcta no consiste en elegir entre seguridad y burocracia. Consiste en diseñar una matriz de asociaciones con estado, fecha de solicitud, responsable interno, CDaC correspondiente y número de notificaciones utilizadas. Esa matriz debe vivir junto al inventario de productos con elementos digitales y al registro de vulnerabilidades, no en una bandeja de entrada individual.
Una asociación no verificada no debería cerrarse administrativamente como “pendiente” y olvidarse. El fabricante necesita un control de escalado: revisión periódica, confirmación de que el correo de contacto es operativo y evidencia de cualquier comunicación con el coordinador. Si el proceso de verificación tarda, la dirección debe conocerlo antes de que el contador del artículo 14 empiece a correr.
El cambio de representante principal requiere gobierno, no solo un botón
La guía permite que un representante secundario solicite asumir el rol de representante principal. Para hacerlo, debe estar asociado al fabricante, tener estado activo y entrar en “Settings” para seleccionar la opción de reclamar el rol principal. La solicitud se envía al CDaC para revisión y aprobación.
La función resuelve una situación frecuente: el representante principal abandona la organización, pierde acceso o deja de estar disponible. Pero el cambio no debe tratarse como una sustitución automática de permisos. La solicitud se somete a revisión; por tanto, hasta la aprobación el secundario conserva su rol existente, según el flujo descrito por ENISA.
Esto tiene una consecuencia que muchos planes de continuidad omiten. La designación de un secundario no equivale a concederle inmediatamente todas las facultades del principal. Una política de sustitución que diga “el backup toma el control” necesita identificar el evento que activa la reclamación, quién inicia la solicitud, cómo se informa al fabricante y qué ocurre con una notificación urgente mientras el cambio espera validación.
La compañía debería probar dos escenarios distintos. El primero es la indisponibilidad temporal del principal, en la que el secundario mantiene su rol y presenta una notificación utilizando los permisos existentes. El segundo es la pérdida estructural del principal, en la que el secundario debe solicitar el cambio. Mezclarlos en un único procedimiento es la forma más rápida de descubrir, durante un incidente, que la continuidad era solo una palabra en el documento.
También conviene registrar el cambio de rol como un evento de gobierno. Deben conservarse la solicitud, la aprobación del CDaC, la fecha efectiva, el responsable que la autorizó internamente y la comprobación posterior de que el acceso funciona. No porque el CRA imponga una carpeta con ese nombre, sino porque la organización tendrá que demostrar que sus comunicaciones fueron controladas y atribuibles.
El SRP no sustituye al proceso de respuesta a vulnerabilidades
El mayor riesgo de esta guía es leerla como si fuera un manual completo de cumplimiento. No lo es. Explica funciones de interfaz. No decide si una vulnerabilidad está siendo explotada activamente, si un incidente es grave, qué fabricante debe responder cuando participan varias entidades de un grupo ni cómo se aprueba internamente el contenido técnico de una alerta.
Esas decisiones pertenecen al sistema de gestión de vulnerabilidades y de incidentes del fabricante. El artículo 14 del CRA conecta la obligación externa con la capacidad interna para detectar, clasificar y comunicar. Si el equipo de producto no comparte información con el PSIRT, si legal recibe el expediente cuando ya han pasado 20 horas o si el SOC no conoce qué productos están cubiertos por el CRA, una interfaz perfectamente configurada no salvará el proceso.
El fabricante necesita, como mínimo, un vínculo trazable entre cinco elementos: producto afectado, vulnerabilidad o incidente, decisión de clasificación, persona autorizada para notificar y comunicación enviada a través del SRP. El objetivo no es producir burocracia adicional. Es evitar que la alerta temprana se convierta en una discusión retrospectiva sobre quién sabía qué y cuándo.
Una alerta de 24 horas no debería depender de que el equipo haya completado todos los campos del informe final. El procedimiento interno debe separar la decisión de notificar de la investigación exhaustiva. La primera comunicación debe contener la información disponible y activar el trabajo posterior; el informe ampliado llegará cuando haya evidencias suficientes. Si la organización espera certeza total, estará confundiendo calidad del análisis con puntualidad regulatoria.
También debe distinguirse el canal de notificación del canal de coordinación técnica. La comunicación en el SRP no reemplaza la gestión de parches, el aviso a clientes, la coordinación con investigadores, la preservación de evidencias o la interacción con las autoridades de mercado. Un registro en la plataforma acredita que se ha iniciado una comunicación regulatoria; no demuestra que el producto sea seguro ni que los usuarios hayan sido protegidos.
Qué deberían comprobar ahora los equipos de seguridad y compliance
La actualización de ENISA permite convertir una obligación abstracta en pruebas concretas. El primer control es un inventario de fabricantes y productos cubiertos, con la identificación del representante autorizado principal y secundario. Debe incluirse el estado exacto de cada asociación en el SRP y la fecha de la última verificación.
El segundo es una prueba de acceso. El representante principal y el secundario deberían iniciar sesión con sus cuentas EU Login, comprobar que el estado aparece como “Active” y confirmar que visualizan el fabricante correcto. La prueba debe ejecutarse con la misma lógica que una prueba de recuperación: alguien diferente del titular habitual debe poder completar las acciones autorizadas sin recibir credenciales compartidas.
El tercero es una prueba de sustitución. No basta con que el secundario figure en una hoja de cálculo. Debe conocerse el procedimiento para reclamar el rol principal, el tiempo que puede tardar la revisión del CDaC y el canal alternativo para escalar un problema de acceso. La guía no promete una aprobación inmediata; el plan interno no debería comportarse como si la prometiera.
El cuarto es el control del límite de 20 notificaciones asociado a una relación no verificada. Cada solicitud pendiente debe tener un contador y un propietario. Si el fabricante opera con varias entidades o marcas, el recuento no puede mantenerse en una única bandeja de correo. La unidad de control es la asociación con el fabricante, no la intuición del representante.
El quinto es un ejercicio de tiempo. El equipo debería simular el descubrimiento de una vulnerabilidad explotada activamente y medir cuánto tarda en: confirmar el producto afectado, identificar al representante disponible, entrar en el SRP, preparar la alerta inicial, obtener la aprobación interna mínima y conservar la evidencia del envío. Si el ejercicio consume 18 horas antes de llegar a la pantalla de notificación, no hay 24 horas de margen: hay seis.
La conexión con el resto del régimen europeo
El CRA no opera aislado. Un fabricante de productos conectados puede afrontar simultáneamente obligaciones del Reglamento General de Protección de Datos, de la Directiva NIS2 o de requisitos sectoriales de resiliencia. La notificación al SRP no determina por sí misma si existe una violación de datos personales que deba comunicarse a la autoridad de protección de datos conforme al artículo 33 del RGPD, ni sustituye una notificación bajo el artículo 23 de NIS2 cuando la entidad está dentro de su ámbito.
La diferencia de destinatarios y de plazos exige una matriz de decisión. Un fallo en un dispositivo médico conectado, una plataforma de pagos o un producto empresarial puede activar obligaciones distintas según el producto, la entidad afectada y el tipo de daño. El error más caro sería asumir que una comunicación al SRP satisface automáticamente todas las demás obligaciones europeas.
Para las entidades financieras, el análisis tiene además una conexión evidente con DORA. El artículo 17 del Reglamento (UE) 2022/2554 regula la gestión y clasificación de incidentes relacionados con las TIC, mientras que el artículo 19 establece la notificación de incidentes graves a la autoridad competente. Si un producto con elementos digitales de un proveedor tecnológico contribuye a un incidente operativo en una entidad financiera, habrá que analizar por separado qué debe notificar el fabricante al SRP y qué debe notificar la entidad financiera bajo DORA. Son canales distintos, con responsables distintos y con criterios que no deben mezclarse.
La coordinación europea tampoco elimina la responsabilidad corporativa. ENISA administra la plataforma y recibe las comunicaciones previstas por el CRA, pero la empresa sigue teniendo que mantener sus datos correctos, sus relaciones de representación actualizadas y su proceso de decisión documentado. La centralización del canal reduce fricción para las autoridades; no convierte el cumplimiento en un servicio externalizado.
La parte que la guía no resuelve: la calidad de la información
Una plataforma puede estar accesible y un representante puede estar verificado. Aun así, la notificación puede ser deficiente. La calidad depende de la capacidad del fabricante para describir el producto afectado, el alcance conocido, la vulnerabilidad, la explotación observada y las medidas de mitigación sin adornar la incertidumbre ni ocultarla.
El artículo 14 obliga a comunicar pronto, pero la rapidez no justifica datos inventados. Una primera alerta debe distinguir con claridad entre hechos confirmados, indicios y elementos todavía desconocidos. Esa disciplina es especialmente relevante cuando la empresa teme el impacto reputacional. El impulso de rebajar la gravedad para comprar tiempo puede producir una comunicación incompleta; el impulso contrario, declarar afectado todo el catálogo, puede desencadenar una respuesta desproporcionada y difícil de corregir.
La organización debería definir quién aprueba cada tipo de dato: el equipo de vulnerabilidades para la descripción técnica, producto para el alcance, legal para la base regulatoria y el representante autorizado para la presentación en el canal. No se trata de crear un comité que se reúna durante 23 horas. Se trata de asignar previamente autoridad y límites para que la decisión no quede huérfana cuando el incidente llegue de madrugada.
El registro de cambios del informe también importa. La guía de interfaz explica cómo realizar funciones, pero el fabricante debe conservar una versión interna de lo enviado, la hora de presentación, el usuario que lo presentó y las actualizaciones posteriores. La evidencia debe permitir reconstruir la secuencia completa sin depender de capturas de pantalla improvisadas después del incidente.
Una señal temprana para fabricantes y representantes
La actualización del 9 de septiembre de ENISA tiene un alcance modesto y una lectura estratégica. No anuncia una nueva sanción, no modifica los plazos del artículo 14 y no presenta una interpretación revolucionaria del CRA. Su valor está en hacer visible que la primera barrera del cumplimiento es administrativa: una identidad correcta, una relación validada y una ruta de sustitución que funcione.
El mercado tiene ahora una ventana corta para corregir fallos de acceso antes de que el volumen de notificaciones y asociaciones ponga a prueba el sistema. Los fabricantes que esperen a diciembre de 2027 para probar el SRP estarán dejando sin ejercicio precisamente la parte del régimen que ya está activa desde el 11 de septiembre de 2026.
La decisión razonable es tratar la cuenta del representante autorizado como un control crítico, no como un dato de contacto. Debe tener propietario, suplente, revisión de permisos, prueba de acceso, seguimiento del estado de verificación y conexión con el proceso de respuesta a vulnerabilidades. También debe existir una regla clara para saber cuándo una asociación “Unverified” se convierte en un riesgo que debe escalarse a dirección.
El CRA pretende que la seguridad de los productos digitales deje de depender de promesas genéricas del fabricante. La guía del SRP aplica la misma lógica a la notificación: no basta con afirmar que existe un proceso. Hay que demostrar que la persona correcta puede entrar en el sistema correcto, con el fabricante correcto, y comunicar el hecho correcto antes de que expire el plazo. La tecnología europea acaba de estrenar plataforma; ahora toca comprobar que las organizaciones no llegan a ella con las llaves equivocadas.