CRA UE: secure-by-design que ya toca tus routers y firewalls

octubre 12, 2026 Alfonso Moreno | Sysadmin Senior 19 Visitas 12 min de lectura

TL;DR — Lo que vas a tener al final

Tiempo de setup: 2-3 horas para el switch a enforcing.
Requisitos: Root, kernel moderno, 2-4 semanas en permissive antes de enforcing.
Resultado: Sistema con MAC activo, logs en /var/log/audit/audit.log.
Troubleshooting: audit2allow, audit2why, setenforce 0 para emergencias.

Por qué importa HOY

El 11 de septiembre de 2026 se encendió la primera obligación real del Cyber Resilience Act de la Unión Europea. Quien mantenga, venda o despliegue productos con elementos digitales (léase: routers, gateways, firewalls, APs, firmwares embebidos Linux) en el mercado europeo tiene desde esa fecha obligaciones formales de reporte de vulnerabilidades. No es un debate hipotético para 2027: ya hay reloj corriendo, y la mayoría del sector ni siquiera sabe que está en él.

Según el reporte 2026 CRA Awareness and Readiness Report de la Linux Foundation, el 66% de las empresas en Europa siguen sin estar familiarizadas con el CRA, y solo el 41% espera estar completamente cumplidas para diciembre de 2027. Eso es un océano de fabricantes que van a despertar tarde, y desde el lado sysadmin/redes del mostrador, significa que la próxima auditoría de tu proveedor puede sacar trapos sucios de tu inventario.

Qué es el CRA y cuándo se aplica

El Reglamento (UE) 2024/2847, conocido como Cyber Resilience Act, es la primera regulación europea que cubre de forma horizontal la ciberseguridad de productos con elementos digitales. Va más allá del clásico marcado CE de radio/EMC: introduce obligaciones de seguridad por diseño, gestión de vulnerabilidades durante todo el ciclo de vida del producto, y transparencia sobre la composición de software (SBOM, Software Bill of Materials).

Fecha	Hito
10 diciembre 2024	Publicación en el DOUE, entrada en vigor 20 días después
11 septiembre 2026	Obligaciones de reporte de vulnerabilidades e incidentes
11 diciembre 2027	Aplicación plena del reglamento, incluyendo obligaciones de marcado CE y SBOM

Los plazos están alineados con la realidad técnica: la fase 2026 es operacional (reportar), la fase 2027 es estructural (diseñar bajo el CRA). Esto no es NIS2, que cubre operadores críticos: el CRA toca al producto en sí, esté o no detrás de un ISP o un hospital.

Qué productos cubre (y cuáles NO)

El alcance son productos con elementos digitales colocados en el mercado UE. Incluye:

Routers, switches, gateways, APs Wi-Fi, bridges, módems.
Firewalls, IDS/IPS, gateways VPN, appliances de detección.
Dispositivos IoT industriales, lectores RFID, control industrial.
Software standalone vendido por separado (apps, suites, plugins distribuidos como productos).
Firmware que se entrega como actualización para cualquiera de los anteriores.

Quedan explícitamente fuera:

Software open source no comercial (modelo steward, ver abajo).
Productos médicos regulados por MDR/IVDR.
Productos aeronáuticos, automovilísticos (tipo homologación tipo).
Servicios SaaS puros (cubiertos por NIS2, no por CRA).
Sistemas puramente internos de defensa y seguridad nacional.

Para un sysadmin de redes esto significa que tus routers, switches y firewalls son producto CRA si fueron fabricados/distribuidos para venta en la UE. Tu OpenWrt personal sobre un Linksys viejo en tu casa NO está cubierto (uso privado, no es producto en el mercado). Pero si tu empresa vende appliances OpenWrt-marcados a clientes europeos, ahí sí.

Lo que cambió el 11 de septiembre de 2026

Puedes verificar el estado del reglamento y descargar los anexos técnicos directamente del repositorio oficial de EUR-Lex. El texto consolidado incluye el Anexo I con los productos cubiertos y el Anexo II con los requisitos esenciales:

