The real-world evidence from industry adoption of STPA for Security (STPA-Sec)
Why Are Organizations Adopting STPA-Sec?
Organizations adopt STPA-Sec because modern losses often emerge from dysfunctional interactions among software, hardware, operators, automation, suppliers, policies, and assumptions, not simply from broken parts or known attack paths. STPA-Sec gives stakeholders a disciplined way to define secure mission behavior before architecture is frozen and before detailed threat-enumeration methods have enough design information to work well.
Three Reasons Organizations Adopt STPA-Sec
1
STPA-Sec identifies functional and interaction-driven vulnerabilities, including scenarios where components operate as specified but the combined behavior is unsafe, insecure, or mission-degrading.
STPA-Sec moves security left of architecture, making stakeholder losses, hazards, constraints, and mission-critical behaviors explicit during concept and requirements work.
STPA-Sec produces engineering artifacts: losses, hazards, constraints, control structures, insecure control actions, loss scenarios, requirements, test objectives, wargame inputs, and assurance evidence.
Used this way, STPA-Sec improves both the quality of security requirements and the relevance of downstream cyber controls and tests.
One Picture of Security for Every Team
STPA-Sec gives executives, systems engineers, design engineers, and cyber testers the same mission-centered picture of security: what must not be lost, what system behavior must be controlled, and what evidence will prove the system is secure enough for its intended purpose.
Leadership
Connects cybersecurity investment to mission assurance, accountable risk decisions, supplier expectations, and defensible evidence.
Engineers
Turns security from abstract threats and control catalogs into design constraints that can shape the system before expensive rework is locked in.
Cyber Testers and Red Teams
Identifies the control paths, feedback weaknesses, timing conditions, and mission-impact scenarios that deserve priority.
“The objective long-term, is to make SP 800-160 and STPA-Sec the rule rather than the exception with regard to building trustworthy secure systems.”
— Ron Ross, ROSSSECURE Systems Security Advisory Services, lead NIST author of the SP 800-160 systems security engineering guidance
Evidence from Industry: STPA-Sec Benefits
STPA-Sec’s core advantage is its ability to identify functional vulnerabilities: scenarios where the intended logic, control authority, feedback, timing, trust relationships, or human decision process can lead to loss even when no component “fails” in the traditional sense. This is especially important for autonomous, software-intensive, and mission-critical systems.
The most cost-effective way to improve security is to find security-relevant requirements, assumptions, and architectural flaws before the design is fixed. STPA-Sec is suited to this pre-architecture phase because it analyzes mission losses, functional control, feedback, trust assumptions, and constraints rather than waiting for a finished component architecture.
A DoD pilot identified vulnerable build/update-process control scenarios before the public SolarWinds disclosure; the scenarios were later analogous to a major software-supply-chain compromise pattern.
Read the full example
A compelling example comes from a DoD-sponsored software supply-chain pilot conducted before the public SolarWinds disclosure. The analysis did not search for a specific malware signature. It examined the control structure of the build, integration, release, and update process, and identified vulnerable classes of control scenarios in the supply chain.
The appropriate conclusion is that the pilot identified vulnerable build/update process scenarios that were later analogous to the SolarWinds compromise pattern. The value was not clairvoyance; it was identifying classes of vulnerable control scenarios before the attack became public.
The engineering lesson: STPA-Sec can reveal security weaknesses in the authority, feedback, trust assumptions, update paths, and control enforcement of trusted processes, before the adversary’s exact technique is known.
Traditional methods: traditional certification and threat controls already existed. STPA-Sec: a pilot before the SolarWinds disclosure. Outcome: identified vulnerable build/update control scenarios analogous to SolarWinds-class compromise patterns; demonstrates different coverage.
Supports and Enhances Cybersecurity Test and Evaluation of Complex Systems
“System Theoretic Process Analysis for Security, which links vulnerabilities to operational impact. This process is integral to the GBSD cybersecurity plans, and provides a rigorous analytical basis for test design and analysis.”
“STPA-Sec has proven valuable not only to test planning but has positively influenced design decisions to enhance safety and security… What a great use of model-based systems engineering to partner with prototype developers to find and fix critical control and security issues early… We’ve seen meaningful value and system design impact from only two days of effort.”
Director of Test Operations (USAF Colonel), Air Force Operational Test and Evaluation Center (AFOTEC) Exchange, Issue 7, October 2021
In one comparative study, STPA-Sec with attack trees outperformed any single SAE J3061-era method assessed on process, quality, and quantity of cyber-physical threats identified.
Different methods found different threat and hazard sets. STPA-Sec was valuable for interaction-driven scenarios, insecure control actions, and enforceable security constraints.
Improves Red Teaming of Gen AI Systems
“STPA-Sec steers red teams toward a more holistic view of the system, including interdependencies across components, rather than focusing exclusively on attacking the GenAI component… STPA-Sec enables blue teams to anticipate red team attacks and to develop mitigations.”
“Cybersecurity is a growing area of Akamai’s business, one where IT organizations seek expert help repeatedly. Solutions that work for private companies can also work for federal agencies, specifically:… Protecting federal data through role and policy-based access controls. Encouraging ‘security by design’ through systems analysis methodologies like STPA-Sec.”
STPA-Sec derives security controls top-down from strategic unacceptable losses to circuit-level hardware implementations. It treats security as a systemic control problem, enabling end-to-end traceability that allows stakeholders to weigh high-assurance controls directly against nation-state (OC5) threat prevention.
Applicability to Securing System-of-Systems
“STPA-Sec is the Foundation for Securing System-of-Systems. We are Building the STITCHES Secure Integration Process on top of it… It clearly enables early assessment of mission operational risk and provides the design guidance to our engineers.”
USAF, GS-15 Program Manager, USAF Integration Prime Program Review
A safety analysis with STPA, not STPA-Sec, on the H-II Transfer Vehicle. STPA found all the causes the fault tree analysis found, plus additional causal factors, most of them design flaws and software.
STPA provides a sociotechnical lens for policy, organizational, human, sequencing, and subsystem-state conditions that conventional component-centric tools can overlook.
Many defects are introduced in requirements and design but discovered much later, when correction requires redesign, retesting, integration rework, certification updates, or operational mitigation.
Read more
Defects at Each Stage of the Life Cycle
Requirements/design: many defects originate here, including missing requirements, flawed assumptions, conflicting goals, and incomplete security policies.
Test/integration: many defects are first discovered here, when changes are more disruptive and the cost of correction is higher.
Operations/sustainment: late discovery can require patches, workarounds, retrofits, recertification, or mission limitations; cost is not only financial but operational.
STPA-Sec shifts discovery left by turning mission losses and insecure system states into explicit constraints, requirements, design questions, and test objectives during concept and requirements work.
STPA is top-down, can start in early concept analysis, includes software and humans, and identifies non-failure scenarios. Outputs can drive requirements, architecture, test planning, leading indicators, and MBSE.
Security and safety can be framed as loss-prevention problems grounded in systems theory. Actor intent matters, but the engineering focus should be the controllable system design and constraints.
Systems security engineering emphasizes stakeholder objectives, protection needs, requirements, architecture, verification, validation, assurance, and trustworthiness across the system life cycle.
Cyber resiliency is a systems engineering specialty used with security and resilience engineering. STPA-Sec helps identify the mission functions and loss scenarios resiliency techniques must preserve or recover.
DO-356A provides methods and guidelines within the airworthiness security process. STPA-Sec can support early threat-condition, constraint, requirement, and scenario generation, but approval remains program-specific.
Security-Specific STPA Additions
What STPA-Sec Adds to STPA
STPA-Sec Phase 1 and Phase 4 materials
STPA-Sec adds problem framing, security-specific hazards, reference-monitor/security-model reasoning, insecure control actions, security scenarios, and wargaming to the STPA workflow.
Implementation Evidence
Where STPA-Sec Has Been Used
Real-world STPA-Sec implementation examples
DoD, aerospace, and cyber-test examples show practical use in concept analysis, test planning, mission-defense analysis, and architecture trades. This is practitioner evidence supporting adoption.
Security as a Control Problem
STPA-Sec’s value comes from its underlying causality model: STAMP. Traditional security methods often begin with threats, vulnerabilities, or component failures. STPA-Sec begins with unacceptable losses and asks what system behavior must be constrained so that those losses do not occur. This top-down framing is especially useful for complex systems where secure behavior depends on coordination, timing, authority, feedback, and trust.
The Control Loop and Process Models
Every STPA-Sec analysis is built around control loops. A controller, which may be a human, software, automation, an AI/ML component, a manager, a supplier, an operator, or a security mechanism, issues control actions to a controlled process and receives feedback that shapes its process model: its internal belief about the system state and what action is appropriate.
An adversary does not need to “break” a component if they can manipulate feedback, timing, trust assumptions, authority, or a controller’s process model.
Feedback: spoofed, blocked, or delayed. The controller keeps acting on a picture of the system that is no longer true, and no component has failed.
Control actions: tampered with, blocked by a denial of service, or delivered at the wrong time. The controller sends the right command, and the process receives something else, or nothing.
Process model: malformed data or a false trust assumption corrupts what the controller believes. Its logic then works as designed and still makes an insecure decision.
Authority: a controller without authority issues commands, or impersonates one that has it. The controlled process acts on them unless the design gives it a way to tell.
Policy and oversight: policy gaps, missing responsibilities, or misplaced trust higher up leave a security constraint that no one enforces.
STPA-Sec then looks for control actions that are insecure in a particular context: a control action not provided, provided when it should not be, provided too early, too late, or out of order, or stopped too soon or applied too long. The loss scenarios work out how each could arise, including through the adversary actions above. This is how STPA-Sec covers spoofing, tampering, denial of service, unauthorized control, malformed data, and policy gaps as ways to disrupt secure function.
Socio-Technical Scope
Traditional security analysis often stops at the technical perimeter. STPA-Sec includes operators, maintainers, managers, suppliers, incentives, procedures, policy, and organizational control structures. This is not optional for modern security: many losses arise from flawed assumptions, conflicting goals, poor feedback, missing responsibilities, or misplaced trust across the socio-technical system.
STPA-Sec Compared with Other Methods
STRIDE is valuable for enumerating technical threat categories; attack trees are useful for exploring attack paths; CORAS helps communicate risk; PASTA connects application threats to business impact; and FMEA/FMECA help analyze known failure modes. STPA-Sec strengthens these methods by clarifying what system behavior must never occur, why it matters, and how that behavior could arise through interactions.
Question
STRIDE
STPA-Sec
Foundation
Threat categories
Systems and control theory; STAMP
Analytical Object
Components, data flows, trust boundaries
Losses, hazards, constraints, control loops, process models
View of Losses
Result of threats exploiting weaknesses
Result of uncontrolled interactions or violated constraints
Applicability
Best once architecture/data flows exist
Useful from concept through operations; can start before detailed architecture
Best For
Finding known technical threat classes
Generating mission-centered constraints, scenarios, requirements, tests, and assurance claims
Question
Attack Trees
STPA-Sec
Foundation
Attacker goals and Boolean decomposition
Systems and control theory; STAMP
Analytical Object
Attack paths and enabling conditions
Losses, hazards, constraints, control loops, process models
View of Losses
Result of an attacker reaching a goal
Result of uncontrolled interactions or violated constraints
Applicability
Useful for detailed attack-path exploration
Useful from concept through operations; can start before detailed architecture
Best For
Visualizing multi-step intrusion paths
Generating mission-centered constraints, scenarios, requirements, tests, and assurance claims
Question
PASTA
STPA-Sec
Foundation
Risk-centric application threat modeling
Systems and control theory; STAMP
Analytical Object
Business objectives and application stack
Losses, hazards, constraints, control loops, process models
View of Losses
Business impact from attack
Result of uncontrolled interactions or violated constraints
Applicability
Useful for application/security program planning
Useful from concept through operations; can start before detailed architecture
Best For
Connecting technical threats to business risk
Generating mission-centered constraints, scenarios, requirements, tests, and assurance claims
Question
CORAS
STPA-Sec
Foundation
Risk modeling and asset/context diagrams
Systems and control theory; STAMP
Analytical Object
Assets, threats, vulnerabilities, treatments
Losses, hazards, constraints, control loops, process models
View of Losses
Result of vulnerabilities and unwanted events
Result of uncontrolled interactions or violated constraints
Applicability
Useful for communicating risk and treatment options
Useful from concept through operations; can start before detailed architecture
Best For
Aligning cyber risk with stakeholders
Generating mission-centered constraints, scenarios, requirements, tests, and assurance claims
Question
FMVEA/CHASSIS
STPA-Sec
Foundation
Failure modes and effects
Systems and control theory; STAMP
Analytical Object
Functions, components, failure modes
Losses, hazards, constraints, control loops, process models
View of Losses
Result of failures or degraded functions
Result of uncontrolled interactions or violated constraints
Applicability
Useful when design/function decomposition is known
Useful from concept through operations; can start before detailed architecture
Best For
Known failure and degradation modes
Generating mission-centered constraints, scenarios, requirements, tests, and assurance claims
Method
Foundation
Analytical Object
View of Losses
Applicability
Best For
STRIDE
Threat categories
Components, data flows, trust boundaries
Result of threats exploiting weaknesses
Best once architecture/data flows exist
Finding known technical threat classes
CORAS
Risk modeling and asset/context diagrams
Assets, threats, vulnerabilities, treatments
Result of vulnerabilities and unwanted events
Useful for communicating risk and treatment options
Aligning cyber risk with stakeholders
FMVEA/ CHASSIS
Failure modes and effects
Functions, components, failure modes
Result of failures or degraded functions
Useful when design/function decomposition is known
Known failure and degradation modes
Attack Trees
Attacker goals and Boolean decomposition
Attack paths and enabling conditions
Result of an attacker reaching a goal
Useful for detailed attack-path exploration
Visualizing multi-step intrusion paths
PASTA
Risk-centric application threat modeling
Business objectives and application stack
Business impact from attack
Useful for application/security program planning
Connecting technical threats to business risk
STPA-Sec
Systems and control theory; STAMP
Losses, hazards, constraints, control loops, process models
Result of uncontrolled interactions or violated constraints
Useful from concept through operations; can start before detailed architecture
Generating mission-centered constraints, scenarios, requirements, tests, and assurance claims
Use STPA-Sec with Existing Methods
Systems Security Engineering (SSE) is the broader engineering discipline that integrates security into the systems engineering lifecycle; cybersecurity supplies essential tactics, tools, controls, monitoring, hardening, testing, and response capabilities within that larger engineering strategy. In practical terms, cybersecurity helps defend the system, while SSE helps define and engineer the secure behavior the system must deliver. STPA-Sec provides the method that connects those two worlds: it translates mission losses, hazards, constraints, interfaces, control actions, trust assumptions, and architecture trades into requirements, verification objectives, cyber test priorities, red-team scenarios, and assurance evidence.
First
STPA-Sec Defines
Losses
Hazards
Constraints
Control structures
Insecure control actions
Loss scenarios
Once design details are available
Detailed Methods Refine the Scenarios
STRIDE
Attack trees
Architecture analysis
Secure development
Red-team testing
Vulnerability analysis
Throughout
Frameworks Document the Evidence
RMF
ISO/SAE 21434
DO-326A/DO-356A
ISO/IEC/IEEE 15288-aligned systems engineering
Other program-specific frameworks
For compliance, verification, validation, and assurance evidence.
The Front End, Not a Replacement
STPA-Sec is not a replacement for secure coding, cryptography, hardening, vulnerability management, penetration testing, RMF, ISO/SAE 21434, DO-326A/DO-356A, or operational monitoring. STPA-Sec is best used as the front-end systems security analysis that tells those activities what mission behavior must be protected, what constraints must be enforced, and which scenarios deserve priority.
Known Limitations
Published safety/security co-analysis work notes that STPA-Sec is strongest for high-level concept analysis, and may need complementary methods for detailed network architecture, standards conformance, risk rating, vulnerability analysis, and implementation verification.
STPA-Sec gives existing security methods a mission-centered loss model and traceable behavioral constraints.
Briefing Your Leadership
We offer customized briefings to introduce STPA-Sec to your organization or leadership as one of our professional services. Contact us to schedule a session.
Key standards, papers, and handbooks underpinning STPA-Sec:
Leveson, Nancy G., and John P. Thomas. STPA Handbook. MIT Partnership for Systems Approaches to Safety and Security, 2018.
Young, William, and Nancy G. Leveson. “An Integrated Approach to Safety and Security Based on Systems Theory.” Communications of the ACM 57, no. 2 (2014): 31–35. doi:10.1145/2556938
SAE J3307_202503, System Theoretic Process Analysis (STPA) Standard for All Industries, 2025; SAE J3187_202305, STPA Recommended Practices, 2023.
RTCA DO-356A, Airworthiness Security Methods and Considerations, 2018; DO-326A/ED-202A airworthiness security process context.
Sidhu, Amardeep Singh. “Application of STPA-Sec for Analyzing Cybersecurity of Autonomous Mining Systems.” MIT, 2018. MIT DSpace
Sahay, Rishikesh, et al. “A Comparative Risk Analysis on CyberShip System with STPA-Sec, STRIDE and CORAS.” Computers & Security 128 (2023) 103179. doi:10.1016/j.cose.2023.103179
Where to Go Next
Keep Learning
The introductions to the methods, the evidence for using them, and the industry pages are all free.
