SSDF PW.1.3 says that, where appropriate, your software should integrate with standardized security features and services, such as existing log management, identity management, access control and vulnerability management, instead of proprietary versions. The evidence is a list of shared modules, secure configurations and criteria for what software must support.
What the task says
PW.1.3: where appropriate, build in support for using standardized security features and services (for example, enabling software to integrate with existing log management, identity management, access control and vulnerability management systems) instead of creating proprietary implementations. NIST notes it was formerly PW.4.3 and now sits with the design practice.
The NIST examples are practical. Maintain repositories of modules that support standardized features. Determine secure configurations for those modules and publish them, for example as configuration-as-code. Define criteria for which security features and services software must support.
Plain examples
| Need | Standardized approach | Homegrown approach to avoid |
|---|---|---|
| Sign-in | Use your identity provider | A custom login table |
| Permissions | Central access control service | Role checks scattered in code |
| Logging | Shared logging library to a central system | Print statements to local files |
| Vulnerability intake | Existing tracker and scanning | A private spreadsheet |
These are illustrations, not NIST's list.
Why it is a design topic
The choice is made early. By the time code is written, a custom login or logging layer is expensive to remove. Putting a security requirement into design review, such as "must authenticate through the identity provider", prevents this and gives you evidence at PW.1 and PW.2.
Steps
- List the shared services your organization already runs for identity, logging and access control.
- For each, create a small module or template with a secure configuration.
- Add a design review question: does this feature use the standard service? If not, why not?
- Record any approved departure in the exception register.
- Publish the module list where developers find it.
Evidence to keep
- The list of standard services and modules
- The published secure configurations
- Design review records showing the question was asked
- Exception entries for departures
Where appropriate matters
NIST says where appropriate. Some products have unusual needs, and a standard service may not fit. The goal is a reasoned choice, written down, not a ban on custom code. When you do build something custom, PW.4.2 applies and you maintain it as a managed component. See our guide on building a shared component.
A design review prompt
Add one line to your design review template: which existing security services does this design use, and which does it replace with custom code? Reviewers can answer in a sentence. Over time the answers show where teams keep reinventing a feature, which points to a missing shared module. That is a cheap, useful signal and it produces the PW.2 evidence at the same time.
Quick check
Does PW.1.3 forbid custom authentication?
No. It says where appropriate. If you build custom, record the reason and treat it as a managed component.
Where do we keep the secure configurations?
In version control, so developers can reuse them and changes are tracked.
Safeguard's policies and gates can check that builds meet rules you set. The free scan is at gold.safeguard.sh/scan.
Sources
- NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1
- NIST CSRC publication page for SP 800-218
Last reviewed: 19 October 2026.
