En este artículo examinamos el borrador del estándar vertical EN 304 633, su alcance, sus requisitos y cómo utilizarlo para la conformidad con el CRA.
ETSI EN 304 633 es una norma de ciberseguridad específica para productos, actualmente en desarrollo, diseñada para facilitar el cumplimiento de la Ley de Ciberresiliencia (CRA) de la UE para los juguetes conectados a Internet. La norma se aplica a productos como juguetes de interacción social y juguetes con funcionalidades de localización, transformando las obligaciones generales de ciberseguridad de la CRA en requisitos técnicos prácticos y evaluables para los fabricantes.
A medida que la CRA avanza hacia su plena aplicación, los fabricantes que comercialicen juguetes conectados a Internet en el mercado europeo deberán demostrar que sus productos cumplen los requisitos esenciales de ciberseguridad a lo largo de todo su ciclo de vida. La EN 304 633 proporciona un marco estructurado para lograrlo, abordando aspectos como configuraciones seguras por defecto, controles parentales, gestión de vulnerabilidades, actualizaciones de software, protección de datos y evaluaciones de seguridad.
Aunque la norma aún está en desarrollo, ofrece una indicación temprana de cómo podrían aplicarse los requisitos de la CRA a los juguetes conectados a Internet y de cómo podrían estructurarse las futuras evaluaciones de conformidad. Esta guía explica el alcance, la estructura y los requisitos clave de la EN 304 633, ayudando a los fabricantes a comprender cómo encaja la norma dentro del marco general de cumplimiento de la CRA.
La ETSI EN 304 633 se aplica a dos categorías de juguetes conectados a Internet:
Juguetes de interacción social
Juguetes equipados con micrófonos, altavoces y cámaras que permiten comunicaciones bidireccionales.
Juguetes de localización
Juguetes que incorporan capacidades GPS o funcionalidades de seguimiento de ubicación.
Una característica diferencial de esta norma es su enfoque en la relación tutor-menor. A diferencia de los dispositivos IoT de propósito general, los juguetes inteligentes conectados deben implementar controles parentales que permitan a los tutores gestionar el acceso de los menores a la configuración de seguridad, a fuentes de contenido externas y a entidades de comunicación. Se trata de un requisito único que diferencia a la EN 304 633 de otras normas verticales.
Comprender la estructura del documento ayuda a navegar la norma de forma eficiente:
Capítulo 4
Contexto del producto y marco de niveles de impacto
Define cómo clasificar el entorno operativo del producto y determinar su nivel de impacto en cinco dimensiones: daño funcional, integridad, confidencialidad, disponibilidad temporal y pérdida de disponibilidad.
Capítulo 5
54 requisitos de seguridad agrupados en 12 categorías
Contiene los requisitos técnicos principales organizados por dominios funcionales. Es la sección donde se concentra el trabajo de implementación.
Capítulo 6
Criterios de evaluación
Define cómo se evalúa cada requisito, incluyendo objetivos de evaluación, preparación, actividades y asignación de resultados.
Anexo C
Definiciones de niveles de impacto
Proporciona criterios detallados para los niveles Bajo, Medio y Alto en las cinco dimensiones de impacto.
Anexo D
Taxonomía de activos de datos y funciones
Incluye activos previamente clasificados con sus niveles de impacto y proporciona un punto de partida para la evaluación del producto.
Anexo E
Tablas de intensidad de evaluación
Contiene siete tablas de referencia (tablas 2 a 8) que determinan la intensidad requerida de los controles de seguridad en función del nivel de impacto y de la superficie de ataque del producto.
Idea clave: Para los fabricantes de juguetes conectados a Internet, el Nivel de Impacto es el mecanismo central de la norma. La clasificación del producto en las cinco dimensiones determina directamente cuáles de los 54 requisitos son aplicables y con qué nivel de exigencia deben implementarse. Dedicar tiempo al Capítulo 4 y al Anexo C permite ahorrar un esfuerzo significativo en fases posteriores.
En lugar de enumerar los 54 requisitos de la ETSI EN 304 633, a continuación se presenta un resumen de las 12 categorías de requisitos y de sus principios fundamentales:
1. Vulnerabilidades explotables conocidas (NKEV)
5 requisitos. El producto no debe contener vulnerabilidades explotables conocidas en el momento de su comercialización y debe mantener capacidades seguras de actualización durante todo su ciclo de vida. Incluye gestión de vulnerabilidades, soporte de actualizaciones de software, actualizaciones automáticas, notificaciones de actualización y actualización de componentes esenciales.
2. Configuración segura por defecto (SDC)
5 requisitos. El producto debe ser seguro desde el primer uso. Incluye autenticación habilitada por defecto para funciones con potencial de daño, actualizaciones automáticas activadas por defecto, notificaciones de actualización activadas por defecto, capacidad de restauración a valores de fábrica y restricciones parentales configuradas por defecto.
3. Control de acceso y autenticación (ACM/AUM)
6 requisitos. Solo las entidades autorizadas deben poder acceder a funciones que puedan causar daños. Incluye control de acceso, soporte para controles parentales, intensidad de autenticación, principio de mínimo privilegio, permisos revocables y diferenciación de autorizaciones entre tutor y menor.
4. Protección de la integridad (INT)
2 requisitos. Evitar modificaciones no autorizadas del software y de los datos. Incluye verificación de paquetes de software (Tabla 4) y comunicaciones protegidas mediante mecanismos de integridad (Tabla 5).
5. Protección de la confidencialidad (CONF)
2 requisitos. Proteger los datos sensibles frente a accesos no autorizados. Incluye almacenamiento seguro (Tabla 6) y protección de las comunicaciones (Tabla 7).
6. Minimización de datos (DMIN)
1 requisito. Los datos confidenciales solo deben procesarse para la finalidad prevista y documentada. Es obligatorio justificar dicho tratamiento.
7. Protección de la disponibilidad (AVAI)
10 requisitos. Garantiza que las funciones críticas permanezcan operativas frente a fallos y escenarios de ataque. Incluye recuperación tras pérdida de alimentación, funcionamiento local durante interrupciones de red, reconexión, notificaciones de indisponibilidad, priorización de recursos, control de amplificación, limitación de tasa frente a ataques DoS y planificación de actualizaciones.
8. Limitación de la superficie de ataque (LAS)
6 requisitos. Minimiza las interfaces y aplicaciones expuestas. Incluye validación de entradas, saneamiento de datos de entrada, minimización de interfaces físicas y lógicas, minimización de aplicaciones y arranque seguro.
9. Registro y monitorización (LOG)
7 requisitos. Proporciona trazabilidad para la detección e investigación de eventos de seguridad. Incluye tres niveles de registro, marcas temporales, almacenamiento persistente y copias de seguridad automáticas.
10. Mecanismo de eliminación (DLM)
1 requisito. Debe permitir la eliminación permanente de los datos relacionados con el usuario, incluidos subconjuntos de datos, mediante un mecanismo fácil de utilizar.
11. Otros requisitos técnicos
9 requisitos. Garantizan una experiencia de usuario segura. Incluyen notificaciones sobre disponibilidad de funciones de seguridad, lenguaje claro para las notificaciones de seguridad, visualización de configuraciones de seguridad en la interfaz gráfica, criptografía de última generación, requisitos de longitud de claves y reglas de complejidad de contraseñas.
12. Gestión de vulnerabilidades
Hace referencia a la prEN 40000-1-3 para implementar un ciclo de vida completo de gestión de vulnerabilidades en seis etapas, descrito en la sección siguiente.
La ETSI EN 304 633 no redefine la gestión de vulnerabilidades. En su lugar, hace referencia a la prEN 40000-1-3 (CEN/CLC JT013090:2026) como especificación técnica para la gestión de vulnerabilidades. Esto constituye tanto un requisito de la norma como una obligación regulatoria directa derivada de la CRA con efecto a partir del 11 de septiembre de 2026.
El marco de trabajo de la prEN 40000-1-3 consta de seis etapas:
| Etapa | Actividades principales | Obligación |
|---|---|---|
| Preparación | Establecer la estrategia de gestión de vulnerabilidades, crear el equipo PSIRT y publicar los canales de notificación. | Debe completarse antes de septiembre de 2026. |
| Recepción | Proporcionar un mecanismo accesible para comunicar vulnerabilidades y confirmar la recepción en un plazo máximo de cinco días laborables. | Recibir informes procedentes de investigadores de seguridad de todo el mundo. |
| Verificación | Validar la explotabilidad y evaluar la puntuación de impacto CVSS. | Validación técnica de cada informe considerado válido. |
| Remediación | Desarrollar parches y realizar pruebas de verificación. | Proporcionar soluciones en un plazo razonable. |
| Publicación | Publicar avisos con identificadores CVE, distribuir parches y coordinar la divulgación. | Garantizar una divulgación transparente y oportuna. |
| Post-publicación | Supervisar la adopción de parches y actualizar la documentación. | Mejora continua. |
Conclusión clave: Si se cumple con la prEN 40000-1-3, se presume el cumplimiento tanto del requisito NKEV-MKAV de la EN 304 633 como de la obligación de notificación de vulnerabilidades establecida por la CRA. La creación de un equipo PSIRT y de un canal público de reporte de vulnerabilidades antes de septiembre de 2026 es obligatoria.
Si estas iniciando tu estrategia de cumplimiento con la EN 304 633, prioriza las siguientes tres acciones:
Acción 1: Completa la autoevaluación de niveles de impacto
Utiliza el Capítulo 4 y el Anexo C para clasificar tu producto en las cinco dimensiones de impacto. Este ejercicio determina qué requisitos de los 54 existentes son aplicables a tu producto y con qué nivel de intensidad deben implementarse. Una correcta clasificación desde el inicio evita tanto la sobreingeniería como la falta de implementación de requisitos aplicables.
Acción 2: Crea tu SBOM y documenta los mecanismos de actualización
Genera una Lista de Materiales de Software (SBOM) completa en formato SPDX o CycloneDX y documenta el mecanismo de actualización de cada componente software. Estos artefactos son requisitos previos para múltiples controles, incluidos NKEV-SUM-SUPPORT, NKEV-SUM-PROVIDE y NKEV-SUM-AUTO, y se encuentran entre las primeras evidencias que solicitará un Organismo Notificado.
Acción 3: Establece un equipo PSIRT y un canal público de reporte de vulnerabilidades
Con la fecha límite de septiembre de 2026 acercándose, esta es la acción más urgente. Necesitarás un equipo de respuesta a incidentes de seguridad de producto (PSIRT), una página pública para la recepción de vulnerabilidades y un proceso interno coordinado entre I+D, Seguridad, Legal y Comunicación.
Equipos de Producto e I+D
Impacto principal: deberán rediseñar los juguetes conectados a Internet para que sean seguros por defecto; los 54 requisitos influyen directamente en las decisiones de diseño del producto.
Acción requerida: integrar los requisitos de seguridad en las fases de diseño del producto y realizar la evaluación de niveles de impacto antes de congelar el desarrollo funcional.
Equipos de Seguridad
Impacto principal: deberán desarrollar capacidades de gestión de vulnerabilidades mediante un PSIRT y preparar la organización para futuras evaluaciones.
Acción requerida: establecer un PSIRT, preparar una SBOM, desarrollar políticas de gestión de vulnerabilidades y de divulgación coordinada de vulnerabilidades (CVD), y crear capacidades internas de ensayo.
Equipos Legales y de Compliance
Impacto principal: deberán seguir la evolución regulatoria y coordinar las actualizaciones de la norma.
Acción requerida: monitorizar ETSI y el Diario Oficial de la Unión Europea para detectar nuevas versiones de la norma y preparar las plantillas de Declaración UE de Conformidad.
Consumidores (Tutores)
Impacto principal: dispondrán de mayores garantías de privacidad y mejores controles parentales.
Resultado esperado: acceso a funcionalidades de seguridad mejoradas, incluidos controles parentales, notificaciones de seguridad más claras y opciones de eliminación de datos.
Para ilustrar cómo un requisito de la ETSI EN 304 633 se transforma en controles técnicos y evidencias verificables, consideremos el requisito NKEV-SUM-AUTO (Actualizaciones automáticas de seguridad):
| Elemento | Descripción |
|---|---|
| Requisito | “Cuando el juguete conectado a Internet tenga capacidad para conectarse a una red pública, deberá soportar la actualización automática de su software.” |
| Condición de aplicación | El producto se conecta a una red pública, por ejemplo mediante Wi-Fi y servicios cloud. |
| Implementación del control | Implementar un mecanismo automático de actualización que: (1) compruebe la existencia de nuevas versiones en el servidor de actualizaciones, (2) descargue automáticamente dichas actualizaciones, (3) instale las actualizaciones sin intervención del usuario, (4) verifique la integridad de las actualizaciones antes de instalarlas. |
| Evidencia de evaluación | Informe de ensayo que demuestre que: (1) el servidor de actualizaciones contenía una nueva versión, (2) el producto detectó, descargó e instaló automáticamente la actualización, (3) la versión del software cambió correctamente, (4) se registró el evento correspondiente en los logs. |
Nota: Este requisito está alineado con EN 18031-2 [SUM-3], lo que significa que, si ya se ha realizado una evaluación EN 18031, el resultado de dicho ensayo puede reutilizarse directamente como evidencia de cumplimiento para la EN 304 633.
Para los fabricantes que ya hayan completado, o tengan previsto completar, una evaluación EN 18031 en el marco de la Directiva RED, el nivel de reutilización de evidencias es el siguiente:
| Categoría de reutilización | Cantidad | Descripción |
|---|---|---|
| Reutilización eficiente | 15 | Los resultados obtenidos en EN 18031 satisfacen directamente los requisitos de EN 304 633 sin necesidad de ensayos adicionales. |
| Reutilización condicionada | 19 | EN 18031 cubre los requisitos base, pero se necesitan ensayos complementarios para demostrar requisitos adicionales de EN 304 633. |
| Nueva evaluación | 19 | EN 18031 no cubre estos requisitos, por lo que deben realizarse evaluaciones y ensayos independientes. |
| DLM-PERM | 1 | Requisito adicional incorporado como requisito número 54 y no contemplado en el análisis inicial de brechas. |
Los 19 requisitos clasificados como “Nueva evaluación” se concentran principalmente en el área de disponibilidad (10 requisitos) y en la configuración segura por defecto (3 requisitos). Estos son ámbitos en los que las normas verticales asociadas a la CRA van más allá del alcance cubierto por RED.
Applus+ utiliza cookies propias y de terceros para fines analíticos y para mostrarte publicidad personalizada en base a un perfil elaborado a partir de tus hábitos de navegación (por ejemplo, páginas visitadas). Puedes aceptar todas las cookies pulsando el botón “Aceptar” o configurarlas o rechazar su uso. Para más información, consulta nuestra Política de Cookies.
Permiten el funcionamiento de la web, cargar contenido multimedia y proteger su seguridad. Consulta las cookies que almacenamos en nuestra Política de cookies.
Nos permiten conocer cómo interactúas con la web, el número de visitas en las diferentes secciones y establecer estadísticas para mejorar nuestras prácticas comerciales. Consulta las cookies que almacenamos en nuestra Política de cookies.
A través de tu comportamiento en la web (dónde haces click, el tiempo que navegas, etc.) establecemos parámetros y un perfil para que visualices anuncios que se correspondan con tus intereses. Consulta las cookies que almacenamos en nuestra Política de cookies.