El Playbook Secure by Design de ENISA: qué significa para los equipos de producto bajo el CRA

¿Qué es el Playbook Secure by Design de ENISA?

El 19 de marzo de 2026, la Agencia de la Unión Europea para la Ciberseguridad (ENISA) publicó el Playbook de Seguridad por Diseño y por Defecto, versión 0.4, como borrador para consulta pública.

Es la primera guía oficial de la UE que traduce los requisitos de seguridad del CRA en checklists de ingeniería concretos orientados a pymes. El documento no constituye asesoramiento jurídico: proporciona enfoques técnicamente fundamentados que los equipos de producto pueden aplicar durante las fases de diseño, desarrollo y despliegue.

El playbook está dirigido a pymes (organizaciones con menos de 250 empleados y facturación anual inferior a 50 millones de euros) que fabriquen productos con elementos digitales. Esto incluye software embebido, dispositivos IoT, sistemas conectados, software independiente y hardware con componentes programables.

ENISA desarrolló el playbook a partir del análisis de marcos de seguridad existentes publicados por ENISA y otras agencias de ciberseguridad europeas, así como de las guías del NIST y OWASP. Se identificaron requisitos comunes y patrones de implementación, y se evaluaron frente a las capacidades de las pymes para determinar su viabilidad y las adaptaciones necesarias.

El Anexo C del playbook mapea los 22 principios directamente con los requisitos esenciales del Anexo I del CRA, estableciendo una correspondencia trazable entre las prácticas de ingeniería y las obligaciones regulatorias.

¿A quién va dirigido este playbook?

El playbook identifica cuatro grupos principales (sección 1.3):

• Desarrolladores e ingenieros de software: personas que escriben código y necesitan formas prácticas de incorporar seguridad sin ralentizar la entrega
• Technical Product Managers: personas que equilibran el trabajo de funcionalidades con los requisitos de seguridad y tratan de que ambos encajen
• Responsables de seguridad en pymes: personas que traducen marcos empresariales a algo que funcione con presupuestos limitados y equipos pequeños
• Arquitectos de sistemas: personas que diseñan sistemas y quieren que la seguridad esté integrada desde el principio, no añadida a posteriori

El reto común que ENISA reconoce: la mayoría de las pymes no tienen un equipo de seguridad dedicado, el presupuesto para herramientas de seguridad es limitado y el trabajo de seguridad compite constantemente con la entrega de funcionalidades.

La respuesta del playbook: checklists estructurados que ayudan a los equipos a identificar controles de seguridad de alto impacto inmediato, implementarlos de forma realista y construir una base repetible que puedan mejorar con el tiempo.

Seguridad a lo largo del ciclo de vida del producto

La seguridad debe considerarse de extremo a extremo, independientemente del modelo de producción utilizado (modelo en V, Agile u otro). El playbook define seis fases, cada una con acciones de seguridad específicas y entregables concretos.

Principios clave del documento:

• Usar artefactos pequeños y reutilizables (notas de contexto de una página, diagramas sencillos, checklists)
• Preferir controles automatizados en CI/CD sobre revisiones manuales, reservando la revisión en profundidad para cambios de alto riesgo
• Incorporar gates de seguridad rápidos alineados con las ceremonias ágiles existentes (Definition of Ready/Done, comprobaciones en PR, checklist de publicación)

Cada fase produce un entregable concreto. No es una guía abstracta.

¿Qué actividades de gestión de riesgos recomienda ENISA?

Las actividades de gestión de riesgos son la base de todas las decisiones de Seguridad por Diseño y por Defecto. El playbook no propone un marco formal pesado. En su lugar, define un conjunto mínimo de actividades que permiten tomar decisiones de seguridad sin crear procesos complejos (sección 2.2).

El documento define 8 actividades (Tabla 2):

