When a cloud environment is breached, the post-mortem almost never reads like a thriller. There is rarely a novel exploit or a zero-day. There is an over-permissioned role, a long-lived access key in a place it should not have been, a storage bucket opened to the world by a misconfiguration or a policy exception nobody revisited, or a trust relationship between accounts that was broader than anyone intended. The techniques are well understood and the fixes are unremarkable. What makes cloud incidents expensive is not their sophistication; it is that the weaknesses sat in the identity and configuration layer, where a single misstep can hand an attacker the whole environment, and where most organisations are still threat modeling as though they were defending a data centre.
For a security leader, that is the entire point. The cloud does not just move your systems; it moves where your risk concentrates and where your control budget earns its return. A threat model carried over unchanged from on-premises thinking will diligently protect the application tier while the actual exposure sits in the control plane it never looked at. This article is about that shift: what changes, what you are still accountable for, and what to demand of a cloud threat model.
Shared responsibility is an accountability question
Every provider publishes a shared-responsibility model, and most leaders can recite the headline: the provider secures the cloud, you secure what you put in it. Where that line sits moves with the service model: on IaaS you still own the operating system and everything above it, while PaaS and SaaS shift more of the stack to the provider. So the first question for any system is which model it actually runs on. But the part that matters is less comfortable. Whatever the model, the security decisions that cause real breaches — who can assume which role, which data is encrypted and with whose keys, what is exposed to the internet, whether anyone is watching the logs — sit on your side of the line. Moving to the cloud does not transfer that accountability; it concentrates it into configuration, where mistakes are fast to make, invisible until exploited, and easy to make at scale.
That is a board-level framing worth being precise about, because it is the first thing examined after an incident. “The provider was responsible” is not a defence for a public bucket or an over-scoped role. Those were your decisions, made in your account, and a mature cloud threat model treats them as the primary risk surface rather than a footnote.
Identity is the perimeter, and that is a governance problem
In a data centre, the network edge did a great deal of your security work; something inside the perimeter was, by default, somewhat trusted. In the cloud most of that edge is gone. The primary boundary of your environment becomes identity: who and what can authenticate, and what they are permitted to do once they have. Network segmentation and exposure controls still matter, but they no longer carry the load alone. This is why the most damaging cloud attacks are not perimeter breaches in the old sense; they are identity and privilege problems: failures of identity and access management, or IAM, the layer that governs both.
The patterns recur across every environment I assess. Roles accrue permissions over time and are almost never trimmed, so a foothold in a minor component inherits far more access than its function requires. Long-lived credentials persist in code, configuration, and developer machines, each one a permanent key rather than a temporary one. And trust relationships between accounts (the mechanism that lets one part of your estate act in another) are drawn too broadly, so a compromise in a low-value account reaches into a high-value one. The concrete attack paths follow from these: a server-side request forgery that reaches an instance’s metadata service (where IMDSv1, which does not require the session token IMDSv2 enforces, still answers on far too many AWS estates) and walks away with its role credentials; a modest initial access that escalates by assuming a more privileged role the model never expected it to reach; a leaked key that unlocks storage no one realised that key could touch. None of these require brilliance. They require that somebody, somewhere, granted more trust than they meant to — and that no threat model caught it.
The leadership consequence is that cloud security spending returns the most when it is aimed at identity: least-privilege role design, the elimination of long-lived keys in favour of short-lived credentials issued to the workload itself, meaning IAM roles with temporary STS credentials on AWS, managed identities and workload identity federation on Azure, and service accounts with Workload Identity Federation on GCP rather than static access keys; tight scoping of cross-account trust; and enforced multi-factor authentication for your human identities. A threat model that spends its energy on the application and treats IAM as plumbing is optimising the wrong surface.
What a cloud threat model must cover, and demand
The categories of risk are not mysterious; the value is in insisting that a model addresses each rather than defaulting to the application layer. A cloud threat model that has earned its keep will have examined identity and access as its centre of gravity; storage and data protection, including what is public, what is encrypted, and who holds the keys; the network and its exposure, including what is reachable from the internet that should not be; the baseline configuration and the defaults left unchanged; the state of logging and monitoring, because an environment you cannot see is one you cannot defend; and resilience, because availability failures in consumption-billed services can be a security and a financial event at once.
Crucially, the mitigations have to land in the provider’s own terms. “Apply least privilege” is not a control; it is an aspiration. The model has to name the mechanism (the specific policy, the key management service, the network rule, the audit and detection service) for the provider you actually run on, whether that is AWS, Azure, or GCP. A finding that cannot be handed to a team as a concrete, implementable change in their environment has not been finished. When you review a cloud threat model, this is the tell: generic best-practice language means the work stopped early; provider-specific, verifiable controls mean it was done.
Prioritise by business impact, including the bill
Cloud gives risk prioritisation an extra dimension that leaders should not overlook. The familiar likelihood-by-impact judgement still applies (a likely threat with critical impact is not in the same conversation as a rare one with minor impact), but “impact” in the cloud includes direct financial exposure that is unusually immediate. Elastic, consumption-billed services mean that a denial-of-service or a runaway compromise is not only an availability incident; it is a cost incident that can run up a bill in hours. Data-protection failures carry regulatory and disclosure costs. Framing cloud risk in these terms is what lets you allocate control spending where it actually protects the business, rather than spreading it evenly across threats that do not carry equal weight.
What good looks like
A cloud environment changes continuously, often through infrastructure-as-code, and a threat model that is refreshed once a year is describing a system that no longer exists. The mature pattern is to bring modeling close to the way the environment actually changes: to treat a significant change to the infrastructure definition as a trigger for review, and to push as much of the checking as possible into automated policy that runs against the infrastructure code before it deploys. The threat model sets the intent — these are the trust boundaries, these are the controls that must hold — and policy-as-code enforces that intent continuously, so drift is caught by machines rather than discovered by attackers.
The through-line across all of this is the same one that governs threat modeling anywhere, pointed at the layer the cloud made most dangerous. The identity and configuration plane has no network edge to hide behind, changes constantly, and concentrates enormous blast radius in decisions that are trivial to get wrong. Model that plane with the seriousness you would give the application, insist on controls named in your provider’s own terms, and tie the whole thing to the way your environment actually changes. That is the difference between a cloud threat model that protects the business and one that documents the parts an attacker was never going to bother with.
Final article in a three-part series. Start with Threat Modeling Explained: A Security Leader’s Guide, then Threat Modeling in Practice: Building a Program Your Teams Actually Run.