Most cloud breaches do not defeat the provider: they log in with a valid identity, a leaked access key or a role that can do far more than its job needs. In the Cloud Security Alliance's Top Threats to Cloud Computing 2026 survey of more than 500 experts, inadequate identity and access management ranked first and provider infrastructure concerns dropped off the list. This list ranks ten cloud risks by our judgement of likelihood and impact, with an incident where one fits and the first fix. It is for cloud security engineers, platform teams and landing zone owners. For the full picture, see the Cloud Security Guide.
The Top 10 at a glance
- Over-privileged and poorly governed cloud identities
- Long-lived access keys and leaked secrets
- Workload credential theft through metadata services
- Misconfiguration and uncontrolled change
- Public storage and accidental data disclosure
- Exposed interfaces, APIs and management planes
- Third-party, supply chain and CI/CD access
- Limited visibility: shadow accounts, unmonitored workloads and logging gaps
- Unpatched workloads, images and functions
- Extortion, destruction and resource hijacking
| # | Risk | How attackers use it (ATT&CK v20) | First fix |
|---|---|---|---|
| 1 | Over-privileged identities | Sign in with valid cloud accounts and grant themselves roles (T1078.004, T1098.003) | Phishing-resistant MFA; no standing admin |
| 2 | Long-lived keys and leaked secrets | Use keys found in code and .env files (T1078.004, T1098.001) | Block key creation by policy; scan and rotate |
| 3 | Workload credential theft | Ask the metadata API for role credentials (T1552.005) | IMDSv2 only; one narrow role per workload |
| 4 | Misconfiguration and change | Exploit what was opened by hand (T1190, T1578) | Infrastructure as code with policy checks |
| 5 | Public storage | List and read open buckets and links (T1619, T1530) | Block public access at organisation level |
| 6 | Exposed interfaces | Exploit exposed consoles and APIs (T1190, T1651) | Private endpoints; authenticate every API |
| 7 | Third-party and pipeline access | Abuse trusted suppliers and app tokens (T1199, T1195, T1528) | Federated, scoped, expiring access |
| 8 | Limited visibility | Work in unused Regions; switch off logging (T1535, T1685) | Organisation-wide logging to a separate account |
| 9 | Unpatched workloads | Exploit public-facing workloads and functions (T1190, T1648) | Agentless scanning; exposed workloads first |
| 10 | Extortion and hijacking | Encrypt, delete, exfiltrate or mine (T1486, T1485, T1537, T1496.004) | Immutable backups; budget alerts |
1. Over-privileged and poorly governed cloud identities
The risk: users, roles and service principals hold broad built-in roles (Owner, Editor, AdministratorAccess) they rarely use, console sign-in lacks phishing-resistant MFA, and hybrid sync accounts bridge on-premises and cloud directories (T1078.004 Cloud Accounts, T1098.003 Additional Cloud Roles, T1556.007 Hybrid Identity).
Why it matters: one valid identity with wide permissions is the whole estate. In the Snowflake breach, infostealer credentials without MFA unlocked 165 customer data warehouses; in the Storm-0501 hybrid cloud attacks, stolen Entra Connect sync credentials carried ransomware operators into the cloud.
The fix: federate humans through one identity provider with phishing-resistant MFA, replace standing administrator roles with just-in-time elevation, and cut permissions to what usage data (IAM last accessed information, Access Analyzer unused access findings, CIEM) shows is used. See the Cloud PAM and CIEM Guide.
2. Long-lived access keys and leaked secrets
The risk: IAM user access keys, service account key files, storage account keys and connection strings that never expire, copied into code, images, CI variables and .env files. Intruders also add their own credentials to service principals to persist (T1098.001 Additional Cloud Credentials).
Why it matters: a static key works from anywhere until revoked. In the Toyota T-Connect key exposure a key sat on public GitHub for five years, and the 230 Million AWS Cloud Environments campaign harvested keys from exposed .env files at scale.
The fix: AWS says "Where possible, we recommend relying on temporary credentials instead of creating long-term credentials such as access keys." In Google Cloud, enforce the "Disable service account key creation" and "Disable service account key upload" constraints at the organisation root and set Service Account Key Exposure Response to DISABLE_KEY, noting that "Google Cloud doesn't guarantee that it will detect leaked keys." Scan code and images for secrets and follow the Leaked Credential Response Playbook when one escapes.
3. Workload credential theft through metadata services
The risk: a virtual machine, container or function carries a role far broader than its job, and an application flaw lets an attacker request that role's temporary credentials from the instance metadata service (T1552.005 Cloud Instance Metadata API).
Why it matters: temporary credentials only help if the role behind them is narrow. In the Capital One breach, server-side request forgery through a firewall retrieved role credentials that could read storage holding data on 106 million people.
The fix: require IMDSv2 (token required) on every EC2 instance, block metadata access from pods that do not need it, give each workload its own role, managed identity or service account, and use workload identity federation for workloads outside the provider. Microsoft notes managed identities "eliminate the need for developers to manage these credentials", but user-assigned ones "Must be explicitly deleted." See the Cloud Workload Identity Guide.
4. Misconfiguration and uncontrolled change
The risk: security groups open to 0.0.0.0/0, encryption or logging switched off, and resources changed by hand in the console, so the estate drifts from the approved design (T1190 Exploit Public-Facing Application, T1578 Modify Cloud Compute Infrastructure).
Why it matters: NSA states that "Many cloud breaches occur due to misconfigurations in cloud tenants." CSA ranked it first in 2024 and fifth in 2026, as identity and AI moved above it.
The fix: deploy through infrastructure as code with policy checks in the pipeline, set preventive guardrails at the top of the hierarchy (AWS SCPs and RCPs, Azure Policy deny effects, Google Cloud organisation policies), and detect drift against a CIS Foundations baseline (CIS AWS Foundations is at v7.1.0). See the Cloud Misconfiguration Guide and the CNAPP Guide.
5. Public storage and accidental data disclosure
The risk: buckets and containers readable by anyone, public snapshots, and shareable links (Azure SAS tokens, S3 presigned URLs) with broad scope and long expiry (T1619 Cloud Storage Object Discovery, T1530 Data from Cloud Storage).
Why it matters: exposure needs no exploit, only discovery. In the Microsoft SAS token exposure, one over-permissive link exposed 38TB of internal data.
The fix: enable S3 Block Public Access at organisation level, where "all four settings are applied together as a unified policy"; disallow anonymous blob access and Shared Key authorisation on Azure storage; enforce public access prevention in Google Cloud; keep shared links short-lived; and use DSPM to find sensitive data. See the DSPM Buyer's Guide.
6. Exposed interfaces, APIs and management planes
The risk: Kubernetes dashboards and API servers, database consoles, notebook servers and internal APIs reachable from the internet, and run-command style administration available to too many principals (T1190, T1651 Cloud Administration Command).
Why it matters: CSA ranks insecure interfaces and APIs fourth in 2026. The Tesla Kubernetes cryptojacking began at an open console that exposed AWS credentials.
The fix: private endpoints for control planes and data services, authentication on every API including internal ones, an owned API inventory and administration commands limited to a few roles. See the API Security Guide and the Kubernetes Security Guide.
7. Third-party, supply chain and CI/CD access
The risk: managed service providers with standing cross-account roles, SaaS tools with tenant-wide read access, pipelines holding deployment keys, and compromised dependencies (T1199 Trusted Relationship, T1195 Supply Chain Compromise, T1528 Steal Application Access Token).
Why it matters: insecure third-party resources rose to third in CSA's 2026 ranking, and NSA warns that "using an MSP can increase an organization's attack surface." In the CircleCI breach, a stolen SSO session exposed every customer's CI/CD secrets.
The fix: give suppliers federated, scoped roles with conditions, never shared keys; replace pipeline secrets with OIDC federation to short-lived roles bound to repository and branch; review cross-account trust and OAuth grants quarterly. See the CI/CD Pipeline Identity Security Guide and the Third-Party Access Guide.
8. Limited visibility: shadow accounts, unmonitored workloads and logging gaps
The risk: accounts, subscriptions and projects created outside the landing zone, workloads with no owner, data access logs never enabled and Regions nobody watches (T1535 Unused/Unsupported Cloud Regions, T1580 Cloud Infrastructure Discovery, T1685 Disable or Modify Tools when attackers stop logging).
Why it matters: a forgotten test tenant without MFA was the start of the Microsoft Midnight Blizzard breach. NSA notes that "Default logging policies vary greatly between cloud services": S3 data events, Google Cloud Data Access logs and Azure resource logs are mostly off until enabled.
The fix: create every account through a vending process that enrols it in guardrails and logging, send organisation-wide logs to a separate log archive account, deny unused Regions by policy and alert on any attempt to stop logging. See the Log Management and Retention Guide and the Cloud Incident Response Guide.
9. Unpatched workloads, images and functions
The risk: internet-facing virtual machines behind on patches, container images never rebuilt, and function runtimes past end of support (T1190, T1648 Serverless Execution).
Why it matters: guest operating systems, images and code stay the customer's responsibility, and CSA's 2026 list still includes system vulnerabilities.
The fix: agentless snapshot scanning for full coverage, rebuild and redeploy images rather than patching in place, prioritise by internet exposure, attached permissions and CISA's Known Exploited Vulnerabilities catalogue, and track runtime deprecation dates. See the Container Security Guide and the Serverless Security Guide.
10. Extortion, destruction and resource hijacking
The risk: intruders encrypt or delete data and backups, copy data to their own cloud accounts, or run cryptominers and resell AI model access on the victim's bill (T1486 Data Encrypted for Impact, T1485 Data Destruction, T1537 Transfer Data to Cloud Account, T1496.004 Cloud Service Hijacking).
Why it matters: the Codefinger S3 ransomware used stolen keys to encrypt buckets with AWS's own server-side encryption, and LLMjacking turned stolen cloud credentials into free AI for attackers.
The fix: backups in a separate account with object lock or immutable vaults, tight control of who can change encryption settings or delete keys, budget and quota alerts, and AI model access limited to approved roles and Regions. See the Backup Security and Immutable Backup Guide.
Mapping to OWASP
OWASP has no maintained cloud Top 10, so this list maps to OWASP weakly. The closest is the OWASP Cloud-Native Application Security Top 10, which its page calls an "Interim List of Risks - Currently Under Review!", last updated in April 2022. The CSA Top Threats 2026, NSA's ten cloud mitigation strategies and ATT&CK's cloud techniques are better maps, so we lead with them.
| Risk | ATT&CK v20 | CSA Top Threats 2026 | NSA mitigation strategy | OWASP CNAS (draft) |
|---|---|---|---|---|
| 1. Over-privileged identities | T1078.004, T1098.003, T1556.007 | 1 Inadequate IAM | Secure Cloud IAM Practices | CNAS-3 |
| 2. Long-lived keys | T1078.004, T1098.001 | 1 Inadequate IAM | Secure Cloud IAM; Secure Cloud Key Management | CNAS-5 |
| 3. Workload credential theft | T1552.005 | 1 Inadequate IAM | Secure Cloud IAM Practices | CNAS-3 (weak fit) |
| 4. Misconfiguration | T1190, T1578 | 5 Misconfiguration and Inadequate Change Control | Shared Responsibility Model; IaC | CNAS-1, CNAS-6 |
| 5. Public storage | T1619, T1530 | 10 Accidental Cloud Data Disclosure | Secure Data in the Cloud | CNAS-1 |
| 6. Exposed interfaces | T1190, T1651 | 4 Insecure Interfaces and APIs | Network Segmentation and Encryption | CNAS-2, CNAS-6 |
| 7. Third-party and pipelines | T1199, T1195, T1528 | 3 Insecure Third-Party Resources; 9 Insecure Software Development | Defending CI/CD; MSP risks | CNAS-4 |
| 8. Limited visibility | T1535, T1580, T1685 | 8 Lacking Cloud Security Strategy and Governance | Manage Cloud Logs; Hybrid and Multi-Cloud | CNAS-8, CNAS-10 |
| 9. Unpatched workloads | T1190, T1648 | 11 System Vulnerabilities | No direct strategy | CNAS-7 |
| 10. Extortion and hijacking | T1486, T1485, T1537, T1496.004 | 2 AI-Enhanced Attacks; 7 Advanced Persistent Threats | Secure Data in the Cloud; Key Management | CNAS-9 (weak fit) |
CSA's 2026 list dropped limited cloud visibility, but we keep it (risk 8) because every other fix depends on it. ATT&CK v20 moved defence evasion into the Defense Impairment tactic: map disabled cloud logging to T1685 Disable or Modify Tools, which replaced the retired Impair Defenses technique.
Where to start
If you can do only three things this quarter: enforce phishing-resistant MFA on every human cloud identity and remove standing administrator roles (risk 1), block creation of long-lived keys by policy and rotate the ones found in code (risk 2), and turn on organisation-level public access blocks for storage (risk 5). Then send organisation-wide audit logs to a separate log archive account (risk 8). Track five numbers monthly: human cloud identities without phishing-resistant MFA (target zero), access keys and service account keys older than 90 days, identities holding admin roles unused for 90 days, publicly accessible storage resources without a recorded exception (target zero), and accounts or projects outside central logging (target zero).
Primary sources: the CSA Top Threats to Cloud Computing 2026 announcement, NSA's Top Ten Cloud Security Mitigation Strategies, the MITRE ATT&CK cloud matrix, AWS IAM security best practices and Google Cloud best practices for managing service account keys.
Related NHI Mgmt Group resources: Cloud Security Guide · Cloud Workload Identity Guide · Cloud PAM and CIEM Guide · Secrets Management Guide · CNAPP Guide