1. Contexto y alcance del producto: Definir el uso previsto, los entornos de despliegue, los roles de usuario y administrador, los tipos y la sensibilidad de los datos, y las dependencias externas clave. Entregable: nota de "Contexto de Seguridad del Producto" de 1-2 páginas (alcance, supuestos, dependencias).
2. Identificación de activos y daños: Listar los principales activos de datos, hardware o funciones (credenciales, datos de clientes, PII, control de dispositivos) y los daños potenciales clave (violación de privacidad, toma de control, interrupción del servicio, fraude, impacto en la seguridad física). Entregable: Lista de activos + lista de "Daños principales" (una página).
3. Modelado de amenazas ligero: Véase la sección modelado de amenazas más adelante.
4. Registro de riesgos: Registrar 10-30 riesgos con probabilidad e impacto (escala sencilla), responsable, tratamiento y estado. Vincular los riesgos altos a elementos del backlog o controles. Entregable: Registro de riesgos dinámico (hoja de cálculo o tablero de tareas).
5. Criterios de aceptación de riesgos: Definir un conjunto de condiciones de riesgo no negociables. Por ejemplo: el uso indebido de actualizaciones de software, el acceso administrativo no autorizado o la explotación de credenciales predeterminadas NO son aceptables. Establecer criterios para aceptar riesgos residuales que no deban comprometer los requisitos esenciales de ciberseguridad. Entregable: Política de Aceptación y Excepciones de Riesgos de 1 página.
6. Línea base de requisitos de seguridad: Traducir los riesgos principales en requisitos "obligatorios" comprobables (autenticación/autorización, valores predeterminados seguros, secretos, cifrado, logging, actualizaciones). Entregable: Checklist de requisitos de seguridad para pymes (controles verificables).
7. Gate de revisión de riesgos previo a la publicación: Gate formal antes de cada publicación: confirmar que el checklist se ha cumplido, que los valores predeterminados se han verificado, que las vulnerabilidades conocidas han sido tratadas y que los riesgos altos se han mitigado o aceptado con justificación documentada. Decidir si publicar o no. Entregable: Registro de revisión de seguridad de publicación + excepciones documentadas.
8. Reevaluación ante cambios: Repetir los pasos de contexto, amenazas y riesgos cuando se produzcan cambios importantes (arquitectura, modelo de autenticación, dependencia o proveedor crítico, entorno de despliegue, tras incidentes). Entregable: Nota de contexto actualizada, lista corta de amenazas y entradas del registro de riesgos (con fecha).

¿Cómo deben abordar el modelado de amenazas las pymes?

El playbook se basa en la metodología STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) como fundamento para la identificación y clasificación de amenazas (sección 2.3).

El documento advierte explícitamente contra los antipatrones más comunes: tratar el modelado de amenazas como un ejercicio de cumplimiento puntual, construir modelos sobredimensionados que no influyen en el diseño ni en las decisiones de configuración segura por defecto, y no revisar el modelo tras modificaciones sustanciales del producto o cambios en el panorama de amenazas.

Para las pymes, especialmente las que desarrollan productos para entornos de riesgo no crítico o reducido, el objetivo es un modelo "mínimamente viable": rápido de producir, fácil de actualizar y estrechamente ligado a la entrega (decisiones de arquitectura, configuración por defecto y gates de publicación).

Los 5 pasos (Tabla 3)

1. Definir alcance, supuestos y objetivos de seguridad: Acotar el paso de definición de alcance en el tiempo. Capturar qué está dentro y fuera del alcance, el contexto de despliegue y los supuestos en los que se confía (por ejemplo, "la red del cliente no es de confianza", "las APIs en la nube están expuestas a Internet"). Declarar los objetivos de seguridad relevantes para este producto (confidencialidad, integridad, disponibilidad, más privacidad y seguridad física si aplica). Identificar las "joyas de la corona": qué no puede fallar. Entregable: "Alcance y Objetivos del Modelo de Amenazas" de 1 página.

2. Modelar el sistema con el nivel de abstracción adecuado: Producir un único diagrama de arquitectura o de flujo de datos, sencillo. Mostrar los componentes principales, entidades externas, almacenes de datos y los puntos de entrada y flujos de datos clave. Un diagrama estilo DFD es el enfoque más rápido y de mayor valor. El documento dice "no darle demasiadas vueltas". Entregable: Diagrama con los componentes principales, entidades externas, almacenes de datos y puntos de entrada.

