Topic starter
18/08/2026 2:10 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Intruder: “2026 Cloud Security Index: How risk differs across AWS, Azure, and Google Cloud”.
By the numbers:
- Intruder analyzed misconfiguration data from 3,000 organisations across AWS, Azure and Google Cloud over 12 months.
- Remediation peaked at 35 days in the 1,000-5,000 employee range before improving to around 10 days for organisations with 10,000+ employees.
Key questions
Q: What breaks when cloud misconfiguration is managed provider by provider?
A: The control model breaks because teams lose a comparable view of risk.
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: What are the signs that cloud vulnerability management is failing in multi-cloud environments?
A: The clearest warning signs are inconsistent inventories, gaps between what teams believe is deployed and what is actually exposed, and vulnerable assets that remain live after deployment.
Practitioner guidance
- Normalise misconfiguration scoring across providers Create a single severity model for AWS, Azure and GCP so similar exposure patterns are ranked consistently even when the underlying service names differ.
- Prioritise IAM before peripheral hardening Focus first on overprivileged roles, privilege escalation paths, service account exposure and missing logging because those are the shared failure modes that most directly change blast radius.
- Set remediation targets by risk class Use separate service-level targets for exposed services, weak IAM and storage misconfiguration so high-impact issues do not wait behind lower-risk cleanup work.
Bottom line: Cloud misconfiguration differs materially by provider, so cross-cloud security programmes need a common risk model rather than separate local scoring methods.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:03 pm
Cloud misconfiguration is an identity governance problem once privilege paths remain consistent across providers. The article’s central finding is not simply that AWS, Azure and GCP differ, but that weak IAM and missing logging remain stubbornly common everywhere. That means the control question shifts from provider hardening to governance over permissions, auditability and escalation paths. Practitioners should treat cloud posture and identity posture as a single operating model.
A few things that frame the scale:
- 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to the Ultimate Guide to NHIs.
- The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to the 2024 State of Secrets Management Survey.
A question worth separating out:
Q: Should organisations prioritise identity-level controls or traditional network controls in cloud?
A: Organisations should prioritise identity-level controls for cloud access decisions because the real question is who can use which service or dataset after authentication. Network controls still matter, but they cannot express enough context for distributed cloud resources. Identity-first security is the more precise control model for modern access governance.
👉 Read our full editorial: Cloud misconfiguration risk varies sharply across AWS, Azure and GCP