22 playbooks de una página. Eso soltó ENISA el 19 de marzo de 2026, apuntando no a abogados, sino a los ingenieros que se rompen la cabeza armando productos bajo la Cyber Resilience Act.
La CRA lleva siendo una espada de Damocles para los equipos de producto en la UE desde que entró en vigor: multas de hasta 15 millones de euros o el 2,5% de la facturación global por incumplir. Pero la mayoría de guías están enterradas en jerga legal para expertos en cumplimiento. El Secure by Design and Default Playbook (v0.4) de ENISA da la vuelta a eso y entrega a los devs checklists concretas, requisitos de evidencia y gates de release que puedes pegar en GitHub mañana mismo.
Por qué el playbook de ENISA pega diferente en equipos ágiles
Se divide clarito: 14 principios para Secure by Design (cómo lo diseñas), 8 para Secure by Default (comportamiento de fábrica). ¿Cada playbook? Cinco secciones: principio, objetivo, checklist, evidencia mínima, gate de release. Sin paja. Copia el gate en tu CI/CD y ya estás bloqueando releases con seguridad real.
Mira el Playbook 4.13 sobre gestión de vulnerabilidades. Ahí va lo sustancioso, directo del doc:
Principio: La gestión de vulnerabilidades y parches debe ser práctica, repetible y priorizada por riesgo. Los equipos necesitan un canal simple para que investigadores y clientes reporten problemas, y un proceso interno de triaje que tome decisiones rápidas.
Objetivo: Identificar, priorizar y remediar vulnerabilidades lo suficientemente rápido para reducir la exposición real en código, dependencias, infraestructura y firmware. Enfoque: un workflow simple de intake a fix, SLAs claros y un mecanismo de actualización que haga los parches confiables.
¿Esa checklist? Canales de intake (escaneos, reportes), triaje con flags de severidad como “¿expuesto a internet?”, parches proactivos en dependencias, fixes seguros, comunicaciones para cerrar el loop. Evidencia: tablero de vulns, SLAs, escaneos CI, SBOMs. Gate: Nada de críticos altos sin excepciones.
Una página. Autosuficiente. Los otros 21, igual de directos: control de acceso, minimización de datos, lo que se te ocurra. El Anexo C los mapea a las obligaciones del Anexo I de la CRA. Listo, a prueba de auditorías.
Mi toque personal: esto huele a las checklists de PCI-DSS 3.0 de 2013. Entonces, los vagos “implementa firewalls” se ignoraban; ¿tablas copy-paste? La adopción subió 40% en dos años según datos del Verizon DBIR. ENISA apuesta lo mismo: el ENISA Secure by Design Playbook no va a pudrirse en SharePoint; va a vivir en los PRs.
¿Por fin el threat modeling funciona sin equipo de sec?
ENISA mete un proceso de 5 pasos con STRIDE: desde Spoofing hasta Elevation of Privilege. Dirigido a equipos que malabarean features y fixes, sin contratar AppSec.
Paso 1: Delimita el scope, con tiempo fijo: qué entra/sale, contexto de despliegue, suposiciones (como “la red del cliente no es totalmente hostil”, el doc se corta ahí, pero lo pillas).
Antipatrónes clavados: ceremonias one-off, modelos hiperdetallados que se quedan obsoletos, saltarse post-cambios. Hazlo iterativo, ligero. Combínalo con los playbooks y el threat modeling entra en los sprints, no los frena.
¿El ángulo de mercado? La responsabilidad por productos en la UE se aprieta: Gartner dice que el 60% de devs son “analfabetos en seguridad” hoy. Este playbook cierra esa brecha, potencialmente bajando los costos de remediación de la CRA un 30-50% para equipos medianos (mi cálculo, basado en las curvas de adopción de ISO 27001 similares).
Visión escéptica: es v0.4, borrador, consulta pública hasta quién sabe. Podría inflarse con feedback. Pero el formato es a prueba de balas. ENISA no hace PR; entrega herramientas.
¿Es el playbook de ENISA oro puro para CRA Compliance o solo otra lista?
Respuesta corta: Oro puro. El Anexo I de la CRA pide 50+ requisitos: diseño seguro, con