3. Marcar límites de confianza y rutas privilegiadas; identificar activos clave: Anotar el diagrama con los límites de confianza (Internet-backend, dispositivo-nube, usuario-administrador, inquilino-inquilino) y las operaciones de mayor privilegio (actualización de firmware/OTA, administración remota, aprovisionamiento de claves, emisión de identidades). Este paso convierte una "arquitectura" en una "arquitectura relevante para la seguridad". Entregable: Diagrama con límites de confianza, rutas privilegiadas y activos principales.

4. Identificar y priorizar las principales amenazas (5-10 casos de abuso): Generar una lista corta de casos de abuso realistas mapeados a puntos de entrada y límites (por ejemplo, "credential stuffing -> toma de cuenta", "actualización maliciosa", "bypass de autorización en API", "MITM en el onboarding"). Clasificarlos con un esquema ligero (Alto/Medio/Bajo) según el impacto y la plausibilidad. OWASP describe la identificación y clasificación de amenazas como un paso central en la mayoría de los enfoques de modelado de amenazas. Entregable: Tabla de principales amenazas con 5-10 casos de abuso, impacto + probabilidad, lista de "riesgos principales".

5. Definir mitigaciones, valores predeterminados seguros y verificación; establecer triggers de actualización: Para cada amenaza principal, especificar la estrategia de mitigación, el control o controles necesarios y el valor predeterminado seguro que debe salir en producción (por ejemplo, "interfaz de administración deshabilitada por defecto", "sin contraseñas predeterminadas", "actualizaciones con firma obligatoria", "roles con mínimo privilegio", "intentos de autenticación con limitación de tasa"). Mapear cada control a un método de verificación (comprobaciones de CI, pruebas, validación de configuración, gate de publicación). Definir los triggers que requieren repetir el modelado (nueva interfaz expuesta a Internet, cambio en el modelo de autenticación, nuevos datos sensibles, nueva dependencia crítica, cambio arquitectónico mayor). Entregable: Checklist de Controles, Valores Predeterminados y Verificación.

¿Cuáles son los 22 principios de seguridad?

El documento define 22 principios de seguridad (sección 3), cada uno con su propio playbook de una página en la sección 4. Los playbooks son el entregable central del documento. Cada uno destila un único principio en una guía orientada a la ejecución con checklist, evidencia mínima y criterios de gate de publicación. Los principios se organizan en dos pilares: Secure by Design (cómo se diseña el sistema, 14 principios) y Secure by Default (cómo llega el producto y cómo se comporta al encenderse por primera vez, 8 principios). Cada pilar se divide a su vez en dos grupos.

Fundamentos Arquitectónicos (6 principios)

Tratan sobre cómo se diseña y construye el sistema de forma estructural:

1. Límites de confianza y modelado de amenazas: Hacer explícita la confianza. Definir dónde cruzan datos, identidades y contextos de ejecución de zonas de confianza a no confianza. Modelar amenazas para identificar qué puede salir mal en esos límites.
2. Mínimo privilegio: Conceder únicamente el acceso mínimo necesario. Aplicar de forma consistente en cuentas de usuario, cuentas de servicio, APIs y roles de administración. Elevar privilegios solo cuando sea necesario, durante el menor tiempo posible.
3. Arquitectura de identidad y autenticación robusta: Enfoque claro sobre cómo se crean, verifican y gestionan las identidades de usuarios, dispositivos, servicios y administradores. Resistente a credential stuffing, replay y secuestro de sesión.
4. Minimización de la superficie de ataque: Reducir la complejidad. Eliminar cuentas predeterminadas, desinstalar paquetes no utilizados, cerrar puertos no esenciales, limitar las interfaces de gestión expuestas. Análisis de vulnerabilidades continuo.
5. Defensa en profundidad: Controles en capas para que el fallo de uno no implique un compromiso total. Controles preventivos, detectivos y correctivos. Diversos e independientes, sin depender todos de la misma tecnología o supuesto de confianza.
6. Diseño abierto (evitar la oscuridad): No depender del secreto del diseño para la protección. Usar algoritmos y protocolos bien estudiados, documentación clara y diseños que soporten el escrutinio. La seguridad debe basarse en claves protegidas, autenticación robusta e implementación sólida, no en mecanismos ocultos.

