Most security problems that reach production were designed in: a trust boundary nobody drew, a service account with rights it never needed, a recovery path that depends on the system being recovered. NIST SP 800-160 is NIST's answer to that, in two volumes. Volume 1 Rev. 1 sets out how to engineer trustworthy secure systems across the whole system life cycle, and Volume 2 Rev. 1 adds cyber resiliency engineering for systems that must keep working when an adversary is already inside. This guide explains how the two volumes fit together, what their processes, principles and resiliency constructs ask of engineering teams, how they connect to SP 800-53 SA-8 and the RMF, and how to bring them into a real delivery process without creating paperwork. It is written for security architects, systems and platform engineers, product security leads and assessors. Status was checked on csrc.nist.gov on 27 October 2026.
Key takeaways
- Volume 1 is about engineering, not controls: it builds security into the 30 system life cycle processes drawn from ISO/IEC/IEEE 15288 and gives 30 principles for trustworthy secure design.
- Volume 2 assumes compromise: its four goals (anticipate, withstand, recover, adapt), eight objectives and 14 techniques are for designing systems that keep delivering the mission with an adversary present.
- Use the volumes together: NIST says Volume 2 can be used in conjunction with Volume 1, and both sit alongside SP 800-37 and SP 800-53 rather than replacing them.
- SA-8 is the bridge to controls: SP 800-53 SA-8 Security and Privacy Engineering Principles and its 33 enhancements turn design principles into something an assessor can test, but the names differ from Volume 1 Rev. 1, so map them deliberately.
- Machine identities are a design decision: least privilege, least persistence and privilege restriction apply first to the service accounts, workload identities and agents a design creates.
What it is and who it applies to
| Volume | Title and status (27 Oct 2026) | Purpose |
|---|---|---|
| SP 800-160 Vol. 1 Rev. 1 | Engineering Trustworthy Secure Systems; final, 16 November 2022; supersedes Vol. 1 (March 2018); no newer draft listed | Principles, concepts, activities and tasks for engineering trustworthy secure systems, intended to advance systems engineering for contested operational environments and to serve as a basis for education, certification and assessment criteria |
| SP 800-160 Vol. 2 Rev. 1 | Developing Cyber-Resilient Systems: A Systems Security Engineering Approach; final, 9 December 2021 (NIST with MITRE); supersedes Vol. 2 (November 2019); no newer draft listed | Cyber resiliency engineering, so systems can anticipate, withstand, recover from and adapt to adverse conditions, stresses, attacks or compromises on cyber resources |
The audience is anyone who specifies, designs, builds, acquires or operates systems: systems engineers, security engineers, architects, acquisition staff and the authorising officials who rely on their work. It is not limited to federal systems; the processes are generic and the language is deliberately technology neutral. The live Cyber Resilience Guide covers resilience programmes, impact tolerances and recovery exercises; this page stays with the engineering.
Structure and key requirements
Volume 1: concepts and framework
- Trust versus trustworthiness: trust is a belief that an entity will meet expectations and can be granted whether or not it is deserved; trustworthiness is the demonstrated ability to meet expectations, including under adversity, and rests on evidence. Much of the volume is about producing that evidence.
- Assets, loss and protection needs: Chapter 3 frames security as control of asset loss. The first objective is to determine asset protection needs, considering the context of loss, the significance of loss and confidence in addressing it.
- The framework: Chapter 4 organises the work into a problem context (what must be protected and why), a solution context (the design) and a trustworthiness context (the evidence that the design meets the need).
- Appendices: security policy and requirements, trustworthy secure design, design principles (Appendix E), trustworthiness and assurance (Appendix F), and the life cycle processes in Appendices G to K.
Volume 1: the life cycle processes
| Process group | Processes | Where security work lands |
|---|---|---|
| Agreement (2) | Acquisition; Supply | Security requirements in contracts and supplier evidence |
| Organisational project-enabling (6) | Life Cycle Model Management; Infrastructure Management; Portfolio Management; Human Resource Management; Quality Management; Knowledge Management | Secure development environments, skills, reusable patterns |
| Technical management (8) | Project Planning; Project Assessment and Control; Decision Management; Risk Management; Configuration Management; Information Management; Measurement; Quality Assurance | Security risk decisions, configuration baselines, security metrics |
| Technical (14) | Business or Mission Analysis; Stakeholder Needs and Requirements Definition; System Requirements Definition; System Architecture Definition; Design Definition; System Analysis; Implementation; Integration; Verification; Transition; Validation; Operation; Maintenance; Disposal | Protection needs, security requirements, architecture, verification and secure disposal |
Volume 1: principles for trustworthy secure design
Appendix E lists 30 principles: Anomaly Detection; Clear Abstractions; Commensurate Protection; Commensurate Response; Commensurate Rigor; Commensurate Trustworthiness; Compositional Trustworthiness; Continuous Protection; Defense In Depth; Distributed Privilege; Diversity (Dynamicity); Domain Separation; Hierarchical Protection; Least Functionality; Least Persistence; Least Privilege; Least Sharing; Loss Margins; Mediated Access; Minimal Trusted Elements; Minimize Detectability; Protective Defaults; Protective Failure; Protective Recovery; Reduced Complexity; Redundancy; Self-Reliant Trustworthiness; Structured Decomposition and Composition; Substantiated Trustworthiness; and Trustworthy System Control.
Volume 2: cyber resiliency constructs
| Construct | Contents |
|---|---|
| Goals (4) | Anticipate; Withstand; Recover; Adapt |
| Objectives (8) | Prevent or Avoid; Prepare; Continue; Constrain; Reconstitute; Understand; Transform; Re-Architect |
| Techniques (14) | Adaptive Response; Analytic Monitoring; Contextual Awareness; Coordinated Protection; Deception; Diversity; Dynamic Positioning; Non-Persistence; Privilege Restriction; Realignment; Redundancy; Segmentation; Substantiated Integrity; Unpredictability |
| Approaches | Implementation approaches under each technique (defined in Volume 2 Table D-4) |
| Design principles | Strategic principles (for example, assume compromised resources and reduce attack surfaces) and structural principles that guide architecture |
NIST's abstract says organisations can select, adapt and use some or all of these constructs. Volume 2 is a menu, not a checklist: choose the objectives that matter for the mission, then the techniques that serve them.
Identity and NHI requirements
Neither volume is an identity standard, but their principles fall hardest on the machine identities a design creates. Every service, pipeline, integration and agent added in the Design Definition and Implementation processes brings credentials and privileges with it.
| Principle or technique | Source | What it means for non-human identities |
|---|---|---|
| Least Privilege | Vol. 1 Appendix E | Each workload, service account or agent gets only the permissions its function needs, designed in rather than trimmed later. See the Least Privilege Techniques Guide. |
| Least Persistence | Vol. 1 Appendix E | Short-lived tokens and just-in-time credentials instead of standing keys. See the Dynamic Secrets and Ephemeral Credentials Guide. |
| Distributed Privilege | Vol. 1 Appendix E | No single automation identity able to change production, approve and deploy; require two parties for critical actions |
| Mediated Access | Vol. 1 Appendix E | Workloads reach secrets and data through a policy enforcement point (a vault, a broker, a gateway), not directly |
| Privilege Restriction | Vol. 2 technique | Restrict privileges by attributes and context; limit what a compromised identity can reach |
| Non-Persistence | Vol. 2 technique | Rebuild workloads and reissue their identities regularly so stolen credentials expire with them |
| Substantiated Integrity | Vol. 2 technique | Verify the identity and integrity of software and workloads before trusting them, for example signed artefacts and workload attestation |
| Segmentation | Vol. 2 technique | Separate identity planes, so that a CI/CD identity cannot reach the identity provider's admin plane |
The Snowflake customer breach is a design lesson as much as an operational one: single-factor passwords that never expired, no network allow lists and service users with no clear owner meant that one stolen password was enough to export a data warehouse. Requirements written under the Stakeholder Needs and System Requirements processes are the place to stop that, not the post-incident review. See the Non-Human Identity (NHI) Guide.
Implementation steps
- Start with protection needs. For each system, list the assets (data, functions, credentials, the system's own trust anchors) and the losses that matter. This is the Vol. 1 problem context and the input to everything else. See the NIST SP 800-30 Risk Assessment Guide.
- Turn needs into security requirements. Write testable requirements in the same backlog as functional ones, including machine identity requirements (credential type, lifetime, permission scope).
- Pick principles that matter for this system. Choose a handful of Appendix E principles and Volume 2 objectives that fit the mission. Record the choice in the architecture decision record.
- Threat-model the architecture. Review trust boundaries, privilege paths and failure modes against the chosen principles during System Architecture Definition. See the AI Agent Threat Modelling Guide for agent-based designs.
- Design for compromise. For critical functions, apply Volume 2 techniques: segmentation, non-persistence, redundancy, analytic monitoring. Decide how the system degrades and how it is reconstituted from trusted state.
- Build the trustworthiness case. Collect evidence as you go: design reviews, test results, code analysis, supplier attestations. Commensurate Rigor means more evidence for more critical components.
- Verify and validate. Verification checks the system meets its security requirements; validation checks it meets the stakeholder protection needs in its real environment. Run both before Transition.
- Operate, maintain and dispose. Keep the design assumptions under review in operation, and plan secure disposal, including revocation of the system's credentials and keys. See the Media Sanitisation Guide.
Small versus large organisations
- Small teams: fold the processes into existing delivery. A one-page protection needs statement, a short principles list in the architecture template and a design review gate cover most of the value.
- Large or regulated estates: map Vol. 1 processes to your system development life cycle, set evidence expectations by criticality, and reserve full Volume 2 analysis for mission-critical systems. Over-applying Volume 2 to every system is expensive and dilutes attention.
Evidence and assessment
SP 800-160 does not define its own assessment. Evidence is assessed through SP 800-53 controls (with SP 800-53A procedures), RMF authorisation, or customer and regulator reviews. Useful artefacts:
- Protection needs statement: assets, losses and their significance for the system.
- Security requirements traceability: from stakeholder needs to system requirements to tests.
- Architecture decision records: principles chosen, trade-offs accepted, residual risk.
- Threat models and design review records for each major change.
- Verification and validation results, including penetration test and resilience test outcomes.
- Trustworthiness or assurance case: the argument and evidence that the system meets its protection needs.
Metrics
- Percentage of new systems with a documented protection needs statement before design approval.
- Percentage of security requirements traced to a passing verification test.
- Security defects found after release that trace to design rather than implementation (falling over time).
- Percentage of machine identities created with a defined scope, owner and lifetime at design time.
- For mission-critical systems, time to reconstitute from trusted state in exercises against the target.
Mapping to other frameworks
| Framework | Where SP 800-160 lands |
|---|---|
| NIST SP 800-53 Rev. 5 | SA-8 Security and Privacy Engineering Principles and enhancements SA-8(1) to SA-8(33); SA-3 System Development Life Cycle; SA-4 Acquisition Process; SA-17 Developer Security and Privacy Architecture and Design; PL-8 Security and Privacy Architectures; SR-2 Supply Chain Risk Management Plan |
| SP 800-53 controls supporting Vol. 2 techniques | SC-7 Boundary Protection and SC-39 Process Isolation (segmentation); SI-14 Non-persistence; SC-29 Heterogeneity (diversity); SC-26 Decoys and SC-30 Concealment and Misdirection (deception); SI-7 Software, Firmware, and Information Integrity (substantiated integrity); SC-36 Distributed Processing and Storage and CP-9 System Backup (redundancy); AC-6 Least Privilege (privilege restriction) |
| NIST RMF (SP 800-37) | Systems security engineering feeds the Prepare, Select and Implement steps. See the NIST Risk Management Framework (SP 800-37) Guide. |
| NIST CSF 2.0 | PR.IR-03 mechanisms to achieve resilience requirements; PR.PS-06 secure software development practices; GV.OC-04 critical objectives and services understood |
| ISO/IEC/IEEE 15288 | The source of the system life cycle processes; NIST lists it as a companion reference |
| NIST SSDF (SP 800-218) | Software-level secure development practices within the Implementation process. See the NIST Secure Software Development Framework (SSDF, SP 800-218) Guide. |
A mapping note: the SA-8 enhancement names come from the original 2018 Volume 1, so some differ from the Rev. 1 principle names. Rev. 1 says Protective Defaults where SA-8(23) says Secure Defaults, and Protective Failure and Protective Recovery where SA-8(24) says Secure Failure and Recovery; Least Privilege (SA-8(14)), Clear Abstractions (SA-8(1)) and Reduced Complexity (SA-8(7)) match directly. Keep a small crosswalk so engineers and assessors use the same words.
Common pitfalls
- Treating 800-160 as a control list: teams look for "the 800-160 controls" and miss that the value is in processes and principles applied during design.
- Security requirements written after the architecture: requirements reverse-engineered from a finished design justify it rather than shape it.
- Machine identities left to implementation: service accounts and tokens appear during build with whatever rights make the tests pass. Least privilege has to be a design-time requirement.
- Recovery that depends on the compromised system: backups and recovery tooling share the identity provider or credentials of the production system, so an attacker who owns one owns both. Volume 2 segmentation and redundancy exist for this.
- Applying all 14 techniques everywhere: cost rises, systems become harder to operate, and complexity itself becomes a weakness, against the Reduced Complexity principle.
- No evidence trail: good design decisions that were never recorded cannot support an authorisation or a customer assurance request.
Practitioner checklist
- Require a protection needs statement before any new system's architecture is approved.
- Put security and machine identity requirements in the same backlog as functional requirements.
- Add a principles section to the architecture template, drawing on Vol. 1 Appendix E.
- Apply Volume 2 objectives and techniques to mission-critical systems, chosen for the mission, not all of them.
- Keep a crosswalk from Vol. 1 Rev. 1 principle names to SP 800-53 SA-8 enhancements.
- Design recovery paths that do not share identities or credentials with the systems they recover.
- Collect trustworthiness evidence during delivery, scaled to criticality.
- Include credential and key revocation in the Disposal process.
Standards and references
- NIST: SP 800-160 Vol. 1 Rev. 1, Engineering Trustworthy Secure Systems
- NIST: SP 800-160 Vol. 2 Rev. 1, Developing Cyber-Resilient Systems: A Systems Security Engineering Approach
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls
- NIST: SP 800-37 Rev. 2, Risk Management Framework
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-218, Secure Software Development Framework
Related NHI Mgmt Group resources: Cyber Resilience Guide · NIST SP 800-53 Guide · NIST Risk Management Framework (SP 800-37) Guide · Least Privilege Techniques Guide