El 11 de septiembre de 2026 entraron en vigor las primeras obligaciones sustantivas del Reglamento de Ciberresiliencia (CRA). No las de diseño, no las de marcado CE: las de notificación. Desde ese día, si un atacante explota una vulnerabilidad de tu producto, tienes 24 horas para dar la primera alerta.
La mayoría de las empresas de software españolas no lo tiene montado. No porque lo ignoren, sino porque el CRA se ha contado como una norma de dispositivos conectados, y su alcance es bastante más amplio.
A quién considera «fabricante»
El reglamento se aplica a los productos con elementos digitales puestos en el mercado europeo. Eso incluye programas informáticos, firmware, aplicaciones y sistemas que se integran en otros productos. Si desarrollas software y lo comercializas, lo licencias o lo entregas como parte de un proyecto con contraprestación, estás en el ámbito.
Matices que conviene tener claros:
- No importa el tamaño. Una pyme de cinco personas con un producto propio es fabricante igual que una multinacional.
- También alcanza a importadores y distribuidores, con obligaciones propias de verificación.
- El software interno no es un producto. Una aplicación que solo usas tú, sin ponerla en el mercado, queda fuera. Otra cosa es que tus clientes te exijan lo mismo por contrato.
- El código abierto no comercial tiene un régimen específico, y los administradores de proyectos abiertos asumen obligaciones de notificación desde diciembre de 2027.
Los tres relojes del artículo 14
- 24 horas para la alerta temprana al CSIRT designado como coordinador y a ENISA, a través de la plataforma única de notificación. Basta con indicar que existe una vulnerabilidad explotada o un incidente grave y el producto afectado.
- 72 horas para la notificación completa: gravedad, impacto, indicadores de compromiso y medidas adoptadas o previstas.
- 14 días desde que haya una medida correctiva disponible para el informe final en vulnerabilidades; un mes desde la notificación en incidentes graves.
Y un detalle que se pasa por alto: la obligación no distingue cuándo se puso el producto en el mercado. Alcanza también a versiones ya vendidas que sigan dentro de su periodo de soporte. Es decir, a tu base instalada.
Lo que casi nadie tiene montado
Notificar en 24 horas no se improvisa. Exige tener previamente:
- Un canal de recepción de vulnerabilidades: buzón dedicado, clave PGP pública y un security.txt en el dominio. Si nadie puede avisarte, te enteras por Twitter.
- Un SBOM, el inventario de componentes y versiones. Sin él, cuando aparece un CVE en una librería, no sabes en 24 horas si te afecta.
- Un triaje con reloj: quién decide si es explotable, quién redacta, quién firma y quién envía.
- Periodo de soporte declarado y política de actualizaciones. El reglamento pide determinarlo y comunicarlo; la referencia habitual son cinco años salvo vida útil menor.
- Plantillas de notificación prerrellenadas con los datos del producto, para no perder el plazo en burocracia.
Cómo se traduce en arquitectura y contratos
El CRA no es solo un trámite de incidentes. La aplicación general llega el 11 de diciembre de 2027 y trae requisitos de diseño: seguridad por defecto, gestión de vulnerabilidades durante todo el ciclo de vida, actualizaciones seguras y documentación técnica.
En la práctica, eso cambia cuatro cosas en un proyecto:
- Dependencias bajo control. Si tu producto arrastra una librería con un fallo explotado, el reloj corre para ti, no para el mantenedor de la librería.
- Actualizaciones verificables. Firma de releases, canal de distribución y posibilidad de que el cliente sepa qué versión tiene.
- Cláusulas claras. Quién notifica a quién cuando el fallo está en un componente de un tercero, y en qué plazo.
- Fin del «vendido y olvidado». Un producto sin mantenimiento posterior es un pasivo regulatorio, no un ahorro.
Es la misma lógica que aplicamos en software a medida: si el código es tuyo y el mantenimiento está definido, el cumplimiento se puede planificar. Si dependes de un proveedor opaco, no.
Un plan de 30 días
- Inventario real: productos, versiones, componentes y clientes afectados.
- Designar responsable y suplente, con teléfono y correo que se lean fuera del horario.
- Publicar el canal de recepción de vulnerabilidades y el security.txt.
- Generar el SBOM automáticamente en el proceso de build.
- Escribir el runbook de 24/72 horas con plantillas y criterios de gravedad.
- Hacer un simulacro con un CVE ficticio y cronometrarlo de verdad.
- Revisar contratos, periodos de soporte y qué se promete por escrito.
El simulacro es el paso que separa tener un plan de tener una carpeta. Si el primer aviso real llega un viernes a las 19:00, el reloj no espera al lunes.