Integridad Operacional (8 principios)

Tratan sobre cómo se gestiona y mantiene el sistema:

1. Gestión del ciclo de vida: La seguridad va más allá del desarrollo. Mantener, actualizar y retirar de forma controlada. Aplicar Secure by Design desde el desarrollo hasta la retirada del servicio.
2. Diseño centrado en el usuario: La seguridad debe ser usable por usuarios cotidianos. La mala usabilidad lleva a soluciones alternativas inseguras. Configuración simple, cifrado automático, flujos guiados.
3. Prácticas de codificación segura: Seguir estándares de codificación segura establecidos. Herramientas SAST, SCA para dependencias, DAST antes del despliegue. Identificación temprana, no después de la publicación.
4. Logging, monitorización y alertas: Generar logs relevantes para la seguridad, conservarlos durante un período definido y protegerlos frente a manipulaciones. Detectar comportamientos sospechosos (autenticaciones fallidas, escalada de privilegios, cambios de configuración inesperados).
5. Gestión de configuración y cambios: Las configuraciones deben ser controladas, coherentes y auditables. Hardening de la línea base, infraestructura como código, proceso de cambios con revisión, pruebas, aprobación y rollback.
6. Respuesta a incidentes y recuperación: Preparado para vulnerabilidades, código comprometido, actualizaciones maliciosas y uso indebido del producto. Roles definidos, rutas de escalada, playbooks documentados, comunicación con clientes.
7. Gestión de vulnerabilidades y parches: Práctica, repetible y priorizada por riesgo. Canal de entrada sencillo (correo de seguridad + proceso de divulgación), proceso interno de triaje, SLAs claros.
8. Controles de cadena de suministro: Proteger la integridad del producto en los puntos de mayor impacto: repositorios de código, sistemas de build, claves de firma, canales de distribución. Como mínimo: acceso limitado a CI/CD, MFA, revisión por pares para cambios críticos de seguridad, SBOMs.

Hardening por Defecto (4 principios)

Garantizan que los productos arranquen en un estado seguro y restrictivo:

1. Minimización de servicios predeterminados: Funcionalidades y servicios no esenciales deshabilitados por defecto. El usuario debe habilitarlos explícitamente.
2. Acceso inicial restrictivo: Eliminar las credenciales universales "admin/admin". Exigir contraseñas únicas y cambio obligatorio de contraseña en el primer arranque.
3. Comunicación segura por defecto: Todas las comunicaciones externas cifradas y autenticadas desde la primera conexión. Aplicar estrictamente TLS 1.3 o SSH. Sin fallback a HTTP/Telnet.
4. Identidad de dispositivo y secretos únicos por defecto: Entregar con credenciales e identidad criptográfica únicas por dispositivo. Sin claves ni certificados compartidos entre productos. Protegidos frente a extracción.

Protección Guiada (4 principios)

Apoyan a los usuarios para mantener la seguridad después del despliegue:

1. Onboarding de seguridad obligatorio: Las funcionalidades de seguridad críticas deben formar parte del asistente de configuración inicial (MFA, clave de cifrado, configuración de cuenta de administrador). No ocultarlas en los ajustes. Bloquear el funcionamiento hasta que se completen.
2. Mantenimiento y actualizaciones automatizados: Actualizaciones de seguridad automáticas habilitadas por defecto. Separar las actualizaciones de seguridad de las de funcionalidades. Verificadas criptográficamente. Modos de fallo seguros (sin dejar el dispositivo inutilizable). Notificar a los usuarios.
3. Postura de seguridad transparente: Mostrar claramente el estado de seguridad actual. Avisar cuando el usuario reduzca la seguridad. Explicar el impacto en lenguaje claro. Ofrecer un camino con un clic para restaurar la línea base segura.
4. Recuperación segura y ciclo de vida de la propiedad: Recuperación guiada (restablecimiento de credenciales, recuperación de cuenta, restablecimiento de fábrica, transferencia de propiedad). Simple para los usuarios pero resistente a la toma de cuentas e ingeniería social. El restablecimiento de fábrica debe eliminar completamente el acceso del usuario anterior.

