Preparación del proceso de gestión de vulnerabilidades de un fabricante conforme al CRA: recepción, pruebas y plazos de notificación

Objetivo

Estado al 25 de octubre de 2026. Preparar el proceso de gestión de vulnerabilidades de un fabricante para que durante un incidente puedan consultarse las pruebas, la responsabilidad sobre los productos y los plazos de notificación. Volver a consultar el artículo 14, el anexo I y las instrucciones actuales de la SRP de ENISA al actualizar el proceso. Se trata de una propuesta de protocolo de preparación, no de una afirmación de que una organización haya superado una evaluación de cumplimiento.

Las notificaciones del artículo 14 son obligatorias desde el 11 de septiembre de 2026. El artículo 71 fija el 11 de diciembre de 2027 para los requisitos más amplios, incluidas las obligaciones de gestión de vulnerabilidades del anexo I. La preparación para esas obligaciones posteriores puede facilitar las notificaciones actuales, pero sus fechas deben mantenerse diferenciadas. Orientaciones de la Comisión sobre notificaciones.

Requisitos previos

Identificar los productos pertinentes del fabricante, los equipos de ingeniería responsables, un responsable de notificaciones y un sustituto. Disponer de un registro de incidentes con acceso restringido, acceso a la información de versiones y componentes, y un canal para las comunicaciones con los usuarios afectados. Se trata de medidas organizativas propuestas. Confirmar el CSIRT coordinador apropiado conforme al artículo 14(7), en lugar de elegir uno solo por la conveniencia de su idioma.

Pasos

1. Asignar la recepción a una persona responsable identificada. Preparar la política de divulgación coordinada de vulnerabilidades y el contacto para notificarlas descritos en el anexo I, parte II. Un archivo opcional security.txt conforme a RFC 9116 puede dirigir a los investigadores a ambos: utilizar HTTPS en /.well-known/security.txt, incluir los campos obligatorios Contact y Expires, y enlazar la política mediante Policy. Mantener actualizados el archivo y sus destinos. RFC 9116, secciones 2, 3 y 5.

2. Crear de inmediato un registro del caso. Como diseño práctico del registro, separar la hora de recepción, las pruebas recibidas, el momento en que se tuvo conocimiento de un evento sujeto a notificación, el responsable de la decisión y las revisiones posteriores. Conservar las pruebas originales y explicar los cambios de evaluación. Las aprobaciones internas no deberían restablecer silenciosamente la marca de tiempo de conocimiento.

3. Relacionar el problema con las versiones. Mantener una lista de materiales de software (SBOM) junto con los identificadores de productos y versiones. El anexo I, parte II(1), exige un formato de uso común legible por máquina que abarque al menos las dependencias de primer nivel cuando ese requisito sea aplicable. Este protocolo propone vincular esos registros con las versiones distribuidas para poder reconstruir la lista de productos afectados. Una SBOM es un inventario, no una prueba de explotación.

4. Evaluar por separado los supuestos legales de notificación. Según el artículo 3(42), la explotación activa requiere pruebas fiables de que un actor malicioso explotó la vulnerabilidad sin permiso del propietario del sistema. Contrastar los incidentes graves con ambos criterios del artículo 14(5). Registrar las pruebas y las cuestiones sin resolver; una puntuación de gravedad no puede demostrar por sí sola una explotación activa. Los pasos 1, 3 y 4 se basan en el reglamento.

5. Mantener el registro de plazos. Programar las etapas de 24 y 72 horas desde que se tiene conocimiento, manteniendo la exigencia de actuar sin demora. Contar el plazo del informe final de vulnerabilidad desde la disponibilidad de una medida correctora o de mitigación, y el del informe final de incidente desde la presentación de la notificación del incidente. Guardar juntos los acuses de recibo, las versiones presentadas y las solicitudes de las autoridades.

6. Preparar el acceso a la plataforma y las comunicaciones. ENISA exige cuentas personales de EU Login con autenticación multifactor. Sus preguntas frecuentes de octubre recomiendan iniciar el registro en la SRP cuando sea necesario presentar una notificación; preparar antes el acceso a EU Login. Mantener las comunicaciones con los usuarios afectados junto con las notificaciones a las autoridades. Preguntas frecuentes de la SRP de ENISA, pregunta 9.

7. Realizar un ensayo interno. Utilizar un caso de producto ficticio y redactar borradores de informes fuera de la plataforma de notificación real. Encargar al sustituto que localice las pruebas, reconstruya los plazos y explique la elección del destinatario. Registrar los datos que falten y repetir el relevo fallido después de corregir las carencias.

Resultado esperado

Una persona revisora puede seguir un caso desde la recepción, pasando por su asociación con los productos, la evaluación de los supuestos de notificación y la presentación, hasta las comunicaciones con los usuarios, sin reconstruir la cronología a partir de mensajes dispersos.

Límites y base de verificación

No se afirma que se haya realizado un ensayo ni obtenido resultados de aplicación real. La propuesta combina el reglamento, las orientaciones de la Comisión, las preguntas frecuentes de ENISA actualizadas el 15 de octubre de 2026 y RFC 9116. Ni un archivo de contacto publicado ni un ensayo satisfactorio demuestran el cumplimiento; el alcance de los productos y las evaluaciones controvertidas de los supuestos de notificación siguen necesitando una revisión cualificada.