ENISA: Security by Design and Default Playbook

ENISA’s approach is based on the consistent integration of security early in the development process, a concept known in technical terminology as “shift left.” Security requirements thus do not begin during testing or in production, but rather at the stages of requirements definition, architectural design, and technology selection. This lifecycle-oriented approach encompasses the phases of development, deployment, operation, maintenance, and decommissioning.

The so-called “Playbook” structures the requirements into 22 principles, which are divided into the categories “Secure by Design” and “Secure by Default.” These are implemented through specific technical measures, verification requirements, and approval criteria.

Key technical requirements include standardized threat modeling, secure software architectures based on established principles (such as least privilege and defense-in-depth), secure default configurations, and continuous vulnerability management. These are complemented by requirements for monitoring, incident response, and recoverability. As a result, resilience is understood as an integral part of operational activities. One innovative element is the “Machine-Readable Security Manifest” (MRSM). It enables the structured, machine-readable documentation of security measures and their verification. This makes compliance automatable and scalable, representing a decisive step toward regulatory compliance.

In addition to technical measures, ENISA also emphasizes organizational aspects such as clear responsibilities, the integration of security into product decisions, and the securing of supply chains. Security is thus positioned as an interdisciplinary task spanning development, operations, and management.

Overall, the Playbook marks a paradigm shift: cybersecurity is evolving from a downstream add-on function to an integral, verifiable component of the entire product lifecycle. For manufacturers, this means not only increased regulatory requirements but also the need to fundamentally realign their development processes.

The key message is: cybersecurity is a continuous process, not a one-time feature.
 

The Playbook defines 22 specific principles, which are broadly categorized into “Secure by Design” (14 principles) and “Secure by Default” (eight principles).

Each of the 22 principles is explained in greater detail in Chapter 4 of the ENISA document (titled “Playbook”) based on the criteria of objectives, technical implementation elements, evidence (verification requirements), and release criteria (approval criteria).

The goal of this playbook is to translate security principles from the conceptual level into concrete, implementable engineering and operational practices. To this end, clear implementation steps as well as verifiable and binding criteria are defined for each principle, so that security becomes a measurable and auditable integral part of the development process.

The 22 principles are uniformly structured to enable standardized and repeatable application.

• Principle: Concrete security concept (e.g., hardening, access control, updatability).
• Objective: What the principle is intended to achieve and which sources of error it reduces.
• Checklist: The measures with the greatest impact that should be implemented (designed so that they can be implemented in lean/small teams).
• Minimum Proof: Concrete evidence (e.g., configuration statuses, logs, test results, SBOMs) demonstrating the implementation of the measures.
• Release Criteria: Formalized “pass/fail” criteria that can be automatically checked in release processes to ensure compliance with the unchanged security level.

In OT-specific architecture and network design, the focus is on the consistent segmentation of industrial systems. The foundation is a zone and conduit model based on the IEC 62443 series of standards, which divides systems into clearly defined security zones and specifically controls the communication links between them. In addition, a strict separation of IT and OT networks is required to prevent attackers from moving between networks and to limit the impact of security incidents.
The commonly assumed physical separation (“air gap”) must not be regarded as a guarantee of security. Instead, real, necessary connections—such as those for maintenance, monitoring, or data integration—must be explicitly identified and secured through controlled gateways. This includes, in particular, the use of firewalls, protocol gateways, and monitored interfaces.

There is also a particular focus on securing remote access, which is unavoidable in industrial environments. This should be conducted exclusively via hardened access mechanisms, such as the use of VPN connections in combination with multi-factor authentication, as well as dedicated *jump hosts, to prevent direct access to critical systems.

*A jump host is a specially secured computer that serves as a central, controlled access point for securely accessing internal, protected systems from an external network (e.g., the Internet).
 

In OT environments, threat modeling must be established as a mandatory component of the engineering process. In doing so, typical attack scenarios specific to industrial systems must be systematically taken into account. This includes, in particular, the targeted manipulation of PLC logic, through which physical processes can be directly influenced. Risks posed by insecure or misconfigured industrial communication protocols such as Modbus or OPC UA must also be addressed, as these often lack adequate security mechanisms.

Another key attack scenario is lateral movement via engineering workstations. These often serve as bridge systems between IT and OT networks and therefore represent an attractive target for attackers. Furthermore, supply chain attacks, particularly in the context of compromised firmware or manipulated update mechanisms, are becoming increasingly significant.

Central to this is the requirement that threat modeling in OT go beyond traditional IT security considerations, as it must necessarily also incorporate the impacts on physical processes as well as safety-related functions. Only in this way can the actual risk profile of industrial systems be realistically assessed and effectively addressed.
 

The playbook defines eight key activities in the areas of risk management and operational security. These must be established as continuous processes. They include, in particular, systematic vulnerability management for the ongoing identification and remediation of security vulnerabilities, clearly structured incident response processes for a rapid and coordinated response to security incidents, and robust backup and recovery strategies to ensure operational continuity in the event of a disruption. In addition, comprehensive measures for security monitoring and logging are required to detect attacks early and analyze them in a traceable manner.

Central to this is the underlying understanding of resilience: This is not defined as a goal in the system architecture, but is understood as an operational capability that must be actively implemented, reviewed, and continuously improved during ongoing operations.
 

A central, innovative component of the guide is the concept of the “Machine-Readable Security Manifest” (MRSM). This is an approach to the structured, machine-readable representation of security evidence. The goal is to document security requirements in a systematic and traceable manner.

At its core, the MRSM links declarative security claims with concrete technical evidence such as configuration data, test results, or logs. This creates a robust and, at the same time, automatable foundation for assessing a product’s security level.

A key benefit lies in supporting automated compliance checks, for example during audits. In this way, MRSM addresses a central challenge of regulatory requirements: providing verifiable and scalable compliance documentation that goes beyond purely static or manual evidence.
 

Appendix C of the Playbook provides a direct mapping of the 22 security principles to the requirements in Appendix I of the Cyber Resilience Act (CRA). This establishes clear obligations for manufacturers: security measures must be demonstrably implemented throughout the entire product lifecycle, vulnerabilities must be actively managed, and security updates must be provided on an ongoing basis. Thus, cybersecurity becomes a mandatory regulatory requirement and is no longer optional.