Reglamento de Ciberresiliencia (CRA): a quién afecta de la cadena de software

El Reglamento de Ciberresiliencia europeo —el CRA, por sus siglas en inglés— es la norma que obliga a que los productos con elementos digitales que se vendan en la Unión Europea sean seguros durante toda su vida útil, y no solo el día que salen al mercado.

Suena a asunto de fabricantes de dispositivos. Afecta a más gente de lo que parece, y conviene saber en qué lado de la línea estás antes de que llegue la fecha.

Qué obliga, en corto

A quien pone en el mercado un producto con elementos digitales —hardware o software— se le exige, entre otras cosas:

• Diseñarlo y entregarlo con una configuración segura por defecto.
• Mantener un proceso de gestión de vulnerabilidades durante el periodo de soporte, con actualizaciones de seguridad gratuitas.
• Publicar un periodo de soporte claro, de forma que el comprador sepa cuántos años recibirá parches.
• Documentar los componentes que incorpora (lo que se conoce como inventario de software).
• Notificar vulnerabilidades explotadas activamente e incidentes graves a las autoridades, en plazos cortos.

Las obligaciones entran en aplicación por fases, y las de notificación llegan antes que el resto. Antes de tomar decisiones, comprueba el calendario vigente en la fuente oficial: es lo que más cambia.

¿Te afecta a ti?

Lo que cambia para quien solo compra tecnología

Aunque no seas fabricante, el CRA te da algo muy útil: argumentos y preguntas para elegir proveedores. A partir de su aplicación, podrás exigir con norma en la mano lo que hoy pides por sentido común:

• ¿Cuántos años vais a publicar actualizaciones de seguridad de este producto?
• ¿Cómo me avisáis cuando aparece una vulnerabilidad?
• ¿Qué componentes de terceros lleva dentro?
• ¿La configuración de fábrica es segura, o llega con todo abierto?

Eso ataca directamente el problema que más webs nos hace limpiar: componentes abandonados que nadie parchea y extensiones empaquetadas con un tema sin canal de actualización propio.

Si vendes software, por dónde empezar

1. Determina si tu producto entra y en qué clase. Las categorías críticas tienen requisitos más duros.
2. Inventario de componentes. Qué bibliotecas de terceros usas y en qué versión. Sin esto no puedes responder cuando aparezca un fallo en una de ellas.
3. Canal de reporte de vulnerabilidades: una dirección pública y un procedimiento para atender avisos. Es barato y es de lo primero que se mira.
4. Política de soporte publicada: cuántos años y con qué frecuencia.
5. Proceso de parcheo con plazos comprometidos y forma de distribuir la actualización.
6. Documentación al usuario: instalación segura, configuración recomendada, qué datos trata.
7. Procedimiento de notificación a las autoridades, integrado en tu plan de respuesta a incidentes.

El efecto indirecto más probable

Aunque no seas fabricante, si vendes a empresas que sí lo son, empezarás a recibir cuestionarios: qué componentes usas, cómo gestionas vulnerabilidades, cuánto tardas en parchear. Es el mismo fenómeno que ya provoca NIS2 en la cadena de suministro: las obligaciones de tu cliente se convierten en requisitos de tu contrato.

Prepararte para eso no es cumplir una norma que no te aplica: es no quedarte fuera de los concursos. Y casi todo lo que te pedirán ya lo deberías tener por otras razones —inventario, actualizaciones, respuesta a incidentes, control de accesos—, que es exactamente el material del resto de esta sección.

El texto del Reglamento y el calendario oficial de aplicación están publicados en EUR-Lex. Consúltalo antes de tomar decisiones con fecha, porque es donde figura la versión vigente.