# Bajarse el reglamento consolidado desde EUR-Lex
# (URL estable del DOUE, dominio oficial de la UE)
curl -sLo /tmp/cra-regulation.pdf 
  "https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX:32024R2847"
# Confirmar que descargó algo con sentido (un PDF suele pesar >300 KB)
ls -la /tmp/cra-regulation.pdf
file /tmp/cra-regulation.pdf
# Extraer las fechas clave con pdftotext si necesitas indexarlas
pdftotext /tmp/cra-regulation.pdf - | 
  grep -iE "11 september|11 december|11 septembre"

Desde esa fecha los fabricantes cubiertos deben notificar a ENISA (la agencia de ciberseguridad europea) sobre:

Vulnerabilidades explotadas activamente en sus productos.
Incidentes de seguridad graves que afecten a sus productos.
Vulnerabilidades conocidas pero no parcheadas, en ventanas de 24 horas (incidentes severos) o 72 horas (incidentes generales).

El reporte va acompañado de un SBOM actualizado y de un parche o mitigación (si está disponible). Esto es operativo, no declarativo: hay plantillas, deadlines, y la trazabilidad es por producto SKU. El incumplimiento arrastra multas de hasta 15 millones de euros o el 2,5% del volumen de negocios anual global.

El detalle técnico de las obligaciones está en el EU Cyber Resilience Act Stewardship Guidelines de Red Hat, donde el rol de steward es la pieza que ata a los proyectos open source con el cumplimiento.

El readiness gap: cifras que asustan

Volvamos a los números. El reporte de la Linux Foundation con datos recogidos en el primer trimestre de 2026 pinta mal:

Métrica	Valor	Qué significa
Empresas UE familiarizadas con el CRA	34%	Dos tercios siguen sin saber
Esperan cumplimiento total para dic-2027	41%	El resto lo ve imposible
Mantienen forks privados de OSS críticos	38%	Camino caro, hablan las cifras abajo
Costo anual de mantener un fork privado	hasta USD 258.000	Por producto, según el reporte

Detrás de ese USD 258.000 hay gente, CI, infraestructura de parcheo y auditorías recurrentes. Cuando tu parche diverge del upstream por seis meses, el siguiente CVE te exige reescribir el fix encima de código que ya no existe. Contribuir upstream elimina ese costo porque tu parche ya está mergeado antes de que la vulnerabilidad sea pública.

Secure-by-design en la práctica: hábitos que puedes auditar

El CRA no inventa el concepto: lo pide. Para un equipo de networking/sysadmin que mantiene firmware o productos, secure by design se traduce en cinco hábitos que Red Hat y la OpenSSF codificaron en la CRA Readiness Guide for Maintainers and Developers:

Vulnerability handling policy pública: donde declaras cómo recibes, triageas y parcheas reportes. Una página de security.txt en tu sitio + un alias security@tu-dominio ya cumple el mínimo. Compruébalo con un curl antes de confiar en la documentación del fabricante:

# Verificar que el fabricante expone security.txt en /.well-known/
curl -sI https://fabricante.example/.well-known/security.txt | head -3
curl -s https://fabricante.example/.well-known/security.txt 
  | grep -iE "(contact|expires|encryption|preferred-languages)"
# Comprobar que el alias security@ responde (test pasivo)
dig +short TXT fabricante.example | grep -i spf

SBOM firmado y versionado: cada release incluye la lista exacta de dependencias y sus versiones. El estándar es CycloneDX o SPDX, en formatos machine-readable.
Canal seguro de reporte: PGP o Sigstore para cifrar reportes, ventana de respuesta documentada (ej. 5 días hábiles para acknowledgement).
Política de fin de vida clara: cuánto tiempo das soporte tras el EOL del componente upstream y qué avisarás al cliente.
Auditorías recurrentes: ya sea SCA (software composition analysis) o revisión manual por trimestre. Esto era opcional, con el CRA pasa a ser demostrable.

