Navegando por el cumplimiento de la ciberseguridad de la UE para los productos conectados: respuestas expertas a sus preguntas RED y CRA
17 jul 2026
Durante nuestro seminario web, Navegando por la ciberseguridad europea para los productos conectadosLos asistentes plantearon preguntas detalladas acerca de la Ley de Resistencia Cibernética (CRA), Requisitos de ciberseguridad RED, clasificación de productos, evaluación de conformidad, reporte de incidentes, sistemas en la nube y períodos de soporte de seguridad.
Hemos respondido a varias preguntas durante la sesión en vivo. Para el sorteo del seminario web principal, incluyendo RED escoping, EN 18031 evaluación de riesgo, documentación, preparación de pruebas, y la preparación de informes CRA, lea nuestra guía RED, EN 18031 y CRA Readiness Guide: Respuestas prácticas del seminario web QIMA.
No pudimos cubrir todas las preguntas durante la sesión, por lo que nuestros expertos en ciberseguridad prepararon las respuestas adicionales a continuación.
Este artículo refleja el estatus regulador y normalizado a partir de julio de 2026. Las obligaciones de notificación de la CRA se aplican a partir del 11 de septiembre de 2026, mientras que los principales requisitos de la CRA se aplican a partir del 11 de diciembre de 2027.
Estas respuestas proporcionan orientación técnica general. La ruta correcta de clasificación y evaluación de la conformidad de un producto específico debe determinarse utilizando su documentación técnica completa, , uso razonablemente predecible, conectividad y arquitectura de seguridad.
Pregunta 1: Tenemos una cartera criptográfica fría en forma de tarjeta NFC. Sus funciones principales son almacenar, enviar y recibir recursos criptográficos sin KYC. Funciona a través de una aplicación móvil usando NFC. ¿Qué normas y restricciones armonizadas pueden aplicarse?
Es probable que la coincidencia más cercana bajo el Reglamento de Implementación (UE) 2025/2392 sea “tarjetas inteligentes o dispositivos similares, incluyendo elementos seguros", que es una categoría de producto crítico.
Esto se debe a que la funcionalidad principal de la tarjeta parece ser el almacenamiento seguro de claves criptográficas y la firma de transacciones en un factor de formulario de tarjeta. Sin embargo, una clasificación precisa requiere una evaluación cuidadosa.
¿Qué chip está dentro de la carta?
La descripción técnica del Anexo IV requiere que el elemento seguro proporcione resistencia a los ataques al menos en AVA_VAN.4 bajo criterios comunes.
Dependiendo del chip, el producto puede ser clasificado de la siguiente manera:
Un elemento seguro basado en JavaCard en AVA_VAN.4 puede clasificarse como crítico.
Un chip resistente a la manipulación en AVA_VAN.2 o AVA_VAN.3 puede ser clasificado como clase importante II.
Un microcontrolador de seguridad bajo AVA_VAN.2 puede ser clasificado como Clase Importante I.
Un simple chip de memoria NFC con procesamiento criptográfico realizado en software en otros sitios probablemente permanecerá en la categoría Por defecto.
¿Cuál es la verdadera funcionalidad básica del producto como un todo?
Según el borrador de orientación CRA, la clasificación se basa en la funcionalidad única central del producto en su conjunto.
En este caso, la funcionalidad principal se describe con mayor precisión como almacenamiento de claves seguras y firma de transacciones, en lugar de enviar y recibir criptografías. La transmisión de la transacción al blockchain es normalmente realizada por la aplicación móvil, no por la tarjeta.
Esta distinción importa cuando se compara el producto con las descripciones técnicas en la Regulación de Implementación.
¿Cuál es la ruta de evaluación de la conformidad si el producto está clasificado como Crítico?
El apartado 4 del artículo 32 de CRA exige la certificación europea de seguridad cibernética para los productos críticos. Se espera que el sistema pertinente sea EUCC, que se basa en criterios comunes y en el Perfil de protección aplicable para elementos seguros.
Los estándares armonizados y la certificación EUCC pueden suponer la conformidad con los requisitos esenciales de Cybersecurity Requirements CRA pero su uso depende de la categoría del producto y de las condiciones aplicables.
Se deben comprobar dos puntos antes de confiar en un certificado EUCC para la conformidad con CRA.
1. Alineación entre el límite del producto y el objetivo de evaluación
Un certificado EUCC sólo cubre lo que se incluye dentro de su objetivo definido de evaluación, o TOE.
El fabricante debe verificar que el límite de TOE cubre todo lo incluido en la reclamación de conformidad de CRA.
El elemento seguro
Firmware
La aplicación de cartera que se ejecuta en el elemento seguro
Interfaz NFC
La aplicación móvil, donde forma parte del producto
Cualquier procesamiento de backend que califique como solución de procesamiento de datos remotos
2. El acto delegado requerido de CRA aún no ha sido emitido
El acto delegado que define las condiciones en las que la EUCC presupone la conformidad con la CRA todavía no se ha adoptado.
Hasta que no se aplique, los productos críticos deben seguir el procedimiento de reserva para los productos de clase II importantes. Esto requiere una evaluación obligatoria de terceros usando el Módulo B más el Módulo C, o el Módulo H, con un cuerpo notificado.
El acto delegado también definirá el nivel de garantía exigido por la EUCC. que debe ser al menos “sustancial” y puede ser “alto”, dependiendo del riesgo identificado.
¿Qué normas previstas pueden ser relevantes?
Tanto a nivel de plataforma como a nivel de aplicación pueden ser relevantes:
prEN 50764, Requisitos de ciberseguridad para plataformas de tarjetas inteligentes y dispositivos similares, incluyendo elementos seguros. Esto cubre la plataforma de hardware y firmware de elementos seguros. Normalmente será relevante para el fabricante de chip, pero también puede ser aplicable cuando el fabricante del monedero diseñe su propio chip.
prEN 18330, Requisitos de ciberseguridad para tarjetas inteligentes o dispositivos similares, incluyendo elementos seguros, capa de aplicación. Esto cubre la aplicación de cartera que se ejecuta en el elemento seguro y es más directamente relevante para el fabricante de la cartera.
prEN 40000-1-2, prEN 40000-1-3, y prEN 40000-1-4, estándares horizontales que cubren principios de resiliencia cibernética, cumplimiento basado en riesgo, manejo de vulnerabilidades y requisitos genéricos de ciberseguridad.
En el momento de la escritura, estas normas no se han citado en el Diario Oficial de la Unión Europea como normas armonizadas de CRA. Por lo tanto, todavía no suponen una presunción de conformidad.
El siguiente paso es identificar el chip y su nivel de certificación Criterios Comunes, definir el límite preciso del producto, documentar el papel de la aplicación móvil. y el mapa de la funcionalidad principal del producto frente a las descripciones técnicas en la implementación del Reglamento (UE) 2025/2392.
Una vez que prEN 50764 y prEN 18330 son publicados, deben revisarse cuidadosamente sus secciones de alcance para determinar cómo se aplican al producto específico y cómo se dividen las responsabilidades entre la plataforma de elementos seguros y la aplicación que se ejecuta en él.
Si la clasificación sigue siendo incierta, el fabricante debería consultar a la autoridad competente de vigilancia del mercado o al organismo de evaluación de la conformidad antes de seleccionar una ruta de evaluación de la conformidad.
Pregunta 2: ¿Se sustituirá la EN 18031 por la EN 40000?
EN 18031 no debe ser visto como sustituido directamente por la EN 40000.
En virtud de la Directiva sobre equipos radiofónicos, el enfoque preferido para demostrar el cumplimiento de los requisitos de ciberseguridad en la letra d del apartado 3 del artículo 3), 3(3)(e), y 3(3)(f) aplicarán la serie armonizada EN 18031, teniendo en cuenta las restricciones incluidas en su Diario Oficial.
Desde el 11 de diciembre de 2027, los productos cubiertos por el CRA deberán cumplir con los requerimientos de Cybersecurity Esencial CRA y estándares de uso alineados o armonizados bajo la CRA.
EN 40000 es una serie estándar más amplia relacionada con la CRA con varias partes. Por ejemplo, EN 40000-1-3 se centra en el manejo de vulnerabilidades, mientras que otras partes abordan los procesos de cumplimiento basados en el riesgo y los requisitos genéricos de ciberseguridad.
Los requisitos de seguridad específicos del producto deben seguir seleccionándose en función de la evaluación y clasificación de riesgos del producto.
Por lo tanto, la EN 18031 puede seguir siendo evidencia técnica útil cuando sus requisitos sean relevantes. Sin embargo, la conformidad con CRA requerirá que el fabricante asigne los riesgos del producto y los requisitos esenciales de Cybersecurity de CRA contra las piezas aplicables EN 40000, normas específicas del producto u otras especificaciones técnicas justificadas.
Pregunta 3: Si tenemos varios dispositivos con la misma funcionalidad pero diferentes factores de formulario, como las tarjetas y los anillos, ¿necesitamos realizar los controles de cumplimiento dos veces?
Cada tipo de producto distinto, incluyendo cada factor de formulario, debe estar cubierto por la evaluación de la conformidad y la Declaración de conformidad de la UE. Para una tarjeta y un anillo, esto normalmente significará evaluar ambos tipos de productos.
Sin embargo, la cantidad práctica de trabajo repetido depende del módulo de evaluación de la conformidad seleccionado.
Módulo H, garantía de calidad completa
El módulo H puede ser la ruta más eficiente en esta situación.
El organismo notificado evalúa y certifica el sistema de gestión de calidad del fabricante que cubre los tipos de productos pertinentes. Añadir un nuevo factor de formulario puede ser tratado como una extensión del sistema de calidad existente, y no como una reevaluación completa desde el principio.
Módulo B más módulo C
Bajo el Módulo B más Módulo C, se puede requerir un certificado de examen de tipo UE separado para cada tipo de producto.
Sin embargo, los resultados de las pruebas, la documentación técnica y otras pruebas de la primera evaluación pueden reutilizarse cuando la tecnología subyacente es idéntica, incluyendo:
El elemento seguro
Firmware
Funciones criptográficas
Arquitecto de seguridad
Actualizar mecanismos
Donde la funcionalidad principal y la arquitectura de seguridad son iguales, la evaluación adicional debe centrarse en las diferencias introducidas por el factor formulario, como la interfaz física, la integración de hardware, la resistencia a manipulaciones y la superficie de ataque.
El módulo H puede ser la ruta más eficiente para los fabricantes que planean colocar múltiples variantes de productos relacionados en el mercado. El tratamiento de modelos individuales y tipos de producto debe confirmarse con el organismo notificado seleccionado.
Pregunta 4: ¿Una pasarela como una pasarela utilizada para controlar las luces de ZigBee sería considerada un producto por defecto o importante?
La clasificación requiere un análisis exhaustivo de la funcionalidad principal del producto basado en su documentación completa.
Esto incluye:
Propósito
Documentación técnica
Instrucciones para uso
Materiales promocionales
Implementación técnica real
El fabricante debe hacer esta determinación. Una clasificación no puede ser asumida de la palabra “pasarela” solamente.
De acuerdo con la prueba de "partidas completas" descrita en el borrador de guía CRA, la funcionalidad principal del producto debe coincidir plenamente con la descripción técnica de una categoría del Anexo III o del Anexo IV para calificar como Importante o Crítico.
Para una pasarela ZigBee cuya funcionalidad básica documentada es el control local de dispositivos inteligentes tales como luces de cambio o atenuación, dos categorías pueden aparecer inicialmente relevantes.
Enrutador
La descripción técnica de los enrutadores requiere que el producto establezca y controle el flujo de datos entre diferentes redes utilizando mecanismos y algoritmos de protocolo de enrutamiento en la capa de red.
Un puente de protocolo utilizado para el control de dispositivos puede no cumplir esta definición, pero el resultado debe ser verificado contra la implementación técnica real.
Productos inteligentes para el hogar con funcionalidad de seguridad
Esta categoría se aplica a productos domésticos inteligentes cuya funcionalidad principal está relacionada con la seguridad física de los consumidores, tales como cerraduras de puertas, cámaras y sistemas de alarma.
Normalmente, el control de luz no coincide completamente con esta descripción.
Si la funcionalidad principal del producto no coincide plenamente con ninguna descripción técnica del Anexo III o del Anexo IV, se mantendrá generalmente en la categoría Predeterminada.
Sin embargo, el resultado puede ser diferente si la documentación completa del producto muestra que el enrutamiento orientado a Internet o una función de seguridad explícita forma parte de su funcionalidad principal.
Pregunta 5: ¿Quién debe informar de incidentes a través de la Plataforma Única de Información, si una empresa está formada por varias fábricas que operan bajo la misma marca?
El informe no debe ser presentado por separado por cada fábrica.
Debería ser presentada por la empresa o fabricante legal responsable de colocar el producto en el mercado de la UE.
En la práctica, todas las fábricas deben informar internamente sobre cuestiones relevantes a un equipo central de seguridad de producto o CRA responsable.
Este equipo central debería:
Decide si el caso cumple con los requisitos de presentación de informes CRA
Recoge la información requerida
Prepara la notificación
Envíalo a través de la plataforma de reporte individual
Coordina cualquier comunicación requerida a los usuarios
Con fines informativos, la ubicación pertinente es normalmente el principal establecimiento del fabricante en la UE.
Esto significa generalmente el establecimiento donde se toman las principales decisiones de ciberseguridad relativas al producto. Si esto no se puede determinar, puede estar vinculado al establecimiento de la UE con el mayor número de empleados.
Por lo tanto, la empresa debería tener un propietario central de informes y un claro proceso de escalada interna que cubra todas las fábricas y sitios.
Pregunta 6: EN 18031 no explica cómo realizar la evaluación de riesgos ni proporcionar una plantilla.
La CRA no requiere que los fabricantes utilicen una metodología específica de evaluación de riesgos de ciberseguridad.
Los fabricantes pueden elegir su propio enfoque, siempre que les permita documentar:
Identificación de riesgo
Análisis y evaluación de riesgos
Tratamiento de riesgo
La relación entre los riesgos identificados y los requerimientos de ciberseguridad esencial de CRA
Las decisiones tomadas durante la evaluación
La evaluación de riesgos debe apoyar las obligaciones establecidas en el artículo 13 de la CRA y los requisitos de documentación técnica del anexo VII.
Las fuentes actuales de orientación incluyen:
Preguntas frecuentes sobre la implementación de la CRA de la Comisión Europea, en particular la sección que explica el ámbito de aplicación, los resultados y la documentación necesarios.
Guía de la Comisión sobre evaluación de riesgos y tratamiento de riesgos en la ciberseguridad
BSI TR-03183-1, que proporciona una metodología detallada de evaluación de riesgos paso a paso estructurada alrededor de los requisitos del Anexo I de la CRA
Se espera que la norma prEN 40000-1-2 de desarrollo proporcione un proceso de cumplimiento estructurado basado en el riesgo. Sin embargo, no debe tratarse como una plantilla obligatoria que se puede aplicar sin cambios a cada producto.
Pregunta 7: ¿El CRA se aplica a los productos que se conectan entre sí tales como alarmas de humo vinculadas, incluso si no se conectan a Internet o a una aplicación?
Sí, pueden entrar en el ámbito de CRA.
El CRA define un producto con elementos digitales como un producto cuyo propósito o uso razonablemente predecible incluye un producto directo o indirecto, conexión de datos lógicos o físicos a un dispositivo o red.
Por lo tanto, no se requiere una conexión a Internet o una aplicación móvil.
Las alarmas de humo vinculadas que intercambian datos directamente entre sí pueden cumplir esta definición porque tienen una conexión directa con otro dispositivo o red.
Si el producto es por defecto, importante o crítico, entonces debe evaluarse por separado basándose en su funcionalidad principal.
Pregunta 8. ¿Cómo afecta el CRA a los distribuidores que agregan valor instalando una imagen personalizada del sistema operativo Windows o Linux?
Instalar una imagen personalizada del sistema operativo probablemente requerirá que el distribuidor evalúe si ha asumido las obligaciones del fabricante bajo la CRA.
Hay dos situaciones principales en las que un distribuidor se convierte en un fabricante de conformidad con el artículo 21 de CRA.
El distribuidor pone el producto en el mercado bajo su propio nombre o marca.
El distribuidor realiza una modificación sustancial del producto.
Una modificación sustancial es un cambio que:
Afecta al cumplimiento de los requisitos esenciales de Cybersecurity de CRA, o
Cambia el propósito para el cual el producto fue evaluado originalmente
Una imagen personalizada del sistema operativo puede cambiar:
Configuraciones de seguridad
Componentes de software instalados o eliminados
Ajustes de seguridad por defecto
Servicios de red
Actualizar mecanismos
Permisos
Loggando
La superficie total de ataque
Estos cambios pueden afectar al cumplimiento de los requisitos esenciales de Cybersecurity Requirements CRA y, por lo tanto, pueden calificarse como una modificación sustancial.
Cuando la modificación es sustancial, el distribuidor se convierte en el fabricante del producto modificado y asume las obligaciones pertinentes de CRA.
Estos pueden incluir:
Evaluación del riesgo de ciberseguridad
Documentación técnica
Evaluación de conformidad
Marcación CE
Manejo de vulnerabilidades
Actualización de seguridad
Informes de incidentes y vulnerabilidades
El distribuidor no puede depender sólo del cumplimiento CRA de Microsoft, un distribuidor de Linux o del fabricante original de dispositivos. El cumplimiento debe ser evaluado y demostrado para el producto configurado final colocado en el mercado.
Pregunta 9. ¿Cómo se evalúan los sistemas de nube bajo el CRA si no utilizamos la infraestructura AWS, Azure o Google Cloud?
El proveedor de la nube no es el factor decisivo.
Lo que importa es si el procesamiento de nube o backend califica como una Solución de procesamiento de datos remotoso RDPS.
El CRA incluye un RDPS dentro de la definición de un producto con elementos digitales cuando se cumplen las siguientes condiciones:
Los datos se procesan a distancia, fuera del dispositivo del usuario o entorno local.
La solución de procesamiento fue diseñada o desarrollada por o bajo la responsabilidad del fabricante.
Sin ese procesamiento, el producto no podría realizar una de sus funciones.
Cuando se cumplan estas condiciones, el backend forma parte del producto con elementos digitales y debe cumplir con los requisitos aplicables del Anexo I de CRA.
Un RDPS no necesita funcionar en infraestructura pública de terceras partes en la nube.
El procesamiento remoto puede calificarse como RDPS cuando se ejecuta en:
Servidores propios del fabricante
Una nube privada
Infraestructura local
Infraestructura operada por otro proveedor
No usar AWS, Azure o Google Cloud no crea una exención.
Los servicios independientes SaaS, PaaS o IaaS diseñados y desarrollados independientemente de un producto específico generalmente quedan fuera de la definición del producto CRA. Otras leyes, incluido el NIS2, todavía pueden aplicarse a estos servicios.
Los fabricantes deben evaluar sus sistemas de backend con arreglo a los criterios de RDPS caso por caso. Cuando reúnan los requisitos, deben incluirse en el límite del producto, la evaluación de riesgos, la documentación técnica y la evaluación de la conformidad.
Pregunta 10. Los controladores multimedia de la industria del entretenimiento utilizan los puertos Wi-Fi y Ethernet para controlar los productos. El protocolo utilizado, Art-Net, es diferente del de Internet, ¿son productos dentro del ámbito de la ciberseguridad RED o de la CRA?
Para el CRA, el punto relevante es la definición de un producto con elementos digitales.
Un producto está dentro del alcance general de CRA cuando su propósito o uso razonablemente asequible incluye un directo o indirecto, conexión de datos lógicos o físicos a un dispositivo o red.
Por lo tanto, un controlador multimedia que se comunique a través de Wi-Fi o Ethernet puede estar dentro del ámbito de CRA, incluso si el protocolo de aplicación es Art-Net.
El nombre del protocolo específico no determina si el producto está en el ámbito de aplicación.
Para la ciberseguridad RED es necesaria una evaluación más detallada.
El fabricante debe evaluar si el equipo de radio puede comunicarse a través de Internet, ya sea directamente o a través de otros equipos.
El uso de Art-Net no coloca automáticamente el producto fuera del ámbito de la ciberseguridad RED. El fabricante debe revisar la arquitectura de conectividad completa, incluyendo pasarelas, enrutadores, sistemas de control remoto y cualquier posible acceso a Internet.
Pregunta 11. ¿Puede usted proporcionar orientación sobre la selección del período de soporte de seguridad correcto?
El período de apoyo por defecto en el marco de la CRA es de al menos cinco años.
Sin embargo, el fabricante también debe considerar la vida útil del producto.
Un período más corto puede justificarse cuando se espera que el producto se utilice durante menos de cinco años. Se requiere un período más largo en el que se espera que el producto permanezca en uso durante más tiempo.
El período de apoyo debe considerar:
El propósito previsto del producto
Su vida útil esperada
expectativas del usuario
El entorno en el que se utiliza
La disponibilidad de productos de reemplazo
Los períodos de soporte de los componentes incorporados
Dependencias en sistemas operativos, aplicaciones o servicios externos
Requisitos legales y contractuales relevantes
Los productos utilizados en tecnología operativa, sistemas industriales, infraestructura de construcción u otros entornos de larga duración pueden requerir un período de apoyo significativamente más largo que cinco años.
El período de apoyo seleccionado debe estar justificado en la evaluación de riesgos, documentada en la documentación técnica y comunicada a los usuarios.
Pregunta 12. ¿El CRA requiere un informe separado de la misma vulnerabilidad para diferentes dispositivos, como una tarjeta y un anillo disponible en varios colores?
Un informe puede cubrir la misma vulnerabilidad en todas las variantes de producto afectadas.
El Artículo 14 de CRA requiere que los fabricantes informen de vulnerabilidades explotadas activamente en un producto con elementos digitales. La notificación debe incluir información general sobre los productos en cuestión.
El CRA no requiere informes separados para cada:
Color
SKU
Factor de forma
Variante comercial
Si la misma vulnerabilidad afecta tanto a la tarjeta como al anillo porque comparten el mismo firmware, software, un elemento seguro, u otro componente vulnerable, una notificación que cubra todas las variantes afectadas es apropiada.
La notificación debe identificar claramente a todos los afectados:
Tipos de productos
Modelos
Versiones de hardware
Versiones de firmware o software
Si la tarjeta y el anillo utilizan diferentes implementaciones de seguridad o firmware y sólo una es afectada, los informes separados pueden ser apropiados porque los productos son técnicamente diferentes.
El fabricante debe enumerar explícitamente todas las variantes afectadas en la notificación. Esto permite que el mismo informe cubra toda la familia de productos afectados sin sumisiones duplicadas innecesarias.
Pregunta 13. ¿Es Cyberexperto una plataforma basada en la nube? ¿Utiliza una API pública, y cómo se garantiza la consistencia de sus producciones?
Sí. Ciberexperto es una plataforma SaaS basada en la nube.
Los usuarios acceden a ella a través de una interfaz web segura donde la información, las evaluaciones, los requisitos y las pruebas se gestionan de forma centralizada.
Esto permite equipos para:
Colaborar en actividades de cumplimiento
Rastrear progreso
Administrar evidencia de producto
Mantener un seguimiento de auditoría consistente
Cyberexpert está diseñado como una plataforma extensible en lugar de una aplicación de IA independiente.
Puede integrarse con servicios externos como:
Proveedores de identidad
Sistemas de gestión de vulnerabilidades
Repositorios de documentos
Plataformas de cumplimiento empresarial
La respuesta del experto confirma que las integraciones externas son soportadas. La disponibilidad de una API pública y opciones específicas de integración debe ser confirmada directamente con el equipo Cyberexpert.
La consistencia de las salidas se apoya a través de varias capas:
Flujo de trabajo estructurado
Lógica de evaluación determinista
Revisión de expertos humanos cuando sea necesario
Una base de conocimiento supervisada y controlada
Orquestación de IA estandarizada
Generación Aumentada de Recuperación usando fuentes controladas
El valor central de Cyberexperto proviene de su lógica de cumplimiento y de su flujo de trabajo estructurado. La IA ayuda en el proceso, pero los resultados se basan en fuentes controladas, información sobre productos y reglas de evaluación definidas.
Pregunta 14. ¿Una radio inteligente utilizada principalmente para la radio de Internet, Spotify, y la reproducción de los medios de comunicación cae dentro de la CRA?
Sí.
Una radio inteligente entra dentro del alcance de CRA porque su objetivo incluye una conexión directa a una red.
El dispositivo inicia y mantiene la comunicación IP bidireccional. Por ejemplo, envía peticiones de conexión y sesión y recibe datos de flujo de audio.
Esto constituye una conexión lógica directa a una red.
El hecho de que el objetivo principal del producto sea escuchar radio o reproducir los medios no lo elimina del ámbito general de la CRA.
Su clasificación como por defecto, importante, o el producto crítico debe evaluarse por separado en función de su funcionalidad básica y de las descripciones técnicas en el Reglamento de aplicación (UE) 2025/2392.
Donde el producto utiliza Wi-Fi, Bluetooth, u otra tecnología de radio también puede estar dentro de la Directiva de equipos de radio y requerir una evaluación de ciberseguridad RED separada.
Preparando el cumplimiento de RED y CRA
Los nombres de los productos y las etiquetas de conectividad no son suficientes para determinar las obligaciones RED o CRA.
Los fabricantes deben definir el límite del producto, documentar la funcionalidad principal del producto, identificar cada ruta de conectividad, determinar la categoría de producto aplicable y conectar cada conclusión de cumplimiento con la evidencia técnica.
Cyberexpert ayuda a los fabricantes a estructurar este trabajo, identificar los requisitos aplicables, preparar la evidencia y determinar dónde se necesita la revisión de expertos o la evaluación formal de la conformidad.
Compartir en
