Security-by-design
antes del CRA 2027
RAG especializado en el Reglamento de Ciberresiliencia. Clasifica tus productos digitales, implementa SBOM y prepara la evaluación de conformidad antes de diciembre 2027.
Multas hasta €15M o 2,5% facturación global · Transición hasta diciembre 2027
Los retos del CRA en tu empresa
El Reglamento EU 2024/2847 afecta a todos los fabricantes de productos con elementos digitales que se comercializan en la UE. La transición termina en diciembre 2027.
Clasificación de productos desconocida
El Reglamento define Clase I (importante, como routers) y Clase II (crítica, como PLCs). Sin clasificación, no sabes qué evaluación necesitas ni si puedes autoevaluarte.
Security-by-design desde cero
El Art.13 CRA exige que el security-by-design esté en el ADN del producto desde el diseño. Rediseñar productos ya en producción es costoso y urgente.
SBOM: inventario componentes software
El Art.13(3) obliga a mantener un Software Bill of Materials para identificar vulnerabilidades en componentes de terceros. La mayoría de fabricantes no tienen este proceso.
Gestión de vulnerabilidades durante toda la vida útil
Obligación de emitir actualizaciones de seguridad durante toda la vida útil del producto o 5 años (lo que sea mayor). Para productos hardware con software, esto es un cambio operativo radical.
Evaluación por organismo notificado para Clase I y II
Los productos de Clase I (routers, antivirus, firewalls) necesitan evaluación de conformidad por organismo notificado acreditado. Hay pocos y con lista de espera.
Coordinación con MDR/IVDR y maquinaria
Los dispositivos médicos conectados tienen overlap con MDR. La maquinaria conectada tiene overlap con el Reglamento de Máquinas. La doble conformidad es compleja.
IgeraRegTech CRA en acción
Entrenado con el Reglamento EU 2024/2847, actos delegados, estándares ENISA y guías técnicas de organismos notificados.
Clasificador de productos CRA
Responde preguntas sobre tu producto y obtén la clasificación CRA: por defecto, Clase I o Clase II. Con el artículo exacto del Reglamento EU 2024/2847.
Clasifica en < 10 minGenerador SBOM conforme
Plantilla SBOM (Software Bill of Materials) en formato SPDX o CycloneDX con todos los componentes software de tu producto y sus versiones.
SBOM inicial en 1 díaAsistente documentación técnica Art.13
Estructura completa de la documentación técnica CRA: especificaciones, análisis de riesgos, medidas de seguridad, proceso de actualización.
Documentación en 3 díasProtocolo gestión vulnerabilidades
Proceso completo de lifecycle de vulnerabilidades: identificación (CVE), evaluación CVSS, parcheo, comunicación a usuarios y notificación ENISA.
Proceso operativo en 1 semanaGap analysis evaluación conformidad
Para Clase I y II: checklist de requisitos para evaluación por organismo notificado. Qué tienes, qué falta y estimación de coste/tiempo de evaluación.
Gap analysis completoMonitor CVEs componentes
Seguimiento automático de CVEs publicados en los componentes de tu SBOM. Alertas cuando aparece una vulnerabilidad que afecta a tus productos en el mercado.
Alertas CVE tiempo realPreguntas reales, artículos exactos
Así responde IgeraRegTech CRA con el Reglamento como fuente de verdad
"Fabricamos routers industriales conectados a Internet. ¿En qué clase CRA caemos y qué evaluación necesitamos?"
Los routers industriales con conectividad a Internet están en el Anexo III del CRA como productos importantes de Clase I (categoría "hardware de red"). La Clase I permite autoevaluación (Módulo A del Reglamento EU 765/2008) o evaluación por organismo notificado (Módulo B+C). Sin embargo, si el router gestiona infraestructuras críticas o procesa datos sensibles, la autoridad supervisora puede exigir Clase II. La obligación central del Art.13 CRA para vuestros routers: sin vulnerabilidades explotables conocidas en el momento de la comercialización, actualizaciones de seguridad durante vida útil, SBOM disponible para clientes y autoridades.
"¿Qué es exactamente el SBOM que exige el CRA y cómo lo implementamos?"
El Art.13(3) del CRA obliga a los fabricantes a preparar y mantener un SBOM (Software Bill of Materials): un inventario exhaustivo de todos los componentes software del producto, incluyendo sus versiones. Formatos estándar reconocidos: SPDX (ISO/IEC 5962:2021) y CycloneDX 1.4+. El SBOM debe incluir: nombre y versión de cada componente, licencia, repositorio origen, dependencias transitivas (no solo directas) y hash de integridad. No es público por defecto — debe estar disponible para autoridades de vigilancia del mercado, no necesariamente para clientes. Herramientas: Syft, SBOM-tool (Microsoft), Grype para análisis de vulnerabilidades contra el SBOM.
"Tenemos un software industrial en SCADA que actualizamos cada 5 años. ¿Cómo nos afecta la obligación de updates de seguridad del CRA?"
El Art.13(8) del CRA establece que los fabricantes deben garantizar actualizaciones de seguridad durante todo el período de soporte del producto, o durante un mínimo de 5 años desde la comercialización (lo que sea mayor). Para un SCADA con ciclos de actualización de 5 años, esto significa: separar las actualizaciones de seguridad de las de funcionalidad (security patches independientes del release cycle), implementar un proceso de divulgación responsable de vulnerabilidades (VDP según Art.13(6)), notificar vulnerabilidades activamente explotadas a ENISA en 24h y a la autoridad de vigilancia en 72h (Art.14 CRA). El ciclo de 5 años de funcionalidad puede mantenerse, pero los parches de seguridad deben emitirse cuando se descubran, no cuando toque el release.
¿Hablamos sobre CRA?
Cuéntanos qué productos digitales fabricas y te mostramos cómo clasificarlos y documentarlos.