El CRA es un problema de 2026, no de 2027

Pregunta a un equipo de producto cuándo les afecta el Reglamento de Resiliencia Cibernética (CRA) y la mayoría dirá diciembre de 2027. Esa es la fecha en la que se aplican los requisitos esenciales, la evaluación de conformidad y el marcado CE, y es la fecha que ancla cada presentación de hoja de ruta. También es la fecha equivocada desde la que planificar.

El CRA entró en vigor el 10 de diciembre de 2024, y el Artículo 71 establece un calendario escalonado, no una única fecha límite. Las disposiciones sobre notificación de organismos de evaluación de la conformidad (Capítulo IV, Artículos 35 a 51) se aplican desde el 11 de junio de 2026. Las obligaciones de notificación del Artículo 14 se aplican desde el 11 de septiembre de 2026. Solo el cuerpo principal del reglamento, los requisitos esenciales del Anexo I y la ruta de conformidad para obtener el marcado CE, esperan hasta el 11 de diciembre de 2027 (Reglamento (UE) 2024/2847, Artículo 71; Comisión Europea, "El Reglamento de Resiliencia Cibernética: Resumen del texto legislativo").

Por lo tanto, la primera obligación concreta para un fabricante ya en el ámbito de aplicación del CRA llega quince meses antes de la fecha en la que todos están planeando.

Esto no es un llamado a empezar pronto. Es una afirmación sobre el orden. El equipo que secuenciación su trabajo del CRA hacia atrás desde la marca CE de 2027 ha colocado la obligación de notificación en último lugar, cuando el calendario y las dependencias operativas la sitúan en primer lugar.

¿Qué entra en vigor realmente en 2026?

El Artículo 14 no es una obligación burocrática que se añada al final. A partir del 11 de septiembre de 2026, un fabricante de un producto con elementos digitales debe notificar cualquier vulnerabilidad activamente explotada en ese producto, así como cualquier incidente grave que afecte a su seguridad, al CSIRT designado como coordinador del Estado miembro correspondiente y a ENISA, a través de una plataforma única de notificación. El plazo es inflexible: una advertencia temprana en un plazo de 24 horas desde que se toma conciencia del hecho, una notificación más completa en un plazo de 72 horas y un informe final en un plazo de 14 días desde que se disponga de una medida correctiva para una vulnerabilidad, o en un plazo de un mes para un incidente grave (Reglamento (UE) 2024/2847, Artículo 14).

Lee con atención el desencadenante. Una "vulnerabilidad activamente explotada" es aquella para la que existe una evidencia fiable de que se ha ejecutado código malicioso por parte de un actor en un sistema sin el permiso del propietario del sistema (Reglamento (UE) 2024/2847, Artículo 3). Esto no es un escenario hipotético que puedas gestionar con calma. Es un evento real y fechado que inicia un plazo de 24 horas en el momento en que te enteras, y esta obligación entra en vigor más de un año antes de los requisitos esenciales que te habrían permitido detectarlo.

La obligación de conocimiento llega antes que la obligación de gestión

Aquí está la inversión que pasa por alto la planificación anclada en 2027. Una obligación de notificar en un plazo de 24 horas desde que se toma conciencia es, en la práctica, una obligación de poder tomar conciencia. No puedes presentar una advertencia temprana sobre una vulnerabilidad activamente explotada en tu producto si:

• No tienes un canal a través del cual la explotación llegue a ti.
• No tienes un inventario que te indique qué versiones enviadas contienen el componente afectado.
• No tienes una regla de triaje que decida si un incidente es "grave" antes de que cierre la ventana de 72 horas.

Cada una de estas capacidades está descrita en el Anexo I, Parte II del mismo reglamento: mantener un inventario de materiales de software que cubra al menos las dependencias de nivel superior en un formato legible por máquina, operar una política de divulgación coordinada de vulnerabilidades con un punto de contacto para informes, y remediar vulnerabilidades sin demora mediante actualizaciones de seguridad (Reglamento (UE) 2024/2847, Anexo I, Parte II). Estos requisitos son legalmente exigibles a partir del 11 de diciembre de 2027. Sin embargo, la obligación de notificación que te vincula legalmente desde el 11 de septiembre de 2026 es difícil de cumplir de manera fiable sin ellas. La ley te permite posponer el proceso de gestión hasta 2027; no te permite posponer las consecuencias una vez que se produce la toma de conciencia.

Por lo tanto, el efecto práctico del Artículo 14, para cualquier fabricante que realmente esté en el ámbito de aplicación, es anticipar la necesidad de partes del modelo operativo del Anexo I, Parte II en quince meses. No porque los requisitos esenciales se apliquen antes, sino porque la obligación de notificación es difícil de cumplir de manera fiable sin la columna vertebral operativa que describen esos requisitos.

La objeción, y por qué no se sostiene

