Secure by Design & Default Practices

Secure by Design and Secure by Default are foundational principles that must be applied across the entire digital product lifecycle—from initial conceptualization and development through to final decommissioning. Driven by frameworks such as the ENISA SME Playbook and stringent regulatory requirements like the EU Cyber Resilience Act (CRA), these concepts ensure that security is engineered intrinsically rather than bolted on as an afterthought.

Secure by Design Principles

Secure by Design focuses on how a system is engineered. It dictates the proactive identification and mitigation of vulnerabilities before code ever reaches a production environment, effectively preventing systemic weaknesses from being built into the product.

User-Centric Design

Security mechanisms must be highly usable and understandable for everyday users. Poor usability frequently drives users toward insecure workarounds or misconfigurations. For example, if a software system requires complex, manual configuration steps to enable encryption, users are likely to either skip the step or apply it incorrectly. Conversely, providing a simple, guided setup that enables encryption automatically reduces the likelihood of human error and actively encourages the adoption of the security feature.

Secure Coding Practices

Engineering teams must follow established secure coding standards to prevent vulnerabilities. Integrating automated security tools early in the software development lifecycle (SDLC) is critical:

• Static Application Security Testing (SAST): Used during the coding phase to analyze source code for structural vulnerabilities without executing the program.
• Software Composition Analysis (SCA): Deployed to detect and track known vulnerabilities in third-party libraries and open-source components.
• Dynamic Application Security Testing (DAST): Executed before deployment to interact with the running application and uncover runtime issues.

Adhering to these practices mitigates systemic risks, such as those highlighted in the OWASP Top 10, ensuring that code-related vulnerabilities are identified and remediated long before the product is released.

Secure by Default Principles

While Secure by Design focuses on engineering, Secure by Default focuses on how the system arrives and behaves when the user first turns it on. Even flawlessly engineered systems become vulnerable if they are shipped with overly permissive settings. The goal of Secure by Default is to drastically minimize the attack surface post-deployment by guaranteeing that the most secure configuration is applied automatically, requiring no user intervention.

The ENISA guidelines organize Secure by Default into two distinct categories: Default Hardening and Guided Protection.

Default Hardening

This category governs the factory-shipped state of the software. It aims to eliminate "low-hanging fruit" for attackers by removing unnecessary features and ensuring all active components operate at peak security without user input. Key practices include:

• Minimization of Default Services: Any feature or service not strictly essential for the core functionality of the product must be disabled by default. If a web server includes an optional file-sharing module, that module must remain "off" until the user explicitly opts in.
• Restrictive Initial Access: Systems must ship with the tightest possible permissions. This mandates the elimination of universal default credentials (e.g., "admin/admin") in favor of unique passwords and mandatory password resets upon the first boot.
• Secure Communication by Default: External communications must be encrypted and authenticated from the very first connection. Instead of allowing unencrypted HTTP or Telnet for perceived convenience, the system must strictly enforce protocols like TLS 1.3 or SSH.
• Unique Device Identity and Secrets: Every product or application instance must be provisioned with unique cryptographic identities and secrets, ensuring that a compromise of a single device does not endanger the entire fleet.

CRA Compliance: Automated Attestation and Security Manifests

The EU Cyber Resilience Act (CRA) mandates strict adherence to these principles for products with digital elements, shifting liability to the manufacturer. Meeting these requirements practically requires embedding validation mechanisms directly into deployment pipelines.

Automated Attestation

To prove that Secure by Design principles are actively maintained, organizations must implement automated security gates. CI/CD pipelines should be configured to block builds if SAST, DAST, or SCA tools detect high-severity vulnerabilities. This creates an Automated Attestation trail, providing cryptographic proof that the software was built in compliance with required security standards before deployment.

Security Manifests

Transparency is a core component of the CRA and aligns with the ENISA NIS2 Technical Implementation Guidance. Systems must automatically generate Security Manifests, specifically Software Bill of Materials (SBOMs) and default configuration files. These manifests document every third-party dependency and the exact factory-shipped configuration state of the application.

By comprehensively mapping the software supply chain and enforcing restrictive baselines, organizations can quickly respond to zero-day vulnerabilities in dependencies, heavily reducing their overall risk exposure and supporting broader Enterprise Cybersecurity Risk Management objectives.