Ninguna de estas prácticas es nueva. Lo nuevo es que ahora son exigibles y auditables. Para un sysadmin que despliega estos productos en una red corporativa, esto se traduce en tener que exigir a tu proveedor evidencia de los cinco puntos: SLA contractual, security.txt verificable, SBOM firmado, política de disclosure y, sobre todo, parches con plazos.

El otro 97%: el código que no ves

El 2026 Open Source Security and Risk Analysis Report de Black Duck estima que más del 97% del código en codebases modernos proviene de open source. Tu router de borde, tu appliance VPN, tu AP Wi-Fi empresarial: su firmware tiene Linux, busybox, openssl, openvpn, netfilter, dnsmasq, systemd-resolved. Cada uno es un proyecto upstream con su propia política de CVE.

Cuando el fabricante de tu appliance mantiene un fork privado y no contribuye al upstream, te encuentras con la peor combinación para una auditoría CRA: parches que no puedes verificar contra una versión pública. No hay diff contra mainline, no hay revisión pública, no hay segunda opinión. Tu equipo de seguridad interno tiene que confiar en el fabricante a ciegas.

La OpenSSF (Open Source Security Foundation) recomienda para evaluar proveedores cubiertos por CRA:

# Verificar que el firmware embebido es identificable
# (esto es parte del SBOM que el fabricante debe entregarte)
sbom-tool validate --input firmware-sbom.spdx.json
# Comprobar que las versiones de componentes son públicas
grep -E '"name": "openssl"' sbom.json | head -1
# Buscar la versión en cve.org / nvd.nist.gov
# Verificar la firma del SBOM
cosign verify-blob --signature sbom.sig firmware-sbom.spdx.json
# Enumerar componentes open source detectados en tu firmware
# (útil para mapear upstream vs fork del fabricante)
syft scan firmware.bin -o spdx-json | jq '.packages[] | {name, version, supplier}'

Si tu proveedor no te entrega un SBOM firmado verificable, no cumple CRA, y el 11 de diciembre de 2027 te tocará migrar.

Stewardship: la puerta que conecta open source con CRA

Aquí aparece el concepto clave que muchos sysadmins de redes todavía no manejan: open source software steward. Es un rol creado por el CRA para que entidades (empresas, fundaciones, consorcios) asuman parte de las obligaciones de cumplimiento de los proyectos open source que hospedean o mantienen.

Red Hat es steward oficial de proyectos como Ansible y Fedora Linux. La implicación práctica: un fabricante que usa Ansible como base puede apoyarse en el stewardship de Red Hat para demostrar cumplimiento CRA de su cadena de suministro open source, sin tener que gestionar cada CVE individualmente.

Para identificar si un proyecto que estás usando tiene stewardship activo, basta con consultar el listado oficial que la Comisión Europea mantiene:

# Descargar la lista oficial de stewards publicados por la Comisión Europea
curl -sL https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act 
  -o /tmp/cra-stewards.html
# Extraer las referencias a proyectos open source cubiertos
grep -oE 'href="/[^"]+"' /tmp/cra-stewards.html 
  | grep -iE "steward|fedora|ansible" | sort -u
# Verificar un proyecto concreto (ej: confirmar Ansible está stewarded)
curl -sI https://docs.ansible.com/ | head -1
# Comprobar la fecha del último advisory de seguridad publicado
curl -s "https://api.osv.dev/v1/query" 
  -H "Content-Type: application/json" 
  -d '{"package":{"name":"ansible-core","ecosystem":"PyPI"}}' 
  | jq '.vulns[] | {id, summary, modified}'

Para ti como sysadmin de redes, esto significa:

Soslayable: si despliegas Red Hat Enterprise Linux en appliances, ya tienes soporte stewardship upstream.
Crítico: si despliegas derivados de Fedora/Community Linux sin suscripción, el stewardship NO está incluido y tú (o tu fabricante) deben asumir el rol.
Si despliegas OpenWrt, VyOS, OPNsense o pfSense en producción, tu proveedor/distribuidor es responsable, no el proyecto upstream.

