When we analyze reports on the largest security breaches of recent years, one pattern repeats with alarming regularity: the cause was not a sophisticated exploit or advanced APT — the cause was a misconfiguration. Open S3 buckets, default admin passwords, unnecessary services listening on public interfaces, lack of encryption in transit. Attackers do not need to pick locks when the doors are wide open.
ENISA’s Security by Design and Default Playbook addresses this problem with two interconnected concepts: Default Hardening and Guided Protection. Together, they form a framework that eliminates the most common breach sources — not by training users, but by changing how systems are designed.
Anatomy of configuration-driven breaches
Before we get to solutions, it is worth understanding the scale of the problem. According to industry data, misconfigurations account for a significant portion of security breaches across cloud and on-premise environments.
Cases that define the problem
Public S3 buckets — one of the most common types of cloud data breaches. AWS default access policies were for years too permissive, allowing public access to resources that should have been private. Thousands of organizations lost customer data, internal documents, and database backups — not because of an attack, but because of a default configuration.
Default credentials — routers, IP cameras, SCADA systems, databases. Products shipped with passwords like admin/admin, root/root, or no authentication at all. Botnets like Mirai built armies of hundreds of thousands of devices using only default credentials.
Unsecured databases — MongoDB, Elasticsearch, Redis instances exposed to the public internet without authentication. This required no exploit — simply connecting was enough. Tens of thousands of instances were taken over and encrypted by ransomware.
Open admin panels — management interfaces accessible from the internet, often without MFA, with default ports and paths. Attackers did not need to find vulnerabilities — a standard URL and weak password sufficed.
The human factor as a risk amplifier
Each case above shares a common denominator: the system allowed an insecure configuration. The user did not have to actively circumvent security — they simply did not take additional steps to secure the system. This is a fundamental asymmetry: security requires action, while insecurity is the default state.
ENISA inverts this logic. In the Secure by Default model, security is the default state, and weakening it requires conscious action.
Default Hardening — secure initial state
The first Secure by Default principle requires that products start in the most restrictive configuration that is practically usable. This is not about blocking everything — it is about ensuring the default configuration protects the user without requiring expert knowledge.
Default Hardening principles
Minimal service exposure — only services essential for basic operation are active by default. All additional services — diagnostic, administrative, development — are disabled and require conscious activation.
In practice, this means:
- HTTP server listens on localhost by default, not 0.0.0.0
- Admin panel requires explicit activation and access configuration
- Debug and profiling ports are disabled in production configuration
- Discovery services (mDNS, SSDP) are disabled by default
Enforced strong authentication — no default passwords. The system should require setting a strong password on first launch or use one-time tokens. Multi-factor authentication (MFA) should be enabled by default, not optional.
Secure communication protocols — TLS 1.2+ by default for all connections. Unencrypted communication channels should be unavailable or require explicit unlocking with a clear warning.
Automatic updates — the system should check for and install security updates automatically. The option to disable automatic updates should be available but with a clear warning about consequences.
Secure default values — sessions expire after reasonable time, logs do not contain sensitive data, password policies enforce minimum complexity, CORS is restrictive.
Implementation through CIS Benchmarks and STIG
In practice, Default Hardening implementation relies on established hardening standards:
CIS Benchmarks — the Center for Internet Security publishes detailed security configuration guides for operating systems, databases, application servers, cloud services, and network devices. Each benchmark defines hundreds of specific settings split into two levels:
- Level 1 — settings that can be deployed without impacting functionality
- Level 2 — more restrictive settings that may require application adjustments
DISA STIG (Security Technical Implementation Guides) — the U.S. Department of Defense publishes detailed configuration guides with risk categories (CAT I/II/III). While intended for military environments, STIGs serve as an excellent reference for organizations requiring high security levels.
Vendor guides — Microsoft Security Baselines, AWS Well-Architected Security Pillar, Google Cloud Security Best Practices — each vendor publishes security configuration recommendations for their products.
Hardening automation
Manually configuring hundreds of security settings on every server does not scale. ENISA emphasizes the need for automation:
Infrastructure as Code — Terraform, Ansible, Puppet, or Chef templates with built-in security settings. Instead of hardening the system after deployment, hardening is part of the infrastructure definition.
Golden images — pre-configured operating system and container images with hardening applied. Every new deployment starts from a secure baseline configuration.
Policy as Code — tools like Open Policy Agent (OPA), Kyverno, or AWS Config Rules that automatically verify configuration and block deployments that do not meet security requirements.
Configuration scanners — tools like Scout Suite, Prowler (AWS), or OpenSCAP that regularly scan the environment for deviations from the secure configuration baseline.
Guided Protection — supporting the user
The second Secure by Default principle acknowledges that security must be designed for people, not against them. Users will make mistakes — the system’s role is to minimize the consequences of those mistakes and help correct them.
Mandatory security steps
ENISA recommends that critical security configurations not be optional. Users should not be able to skip:
- Setting a strong password on first login
- Configuring MFA for administrative accounts
- Reviewing default permissions after installation
- Accepting the security policy before beginning work
This is not a restriction on user freedom — it is a safeguard against consequences that affect not just the individual but the entire organization.
Clear warnings for risky actions
The system should actively inform users about actions that reduce security:
- Disabling firewall → clear warning with information about consequences
- Opening a port to the public internet → information about exposure and alternatives (VPN, Zero Trust)
- Granting administrative privileges → confirmation with explanation of access scope
- Disabling logging → warning about loss of visibility and regulatory compliance
Warnings must be specific and understandable — not generic “Are you sure?” but an explanation of what risk the action entails.
Recovery mechanisms
People make mistakes. Systems must enable easy return to a secure state:
- One button to restore the default secure configuration
- Automatic snapshots of configuration before changes
- Comparison of current configuration with secure baseline
- Guided remediation — step-by-step instructions for fixing detected issues
Automatic security status reporting
Users should have continuous insight into the system’s security state — not as a technical dashboard with hundreds of metrics, but as a clear, understandable summary:
- Time since last security update
- Which components have known vulnerabilities
- Whether configuration deviates from secure baseline
- What actions are recommended and why
Common configuration mistakes — checklist
Based on ENISA’s principles and real-world incident data, here is a checklist of the most common configuration issues organizations should verify:
Authentication and authorization
- No default passwords in any system component
- MFA enabled for all administrative accounts
- Password policy enforcing minimum complexity and rotation
- No shared service accounts
- Regular permission reviews (every 90 days minimum)
- Automatic account lockout after multiple failed login attempts
Network and exposure
- No diagnostic/development services accessible in production
- Admin panel not accessible from the public internet
- Firewall with deny-by-default policy
- TLS 1.2+ for all external connections
- No unencrypted protocols (HTTP, FTP, Telnet) in production
- Network segmentation separating critical systems
Data and encryption
- Encryption at rest for sensitive data
- Encryption in transit for all connections
- No sensitive data in logs
- Secure secret storage (vault, KMS — not in code)
- Regular backups with recovery testing
Updates and patching
- Automatic security updates enabled
- Risk-based vulnerability prioritization process
- Response time: critical vulnerabilities < 48h, high < 7 days
- Third-party dependency vulnerability monitoring (SCA)
- Regular vulnerability scanning (at least weekly)
Logging and monitoring
- Centralized logging of all security events
- Alerts on anomalies and unauthorized access attempts
- Log retention compliant with regulatory requirements
- Log integrity protection (append-only, separate system)
Implementing Secure by Default in existing systems
New systems can be designed following Secure by Default principles from the start. But what about systems already running in production — often with years of accumulated configuration debt?
Phased approach
Phase 1: Inventory — map all systems, services, and their configurations. Identify default configurations that were never changed.
Phase 2: Risk assessment — compare current configurations against benchmarks (CIS, STIG). Assign priorities based on exposure and system criticality.
Phase 3: Quick wins — immediately fix the most critical issues: default passwords, open services, missing encryption, missing MFA on administrative accounts.
Phase 4: Systematic hardening — implement hardening systematically, starting with the most externally exposed systems. Use automation (Ansible, Terraform) instead of manual changes.
Phase 5: Continuous verification — deploy automated configuration scanning to detect drift and new deviations on an ongoing basis.
Change management
Hardening existing systems carries risk of impacting availability and functionality. Key practices:
- Test on staging before deploying to production
- Deploy gradually — system by system, not everything at once
- Communicate with teams — inform about planned changes and their impact
- Prepare rollback — ability to quickly revert changes
- Monitor after deployment — observe logs and metrics for 24-48h after each change
Secure by Default and regulations
NIS2
The NIS2 Directive requires essential and important entities to implement appropriate security measures. Secure by Default directly addresses:
- Art. 21(2)(a) — risk analysis and information system security policies
- Art. 21(2)(e) — security in acquisition, development, and maintenance of systems
- Art. 21(2)(h) — cryptography and encryption policies
DORA
The DORA Regulation for the financial sector requires ICT risk management, including secure system configuration. Default Hardening principles directly support requirements for identification, protection, and resilience.
ISO 27001
Annex A controls of ISO 27001 include requirements for security configuration (A.8.9 Configuration management), vulnerability management (A.8.8), and access control (A.8.2-8.5). Secure by Default provides practical implementation of these controls.
Conclusion
Secure by Default is not a luxury — it is a necessity. In a world where attackers regularly exploit default configurations and human error, the answer lies not in training and procedures but in engineering systems that are secure by nature.
ENISA’s playbook formalizes what the best engineering teams have known for years:
- Security is the default state — users must take conscious action to weaken it
- Systems protect users from the consequences of mistakes instead of punishing them
- Automation is critical — manual hardening does not scale
- Continuous verification detects configuration drift before it becomes an attack vector
Do not wait for the next incident. Conduct a security audit of your default configurations and identify gaps before attackers do.
Related topics
See also:
