The method stays the same, but the diagram grows. For cloud applications, add shared responsibility, managed services, multi-tenancy, identity federation, dynamic infrastructure and data residency. The OWASP Threat Modeling Cheat Sheet says STRIDE and data flow diagrams need adapting for these.
What the OWASP guidance lists
The cheat sheet's cloud section names these adaptations: shared responsibility, managed services, multi-tenancy, identity federation, dynamic infrastructure, and compliance or data residency.
What to add to the diagram
| Cloud factor | What to draw | Threat question |
|---|---|---|
| Shared responsibility | A line showing what the provider secures and what you do | Which controls are ours, and are they in place? |
| Managed services | Each service as an element with its own boundary | Who can call it and with what permissions? |
| Multi-tenancy | Where tenants share components | Can one tenant reach another's data? See tenant isolation |
| Identity federation | Identity providers and token flows | What if a token is stolen or misused? |
| Dynamic infrastructure | Autoscaled and short lived components | Do controls apply to new instances automatically? |
| Data residency | Regions where data is stored and processed | Does data leave an allowed region? |
What changes in the STRIDE walk
Spoofing is often about identities for services and roles, not only people. Information disclosure includes misconfigured storage and overly broad permissions. Denial of service includes cost and quota exhaustion on managed services. Elevation of privilege includes role chaining and permissions that grow over time.
These are practical examples, not quotes from the guidance. Test them against your own estate.
Questions to add
- Which parts of this are the provider's job, and where is that written down?
- Which identities can act in this account, and who reviews them?
- What happens when a new instance or function starts: does it get the same controls?
- Where does data sit, and can it move?
- Who can change the infrastructure definition, and is that change reviewed?
Keep the shared line honest
Provider documentation says what the provider covers. Read it for each service in your diagram and note any gap. The Kubernetes security overview, for example, states that Kubernetes does not own vendor security and points to each provider's guidance. That pattern applies broadly: find the provider's statement and record it.
Quick check
Do I need a different method for cloud?
No. Keep STRIDE and data flow diagrams, and extend them with the cloud factors above.
Who is responsible for the managed service I use?
It is shared. Read the provider's documentation for that service and record which controls are yours.
A note on tooling
Safeguard covers asset discovery, compliance and evidence automation, SBOM and dependency scanning, and policy gates, which support the checking side of cloud work. Try the free scan.
Sources
Last reviewed: 19 October 2026.
