Cloud misconfiguration risk varies sharply across AWS, Azure and GCP

At a glance

What this is: This analysis shows that cloud misconfiguration patterns differ sharply across AWS, Azure and Google Cloud, but weak IAM and missing logging remain near-universal risks.

Why it matters: It matters because identity, privilege and visibility gaps now cut across cloud platforms, and IAM teams need a consistent way to prioritise fixes before exposed access becomes breach entry.

By the numbers:

• Intruder analysed misconfiguration data from 3,000 organisations across AWS, Azure and Google Cloud over the 12 months to July 2026.
• Weak IAM controls affected 98% of large enterprises, 95% of midmarket organisations and 87% of SMEs in the dataset.
• 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

👉 Read Intruder's 2026 Cloud Security Index on multi-cloud misconfiguration risk

Context

Cloud misconfiguration is a governance problem as much as a technical one. In multi-cloud estates, the issue is not simply that each provider exposes different weaknesses, but that security teams lose a single, reliable view of where access, network exposure and logging controls are actually failing. That makes prioritisation harder and slows response, especially where identity and privilege are already stretched across multiple platforms.

The article centres on how AWS, Azure and Google Cloud diverge in posture while still sharing common IAM weaknesses. For IAM and cloud security teams, the important insight is that platform differences do not remove the need for consistent entitlement governance, because overprivileged identities and missing logging undermine control maturity regardless of provider.

Key questions

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. A weak IAM policy or missing audit trail matters more than a cosmetic configuration issue because it increases exploitability across AWS, Azure and Google Cloud. The best programmes normalise exposure into one risk model and then route fixes to the control owners who can close the widest blast radius first.

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. If roles, keys or users are overprivileged, an attacker can bypass network or storage hardening by using legitimate access paths. That is why cloud programmes need entitlement governance, MFA and logging together, not as separate hygiene tasks.

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. If a finding is common, slow to fix and repeatedly reintroduced, the programme is not learning. Effective cloud governance reduces exposure density and shortens the window in which misconfiguration can be abused.

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.

Technical breakdown

Why multi-cloud misconfiguration creates uneven risk

Multi-cloud environments create different failure surfaces because each provider exposes different defaults, control models and administrative pathways. A policy that is safe in one cloud may be too permissive in another, especially where identity models differ between console access, service accounts and federated access. The operational problem is not just technical diversity, but the lack of a common risk lens that can compare exposure consistently. When teams cannot normalise findings across providers, they end up treating each cloud as a separate problem set rather than one governed estate.

Practical implication: build a single posture model that normalises cloud findings by control class, not by provider.

Weak IAM and logging remain the common failure modes

The most important pattern in the dataset is that weak IAM controls and missing logging are widespread across all three clouds. That means the control gap is not limited to one provider's architecture. IAM weakness usually shows up as excessive entitlements, poorly managed roles or identities that can be abused for escalation. Missing logging is equally dangerous because it reduces the chance of detecting abuse before damage spreads. In practice, these two gaps turn local misconfigurations into enterprise-wide visibility and containment problems.

Practical implication: prioritise identity controls and audit coverage before chasing lower-value configuration noise.

Why remediation slows as environments scale

Remediation time does not rise in a straight line with size. Midmarket organisations often sit in the worst position because they have enough cloud complexity to generate recurring exposure, but not enough specialist capacity to clear it quickly. Larger enterprises can recover some speed through process maturity, but they also carry more identities, more exceptions and more change pressure. That is why the same configuration issue can persist far longer in one environment than another even when the underlying finding is identical.

Practical implication: measure time-to-fix by control category and organisation size, then staff for the slowest recurring class.

Threat narrative

Attacker objective: The attacker aims to turn a basic cloud exposure into privileged access that enables data theft, service abuse or deeper cloud compromise.

1. Entry begins with exposed cloud services, permissive ingress or weak account controls that make external access possible.
2. Escalation follows when an overprivileged identity or misconfigured IAM policy allows the attacker to move from limited access to broader control.
3. Impact occurs when the attacker abuses that access to expose data, alter cloud resources or establish a larger foothold inside the environment.

NHI Mgmt Group analysis

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.

Multi-cloud risk needs a normalised control language. AWS, Azure and Google Cloud fail in different ways, but the underlying governance question is the same: who can do what, where, and with what traceability. Without a common mapping between provider findings, teams cannot compare exposure or set remediation priority consistently. That makes cross-cloud governance depend on translation, not just tooling. Practitioners should align findings to a shared control model before they try to rank risk.

Standing privilege remains the most dangerous cloud multiplier. The named concept here is identity-sprawl amplification, where every additional role, key or service account expands the blast radius of a routine cloud misconfiguration. The article’s size findings reinforce this, because larger estates are not safer when identity complexity outpaces governance. Teams should treat excess privilege as the mechanism that turns ordinary cloud defects into material exposure.

Remediation speed is a governance metric, not just an operational one. A control that takes weeks to fix is effectively weaker than one that can be closed in days, even if both are eventually detected. That is why time-to-remediate should sit alongside prevalence in cloud reporting. The practitioner takeaway is to manage exposure by the controls that stay open longest, not only the ones that appear most often.

Provider defaults shape outcomes, but they do not remove accountability. The article suggests that some clouds ship with more secure defaults, yet weak IAM and logging remain widespread across the board. That means shared responsibility still lands on the customer for the controls that matter most. The right response is not to assume one provider is safer, but to enforce consistent governance across all of them.

What this signals

Cloud teams should expect misconfiguration programmes to converge with identity governance because the highest-risk failures are increasingly about who can act, not just what is exposed. The practical challenge is to unify cloud posture, entitlement review and logging into a single operating model, rather than treating them as separate workstreams.

Identity-sprawl amplification: the more roles, keys and service accounts an estate accumulates, the more ordinary cloud defects can become material incidents. That means remediation capacity, not just detection coverage, becomes a core control. Teams that cannot shorten the life of exposure will continue to lose ground to configuration drift.

Where cloud findings point to overprivileged access, teams should map them to established control frameworks such as the NIST Cybersecurity Framework 2.0 and the NIST SP 800-53 Rev 5 Security and Privacy Controls. The goal is not framework compliance as a reporting exercise, but a way to make risk prioritisation repeatable across providers and business units.

For practitioners

• 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.
• Review service accounts and keys with the highest blast radius Identify identities that can reach production data or admin functions, then reduce standing access, rotate secrets and remove unused accounts.

Key takeaways

• Cloud misconfiguration becomes materially more dangerous when weak IAM and poor logging are present across every provider.
• Multi-cloud variance is real, but the underlying governance failure is consistent: excessive privilege and slow remediation widen the blast radius.
• Security teams should measure cloud posture by shared control impact and time-to-fix, not by provider-specific scorecards alone.

Key terms

• Cloud misconfiguration: A security failure caused by incorrect permissions, exposure settings, or integration design in cloud services. It is often less about the cloud platform itself and more about access paths that were created quickly, left broad, and never fully revalidated against actual business need.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Entitlement Governance: Entitlement governance is the discipline of deciding who or what should have access, for how long, and under what business justification. It spans human users, non-human identities, and automated workflows, making it a core control layer for SaaS, cloud infrastructure, and lifecycle management.
• Posture normalisation: Posture normalisation is the act of translating findings from different environments into one comparable risk language. It helps teams compare cloud exposure consistently by control class, so remediation can be driven by impact rather than by whichever platform generates the loudest alert.

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.

👉 Intruder's full report includes provider-by-provider misconfiguration tables and remediation timing detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps security practitioners build the control discipline needed to manage privilege, lifecycle and auditability across modern identity estates.