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 requirements, design, implementation, verification, deployment, maintenance and disposal, which have also been technically revised in version 1.0.

Furthermore, ENISA explicitly states in version 1.0: These processes are presented as groupings rather than as a strictly sequential model. They may overlap, run iteratively and be repeated throughout the product lifecycle. For example, in agile environments, security requirements can be identified and progressively refined through backlog items, user stories, acceptance criteria and the ‘Definition of Done’. 

As a result, the terminology is more closely aligned with traditional development processes (IEC 62443, IEC 61508, etc.). The final version explicitly defines the intended outcomes for the first time, which were still entirely absent from the consultation draft: 

• fewer recurring vulnerabilities 
• secure default configurations earlier risk detection 
• better control of the software supply chain 
• faster resolution of vulnerabilities 
• greater cyber resilience throughout the entire product lifecycle 

The “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-processable Attestation”. 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 key new feature of ENISA Version 1.0 is the new chapter entitled ‘Progressive Adoption of the Playbooks’. In this, ENISA sets out, for the first time, a pragmatic approach to how organisations – particularly small and medium-sized enterprises (SMEs) – can gradually integrate the 22 ‘secure-by-design’ and ‘secure-by-default’ principles into their development processes.

It is important to note ENISA’s clarification that this phased introduction relates exclusively to the practical implementation of the measures. Legal requirements, such as those set out in the Cyber Resilience Act (CRA), must not be delayed or postponed as a result. The proposed sequence serves merely as a guide for a structured and resource-efficient start.

ENISA recommends a three-phase approach, with each phase building on the previous one:

1. Define context and priorities

To begin with, manufacturers should analyse the product context, the intended conditions of use and the key cyber risks. Risk analyses and threat modelling are used to identify the relevant threats, trust boundaries and security objectives. On this basis, the necessary security measures can be prioritised and the scope of implementation sensibly defined.

2. Establish a technical security foundation

In the second step, ENISA recommends establishing a fundamental engineering foundation. This includes, in particular:

• secure software development and verification,
• logging, monitoring and alerting, vulnerability and patch management, and
• measures to secure the software supply chain.

In addition – depending on the product type – key ‘secure-by-default’ functions should be implemented. These include, for example, restrictive default access settings, secure communication protocols, unique device identifiers and automated security updates. Further playbooks are prioritised in line with the identified risks and the product context.

3. Continuously enhancing the security level

Once a solid foundation has been established, further ‘secure-by-design’ and ‘secure-by-default’ principles should be implemented in stages. The aim is to continuously increase the maturity of security measures, improve their consistency and automate as many processes as possible. At the same time, ENISA recommends regularly assessing progress using appropriate metrics and evidence.

In summary, this means that, with the concept of ‘Progressive Adoption’, ENISA is providing, for the first time, a practical implementation guide for introducing ‘Secure by Design’. Instead of implementing all security measures simultaneously, organisations can take a risk-based approach and expand their security processes step by step. For SMEs in particular, this approach offers a realistic way of systematically and sustainably integrating the requirements of the Cyber Resilience Act into the product development process, without compromising on the need for full compliance.

Version 1.0 explicitly recommends, for the first time, the use of the OWASP Software Assurance Maturity Model (SAMM) as a suitable maturity model for the organisational implementation of ‘Secure by Design’.

This is to systematically structure and continuously develop security activities throughout the entire software development lifecycle. The areas of threat assessment and security requirements, in particular, serve as prime examples of how identified threats can be translated into verifiable security requirements.

In version 1.0, this term was amended and expanded to ‘Machine-processable Attestation’. In the final version, ENISA has moved away from the term ‘MRSM’ (Machine-Readable Security Manifest) to some extent and now describes machine-processable security attestations in more general terms. This makes the concept more technology-neutral and will, in future, also allow for formats other than a security manifest alone.

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, Machine-processable Attestation 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.