Dentro de nueve días, el 11 de septiembre, se enciende la mitad de notificación del Reglamento de Ciberresiliencia europeo. No el reglamento entero — eso es el 11 de diciembre de 2027, y esa es la fecha que todo el mundo tiene apuntada. Esta es la otra. La que nadie se puso en el calendario.

Y la separación es justo lo que se le escapa a todo el mundo. Evaluación de la conformidad, seguridad desde el diseño, los requisitos esenciales de ciberseguridad, ponerle el marcado CE a tu firmware: todo eso es 2027. El artículo 14, que dice que cuando una vulnerabilidad de tu producto se está explotando activamente tienes 24 horas para decirlo en voz alta: eso es el viernes que viene.

Qué dice el reloj exactamente

Lo arranca el momento en que te enteras. Alerta temprana en 24 horas. Notificación más completa en 72. Informe final como muy tarde 14 días después de que exista una medida correctora disponible. Los incidentes graves tienen un mes para el informe final, con la misma apertura de 24/72.

Lo que hay que mandar a las 24 horas es deliberadamente poca cosa — tipo y nivel de notificación, quién eres, qué producto, un título y, en el caso de incidentes, si sospechas que alguien lo ha hecho aposta. Ya está. Y me parece bastante sensato, y prefiero decirlo a hacerme el interesante: la alternativa es un reglamento que te obliga a escribir un postmortem con el edificio todavía ardiendo. Es una bengala, no un análisis.

Lo que sí pilla a la gente con el pie cambiado es el alcance. Esto no va de productos que saques después de que el CRA se aplique del todo. El artículo 14 cubre todo lo que tenga elementos digitales y esté en el mercado europeo el 11 de septiembre, incluido lo que pusieras ahí hace años. Un producto que ya pasó su ventana de soporte sigue dentro mientras siga por ahí fuera, en uso. Así que si tenías esto archivado mentalmente en el cajón de «ya lo miraremos cuando toque el empujón de cumplimiento de 2027», lo que estás posponiendo ya ha empezado.

Y el portal abre ese mismo día

Aquí viene la parte que he disfrutado más de lo que debería.

Las notificaciones van por la Single Reporting Platform, una ventanilla central que opera ENISA. Un informe, un sitio, y de ahí se reparte a quien tenga que llegar. Es un buen diseño, ojo — la alternativa era presentar por separado ante 27 autoridades nacionales, que habría sido un infierno con personalidad propia.

Entra en servicio el 11 de septiembre. El mismo día que la obligación. Sin periodo de rodaje, sin pruebas contra un endpoint de staging, sin abrirlo en julio para que la gente se encuentre las aristas cuando todavía no hay nada en juego.

Y según las propias FAQ de ENISA, no hay API en el lanzamiento. Las notificaciones obligatorias van por el portal web. A mano.

Quédate un segundo con eso. Tienes un plazo de 24 horas que puede empezar a las tres de la mañana de un domingo, y el mecanismo de envío es un ser humano, despierto, con un navegador, tecleando.

Y bueno, quiero estar más enfadado de lo que realmente estoy, porque sé perfectamente cómo se llega ahí y no es maldad, son recortes de alcance. Sacamos el portal, la API en la v2. Esa decisión la ha tomado todo equipo del planeta. Lo que pasa es que es un sitio especialmente gracioso donde aterrizar, porque un reloj de 24 horas es exactamente el tipo de requisito que querrías sacar de las manos de una persona, y el reglamento que escribe el reloj y la herramienta que lo atiende parecen no estar de acuerdo en eso.

Y lee el texto, además: nada en el artículo 14 condiciona el plazo a que la herramienta sea cómoda. La obligación no está esperando a la API.

Si mantienes código abierto, tranquilo casi del todo

El primer borrador del CRA era feo de verdad para el código abierto, y las voces que se levantaron después funcionaron — no es una frase que pueda escribir muy a menudo.

