Obligaciones de notificación del CRA: separar correctamente el pasaporte de producto, la notificación de seguridad y el historial de actualizaciones

El 11 de septiembre de 2026 comienza para los fabricantes de productos con elementos digitales una de las primeras obligaciones operativas del Cyber Resilience Act (CRA): las vulnerabilidades explotadas activamente y los incidentes de seguridad graves deberán notificarse a través de la nueva plataforma central de notificación. Esto es más que un nuevo plazo de cumplimiento. En cuestión de horas, deberán reunirse la identidad del producto, los mercados afectados, la evaluación técnica y las medidas adoptadas.

Un pasaporte digital de producto o una página de producto vinculada mediante un código QR puede ayudar a asignar claramente un dispositivo e informar posteriormente a los usuarios sobre una actualización. Sin embargo, no es ni el canal de notificación establecido por ley ni el lugar adecuado para almacenar detalles confidenciales sobre la explotación. Por ello, los fabricantes deberían separar ya tres flujos de datos: la notificación a las autoridades, la información pública del producto y el historial interno de actualizaciones.

El nuevo motivo: directrices del 27 y el 31 de julio

La Comisión Europea publicó el 27 de julio de 2026 su primera directriz exhaustiva sobre el CRA. Aborda, entre otros aspectos, las obligaciones de notificación, la evaluación de riesgos, los periodos de soporte y los cambios sustanciales. La directriz no es vinculante, pero concreta mediante 67 ejemplos cómo pueden aplicar las empresas el reglamento en la práctica.

Cuatro días después, el 31 de julio, ENISA actualizó su información sobre la Single Reporting Platform. Allí figuran ya el procedimiento previsto, los campos de entrada contemplados y las indicaciones para el registro. Está previsto que la plataforma esté operativa el 11 de septiembre de 2026; según la Comisión, las pruebas funcionales y de seguridad ya están en curso.

La distribución temporal es importante: las obligaciones principales del CRA se aplican, en principio, a partir del 11 de diciembre de 2027. Sin embargo, el artículo 14, relativo a las obligaciones de notificación, se aplica ya desde el 11 de septiembre de 2026. Así lo confirman tanto el artículo 71 del Reglamento (UE) 2024/2847 como la visión general de la Comisión sobre el procedimiento de notificación del CRA, actualizada el 31 de julio.

Tres espacios de datos en lugar de un pasaporte de producto sobrecargado

La notificación del CRA y una página pública de producto persiguen objetivos distintos. Quien represente ambos en un único conjunto de datos se arriesga a ofrecer o bien información insuficiente al equipo de incidentes, o bien demasiados detalles sensibles en la web pública.

1. Notificación confidencial a la SRP, el CSIRT y ENISA

La Single Reporting Platform es el canal de entrada establecido por ley. Deben notificarse dos tipos de eventos: una vulnerabilidad explotada activamente, sobre la que existan indicios fiables de explotación no autorizada, y un incidente de seguridad grave que afecte a la disponibilidad, autenticidad, integridad o confidencialidad de datos o funciones.

La notificación no contiene únicamente una denominación del producto. ENISA enumera, entre otros, los Estados miembros afectados, una primera evaluación, las contramedidas ya adoptadas, las posibles medidas para los usuarios y la sensibilidad de la información como campos. En fases posteriores pueden incluirse el nivel de gravedad, las repercusiones, información sobre los atacantes y detalles técnicos de la actualización de seguridad. Esta información no debe aparecer automáticamente en una página DPP de libre acceso.

2. Información pública sobre el producto y la seguridad

El flujo de datos público responde a otras preguntas: ¿Qué producto y qué versión tengo? ¿Sigue siendo compatible? ¿Hay disponible una actualización de seguridad? ¿Qué debo hacer concretamente como usuario? Para ello puede ser útil una página de producto estable accesible mediante un código QR u otro soporte de datos.

La página pública debería mostrar únicamente información aprobada: intervalos de modelos y versiones afectados, versión segura disponible, indicaciones de instalación, contacto de soporte y fecha de publicación. Los detalles de explotación, las reglas internas de detección, las vías de ataque sin parchear o los datos personales del incidente deben permanecer en el procedimiento protegido. La decisión sobre una advertencia pública no corresponde al código QR: conforme al artículo 17 del CRA, el CSIRT coordinador puede informar al público o pedir al fabricante que lo haga cuando sea necesario para prevenir o contener el problema.

3. Historial interno de actualizaciones y evidencias

El tercer flujo es el expediente de trabajo trazable. Vincula el ID del producto, las versiones de hardware y software, la lista de componentes de software, el momento en que se tuvo conocimiento, las decisiones de triaje, las fases de notificación, la aprobación del parche y la comunicación pública. Este historial debe versionar los cambios, en lugar de sobrescribir silenciosamente las evaluaciones anteriores.

