Compartir artículo
En el Secure by Design and Default Playbook, la ENISA, Agencia de la Unión Europea para la Ciberseguridad, explica por primera vez de forma concreta cómo los fabricantes de productos con elementos digitales pueden aplicar, desde el punto de vista técnico y organizativo, los requisitos del Reglamento de Ciberresiliencia (CRA).
Con la versión 1.0 del Secure by Design and Default Playbook, publicada en julio de 2026, la ENISA ha presentado la versión definitiva de su guía práctica. El documento tiene en cuenta los resultados de la consulta pública celebrada en la primavera de 2026, en la que se recibieron 28 contribuciones de la industria, las autoridades públicas y la comunidad de código abierto, e incorpora numerosas precisiones técnicas y nuevas recomendaciones para su aplicación.
La guía está dirigida especialmente a los fabricantes de software y dispositivos IoT y tiene como objetivo integrar sistemáticamente la ciberseguridad a lo largo de todo el ciclo de vida del producto. En este artículo resumimos los aspectos más importantes del documento.
¿Qué objetivos persigue el Playbook de la ENISA y cómo está estructurado?
El enfoque de la ENISA se basa en la integración sistemática de la seguridad desde las primeras fases del desarrollo, un principio conocido en la terminología técnica como «Shift Left». De este modo, los requisitos de seguridad no se tienen en cuenta únicamente durante las pruebas o la fase operativa, sino ya desde la definición de los requisitos, el diseño de la arquitectura y la selección de las tecnologías.
Este enfoque orientado al ciclo de vida comprende las fases Requirements, Design, Implementation, Verification, Deployment, Maintenance y Disposal, que también se han revisado y precisado en la versión 1.0.
Además, la ENISA aclara en la versión 1.0 que estos procesos deben entenderse como agrupaciones de actividades y no como un modelo necesariamente secuencial. Pueden solaparse, desarrollarse de forma iterativa y repetirse a lo largo del ciclo de vida del producto. Por ejemplo, en entornos ágiles, los requisitos de seguridad pueden registrarse y perfeccionarse progresivamente mediante elementos del backlog, historias de usuario, criterios de aceptación y la Definition of Done.
De este modo, la terminología se ajusta en mayor medida a los procesos de desarrollo tradicionales y a referencias como IEC 62443 e IEC 61508.
La versión final define además por primera vez de forma explícita los «Intended Outcomes», que todavía no figuraban íntegramente en el borrador sometido a consulta:
El Playbook estructura los requisitos en 22 principios, divididos en las categorías Secure by Design y Secure by Default. Estos principios se concretan mediante medidas técnicas, requisitos relativos a las evidencias y criterios de aprobación.
Entre los principales aspectos técnicos se encuentran el modelado estructurado de amenazas, las arquitecturas de software seguras basadas en principios consolidados como Least Privilege y Defense in Depth, las configuraciones predeterminadas seguras y la gestión continua de vulnerabilidades. A ello se suman requisitos relativos a la monitorización, la respuesta ante incidentes (Incident Response) y la capacidad de recuperación. De este modo, la resiliencia se entiende como parte integrante de la operación.
Un elemento innovador es el concepto inicialmente denominado «Machine-Readable Security Manifest», que en la versión 1.0 se ha ampliado y reformulado como «Machine-processable Attestation». Su objetivo es permitir una documentación estructurada y procesable automáticamente de las medidas y evidencias de seguridad. De este modo, también las comprobaciones de conformidad pueden automatizarse y escalarse en mayor medida.
Además de las medidas técnicas, la ENISA destaca aspectos organizativos como la asignación clara de responsabilidades, la integración de la seguridad en las decisiones relacionadas con el producto y la protección de la cadena de suministro. La seguridad se convierte así en una tarea interdisciplinar que implica al desarrollo, las operaciones y la dirección.
En conjunto, el Playbook supone un cambio de paradigma: la ciberseguridad deja de ser una función adicional incorporada posteriormente para convertirse en un componente integral y verificable de todo el ciclo de vida del producto. Para los fabricantes, esto implica no solo requisitos regulatorios más exigentes, sino también la necesidad de adaptar de forma sustancial sus procesos de desarrollo.
El mensaje principal es claro: la ciberseguridad es un proceso continuo, no una funcionalidad puntual.
¿Cuál es la finalidad de los 22 principios de seguridad?
El Playbook define 22 principios concretos, divididos en Secure by Design (14 principios) y Secure by Default (ocho principios).
Cada uno de los 22 principios se explica detalladamente en el capítulo 4 del documento de la ENISA, titulado Playbook, atendiendo a criterios como el objetivo, los elementos técnicos de implementación, las evidencias necesarias y los criterios de aprobación.
El objetivo es trasladar los principios de seguridad desde el plano conceptual a prácticas concretas de ingeniería y operación. Para cada principio se describen pasos de implementación y criterios verificables, de modo que la seguridad se convierta en una parte medible y auditable del proceso de desarrollo.
Los 22 principios siguen una estructura uniforme:
¿Qué requisitos específicos pueden derivarse para los sistemas OT?
En el diseño de arquitecturas y redes OT, la segmentación sistemática de los sistemas industriales desempeña un papel fundamental. La base es un modelo de zonas y conductos (zones and conduits) inspirado en la serie de normas IEC 62443, que divide las instalaciones en zonas de seguridad claramente delimitadas y controla específicamente las comunicaciones entre ellas.
También es necesaria una separación clara entre las redes IT y OT para dificultar los movimientos laterales de los atacantes y limitar las consecuencias de los incidentes de seguridad.
Sin embargo, la separación física conocida como «air gap» no debe considerarse por sí sola una garantía de seguridad. Las conexiones realmente necesarias, por ejemplo, para mantenimiento, monitorización o integración de datos, deben identificarse explícitamente y protegerse mediante puntos de transición controlados. Entre las medidas posibles se encuentran los cortafuegos, las pasarelas de protocolo y las interfaces monitorizadas.
Debe prestarse especial atención a la protección de los accesos remotos, que a menudo son necesarios en los entornos industriales. Estos accesos deberían realizarse exclusivamente mediante mecanismos debidamente protegidos, por ejemplo, conexiones VPN combinadas con autenticación multifactor y jump hosts dedicados, evitando así el acceso directo a sistemas críticos.
*Un jump host es un sistema especialmente protegido que actúa como punto de acceso central y controlado para conectarse de forma segura desde una red externa, por ejemplo Internet, a sistemas internos protegidos.
¿Por qué el modelado de amenazas es un proceso fundamental en los entornos OT?
En los entornos OT, el modelado de amenazas debe integrarse de forma permanente en el proceso de ingeniería. Para ello, deben tenerse en cuenta sistemáticamente los escenarios de ataque típicos de los sistemas industriales.
Entre ellos se encuentra, por ejemplo, la manipulación selectiva de la lógica de un PLC, mediante la cual pueden influirse directamente los procesos físicos.
También deben tenerse en cuenta los riesgos derivados de protocolos de comunicación industrial inseguros o configurados incorrectamente, como Modbus u OPC UA, cuando sus mecanismos de seguridad no estén implementados adecuadamente.
Otro escenario relevante es el movimiento lateral a través de estaciones de trabajo de ingeniería, que a menudo actúan como sistemas de enlace entre las redes IT y OT y, por tanto, pueden constituir objetivos especialmente atractivos para los atacantes. Asimismo, están adquiriendo cada vez mayor importancia los ataques a la cadena de suministro, por ejemplo, mediante firmware comprometido o mecanismos de actualización manipulados.
Por tanto, el modelado de amenazas en entornos OT debe ir más allá del análisis tradicional de la seguridad IT e incluir necesariamente también las repercusiones sobre los procesos físicos y las funciones relacionadas con la seguridad funcional (Safety). Solo así puede evaluarse de forma realista el perfil de riesgo de los sistemas industriales y adoptarse medidas adecuadas.
¿Qué papel desempeñan la gestión de riesgos y la seguridad operativa?
El Playbook define ocho actividades principales en el ámbito de la gestión de riesgos y la seguridad operativa, que deben implementarse como procesos continuos.
Entre ellas se incluyen especialmente:
El concepto de resiliencia desempeña aquí un papel central. No se considera únicamente un objetivo de la arquitectura del sistema, sino una capacidad operativa que debe implementarse, verificarse y mejorarse continuamente durante el funcionamiento.
Progressive Adoption: ¿cómo pueden las empresas introducir gradualmente Secure by Design?
Una de las principales novedades de la versión 1.0 es el capítulo «Progressive Adoption of the Playbooks». En él, la ENISA presenta un enfoque pragmático que permite a las empresas, especialmente a las pequeñas y medianas empresas (pymes), integrar progresivamente los 22 principios de Secure by Design y Secure by Default en sus procesos de desarrollo.
La ENISA aclara, no obstante, que esta introducción progresiva se refiere exclusivamente a la implementación práctica de las medidas. Las obligaciones legales, por ejemplo, las derivadas del Reglamento de Ciberresiliencia (CRA), no pueden aplazarse por este motivo. La secuencia propuesta sirve únicamente como orientación para introducir las medidas de forma estructurada y teniendo en cuenta los recursos disponibles.
La ENISA propone un enfoque en tres fases:
1. Definir el contexto y las prioridades
En primer lugar, los fabricantes deberían analizar el contexto del producto, las condiciones de uso previstas y los principales riesgos de ciberseguridad.
Mediante el análisis de riesgos y el Threat Modelling se identifican las amenazas relevantes, los Trust Boundaries y los objetivos de seguridad. Sobre esta base pueden priorizarse las medidas necesarias y definirse adecuadamente el alcance de la implementación.
2. Crear una base técnica de seguridad
En la segunda fase, la ENISA recomienda establecer una base técnica de ingeniería que incluya especialmente:
Dependiendo del tipo de producto, también deberían implementarse funciones importantes de Secure by Default, como accesos predeterminados restrictivos, protocolos de comunicación seguros, identidades únicas de los dispositivos y actualizaciones de seguridad automatizadas.
Los demás principios del Playbook se priorizan posteriormente en función de los riesgos identificados y del contexto del producto.
3. Ampliar continuamente el nivel de seguridad
Una vez establecida una base sólida, pueden implementarse progresivamente otros principios de Secure by Design y Secure by Default.
El objetivo es aumentar continuamente el grado de madurez de las medidas de seguridad, mejorar su coherencia y automatizar el mayor número posible de procesos. Al mismo tiempo, la ENISA recomienda evaluar periódicamente los avances mediante indicadores y evidencias adecuados.
En resumen, con el concepto de Progressive Adoption, la ENISA ofrece una guía práctica para introducir gradualmente Secure by Design. Las empresas no tienen que implementar necesariamente todas las medidas al mismo tiempo, sino que pueden adoptar un enfoque basado en el riesgo y desarrollar progresivamente sus procesos de seguridad.
Especialmente para las pymes, este enfoque ofrece una vía práctica para integrar de forma sistemática y sostenible los requisitos del Reglamento de Ciberresiliencia en el proceso de desarrollo de productos, sin rebajar el objetivo de alcanzar la plena conformidad.
La versión 1.0 recomienda además expresamente el uso del OWASP Software Assurance Maturity Model (SAMM) como posible modelo de madurez para la implementación organizativa de Secure by Design.
Este modelo permite estructurar y desarrollar progresivamente las actividades de seguridad a lo largo de todo el ciclo de vida del desarrollo de software. En particular, ámbitos como Threat Assessment y Security Requirements muestran cómo las amenazas identificadas pueden traducirse en requisitos de seguridad verificables.
¿Qué es la Machine-processable Attestation y cómo se utiliza para aportar evidencias?
En la versión 1.0, el concepto inicialmente denominado Machine-Readable Security Manifest (MRSM) se ha reformulado y ampliado hacia la Machine-processable Attestation.
En la versión final, la ENISA se aleja así parcialmente del concepto específico de MRSM y describe de forma más general las atestaciones de seguridad procesables automáticamente. De este modo, el concepto es más abierto desde el punto de vista tecnológico y puede abarcar formatos distintos de un único Security Manifest.
Se trata de un enfoque destinado a representar las evidencias de seguridad de forma estructurada y procesable por sistemas automáticos. El objetivo es documentar de manera sistemática y trazable el cumplimiento de los requisitos de seguridad.
El concepto vincula las declaraciones de seguridad (Security Claims) con evidencias técnicas concretas, como datos de configuración, resultados de pruebas o registros. De este modo se crea una base sólida y automatizable para evaluar el nivel de seguridad de un producto.
Una ventaja especialmente importante es la posibilidad de facilitar comprobaciones automatizadas de conformidad, por ejemplo, en el marco de auditorías. La Machine-processable Attestation aborda así un problema fundamental de los requisitos regulatorios: proporcionar documentación de conformidad verificable y, al mismo tiempo, escalable, que vaya más allá de evidencias meramente estáticas o manuales.
¿Cómo se aplican concretamente en el Playbook los requisitos del Reglamento de Ciberresiliencia?
El anexo C del Playbook contiene una correspondencia directa entre los 22 principios de seguridad y los requisitos del anexo I del Reglamento de Ciberresiliencia (CRA).
Para los fabricantes, esto pone de relieve la necesidad de implementar y documentar las medidas de seguridad a lo largo de todo el ciclo de vida del producto, gestionar activamente las vulnerabilidades y proporcionar las actualizaciones de seguridad necesarias.
La ciberseguridad se convierte así en un requisito regulatorio vinculante y deja de ser un aspecto opcional. El propio CRA establece requisitos esenciales de ciberseguridad tanto para los productos con elementos digitales como para los procesos de gestión de vulnerabilidades de los fabricantes.
El Secure by Design and Default Playbook de la ENISA ofrece un marco práctico y estructurado para integrar sistemáticamente la ciberseguridad a lo largo de todo el ciclo de vida del producto.
Resulta especialmente relevante su orientación hacia la implementación concreta de los requisitos de seguridad. En lugar de limitarse a directrices abstractas, el documento se centra en medidas prácticas, evidencias verificables y criterios de aprobación claramente definidos.
Para los fabricantes, especialmente en el contexto del Reglamento de Ciberresiliencia, esto supone un importante cambio de paradigma. La seguridad deja de entenderse como una medida complementaria y pasa a ser parte integrante del desarrollo, la operación y la organización.
La introducción de procesos estructurados como el modelado de amenazas, la gestión continua de vulnerabilidades y las evidencias de conformidad automatizables puede mejorar tanto el nivel de seguridad como la trazabilidad de las medidas adoptadas.
Especialmente en entornos industriales y OT, el Playbook ofrece un marco de referencia valioso porque relaciona los requisitos regulatorios con las condiciones operativas reales. Al mismo tiempo, su implementación requiere una estrecha integración entre ingeniería, operaciones y organización, así como la adaptación de los procesos de desarrollo y operación existentes.
En conjunto, el Playbook de la ENISA constituye una base sólida para implementar e integrar la ciberseguridad de forma eficiente, sostenible y verificable.
La versión final desarrolla y amplía el borrador sometido a consulta. Mientras que dicho borrador ya ofrecía una guía práctica para Secure by Design, la versión 1.0 añade objetivos concretos, un modelo de implantación progresiva (Progressive Adoption), procesos del ciclo de vida más precisos y una orientación mucho más marcada hacia evidencias de seguridad verificables.
De este modo, el Playbook se configura cada vez más como un modelo práctico de referencia para la implementación técnica de los requisitos del Reglamento de Ciberresiliencia.
Descarga del Playbook
La versión 1.0 del ENISA Secure by Design and Default Playbook puede consultarse y descargarse a través del siguiente enlace:
Manual de la ENISA sobre «Seguridad desde el diseño y por defecto»
Fecha de publicación: 4 de agosto de 2026 (última actualización)
Wolfgang ReichIngeniería Eléctrica (HTL), especialidad en Tecnología Energética (Dipl.-HTL-Ing.), 20 años de experiencia en el ámbito del marcado CE, la seguridad de las máquinas, la adaptación de máquinas, la ingeniería eléctrica y la protección contra explosiones, 10 de ellos en TÜV Austria e Intertek Deutschland GmbH. Presidente de la Comisión de Exámenes de Maestría de la Cámara de Comercio de Estiria en el ámbito de la mecatrónica (tecnología de automatización y electrónica).
Correo electrónico: wolfgang.reich@ibf-solutions.com | www.ibf-solutions.com
Software CE para la ingeniería sistemática y profesional en materia de seguridad técnica
Seminarios prácticos sobre el tema de la seguridad de los productos
El CE-InfoService (en inglés) le mantiene informado sobre los avances importantes en materia de seguridad de los productos.