Enlace con el CRA: El Anexo C del playbook mapea cada uno de estos 22 principios con los requisitos esenciales específicos del Anexo I del CRA, mostrando exactamente qué prácticas de ingeniería respaldan qué obligaciones legales.

¿Cómo funcionan los playbooks?

El formato del playbook

La sección 4 es la parte más extensa del documento. Ofrece una forma práctica y ligera para que las pymes implementen la Seguridad por Diseño y por Defecto sin crear una carga de gobernanza pesada. Cada playbook destila un único principio de seguridad en una guía de una página orientada a la ejecución que los equipos pueden aplicar repetidamente en distintas publicaciones y líneas de producto (sección 4, p28).

La intención es traducir los principios de seguridad de aspiraciones abstractas en acciones concretas de ingeniería y operación, con expectativas claras, resultados verificables y una "definición de hecho" consistente para la seguridad. Cada playbook sigue el mismo formato de cinco secciones:

• Nombre del principio: El concepto de seguridad que se implementa
• Objetivo: Lo que el principio persigue conseguir y los modos de fallo que reduce
• Checklist: Las acciones de mayor impacto a implementar (diseñadas para ser alcanzables por equipos reducidos)
• Evidencia mínima: El conjunto más pequeño de artefactos, logs o configuraciones que demuestran que el checklist se ha implementado
• Gate de publicación: Un conjunto de criterios pasa/falla listo para copiar y pegar, que puede usarse en una revisión de publicación o en CI/CD para prevenir regresiones

Uso de los playbooks

• Tratar el gate de publicación de cada playbook como un punto estándar del orden del día en las revisiones de preparación para la publicación
• Implementar la evidencia mínima como artefactos del repositorio y salidas de CI siempre que sea posible
• Permitir excepciones solo con justificación documentada, responsable y fecha de revisión
• Actualizar los playbooks periódicamente en función de las lecciones aprendidas de incidentes, tendencias de vulnerabilidades y cambios en el producto
• El contenido debe tratarse como una línea base, no como un estado final. Revisar y actualizar a medida que los productos evolucionen.

Los 22 playbooks de un vistazo

Fundamentos Arquitectónicos:

Integridad Operacional:

Hardening por Defecto:

Protección Guiada:

En detalle: Playbook 4.13, Gestión de vulnerabilidades y parches

Para mostrar la profundidad práctica del formato, se presenta a continuación el Playbook 4.13 en su totalidad, tal como aparece en el documento:

Principio: La gestión de vulnerabilidades y parches debe ser práctica, repetible y priorizada por riesgo. Los fabricantes necesitan una forma sencilla para que clientes e investigadores puedan reportar problemas, y un proceso interno para triar los hallazgos rápidamente y decidir qué requiere acción urgente.

Objetivo: Identificar, priorizar y remediar vulnerabilidades con la rapidez suficiente para reducir la exposición real, en el código, las dependencias, la infraestructura y (si aplica) los dispositivos y el firmware. El foco está en un flujo de trabajo sencillo desde la entrada hasta la corrección, con SLAs claros y un mecanismo de actualización que haga que el parcheo sea fiable.

Checklist:

Evidencia mínima:

• Tablero o registro de seguimiento de vulnerabilidades: problema, severidad, componentes y versiones afectados, responsable, estado, fecha objetivo
• SLAs definidos (ejemplo): triaje de críticas en 48 horas; objetivo de remediación y publicación en X días (ajustado a la realidad)
• Evidencia de análisis: salidas de CI para análisis de dependencias y SAST (y DAST si aplica)
• Parches proactivos de dependencias: SBOM o inventario de dependencias por publicación (como mínimo para los artefactos entregados)
• Registro de publicación de parches: enlace desde el ticket de vulnerabilidad hasta las PR, las pruebas, la versión publicada y la confirmación del despliegue
• Registro de excepciones: los riesgos aceptados tienen responsable, fecha de caducidad o revisión y controles compensatorios (si los hay)