Dónde acabó la cosa: no estar monetizado no es actividad comercial. Un proyecto en GitHub sin soporte de pago, sin licencia dual comercial, sin hoja de ruta patrocinada está fuera del alcance, y quien contribuye a él a título individual no tiene ninguna obligación bajo el CRA. Y eso es una exclusión puesta a propósito, no un resquicio que haya encontrado alguien.

Por encima hay una categoría inventada específicamente para este lío: el open source steward. A grandes rasgos, una persona jurídica — una fundación, ese tipo de cosa — que sostiene de forma continuada el desarrollo de software libre que acaba usándose comercialmente. A los stewards les toca el artículo 24, que es un trato mucho más ligero que el del fabricante: documentar una política de ciberseguridad, cooperar con las autoridades de vigilancia del mercado cuando lo pidan, y notificar vulnerabilidades explotadas activamente e incidentes graves que afecten a su infraestructura de desarrollo. Sin evaluación de la conformidad. Nadie le va a poner el marcado CE a un tarball.

Y es más o menos lo mejor que permite la forma del problema. El regulador quería una parte con nombre y apellidos para el software de uso masivo, y en lugar de fingir que cada mantenedor es un fabricante, montaron un escalón para las entidades que sí pueden sostener una política.

Donde se pone turbio es en medio — tú, con un proyecto paralelo, una página de sponsors y un cliente que te paga soporte. El informe de preparación de la Linux Foundation y la OpenSSF tiene el número: el 61% de los desarrolladores no comerciales no tiene claro cuál es su propia situación. Eso no es ignorancia. Es una definición que necesita un abogado para aplicarse, apuntando a una población que no tiene abogado. Las FAQ de stewards del grupo de trabajo ORC son el sitio menos doloroso que he encontrado para averiguar en qué casilla estás.

Nadie está listo, y no le falta poco

Mismo informe, y los números gordos son regulares. El 66% de quienes respondieron no conocía el CRA «en absoluto» o solo «ligeramente» — un 72% en Estados Unidos y Canadá. De los que sí lo conocen, el 41% todavía no ha averiguado si les aplica. Eso sobre 843 respuestas, un 23% más que el año pasado, además de un análisis de seguridad sobre más de 12.000 proyectos de código abierto.

El dato de Norteamérica es el que yo miraría fijamente. El CRA va del mercado europeo, no de dónde estés constituido. Si tu cosa se puede descargar desde Europa como parte de una oferta comercial, la geografía no es la salida de emergencia que la gente se está imaginando.

Qué haría yo esta semana

Poco. Pero no nada.

Averigua si eres fabricante, steward o estás fuera del alcance. Diez minutos con las definiciones, y la mayoría acaba en «fuera de alcance» y puede dejar de leer.

Si estás dentro, alguien tiene que ser el dueño del reloj — y el modo de fallo no es negarse a notificar, es no darte cuenta hasta el martes de que eso que estás mirando cuenta como explotado activamente. Así que mete la pregunta en tu plantilla de incidentes. Una línea: ¿esto parece explotado en el mundo real y, si es que sí, cuándo nos enteramos nosotros? Esa segunda marca de tiempo es toda la partida, porque el reloj arranca cuando te enteras, y quieres tu propio registro de cuándo pasó eso en lugar de reconstruirlo tres semanas después rebuscando en el historial de Slack.

Y luego abre el portal el día 11, antes de necesitarlo, mientras no te está gritando nadie.

Así que

No tengo ninguna queja real del reglamento. La forma 24/72/14 es más o menos lo que hace de todos modos una respuesta a incidentes decente, y las exclusiones para el código abierto han salido más cuidadas de lo que aquel primer borrador daba a entender.

Lo que no consigo soltar es la distancia entre un calendario de cumplimiento y uno de ingeniería. Sobre el papel es una fecha. En la práctica, el día 11, a alguien le va a tocar descubrir — en producción, a la hora que elija su vulnerabilidad — que el último tramo de un régimen de notificación continental es un formulario.

En fin. Nueve días. Ve a averiguar si el problema es tuyo.