Para una operación DPP, esta diferencia es fundamental: la vista pública muestra el estado actual aprobado; el historial interno demuestra cómo se llegó a él. Quien ya gestione los datos de producto basándose en eventos puede utilizar el mismo principio que en las DPP-actualizaciones y los webhooks: un evento desencadena procesos posteriores, pero cada destinatario recibe únicamente los campos previstos para su función.

El reloj del CRA comienza con el conocimiento

El artículo 14 establece plazos escalonados. En el caso de una vulnerabilidad explotada activamente, debe emitirse una alerta temprana sin demoras indebidas y, como máximo, en las 24 horas siguientes a tener conocimiento de ella. En un plazo de 72 horas debe presentarse la notificación de vulnerabilidad más detallada. El informe final debe estar disponible como máximo 14 días después de que esté disponible una medida correctiva o de mitigación.

En el caso de un incidente de seguridad grave también se aplican 24 horas para la alerta temprana y 72 horas para la notificación del incidente. El informe final debe presentarse en el plazo de un mes desde la notificación de 72 horas. Por tanto, los plazos no comienzan con la publicación de un CVE ni con la siguiente versión periódica, sino en el momento en que se considera que el fabricante ha sido informado.

Para la práctica, se recomienda un procedimiento claro:

Registrar con marca temporal la entrada procedente del soporte, la monitorización, la investigación o la cadena de suministro.
Resolver el producto y la versión mediante un ID interno de producto estable.
Evaluar la explotación o la gravedad del incidente a través del equipo responsable.
Generar el conjunto de datos de 24 horas a partir de la información mínima confirmada y presentarlo mediante la SRP.
Completar los conocimientos técnicos hasta la fase de 72 horas sin perder el estado original.
Aprobar por separado el parche, la medida para los usuarios y la información pública.
Vincular el informe final y el historial interno.

Esta cadena debería practicarse antes de septiembre. ENISA señala que las organizaciones pueden automatizar sus procedimientos internos y bases de datos, pero que la plataforma no ofrecerá una API en el momento de su puesta en marcha. Por ello, un proceso de exportación y revisión por dos personas resulta más realista que una integración directa sin comprobaciones.

Un ID de producto común, pero derechos de acceso separados

Separar no significa mantener tres copias desconectadas. El enfoque más adecuado es una referencia de producto común e inmutable, con vistas dependientes de la función.

Como mínimo, deberían estar disponibles estas correspondencias:

ID interno del producto y referencia al modelo, lote o número de serie;
versión de hardware, firmware y software;
Estados miembros en los que se ha comercializado la variante afectada;
estado de la evaluación de seguridad y momento en que se tuvo conocimiento;
referencias a la notificación de 24 horas, la de 72 horas y el informe final;
medida para el usuario aprobada y versión de destino segura;
estado de publicación de la página pública del producto.

La autorización debería plantearse por campos. El equipo de incidentes y los responsables del CRA necesitan el expediente completo. El soporte y el departamento comercial necesitan una instrucción de actuación aprobada. Los usuarios solo ven la notificación pública. En este contexto, lo ideal es que el código QR transporte únicamente una dirección de producto estable; la plataforma subyacente decide, según el estado y la función, qué información se entrega.

Qué deberían probar los fabricantes antes de septiembre

Un caso de prueba adecuado no necesita una vulnerabilidad real. Elija un producto conectado, una versión de firmware afectada y tres Estados miembros. Simule que se tiene conocimiento del problema en un día laborable y compruebe lo siguiente:

¿Puede el equipo confirmar en 24 horas la cobertura del producto y la información mínima?
¿Está claro quién debe acceder a la SRP como representante a través de EU Login?
¿Pueden añadirse datos de las 72 horas sin hacer públicos detalles confidenciales?
¿La aprobación del parche da lugar a información revisada para los usuarios en todos los idiomas necesarios?
¿Permanece estable la URL pública cuando cambian la versión y las medidas?
¿Puede saberse quién aprobó qué estado y cuándo?

Para este último punto, resulta útil una gestión de datos coherente y versionada. El artículo de qr3 sobre la actualización continua de DPP muestra la idea básica: la identidad permanece estable mientras los datos especializados se actualizan de forma controlada. En el proceso del CRA se añade una capa más estricta de confidencialidad y aprobación.

Conclusión: el pasaporte de producto es un distribuidor, no un centro de notificación

Las nuevas directrices hacen operativo el plazo de septiembre. Los fabricantes no necesitan integrar una base de datos confidencial de vulnerabilidades en su pasaporte digital de producto. Necesitan, más bien, una transición sólida entre tres áreas claramente separadas: la notificación a las autoridades, las evidencias internas y la información aprobada para los usuarios.

Un ID de producto común mantiene unidas estas áreas. Las funciones, las aprobaciones y el versionado evitan que los detalles confidenciales salgan al exterior o que los usuarios se enteren demasiado tarde de una medida disponible. El código QR sigue siendo útil, pero deliberadamente poco llamativo: conduce de forma permanente al contexto correcto del producto. El verdadero cumplimiento del CRA se genera en los procesos que hay detrás.