Gate de publicación:

• Análisis de dependencias y SAST ejecutados para la publicación; hallazgos Críticos y Altos resueltos o con excepción documentada (responsable y caducidad)
• SBOM (o inventario de dependencias) generado o actualizado y almacenado para la publicación
• Las vulnerabilidades conocidas que afectan a los componentes entregados tienen triaje con severidad, responsable y fecha objetivo
• Proceso de parcheo validado: corrección revisada, pruebas superadas y notas de versión actualizadas si es necesario
• Para componentes expuestos a Internet: mitigaciones o parches para Críticos y Altos en vigor antes de la publicación
• OTA o actualización (si aplica) validada para entrega segura; rollback y recuperación documentados
• El riesgo residual aceptado está acotado en el tiempo y con seguimiento hasta el cierre o la fecha de revisión

¿Qué son los Machine-Readable Security Manifests?

La sección 5 del playbook introduce un nuevo concepto: el paso de un cumplimiento estático basado en documentos a atestaciones de seguridad verificables y legibles por máquinas.

Una atestación de seguridad legible por máquinas es una declaración digital en JSON o YAML que afirma que un control de seguridad, proceso o propiedad específico se ha cumplido. A diferencia de los informes PDF estáticos, estas atestaciones pueden ser generadas y consumidas por sistemas automatizados, lo que permite actualizaciones frecuentes y validación automatizada. Al integrarse en el pipeline de desarrollo, la seguridad se vuelve intrínseca, no una casilla que marcar después del desarrollo.

Cuatro propiedades clave

• Demostrabilidad: Capacidad proactiva de proporcionar evidencia legible por máquinas de que los requisitos de seguridad se han implementado, un cambio de "afirmar" a "demostrar"
• Verificabilidad: Una parte independiente puede autenticar y validar programáticamente la integridad de las afirmaciones de seguridad, de forma transparente, a prueba de manipulaciones y mapeada a una raíz de confianza reconocida
• Reutilizabilidad: Usar las atestaciones existentes para construir sobre ellas, integrarlas en el ciclo de desarrollo e incluirlas en los quality gates ágiles
• Fiabilidad: Confiar en las atestaciones para la debida diligencia de terceros, simplificando la confianza en la cadena de suministro

El modelo de cuatro capas

El playbook ilustra un modelo de datos jerárquico en el que cada declaración de seguridad de alto nivel está respaldada por evidencia técnica granular:

1. Metadatos y atestación (dominio de identidad): Identidad del producto, versionado, firma criptográfica del fabricante
2. Capa de control (dominio de gobernanza): Objetivos de seguridad estructurados alineados con requisitos, principios y regulaciones
3. Capa de implementación / Mapa de amenazas y mitigaciones (dominio operacional): Mapea amenazas específicas a mitigaciones implementadas, principios de diseño, configuraciones predeterminadas y descripciones legibles por personas
4. Capa de evaluación y verificación (dominio de evidencia): Resultados de pasa/falla legibles por máquinas de los gates automatizados, con enlaces a SBOMs

El documento también describe capas de control de acceso: un JSON público que proporciona declaraciones de alto nivel y una capa técnica restringida que contiene configuraciones detalladas cifradas de las herramientas y telemetría de pruebas.

El ecosistema existente

El playbook sitúa los MRSM dentro del panorama de estándares existente:

• OSCAL (NIST): "Compliance as Code", catálogos de controles de seguridad estandarizados, planes de seguridad del sistema, resultados de evaluaciones
• CycloneDX CDXA (OWASP/ECMA-424): Originalmente un formato SBOM, ampliado a un estándar de transparencia completo. Atestaciones CDXA para declaraciones de seguridad, VEX para explotabilidad, CBOM para activos criptográficos
• OpenSSF: Security Insights (datos de seguridad legibles por máquinas en YAML), Scorecard (evaluación automatizada de buenas prácticas)
• OWASP ASVS: Application Security Verification Standard, requisitos subyacentes. MLSVS extendiéndose a IA y ML
• TC54 (Ecma International): Transparency Exchange API, estandarizando cómo se descubren y comparten SBOMs y atestaciones