Pregunta obligatoria a tu proveedor en la próxima RFP: ¿tiene algún componente cubierto por CRA? ¿quién es el steward de su open source? ¿me entrega SBOM firmado? Si la respuesta es evasiva, cambia de proveedor.

Checklist práctico: qué revisar en tu red HOY

Para empezar a ponerte al día sin esperar al deadline de 2027, este es el orden de operaciones recomendado:

# 1. Inventario de appliances cubiertos por CRA en tu red
#    (routers, gateways, APs, firewalls de marca con firmware embebido)
nmap -sV -O 192.168.0.0/24 -oA network_cra_inventory
# 2. Identificar el fabricante y modelo de cada uno
#    Cruzar con la lista de stewardship del proyecto CRA oficial
curl -s https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act 
  | grep -oE 'steward[^<]+' | head -20
# 3. Para cada fabricante, abrir ticket pidiendo:
#    - SBOM firmado del firmware actual
#    - Política de vulnerabilidad disclosure (security.txt)
#    - Roadmap de cumplimiento CRA antes de dic-2027

Para validar localmente que un firmware se actualiza correctamente y que el fabricante está cumpliendo, este set de comprobaciones te lleva una hora por proveedor y detecta la mayoría de los incumplimientos:

# Comprobar la versión actual del firmware contra la última publicada
curl -s https://fabricante.example/api/firmware/latest.json | jq -r .version
ssh root@ap-wifi-01 'cat /etc/firmware_version'
# Verificar que la firma del firmware es válida (ejemplo con cosign)
cosign verify-blob 
  --signature firmware.sig 
  --certificate-identity https://fabricante.example 
  --certificate-oidc-issuer https://token.actions.githubusercontent.com 
  firmware.bin
# Listar CVEs abiertas del firmware en la NVD (últimos 90 días)
curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?keywordSearch=fabricante-modelo" 
  | jq '.vulnerabilities[] | {cve: .cve.id, severity: .cve.metrics.cvssMetricV31[0].cvssData.baseSeverity}'
# Auditar la configuración del dispositivo contra el baseline del fabricante
# (la mayoría de marcas publican una "hardening guide" en PDF)
diff <(ssh root@ap 'nvram show') baseline.config || echo "Diverge del baseline"

Si tu red es pequeña (homelab, pyme), la buena noticia es que probablemente todo tu inventario de fabricante grande (MikroTik, Ubiquiti, TP-Link, Cisco) ya tiene a alguien trabajando en ello y te llegarán los parches automáticamente. Tu trabajo es validar que el firmware está actualizado, no auditarlo.

Si tienes appliances de un fabricante pequeño o blanco, escribe hoy. No esperes a diciembre de 2027: la cola de cumplimiento va a estar saturada y los plazos de respuesta se van a estirar.

¿Vale la pena? Mi opinión

El CRA es la regulación que el sector necesitaba y nadie quería. Lo querías si te hartaste de routers con default passwords y CVEs sin parche. No lo querías si vendías appliances low-cost y preferías la opacidad a la auditoría. La balanza está clara: asegurar la cadena de suministro open source beneficia al sysadmin que la opera.

Para el sysadmin de redes hispano en LATAM, la buena noticia es que el CRA te toca indirectamente: si tu proveedor global vende en la UE, todos los modelos que te llegue van a tener el mismo firmware ya endurecido. Te llega el upgrade gratis.

Para el sysadmin en Europa o que trabaja para clientes europeos, la cuenta regresiva ya empezó. El reporte del 11 de septiembre de 2026 es el primer deadline real. Aún tienes 14 meses hasta la aplicación plena de diciembre 2027, pero la mitad de tu cadena de suministro aún no sabe que tiene que trabajar en esto.

Preguntas frecuentes

¿Por qué CRA UE: secure-by-design que ya toca tus routers y firewalls es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con CRA UE: secure-by-design que ya?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con CRA UE: secure-by-design que ya?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar CRA UE: secure-by-design que ya y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a CRA UE: secure-by-design que ya?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.