Secure by design and by default
Secure by design and by default requires manufacturers to integrate security into every phase of a product's lifecycle—from initial architecture to deployment. It mandates that products are shipped with the most secure settings enabled out-of-the-box, ensuring users do not need to manually configure security to be protected from common threats.
What it means
"Secure by design" focuses on the engineering process. It requires that security is not a "bolt-on" feature added at the end of development, but a core requirement defined during the planning phase. This involves anticipating potential attack vectors and building defenses directly into the system architecture to minimize vulnerabilities.
"Secure by default" refers to the state of the product upon delivery. The intent is to reduce the attack surface for the average user by ensuring that high-risk features are disabled, strong authentication is enforced, and the least amount of privilege is granted automatically.
In practice, this shifts the responsibility of security from the end-user to the manufacturer. A product meets this standard if it remains resilient against known threats even if the user never changes a single configuration setting.
How to meet it
- Establish and follow a Secure Software Development Lifecycle (S-SDLC) that mandates security reviews at every stage of development.
- Perform formal threat modeling during the design phase to identify potential risks and document how those risks are mitigated in the architecture.
- Adopt industry-standard secure coding practices (e.g., OWASP or CERT) and integrate automated Static Analysis (SAST) and Dynamic Analysis (DAST) into the CI/CD pipeline.
- Disable all unnecessary ports, protocols, and services by default in the production image.
- Eliminate universal default passwords; require a unique password per device or force the user to create a strong password during initial setup.
- Implement the principle of least privilege for all system processes and default service accounts.
Evidence an auditor asks for
- S-SDLC policy documentation and records showing that security checkpoints (e.g., design reviews, code audits) were completed for the specific product version.
- Threat model documents mapping identified threats to specific technical controls implemented in the product.
- Reports from vulnerability scanners and static/dynamic analysis tools, including evidence that critical findings were remediated before release.
- A "Default Configuration Manifest" listing all enabled and disabled settings shipped to the customer.
- Penetration test reports or third-party validation confirming that the default configuration is resilient against common exploits.
Common pitfalls
- Treating security as a final "checklist" item performed just before release rather than an integrated design process.
- Shipping products with "convenience features" enabled by default (e.g., open telnet ports or guest accounts) to reduce support tickets.
- Relying on a "Hardening Guide