El 11 de septiembre de 2026 empieza a aplicarse una de las primeras obligaciones operativas del Reglamento Europeo de Ciberresiliencia: los fabricantes de productos con elementos digitales deberán reportar vulnerabilidades explotadas activamente e incidentes graves mediante la plataforma única de ENISA. La actualización de preguntas frecuentes publicada por la agencia europea el 31 de agosto confirma cómo funcionará el canal, quién debe utilizarlo y qué CSIRT recibirá inicialmente la notificación.
Para fabricantes de software, hardware, dispositivos conectados y componentes que comercializan en España o en cualquier país de la Unión Europea, la novedad cambia la gestión de vulnerabilidades desde ahora. Las obligaciones generales del Cyber Resilience Act, conocido como CRA, se aplicarán principalmente desde diciembre de 2027, pero el calendario de reporte no espera hasta entonces. Una empresa puede tener que emitir una alerta inicial en 24 horas, completar información en 72 horas y entregar posteriormente un informe final.
No basta con abrir una cuenta en la plataforma. Cumplir exige saber qué productos están en alcance, reconocer una explotación activa, decidir cuándo un incidente es grave, conservar evidencia, coordinar ingeniería, seguridad, legal y dirección, y comunicar medidas útiles a los usuarios. El verdadero reto es construir un proceso que produzca información fiable dentro del reloj regulatorio sin divulgar detalles sensibles ni improvisar responsabilidades.
Qué cambió y por qué importa ahora
La FAQ de ENISA, actualizada el 31 de agosto, describe la Single Reporting Platform o SRP como la herramienta en línea para que fabricantes y responsables de proyectos de software de código abierto sujetos al CRA comuniquen vulnerabilidades explotadas e incidentes graves. El objetivo es presentar una sola notificación, en vez de reportar individualmente ante múltiples autoridades nacionales.
La plataforma quedará operativa el 11 de septiembre. El fabricante seleccionará el CSIRT coordinador correspondiente y el reporte será accesible simultáneamente para ENISA. Como regla general, el punto de entrada depende del Estado miembro donde se toman principalmente las decisiones de ciberseguridad del producto. Para una empresa establecida en España, esa definición obliga a documentar dónde está realmente su función de producto y no limitarse a mirar el domicilio comercial.
Si el fabricante no tiene establecimiento principal en la Unión, el Reglamento establece un orden para determinar el CSIRT: representante autorizado, importador, distribuidor o, en última instancia, el Estado miembro con mayor número de usuarios. Por eso una compañía de México o Colombia que vende software, equipos, aplicaciones o servicios de procesamiento remoto asociados a un producto en Europa puede necesitar analizar el CRA aunque no tenga sede europea.
Qué productos y organizaciones deben revisar el alcance
El CRA cubre, con excepciones y regímenes específicos, productos con elementos digitales puestos en el mercado de la Unión: software, hardware y sus soluciones de procesamiento remoto cuando forman parte de la función del producto. El fabricante es el obligado central, pero importadores y distribuidores también tienen deberes. Además, quien comercializa bajo su propia marca o realiza una modificación sustancial puede asumir responsabilidades de fabricante.
La primera tarea no es interpretar cada línea del reglamento en abstracto, sino crear un inventario defendible. Debe relacionar producto, versiones soportadas, componentes propios y de terceros, países de comercialización, responsables de seguridad, canal de vulnerabilidades, usuarios afectados y evidencia disponible. Las bibliotecas de código abierto merecen atención: integrar un componente no elimina el deber de diligencia ni la necesidad de gestionar sus vulnerabilidades.
| Dimensión | Pregunta empresarial | Evidencia esperada |
|---|---|---|
| Producto | ¿Qué software, hardware o servicio remoto se comercializa en la UE? | Catálogo, versiones, mercados y propietario |
| Componentes | ¿Qué dependencias pueden introducir vulnerabilidades? | SBOM, repositorios y política de actualización |
| Detección | ¿Cómo se confirma que una vulnerabilidad está siendo explotada? | Telemetría, inteligencia, tickets y criterio de decisión |
| Incidente | ¿Quién determina si el impacto es grave? | Matriz de severidad, responsables y registro de decisión |
| Reporte | ¿Quién puede enviar y actualizar la notificación? | Cuenta SRP, suplencias y procedimiento probado |
El reloj de 24 horas, 72 horas y el informe final
El artículo 14 distingue dos eventos. El primero es una vulnerabilidad contenida en el producto que el fabricante sabe que está siendo explotada activamente. El segundo es un incidente grave con impacto en la seguridad del producto. Ambos requieren una alerta temprana sin demora indebida y, como límite, dentro de las 24 horas siguientes a que el fabricante tenga conocimiento.
Para una vulnerabilidad explotada, la notificación ampliada debe presentarse dentro de 72 horas, salvo que la información ya haya sido entregada. Incluye datos generales del producto, naturaleza del exploit y la vulnerabilidad, medidas correctivas o de mitigación y acciones que pueden adoptar los usuarios. El informe final se entrega como máximo 14 días después de que exista una corrección o mitigación disponible.
Para un incidente grave, también existe la alerta en 24 horas y una notificación en 72 horas con naturaleza, evaluación inicial y medidas. El informe final llega dentro del mes siguiente a la notificación de 72 horas e incluye descripción detallada, severidad, impacto, causa probable y mitigaciones aplicadas o en curso.
Estos plazos empiezan cuando el fabricante toma conocimiento, un concepto que debe traducirse en reglas internas. Si un hallazgo entra por soporte, un investigador externo, un proveedor cloud o un equipo de desarrollo, la organización necesita un punto claro de escalamiento. De lo contrario, la información puede quedar días en un buzón mientras el plazo ya corre.
Cómo separar una señal de un evento reportable
Un error de software no equivale necesariamente a una vulnerabilidad explotada activamente y una interrupción tampoco es siempre un incidente grave bajo el CRA. El reglamento considera grave el incidente que afecta o puede afectar negativamente la capacidad del producto para proteger la disponibilidad, autenticidad, integridad o confidencialidad de datos o funciones sensibles o importantes; también el que introduce o puede introducir código malicioso en el producto o en los sistemas del usuario.
La organización necesita criterios repetibles para confirmar explotación, vincularla a una versión y valorar impacto. Debe separar hechos, hipótesis e información pendiente. Una decisión rápida no tiene que ser una decisión intuitiva: puede apoyarse en un árbol de clasificación, fuentes de telemetría, revisión técnica y autoridad designada. Cada cambio de conclusión debe quedar registrado.
Un Security GAP Assessment enfocado en CRA permite contrastar inventario, gestión de vulnerabilidades, respuesta, proveedores, comunicación y evidencia con el proceso que exigirá el reporte. El resultado útil es una lista priorizada de brechas con responsables y fechas, no una matriz genérica de cumplimiento.
Cómo preparar una operación de reporte sin improvisar
- Defina el alcance. Liste productos, versiones, componentes, mercados de la UE y la entidad que toma decisiones de ciberseguridad.
- Nombre responsables y suplentes. Asigne quién recibe, valida, clasifica, aprueba, reporta y comunica a usuarios.
- Formalice el momento de conocimiento. Establezca qué evento inicia el reloj y cómo se registra con fecha, hora y fuente.
- Prepare plantillas. Separe alerta temprana, notificación ampliada, informe final y comunicación a clientes.
- Conecte las fuentes. Integre soporte, repositorios, monitoreo, proveedores, investigadores y canal de divulgación coordinada.
- Preserve evidencia. Conserve versiones afectadas, logs, indicadores, decisiones, pruebas y medidas aplicadas.
- Ejercite el proceso. Simule una explotación un viernes fuera de horario y mida si el equipo llega a las 24 y 72 horas.
El servicio de CISO as a Service puede articular producto, riesgo, legal y dirección, mantener el registro de decisiones y elevar bloqueos que ningún equipo técnico resuelve por sí solo. Para empresas con varios productos o filiales, esa gobernanza evita respuestas contradictorias y autoridades sin dueño.
Del cumplimiento puntual a la seguridad del producto
Reportar no reemplaza corregir. El CRA conecta el aviso con la gestión del ciclo de vida: evaluación de riesgos, desarrollo seguro, componentes, actualizaciones, periodo de soporte e información al usuario. Una empresa puede enviar el formulario a tiempo y aun así conservar una exposición grave si no corrige el defecto, no identifica versiones vulnerables o no llega a sus clientes.
El diseño e implementación de un SGSI ayuda a integrar roles, activos, riesgos, proveedores, incidentes y mejora continua. No convierte automáticamente a un producto en conforme al CRA, pero crea una base de gobierno y evidencia. El alcance del SGSI debe enlazarse con los productos reales y no quedarse en procesos corporativos que excluyen desarrollo y soporte.
Las pruebas técnicas también deben generar evidencia accionable. Un Ethical Hacking sobre el producto, sus API, actualizaciones y servicios remotos puede descubrir rutas que un escaneo automático no cubre. Antes de probar, conviene definir versiones, autorización, datos, límites, criterio de severidad y flujo de escalamiento por si aparece una vulnerabilidad que active el proceso CRA.
Qué cambia para proveedores y empresas latinoamericanas
Una empresa española que integra módulos de terceros debe conocer a quién notificar, cómo recibe parches y qué versiones están desplegadas. Los acuerdos con proveedores necesitan tiempos compatibles con 24 y 72 horas, acceso a evidencia y obligación de cooperación. Un contrato que promete “notificar pronto” puede ser insuficiente si no define el evento, canal, destinatario y datos mínimos.
Para fabricantes de México y Colombia, vender mediante un distribuidor europeo no elimina el análisis. El reglamento prevé responsabilidades para operadores de la cadena y contempla fabricantes sin establecimiento principal en la Unión. La decisión debe basarse en el producto, el modelo de comercialización y la presencia real en el mercado europeo. Este artículo no sustituye asesoría jurídica sobre el caso concreto.
También conviene evitar dos extremos: asumir que cualquier SaaS está automáticamente incluido o concluir que ningún servicio cloud lo está. El texto considera determinadas soluciones de procesamiento remoto cuando son necesarias para la función del producto. Producto, servicio y dependencia técnica deben documentarse antes de fijar el alcance.
Preguntas frecuentes sobre el reporte CRA
¿Cuándo empiezan las obligaciones de reporte?
El 11 de septiembre de 2026. Las principales obligaciones generales del CRA se aplicarán desde el 11 de diciembre de 2027, pero el reporte del artículo 14 entra antes.
¿Qué se reporta en 24 horas?
Una alerta temprana sobre una vulnerabilidad explotada activamente o un incidente grave que afecte la seguridad del producto, sin demora indebida y dentro de un máximo de 24 horas desde que el fabricante toma conocimiento.
¿La alerta de 24 horas debe tener toda la investigación cerrada?
No. El modelo es progresivo: alerta inicial, información ampliada en 72 horas y un informe final posterior. La empresa debe distinguir lo confirmado de lo pendiente y actualizar el reporte.
¿Una empresa de Colombia o México puede quedar alcanzada?
Sí, dependiendo del producto y de cómo se comercialice en la Unión Europea. La ausencia de sede europea no es por sí sola una exclusión; el artículo 14 define cómo seleccionar el CSIRT en esos casos.
¿ISO 27001 demuestra cumplimiento del CRA?
No de forma automática. Un SGSI certificado puede aportar procesos y evidencia, pero el CRA contiene obligaciones específicas de producto, ciclo de vida, vulnerabilidades, soporte, documentación y reporte que deben evaluarse dentro del alcance real.
Prepare el reporte antes de que empiece el reloj
Insylux ayuda a fabricantes y empresas tecnológicas a convertir el CRA en inventario, responsabilidades, evidencia, pruebas y un flujo de notificación practicable. El objetivo es que la primera explotación real encuentre un proceso ensayado y no una cadena de correos sin autoridad.
Solicite una evaluación de preparación CRA y pruebe su capacidad de reportar en 24 y 72 horas.
Fuentes oficiales
- ENISA, preguntas frecuentes de la plataforma única CRA, actualizadas el 31 de agosto de 2026.
- Comisión Europea, obligaciones de reporte y puesta en operación de la plataforma, consultada el 3 de septiembre de 2026.
- ENISA, Single Reporting Platform, con entrada en uso obligatorio el 11 de septiembre de 2026.
- EUR-Lex, Reglamento (UE) 2024/2847, texto jurídico del Cyber Resilience Act.
Fuentes consultadas el 3 de septiembre de 2026. Los ejemplos operativos y recomendaciones son elaboración defensiva del Equipo Insylux. La determinación de alcance y obligaciones requiere revisar producto, estructura empresarial y distribución con asesoría especializada.
