TL;DR: Cloud risk is highly uneven by provider, with weak IAM and missing logging affecting 80% to 98% of accounts and remediation stretching up to 35 days, according to Intruder’s 2026 Cloud Security Index based on misconfiguration data from 3,000 organisations across AWS, Azure and Google Cloud. The real governance problem is not only fixing individual misconfigurations but prioritising exposure consistently across multi-cloud estates.
NHIMG editorial — based on content published by Intruder: 2026 Cloud Security Index
By the numbers:
- Intruder analysed misconfiguration data from 3,000 organisations across AWS, Azure and Google Cloud over the 12 months to July 2026.
- Cloud issues were remediated in as few as 7 days in smaller organisations and as long as 35 days in the 1,000 to 5,000 employee range.
- 76% of cases, had at least one exposed service in 76% of cases, compared with 64% on Azure and 8% on Google Cloud.
Questions worth separating out
Q: How should security teams prioritise cloud misconfigurations across multiple providers?
A: They should rank findings by shared control impact, not by provider name alone.
Q: Why do weak IAM controls remain a cloud risk even when infrastructure is otherwise hardened?
A: Because identity is the enforcement layer for everything else.
Q: How do teams know whether cloud remediation is actually improving?
A: Look at three signals together: prevalence of the control gap, average time to close it, and how often the same issue reappears.
Practitioner guidance
- Normalise cloud findings into one risk model Map AWS, Azure and Google Cloud misconfigurations to a shared control taxonomy so the team can compare exposure without changing the meaning of each provider's finding.
- Prioritise IAM and logging before service hardening Triage overprivileged identities, missing audit trails and weak authentication first, because those issues amplify almost every other cloud weakness.
- Track remediation time by control family Measure how long specific classes such as IAM, logging and exposure fixes stay open, then assign owners to the slowest recurring categories.
What's in the full report
Intruder's full Cloud Security Index covers the operational detail this post intentionally leaves for the source:
- Per-provider misconfiguration breakdowns across AWS, Azure and Google Cloud for teams that need platform-specific remediation paths.
- Category-by-category prevalence data that helps security leaders compare weak IAM, missing logging, exposed services and encryption gaps.
- Remediation timing analysis by organisation size, useful for capacity planning and board reporting.
- The dataset and methodology behind the 3,000-organisation sample, for readers who want to validate the findings before using them in policy work.
👉 Read Intruder's 2026 Cloud Security Index on multi-cloud misconfiguration risk →
Cloud misconfiguration gaps across AWS, Azure and GCP: what changes for IAM teams?
Explore further
Cloud misconfiguration is now an identity problem, not just a configuration problem. The article shows that the most damaging patterns are not isolated networking mistakes but weak IAM controls, unused or overprivileged identities, and missing logging. In practice, those failures determine whether a misconfiguration is merely untidy or immediately exploitable. For IAM and cloud teams, the conclusion is that posture management must start with identity and entitlement governance.
A question worth separating out:
Q: Who is accountable when a cloud misconfiguration exposes production data?
A: Accountability usually sits across security, platform, and application teams because the exposure is created by an operational decision, not a single technical mistake. Governance needs clear ownership for service accounts, repository controls, and access assumptions so that risky combinations are fixed before they become reachable attack paths.
👉 Read our full editorial: Cloud misconfiguration risk varies sharply across AWS, Azure and GCP