
En este artículo (4)
Análisis de los informes del Artículo 14 de la Ley de Ciberresiliencia de la UE
Puntos Clave
- Trate la conciencia de explotación como un desencadenante de presentación, no solo como un ticket de ingeniería.
- Prepare plantillas que capturen el impacto en el producto, los detalles de la explotación, las mitigaciones aplicadas y las acciones de los usuarios.
- Mantenga la obligación de notificación actual del Artículo 14 separada de las obligaciones completas de la CRA que vencerán más adelante.
El CRA aún no se aplica por completo, pero el plazo para notificar incidentes y vulnerabilidades ya está en marcha para los productos cubiertos.
La CRA aún no es plenamente aplicable, pero su reloj de notificación de incidentes y vulnerabilidades ya está en marcha para los productos cubiertos.
Un ticket de vulnerabilidad solía ser un elemento en una cola. Desde el 11 de septiembre, para los productos con elementos digitales vendidos en la Unión Europea, también puede ser un reloj regulatorio. La Ley de Ciberresiliencia todavía está, en gran parte, esperando entre bastidores, y por eso exactamente importa el artículo 14: una parte de la ley llegó antes, y aterriza directamente dentro de la respuesta a incidentes. La pregunta práctica no es si un equipo de producto ha leído la CRA. Es si alguien puede decidir, dentro de 24 horas, si una vulnerabilidad explotada activamente o un incidente grave debe reportarse, quién lo presenta y qué evidencia lo acompaña. Los abogados llaman a esto una obligación de notificación. Quienes construyen productos deberían llamarlo un flujo de trabajo de producción con un regulador al final.
La parte de
la CRA que ya está en el calendario Pearl Cohen describe la CRA como implementada en tres fases: obligaciones para los organismos de evaluación de la conformidad desde el 11 de junio de 2026, la notificación de vulnerabilidades del artículo 14 desde el 11 de septiembre de 2026, y la CRA completa desde el 11 de diciembre de 2027. Cybersecurity Time añade la corrección útil de que la Ley entró en vigor el 10 de diciembre de 2024, mientras que sus obligaciones principales se aplican más adelante. Esa distinción no es académica; significa que hoy los equipos pueden estar fuera del alcance de los requisitos completos del producto y aun así estar dentro del alcance de la notificación.
Pearl Cohen dice que la CRA cubre tanto productos de hardware como de software con elementos digitales introducidos en el mercado de la UE. Esa es la frase que los proveedores de software deberían subrayar, preferiblemente antes de que ventas firme otro cliente de la UE un viernes por la tarde. Esto no es solo un problema de termostatos conectados; puede alcanzar a productos de software si son productos cubiertos con elementos digitales.
Qué exige realmente el artículo 14
Crowell dice que la obligación de notificación del artículo 14 de la CRA se aplica desde el 11 de septiembre de 2026 y puede hacerse cumplir desde esa fecha, mientras que el resto de la CRA se aplica generalmente desde el 11 de diciembre de 2027. La firma también dice que los fabricantes presentan una notificación a través de la plataforma única de notificación al Equipo de Respuesta a Incidentes de Seguridad Informática correspondiente designado como coordinador y a ENISA. Luego esa notificación se comparte con otros CSIRT pertinentes según corresponda, lo cual, afortunadamente, es diferente de los regímenes en los que el mapa de presentación se convierte en su propio incidente.
El texto legal del artículo 14 dice que un fabricante debe notificar cualquier vulnerabilidad explotada activamente en un producto con elementos digitales una vez que tenga conocimiento de ella, simultáneamente al CSIRT coordinador y a ENISA, usando la plataforma única de notificación. También exige una alerta temprana dentro de las 24 horas desde que se toma conocimiento, y una notificación adicional de vulnerabilidad dentro de las 72 horas, salvo que la información pertinente ya se haya proporcionado. El aviso de 72 horas debe incluir, según esté disponible, información general sobre el producto, la naturaleza del exploit y de la vulnerabilidad, las medidas correctivas o de mitigación adoptadas, y las medidas que los usuarios pueden tomar.
Traducido a operaciones, el artículo 14 significa que tu flujo de trabajo de incidentes necesita al menos cuatro campos que los tickets de seguridad suelen dispersar entre chats, retrospectivas y notas de versión. Necesitas el producto afectado, la descripción general del exploit y la vulnerabilidad, lo que la empresa ha hecho y lo que los usuarios pueden hacer. Si esa información no puede capturarse rápidamente, el problema de notificación ya es visible.
Quién debería preocuparse, incluidos los vendedores no pertenecientes a la UE
Faegre Drinker presenta los plazos de septiembre de 2026 como aplicables a los fabricantes de productos conectados y señala el alcance extraterritorial para empresas estadounidenses. El resumen de Pearl Cohen sobre las orientaciones de la Comisión confirma que la CRA se aplica a productos de hardware y software introducidos en el mercado de la UE. En lenguaje claro: estar constituido fuera de la UE no es una capa mágica de invisibilidad si el producto está disponible allí.
Aquí es donde los contratos con proveedores y la titularidad interna importan. Si un fabricante depende de un proveedor de servicios gestionados, un revendedor, un investigador de vulnerabilidades, un alojamiento en la nube o un proveedor de componentes para enterarse de una explotación, la empresa aún necesita un camino desde esa señal hasta quien toma la decisión del artículo 14. La evidencia proporcionada aquí no dice que todos los proveedores deban presentar una notificación, así que no dejes que el folclore de cumplimiento vaya más allá del texto. La medida operativa más segura es asegurarse de que los contratos exijan avisos de seguridad rápidos, detalles técnicos utilizables y cooperación en las comunicaciones de mitigación.
Crowell también señala a los representantes autorizados y los procesos de escalamiento capaces de funcionar contra el reloj de 24 horas. Esa es una forma educada de decir que la ruta de notificación no puede vivir en la bandeja de entrada de una sola persona. Producto, seguridad, legal, soporte y comunicaciones con clientes necesitan una entrega ensayada, porque el reloj empieza cuando el fabricante toma conocimiento, no cuando está listo el borrador perfecto de la retrospectiva.
Qué operacionalizar esta semana
Crowell recomienda ejercicios de simulación, capacitación del personal y actualizaciones de políticas cibernéticas en respuesta al reloj del artículo 14. Esos no son objetos ceremoniales de cumplimiento si ponen a prueba los modos de fallo correctos: quién identifica la explotación activa, quién decide la gravedad, quién abre el proceso de la plataforma única de notificación y quién aprueba el lenguaje de mitigación para usuarios. Una simulación que termina con todos de acuerdo en investigar más no es preparación; es una reunión con aperitivos.
La división útil es entre lo que la ley exige ahora y lo que internet afirmará que exige. Ahora: notificación de vulnerabilidades explotadas activamente e incidentes graves conforme al artículo 14, con una alerta temprana de 24 horas y una ruta de seguimiento de 72 horas, según Crowell y el texto del artículo 14. Más adelante: el conjunto completo de requisitos esenciales de ciberseguridad de la CRA, que Pearl Cohen dice que se aplica desde el 11 de diciembre de 2027.
Para quienes construyen productos, el trabajo inmediato es pequeño pero implacable. Mapea los productos vendidos o introducidos en el mercado de la UE, define los desencadenantes de conocimiento, prepara plantillas de notificación, asigna un representante autorizado cuando sea necesario y ensaya la ruta hacia la plataforma única de notificación. Luego sigue observando la brecha entre la aplicación del artículo 14 y la fecha de la CRA completa, porque los reguladores suelen aprender de las primeras presentaciones mucho antes de que aparezca la primera multa.