ENISA Playbooks
Secure by Design and Secure by Default — 22 practical playbooks for SMEs, published by the European Union Agency for Cybersecurity.
No ATT&CK mapping
Every other framework on this site bridges to ATT&CK techniques. This one does not, and the reason is in the source rather than in the work: across all 22 playbooks, none cites an ATT&CK technique, a CWE, a CAPEC pattern, a NIST control, an ISO clause, IEC 62443, D3FEND or NIS2 — one mentions OWASP. With no identifier to join on, any crosswalk shown here would be this project’s editorial opinion presented as data, so none is shown. The playbooks are reproduced as a reading list, with their provenance attached.
What each playbook contains
- Principlethe security property being upheld
- Objectivewhat applying it should achieve
- Checklistthe steps, in order
- Minimum evidencewhat to keep to show it was done
- Release gatethe checks that must pass to ship
Secure by design
14Protective measures embedded into products during development, rather than added retrospectively.
Architectural foundations
- 1Trust boundaries and threat modellingSecure architectures make trust explicit rather than assumed.
- 2Least privilegeEvery user, service and process operates with the feasible minimum permissions needed to do its job – no more and for no longer than necessary.
- 3Strong identity and authentication architectureDesign identity and authentication as a core part of the architecture.
- 4Attack surface minimisationExpose only what is strictly necessary.
- 5Defence in depthApply multiple layers of security so that the failure or bypass of a single control does not result in full compromise.
- 6Open designSystems should not depend on secrecy of design or hidden behaviour for protection.
Operational integrity
- 7Life-cycle managementSecurity responsibilities extend beyond initial development.
- 8User-centric designSecurity mechanisms must be usable and understandable even for everyday users.
- 9Secure coding and verification practicesDevelopers should follow established secure coding standards to prevent common vulnerabilities.
- 10Logging, monitoring and alertingSystems should generate appropriate security-relevant logs, retain them for a defined period and protect them from tampering, so that they can support investigation and compliance needs.
- 11Configuration and change managementSecure operation requires configurations to be controlled, consistent and auditable.
- 12Incident response and recoveryDevelopers must be prepared to respond quickly and effectively to security incidents that affect their products in the field, including vulnerabilities, compromised code, malicious updates and misuse of product functionality.
- 13Vulnerability and patch managementManufacturers should establish practical, repeatable vulnerability and patch management processes and prioritise remediation according to risk.
- 14Supply-chain controlsDevelopers should protect product integrity without excessive process overhead, focusing on the points where a compromise would have the largest impact: code repositories, build systems, signing keys and the channels used to distribute updates.
Secure by default
8Products ship in the most secure configuration reasonably possible, so security does not depend on user expertise.
Default hardening
- 15Minimisation of default servicesDisable non-essential features and services by default.
- 16Restrictive initial accessShip systems in the most restrictive access state possible.
- 17Secure communication by defaultEnforce secure communication from the start.
- 18Unique device identity and secrets by defaultShip each product instance with a unique cryptographic identity and secrets by default if it uses any private/secret value.
Guided protection
- 19Mandatory security onboardingRequire critical security controls to be configured during initial set-up.
- 20Automated maintenance and updatesManufacturers should provide secure update mechanisms that minimise user and operational effort.
- 21Transparent security postureMake the system’s security posture visible and understandable.
- 22Secure recovery and ownership life cycleProvide secure, guided recovery and ownership transfer mechanisms by default.
Source
ENISA, Secure by Design and Default Playbook: A Practical Guide to Secure by Design and Default Principles for SMEs v1 (July 2026). Licensed CC BY 4.0; titles and principle text are reproduced under it, and the groupings are ENISA’s own. Each entry links to its playbook in the source repository. Not affiliated with or endorsed by ENISA.