Datos del Fabricante y del Producto
Art. 13.15, 13.16, 13.17 — Identificación del fabricante y del producto con elementos digitales
🏢 Datos del fabricante
📦 Datos del producto con elementos digitales
Art. 13.15 — Elemento que permita la identificación del producto
Art. 3.23 — Incluya el uso para el que el producto está diseñado, el contexto y las condiciones de uso
Art. 3.2 — Cloud, API, backend del fabricante sin el cual el producto no puede realizar una de sus funciones
Clasificación del Producto
Art. 2, Art. 7, Art. 8 — Determinar si el producto entra en el CRA y su categoría
🚫 Exclusiones del ámbito (Art. 2)
El CRA no aplica a ciertos productos ya regulados por otra legislación. Responda a las siguientes preguntas para verificar si su producto está excluido.
¿Es un dispositivo médico regulado por Reg. (UE) 2017/745 o 2017/746?
Art. 2.2(a)(b)
¿Es un vehículo tipo-aprobado conforme al Reg. (UE) 2019/2144?
Art. 2.2(c)
¿Es un producto certificado según el Reg. (UE) 2018/1139 (aviación)?
Art. 2.3
¿Es un equipo marino cubierto por la Dir. 2014/90/UE?
Art. 2.4
¿Es un producto desarrollado exclusivamente para seguridad/defensa nacional o para procesar información clasificada?
Art. 2.7
¿Es software libre/open-source NO comercializado (sin monetización, sin datos personales como condición de uso)?
Art. 2 + Considerandos 17-18
Aceptar donaciones sin ánimo de lucro no se considera actividad comercial. Solo el open-source comercializado entra en el CRA.
Requisitos Esenciales de Ciberseguridad
Anexo I, Parte I — Requisitos relativos a las propiedades del producto
Para cada requisito: indique si aplica a su producto y, si aplica, describa brevemente cómo lo implementa. Si no aplica, indique por qué (Art. 13.4 exige justificación en la documentación técnica).
(a) Sin vulnerabilidades explotables conocidas
Anexo I, Parte I, 2(a)
El producto debe ponerse en el mercado sin vulnerabilidades explotables conocidas.
(b) Configuración segura por defecto
Anexo I, Parte I, 2(b)
Configuración segura de fábrica, incluyendo posibilidad de reset al estado original.
(c) Actualizaciones de seguridad
Anexo I, Parte I, 2(c)
Garantizar que las vulnerabilidades puedan corregirse mediante actualizaciones de seguridad, incluyendo actualizaciones automáticas con opción de opt-out.
(d) Protección contra acceso no autorizado
Anexo I, Parte I, 2(d)
Mecanismos de control de acceso: autenticación, gestión de identidad, y reporte de accesos no autorizados.
(e) Confidencialidad de datos
Anexo I, Parte I, 2(e)
Cifrado de datos en reposo y en tránsito mediante mecanismos de última generación.
(f) Integridad de datos
Anexo I, Parte I, 2(f)
Proteger la integridad de datos, comandos, programas y configuración contra manipulación no autorizada.
(g) Minimización de datos
Anexo I, Parte I, 2(g)
Procesar solo datos adecuados, pertinentes y limitados a lo necesario para el propósito previsto.
(h) Disponibilidad y resiliencia
Anexo I, Parte I, 2(h)
Proteger la disponibilidad de funciones esenciales, incluso después de un incidente. Medidas contra ataques de denegación de servicio.
(i) Minimizar impacto en otros dispositivos
Anexo I, Parte I, 2(i)
Minimizar el impacto negativo del producto en la disponibilidad de servicios de otros dispositivos o redes.
(j) Minimizar superficie de ataque
Anexo I, Parte I, 2(j)
Diseñar, desarrollar y producir el producto para limitar la superficie de ataque, incluyendo interfaces externas.
(k) Mitigación de impacto de incidentes
Anexo I, Parte I, 2(k)
Diseñar el producto para reducir el impacto de un incidente usando mecanismos apropiados de mitigación.
(l) Registro y monitorización de seguridad
Anexo I, Parte I, 2(l)
Proporcionar información de seguridad registrando y monitorizando actividad interna relevante, con opción de opt-out para el usuario.
(m) Borrado seguro de datos
Anexo I, Parte I, 2(m)
Permitir a los usuarios borrar de forma segura y permanente todos los datos y configuraciones, y transferirlos de forma segura.
Gestión de Vulnerabilidades y Periodo de Soporte
Anexo I, Parte II + Art. 13.8 — Requisitos de gestión de vulnerabilidades durante todo el periodo de soporte
🛡️ Periodo de soporte (Art. 13.8)
El periodo de soporte mínimo es 5 años, salvo que la vida útil esperada del producto sea inferior. Durante este periodo, el fabricante debe proporcionar actualizaciones de seguridad gratuitas y gestionar vulnerabilidades.
Art. 13.8 — Debe considerar: expectativas razonables del usuario, naturaleza del producto, legislación aplicable sobre vida útil, periodos de soporte de productos similares
📋 Software Bill of Materials — SBOM (Anexo I, Parte II, punto 1)
¿Qué es un SBOM? Es un inventario formal de todos los componentes de software que contiene su producto: librerías, frameworks, módulos de terceros. Es como la lista de ingredientes de un alimento, pero para software. El CRA lo exige para poder rastrear vulnerabilidades en cualquier componente.
Ejemplo: Si su producto usa la librería OpenSSL para cifrado, esa librería debe aparecer en su SBOM. Si mañana se descubre una vulnerabilidad en OpenSSL, el SBOM le permite identificar inmediatamente que su producto está afectado.
Ejemplo: Si su producto usa la librería OpenSSL para cifrado, esa librería debe aparecer en su SBOM. Si mañana se descubre una vulnerabilidad en OpenSSL, el SBOM le permite identificar inmediatamente que su producto está afectado.
Formatos reconocidos por la industria para generar SBOMs legibles por máquina
¿Qué es esto? Las dependencias de nivel superior son las librerías y componentes que su producto importa directamente (no las sub-dependencias de esas librerías). Ejemplo: si su app Node.js tiene 47 paquetes en su package.json, tiene 47 dependencias de nivel superior, aunque esos 47 paquetes a su vez descarguen 300 sub-dependencias. Ponga el número directo.
🔄 Procesos de gestión de vulnerabilidades (Anexo I, Parte II)
¿Por qué es importante? El CRA no solo exige que su producto sea seguro al venderlo, sino que usted mantenga activamente su seguridad durante todo el periodo de soporte. Esto incluye: tener un canal para que le reporten fallos, corregirlos rápido, y distribuir las correcciones a los usuarios.
Anexo I, Parte II, punto 5 — Obligatoria. Un proceso público y documentado que indica a investigadores de seguridad y usuarios cómo reportarle vulnerabilidades de forma responsable. Debe incluir: canal de reporte, tiempos de respuesta, y cómo se coordinará la publicación del fallo una vez corregido.
Ejemplo: "Publicamos nuestra política CVD en nuestra web /security. Los investigadores pueden reportar a security@empresa.com. Acusamos recibo en 48h, evaluamos en 5 días y coordinamos la divulgación pública tras publicar el parche."
Ejemplo: "Publicamos nuestra política CVD en nuestra web /security. Los investigadores pueden reportar a security@empresa.com. Acusamos recibo en 48h, evaluamos en 5 días y coordinamos la divulgación pública tras publicar el parche."
Art. 13.17 — Obligatorio. Una dirección (email, web, teléfono) fácilmente visible donde cualquier persona pueda reportar un fallo de seguridad. El CRA exige que no sea solo un chatbot — debe haber opción de contacto humano.
Ejemplo: "security@miempresa.com + formulario web en /security + teléfono +34 91 XXX XXXX"
Ejemplo: "security@miempresa.com + formulario web en /security + teléfono +34 91 XXX XXXX"
Anexo I, Parte II, punto 7. Cómo envía las actualizaciones de seguridad a sus usuarios de forma segura (que nadie pueda interceptarlas o modificarlas). Incluya: canal de distribución, verificación de integridad, y si las actualizaciones de seguridad se separan de las funcionales.
Ejemplo: "Actualizaciones OTA firmadas digitalmente con Ed25519. Canal cifrado TLS 1.3. El dispositivo verifica la firma antes de instalar. Si falla, se revierte al firmware anterior."
Ejemplo: "Actualizaciones OTA firmadas digitalmente con Ed25519. Canal cifrado TLS 1.3. El dispositivo verifica la firma antes de instalar. Si falla, se revierte al firmware anterior."
Anexo I, Parte II, punto 3. Las pruebas periódicas que realiza para verificar que su producto sigue siendo seguro: tests de penetración, escaneos de vulnerabilidades, revisiones de código, etc.
Ejemplo: "Test de penetración trimestral por empresa externa. Escaneo automático de dependencias semanal con Snyk. Análisis estático de código en cada release con SonarQube."
Ejemplo: "Test de penetración trimestral por empresa externa. Escaneo automático de dependencias semanal con Snyk. Análisis estático de código en cada release con SonarQube."
Anexo I, Parte II, punto 2 — Las actualizaciones de seguridad deben proporcionarse sin demora y de forma gratuita. Cómo clasifica y corrige las vulnerabilidades una vez detectadas. Debe incluir: criterio de priorización (normalmente por gravedad CVSS), tiempos máximos de corrección, y confirmar que las actualizaciones de seguridad son gratuitas.
Ejemplo: "Vulnerabilidades críticas (CVSS ≥9): parche en 24-48h. Altas (7-8.9): parche en 7 días. Medias (4-6.9): parche en 30 días. Todas las actualizaciones de seguridad son gratuitas."
Ejemplo: "Vulnerabilidades críticas (CVSS ≥9): parche en 24-48h. Altas (7-8.9): parche en 7 días. Medias (4-6.9): parche en 30 días. Todas las actualizaciones de seguridad son gratuitas."
Información al Usuario y Estándares
Anexo II + Art. 27 — Información que debe acompañar al producto y estándares aplicados
📖 Información e instrucciones al usuario (Anexo II)
Anexo II, punto 5. Situaciones que usted conoce en las que su producto podría ser vulnerable o comprometido. Piense en: qué pasa si el usuario lo usa mal, en un entorno inseguro, o sin actualizar.
Ejemplo: "Usar el dispositivo en una red WiFi abierta (sin contraseña) puede exponer las comunicaciones. No actualizar el firmware puede dejar vulnerabilidades conocidas sin parchear. Reutilizar el dispositivo sin hacer factory reset puede exponer datos del usuario anterior."
Ejemplo: "Usar el dispositivo en una red WiFi abierta (sin contraseña) puede exponer las comunicaciones. No actualizar el firmware puede dejar vulnerabilidades conocidas sin parchear. Reutilizar el dispositivo sin hacer factory reset puede exponer datos del usuario anterior."
Anexo II, punto 8(a). Los pasos que el usuario debe seguir para instalar y usar su producto de forma segura. Son como las "instrucciones de seguridad" de cualquier producto, pero para ciberseguridad.
Ejemplo: "1. Conectar solo a red WiFi con WPA2/WPA3. 2. Cambiar la contraseña de administrador en el primer uso. 3. Activar autenticación en dos factores. 4. Mantener el firmware actualizado. 5. No exponer el dispositivo directamente a internet."
Ejemplo: "1. Conectar solo a red WiFi con WPA2/WPA3. 2. Cambiar la contraseña de administrador en el primer uso. 3. Activar autenticación en dos factores. 4. Mantener el firmware actualizado. 5. No exponer el dispositivo directamente a internet."
Anexo II, punto 8(d). Cómo el usuario puede borrar sus datos del producto antes de deshacerse de él, venderlo o devolverlo. Incluya tanto el borrado local como la desvinculación de la cuenta cloud (si aplica).
Ejemplo: "Factory reset desde el menú Ajustes > Restaurar valores de fábrica. Borra todas las credenciales, configuraciones y datos locales. Se desvincula automáticamente de la cuenta cloud del usuario."
Ejemplo: "Factory reset desde el menú Ajustes > Restaurar valores de fábrica. Borra todas las credenciales, configuraciones y datos locales. Se desvincula automáticamente de la cuenta cloud del usuario."
📐 Estándares y especificaciones aplicados (Anexo VII, punto 5)
Si ha aplicado estándares armonizados, especificaciones comunes o esquemas de certificación europeos, se presume la conformidad con los requisitos cubiertos por dichos estándares (Art. 27). Si no los aplica, debe describir las soluciones alternativas adoptadas.
Si no hay estándares armonizados publicados todavía, puede indicar estándares internacionales aplicados (ISO/IEC, ETSI EN, etc.)
Resumen de las pruebas realizadas para verificar la conformidad con los requisitos esenciales
Declaración del Firmante y Resumen
Art. 13.12 + Anexo V — Revisión final antes de generar el dossier
📊 Resumen del dossier
Empresa:
País:
Producto:
Tipo:
Tamaño:
En mercado:
Categoría de producto:
Referencia:
Fecha:
Su dossier incluirá 8 documentos (~40 páginas):
• Doc 1: Clasificador de Producto y Ámbito — Art. 2 + Art. 7 + Anexos III/IV (3 páginas)
• Doc 2: Documentación Técnica — Art. 31 + Anexo VII, 8 puntos (5-7 páginas)
• Doc 3: Evaluación de Riesgos de Ciberseguridad — Art. 13 + Anexo I, 13+8 requisitos (8-10 páginas)
• Doc 4: Información e Instrucciones al Usuario — Anexo II, 9 puntos (4-5 páginas)
• Doc 5: Declaración UE de Conformidad — Art. 28 + Anexo V (2-3 páginas)
• Doc 6: Política de Divulgación Coordinada de Vulnerabilidades — Anexo I, Parte II (3-4 páginas)
• Doc 7: Plantilla de Notificación de Vulnerabilidades e Incidentes — Art. 14, 3 fases (7-9 páginas)
• Doc 8: Calendario de Obligaciones CRA + multas por incumplimiento (2-3 páginas)
• Doc 1: Clasificador de Producto y Ámbito — Art. 2 + Art. 7 + Anexos III/IV (3 páginas)
• Doc 2: Documentación Técnica — Art. 31 + Anexo VII, 8 puntos (5-7 páginas)
• Doc 3: Evaluación de Riesgos de Ciberseguridad — Art. 13 + Anexo I, 13+8 requisitos (8-10 páginas)
• Doc 4: Información e Instrucciones al Usuario — Anexo II, 9 puntos (4-5 páginas)
• Doc 5: Declaración UE de Conformidad — Art. 28 + Anexo V (2-3 páginas)
• Doc 6: Política de Divulgación Coordinada de Vulnerabilidades — Anexo I, Parte II (3-4 páginas)
• Doc 7: Plantilla de Notificación de Vulnerabilidades e Incidentes — Art. 14, 3 fases (7-9 páginas)
• Doc 8: Calendario de Obligaciones CRA + multas por incumplimiento (2-3 páginas)
✍️ Declaración del firmante
Versión del producto: CRACheck v1.0 cubre la clasificación de producto (Art. 2 + Art. 7 + Anexos III/IV), la documentación técnica del fabricante (Art. 31 + Anexo VII), la evaluación de riesgos de ciberseguridad (Art. 13 + Anexo I) y la declaración de conformidad (Art. 28 + Anexo V). SolidwareTools monitoriza semanalmente el DOUE y EUR-Lex para garantizar que este producto refleja la normativa vigente.
Su Dossier CRACheck
Genere su documentación técnica completa.
CYBER RESILIENCE ACT · Reglamento (UE) 2024/2847
Sin documentación técnica conforme al Anexo VII, su producto no puede llevar el marcado CE ni comercializarse legalmente en la UE a partir de diciembre 2027.
1 PRODUCTO
149 €
/ producto
PACK 10
990 €
99 € / producto
PACK 30
2.370 €
79 € / producto
✔ Clasificador de Producto (Art. 2 + Anexos III/IV)
✔ Documentación Técnica conforme al Anexo VII — 8 puntos
✔ Evaluación de Riesgos de Ciberseguridad — Anexo I
✔ Declaración UE de Conformidad — plantilla Anexo V
✔ Política CVD + Notificación Art. 14 + Calendario + 2 más
Pago único · 10 regeneraciones · 30 días de edición · PDF tuyo para siempre · 100% en tu navegador
¿Cómo funciona tu licencia?
1. Compras una licencia en Gumroad (1, 10 o 30 productos).
2. Recibes una clave (XXXXXXXX-XXXXXXXX-XXXXXXXX-XXXXXXXX).
3. La pegas aquí abajo y generas tu dossier.
4. 1 licencia = 1 producto. Para otro producto, usa otra licencia del pack o compra una nueva.
1. Compras una licencia en Gumroad (1, 10 o 30 productos).
2. Recibes una clave (XXXXXXXX-XXXXXXXX-XXXXXXXX-XXXXXXXX).
3. La pegas aquí abajo y generas tu dossier.
4. 1 licencia = 1 producto. Para otro producto, usa otra licencia del pack o compra una nueva.
Alto volumen o packs con precio especial: hello@solidwaretools.com
Este documento ha sido generado por CRACheck (SolidwareTools) a partir de la información facilitada por el firmante. No constituye asesoramiento jurídico ni una auditoría de terceros. La veracidad de los datos y el cumplimiento efectivo de las obligaciones legales aplicables son responsabilidad exclusiva del fabricante. SolidwareTools garantiza que la estructura de este documento sigue el Reglamento (UE) 2024/2847 en su redacción vigente a la fecha de emisión. Para asesoramiento personalizado, consulte con un profesional cualificado.