El caso práctico SafeGate-X1

El documento incluye un escenario completo (páginas 56-61) que muestra cómo un fabricante ficticio de controladores de hardware implementaría los MRSM: un modelo de amenazas con 5 amenazas (RCE vía API web, escalada de privilegios, escaneo de puertos, credential stuffing, manipulación de binarios), controles mapeados a principios y un manifiesto JSON que muestra cómo cada threat_id se mapea a un principio, mitigation_control, secure_by_default_setting y verification_gate con evidence_hash. También incluye una tabla de verificación de terceros que muestra qué pueden comprobar los auditores.

¿Cómo se mapean los principios con los requisitos del CRA?

El Anexo C del playbook proporciona un mapeo completo de los 22 principios con los requisitos esenciales específicos del Anexo I del CRA. Este es el puente de ingeniería entre la guía del playbook y las obligaciones legales.

El Anexo I del CRA se divide en dos partes:

• Parte 1 (ANNEX-1.PT1): Requisitos de seguridad del producto, que cubren 14 requisitos: evaluación de riesgos de ciberseguridad, valores predeterminados seguros, actualizaciones, control de acceso, protección de datos, integridad, minimización de datos, disponibilidad, limitación de la superficie de ataque, mitigación de incidentes, logging y borrado seguro de datos
• Parte 2 (ANNEX-1.PT2): Requisitos de gestión de vulnerabilidades, que cubren 8 requisitos: SBOM, remediación oportuna, pruebas, divulgación, VDP coordinada, recepción de vulnerabilidades, distribución segura de correcciones y divulgación oportuna

Cada principio se mapea con múltiples requisitos del CRA. A continuación se presentan ejemplos seleccionados del Anexo C:

Enlace con el CRA: El playbook no es un checklist de cumplimiento legal, pero proporciona el puente de ingeniería hacia el Anexo I del CRA. Si se puede demostrar la adherencia a estos 22 principios, se cuenta con evidencia sustancial que respalda la evaluación de conformidad del CRA.

¿Cuáles son los siguientes pasos?

1. Empezar por la sección 2: Identificar la fase actual del ciclo de vida y producir los entregables de la Tabla 1. Incluso una nota de Contexto de Seguridad de una página y un diagrama de arquitectura básico sitúa al equipo por delante de la mayoría.

2. Recorrer las 8 actividades de gestión de riesgos (Tabla 2): La mayoría de las pymes pueden producir los resultados en 1-2 días de trabajo enfocado. Comenzar con el contexto del producto, la identificación de activos y daños, y los criterios de aceptación de riesgos.

3. Realizar un modelado de amenazas ligero (Tabla 3): Incluso 2 horas con el equipo, usando una pizarra y STRIDE, producen resultados accionables. Centrarse en los 5-10 casos de abuso más importantes.

4. Seleccionar los 3-5 playbooks más relevantes para la próxima publicación y usar los checklists. Puntos de partida habituales: 4.9 (Codificación segura), 4.13 (Gestión de vulnerabilidades), 4.2 (Mínimo privilegio), 4.16 (Acceso inicial restrictivo).

5. Usar los criterios del gate de publicación como orden del día de la revisión de seguridad previa a la publicación. Este es el camino más rápido de "sin proceso de revisión de seguridad" a "gates de seguridad documentados y repetibles".

6. Descargar el playbook completo de ENISA: Se trata de un borrador v0.4. Enviar los comentarios durante el período de consulta.

Fuentes oficiales

• Playbook de Seguridad por Diseño y por Defecto de ENISA v0.4 (PDF)

Guías relacionadas

• CRA Product Classification Guide
• SBOM Requirements Under the CRA
• CRA Technical File (Annex VII) Guide
• CRA Vulnerability Reporting: The 24-Hour Rule
• CRA Conformity Assessment Decision Guide

Este artículo tiene fines informativos y no constituye asesoramiento jurídico. Para orientación específica sobre cumplimiento normativo, consulte con asesores legales cualificados.