SSDF practice PW.9 means your software should install with secure settings already on, so users are not exposed by weak defaults. You define a secure baseline, ship those defaults, test them and document each setting for administrators. Evidence is the baseline, test results and settings documentation.
The two tasks
- PW.9.1 Define a secure baseline by deciding how to configure each security related setting so defaults are secure and do not weaken platform, network or service protections.
- PW.9.2 Implement the default settings and document each one for administrators.
The practice exists to reduce the chance that software is deployed with weak settings and ends up at greater risk.
What a baseline holds
Start with a list of every setting that touches security. For each one record the default, the reason and the effect of changing it.
| Setting area | Secure default to consider |
|---|---|
| Authentication | Strong login required, no shared default accounts |
| Network exposure | Services closed until enabled |
| Logging | On by default |
| Encryption | On by default where data is stored or sent |
| Admin features | Off until a person turns them on |
These rows are illustrations of the idea, not text from the standard.
Document each setting
The PW.9.2 examples say to document each setting's purpose, options, default value, security relevance, operational impact and relationships to other settings. They also suggest recording how administrators can implement and assess each setting programmatically, and storing the default configuration in a usable format under change control, for example configuration as code.
Evidence to keep
- The secure baseline document
- Tests showing defaults work as expected and cause no weakness
- Verification that the approved configuration is in place in each release
- Settings documentation for administrators
- Change records for any default that was altered
Test the unhappy path
A default that is secure on paper may break a common deployment, and then users switch protections off. The PW.9.1 example says to test that settings, including defaults, work as expected without causing weaknesses or operational problems. Try a fresh install by someone who has not read your docs. Note where they stumble and whether they weaken a setting to continue. Fix the default or the guidance, and keep the notes as evidence.
Quick check
Is PW.9 only for products we sell?
It is written for software producers, but internal tools benefit as well, since weak defaults hurt anyone who deploys them.
How do we show defaults did not drift?
Keep the default config in version control and verify it in the pipeline for each release, as the examples suggest.
Where tooling helps
Safeguard offers policies and gates and compliance and evidence automation, which can check configuration files in a pull request and keep the result. The baseline decisions are yours. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
