Cloud misconfiguration risk varies sharply across AWS, Azure and GCP

At a glance

What this is: Intruder’s analysis shows cloud misconfiguration is uneven across AWS, Azure and GCP, but weak IAM and missing logging are broadly persistent across providers.

Why it matters: For IAM and cloud security teams, the main issue is not one platform’s posture in isolation but building a consistent way to rank and remediate cross-cloud exposure.

By the numbers:

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

Context

Cloud misconfiguration is a governance problem, not just a configuration problem. The issue is that different providers surface different default weaknesses, so security teams cannot assume a single hardening pattern will produce the same risk reduction across AWS, Azure and Google Cloud.

In practice, that means posture data has to be normalised before it becomes useful for IAM, cloud and risk teams. The identity bridge is clear: weak IAM, overprivileged access and missing logging turn routine cloud drift into exploitable access paths, and that makes multi-cloud prioritisation a governance control in its own right.

Intruder’s dataset points to a typical enterprise problem rather than an edge case. Multi-cloud estates tend to grow faster than the control model built to govern them, which is why exposure often persists even when individual teams believe they have fixed the obvious issues.

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. AWS, Azure and GCP expose different default weaknesses, so a provider-by-provider process often fixes local issues without revealing which exposures are most dangerous across the whole estate. The result is inconsistent prioritisation, slower remediation and a false sense that cloud posture is improving evenly.

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: 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. If critical issues keep appearing on internet-exposed systems, or if teams rely on outdated inventory data, the programme is not seeing the real attack surface.

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.

Technical breakdown

Why cloud misconfiguration fragments across providers

Cloud misconfiguration does not behave like a single control failure because each provider exposes different defaults, service models and administrative patterns. AWS tends to surface more exposed services and permissive network paths, Azure combines storage, Key Vault and identity issues, and GCP shows a heavy concentration of IAM and OS Login gaps. The technical lesson is that posture is not interchangeable across clouds: the same control objective, such as least exposure or authenticated administrative access, is implemented differently depending on provider design. That makes provider-specific context essential before remediation decisions are made.

Practical implication: Build a provider-aware control map so remediation guidance matches the actual cloud service and not just the category name.

Weak IAM controls and missing logging are the shared failure modes

The strongest common thread in the data is not storage, networking or encryption. It is identity and observability: weak IAM controls and missing logging/alerting remain widespread across all three providers, which means the core issue is governance of who can do what and whether activity is visible after the fact. When those controls fail, other hardening work only reduces the blast radius partially because privilege paths remain open and suspicious activity is harder to detect. In multi-cloud environments, IAM consistency is the control that most directly changes the security outcome.

Practical implication: Treat identity permissions and audit visibility as the baseline control plane before refining provider-specific hardening.

Provider defaults shape remediation speed and residual risk

Remediation time is not just an operations metric. It reflects how much manual interpretation, cross-team coordination and environment-specific knowledge is needed before a team can safely change a setting. Smaller organisations remediate faster, but midmarket environments often slow down because cloud complexity outpaces dedicated security capacity. That delay matters because a misconfiguration is exploitable for as long as it remains live. The governance problem is therefore not only finding the issue, but deciding which issues deserve priority when every platform presents different exposure patterns.

Practical implication: Measure remediation latency by cloud category and use it to set escalation thresholds for high-risk misconfigurations.

Threat narrative

Attacker objective: The objective is to convert a configuration weakness into broader access to cloud resources, data or administrative control before remediation closes the gap.

1. Entry occurs through exposed cloud services, permissive network paths or weak identity controls that leave resources reachable without appropriate restriction.
2. Credential or privilege abuse then lets an attacker move from basic access to higher-impact permissions, especially where IAM policies permit escalation or service accounts are overprivileged.
3. Impact follows as exposed storage, secrets, certificates or administrative interfaces are reached before defenders can detect or contain the activity.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
• 230M AWS environment compromise: 230M AWS environments compromised via exposed .env files with cloud credentials.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Multi-cloud risk becomes materially harder to manage when teams rely on category-level posture rather than provider-level control semantics. A firewall, storage or IAM issue does not carry the same practical meaning across AWS, Azure and GCP because defaults, inheritance and service boundaries differ. That creates a provider-normalisation gap: the organisation may know what failed, but not yet how to compare its severity across estates. Security leaders should expect that gap to distort prioritisation unless they standardise assessment language.

Standing privilege is the real amplifying factor behind cloud exposure. The article shows that weak IAM persists even where other categories improve with scale, which is a sign that identity sprawl is harder to control than network or storage posture. When overprivileged users, service accounts or roles remain active, a single misconfiguration becomes an access pathway rather than a contained defect. Practitioners should focus on limiting who can escalate, not only on closing the visible exposure.

Remediation delay is a governance signal, not just an operational lag. A configuration that remains open for days or weeks is a risk decision whether or not anyone labels it that way. The midmarket pattern in particular suggests that complexity without enough security capacity creates a long exposure window. Teams should track remediation latency as a board-level indicator of whether cloud control ownership is actually working.

Multi-cloud exposure now needs a common risk language. Without one, teams will continue to fix provider-specific symptoms while missing the cross-cloud pattern that ties them together. That is why cloud security programmes need unified identity, logging and prioritisation rules before they add more cloud-specific exceptions.

From our research library:

• 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.
• Read next: Cloud Workload Identity Guide

What this signals

Provider-normalisation gap: cloud security teams need one severity language across AWS, Azure and GCP or they will keep overreacting to local findings and underreacting to cross-cloud exposure. That gap is now a governance problem, not a tooling problem.

The article’s scale data suggests that posture improvement stalls when cloud teams lack enough control ownership to move from detection to closure. As remediation time stretches, exposure becomes a business decision whether or not it is recorded that way.

Identity remains the highest-leverage control plane in multi-cloud security. If an organisation can reduce overprivileged access and improve audit visibility consistently, it can shrink the blast radius of many different provider-specific misconfigurations at once.

For practitioners

• 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.
• Map provider-specific defaults to a control baseline Document the default security assumptions for each cloud platform and compare them against your approved baseline before teams onboard new workloads.
• Track remediation latency as an exposure metric Measure how long high-risk misconfigurations stay open by environment, team and provider so delayed closure becomes visible to security leadership.

Key takeaways

• Cloud misconfiguration differs materially by provider, so cross-cloud security programmes need a common risk model rather than separate local scoring methods.
• Weak IAM controls and missing logging remain the most persistent exposure themes across AWS, Azure and GCP, which makes identity governance central to cloud risk reduction.
• Remediation speed is a governance signal as much as an operational metric, because long-lived misconfigurations extend the window in which exposure can be exploited.

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.
• Provider-Normalisation Gap: The provider-normalisation gap is the difference between knowing a misconfiguration exists and being able to compare its risk consistently across AWS, Azure and GCP. It appears when teams use different control semantics for similar exposures, which weakens prioritisation and slows remediation.
• 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.
• Remediation Latency: The time between identifying a security issue and fully removing or reducing the risk. For NHIs and SaaS access, this metric matters because stale credentials, over-shared files, and dormant integrations stay usable until the control finally acts.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through the NHI Foundation Level course, the industry's only accredited NHI security programme. It helps practitioners connect access governance, secrets handling, and identity lifecycle decisions to real-world control outcomes.