Un profesional cuidadoso planteará esta objeción, y merece ser tomada en serio. El Artículo 14 es estrecho. Solo se activa ante vulnerabilidades activamente explotadas e incidentes graves, no ante el backlog rutinario de hallazgos de baja gravedad. Un producto bien gestionado puede pasar mucho tiempo sin un evento notificable. Entonces, ¿por qué no ejecutar un proceso de notificación mínimo desde septiembre de 2026, mantener el desarrollo real de gestión de vulnerabilidades en la senda de 2027 y aceptar el pequeño riesgo de un desencadenante temprano?

Tres razones por las que la versión mínima es una trampa:

1. El marco de eventos raros invierte el riesgo. La obligación no es onerosa porque se active con frecuencia. Es peligrosa porque se activa de manera impredecible y inicia un plazo de 24 horas que no puedes pausar para construir capacidades. La única semana en la que tienes una vulnerabilidad activamente explotada es precisamente la semana en la que no puedes permitirte estar compilando un SBOM para determinar qué clientes están afectados.

2. La forma de la responsabilidad es diferente a una brecha de conformidad, y peor. Una postura incompleta del Anexo I se detecta en una evaluación, en una sala, con una oportunidad de remediarla. Una notificación de 24 horas perdida es un fracaso concreto, fechado y demostrable externamente. Crea un registro que puede ser relevante más adelante en discusiones supervisoras o de aplicación de la ley, y la trazabilidad de notificaciones que construyas desde septiembre de 2026 forma parte de ese registro. Un proceso mínimo no es una versión reducida del cumplimiento; es un rastro documentado de los momentos en los que no estabas preparado.

3. Un proceso de notificación sin un proceso de gestión detrás es teatro. Poder enviar un formulario a ENISA en 24 horas no sirve de nada si no puedes responder a las preguntas reales del formulario: qué versiones están afectadas, cuál es la medida correctiva y cuándo se envía. La obligación de notificación y los requisitos de gestión son un mismo sistema observado en dos momentos distintos. No puedes comprar la mitad observable y saltarte la máquina.

Secuencia hacia atrás desde septiembre de 2026

La corrección práctica no es "haz todo ahora". Es identificar el subconjunto mínimo de los requisitos esenciales de 2027 que el Artículo 14 convierte en críticos en 2026, y programar ese subconjunto en función de la fecha de septiembre en lugar de la de diciembre de 2027.

Ese mínimo de preparación para notificaciones es más pequeño que todo el programa del Anexo I y lo suficientemente específico como para planificarlo:

• Un inventario actualizado de materiales de software para cada producto enviado, al menos hasta las dependencias de nivel superior, para que el día de una vulnerabilidad explotada puedas determinar el impacto en horas, no en semanas.
• Un canal de recepción monitorizado y una política de divulgación coordinada de vulnerabilidades, para que la explotación y los informes de terceros realmente lleguen a ti e inicien el plazo del que eres responsable.
• Una regla escrita de triaje de gravedad e incidentes que pueda clasificar un evento como notificable dentro de la ventana de 72 horas, sin necesidad de convocar un comité.
• Un propietario designado y una ruta de envío ensayada al CSIRT coordinador y a ENISA, probada en la plataforma de notificación antes de necesitarla en una situación real.

Nada de esto requiere las normas armonizadas o la ruta de conformidad que aún se están finalizando para 2027. Todo ello se puede construir ahora, y todo ello es un pago inicial de las obligaciones de 2027, no trabajo desechable. Los fabricantes de productos importantes incluidos en el Anexo III, Clase II tienen una segunda razón para no esperar: su ruta de conformidad generalmente requiere un organismo notificado, y estos organismos solo pueden ser designados una vez que la maquinaria del Capítulo IV se aplique desde el 11 de junio de 2026. La capacidad de evaluación es finita, y las colas se forman en las fechas límite, no antes.

La regla que vale la pena conservar

Cuando un reglamento se aplica en etapas, la fecha destacada suele ser la última, y la fecha final es lo menos útil para la planificación. Lee el calendario escalonado en su lugar y pregunta qué obligación depende de las demás. En el caso del CRA, la obligación de notificación del Artículo 14 llega primero en el calendario y primero en el grafo de dependencias: no puedes notificar lo que no puedes detectar, y no puedes detectar sin la columna vertebral de gestión que describen los requisitos de 2027. Planifica el trabajo hacia atrás desde el 11 de septiembre de 2026, no hacia adelante hasta el 11 de diciembre de 2027, y el orden se resolverá por sí solo.

Si tu tarea inmediata es determinar qué productos te afectan según el CRA y qué exige exactamente la obligación de notificación de septiembre de 2026 para cada uno, ese trabajo de alcance y cruce de referencias es el tipo de labor para el que ISMS Copilot está diseñado para acelerar. Para muchos equipos, el trabajo de marcado CE es una puerta de 2027; la preparación del Artículo 14 es una puerta de 2026. Planifica primero la más temprana.

Este es un análisis práctico de cumplimiento, no asesoramiento legal. Confirma el ámbito de aplicación de tu producto y tus obligaciones según el reglamento en sí y, donde sea relevante, con tu autoridad competente o asesor legal.