Weak IAM affects up to 98% of cloud environments

1. Executive summary

Intruder's 2026 Cloud Security Index report finds that weak identity and access management (IAM) controls and missing logging/alerting are the most widespread cloud security issues across AWS, Azure, and Google Cloud, affecting 80–98% of accounts surveyed. IAM weakness scales with organisation size: 87% of SMEs, 95% of midmarket, and 98% of large enterprises are affected, driven by the complexity of managing users, roles, and permissions at scale. No specific CVE, threat actor, or active exploitation campaign is referenced; the risk is systemic misconfiguration. For EMEA financial services running multi-cloud estates, the findings indicate a high likelihood that excessive permissions, unrotated keys, and logging gaps are present in production environments and could enable privilege escalation, data exposure, or undetected compromise.

2. Regulatory framing

No specific NIS2 or UK NIS article is directly engaged beyond general incident-management and supply-chain duties that apply to any security finding. The item does not describe a specific incident, breach, or supply-chain compromise with a distinctive trigger.

3. Technical analysis & attack chain

This is a strategic/misconfiguration advisory, not a vulnerability or campaign report. No CVE, exploit, threat actor, or malware is referenced. The following findings are drawn entirely from Intruder's 2026 Cloud Security Index report (single-sourced; verify before enforcement).

How the risk manifests

The core problem is that cloud platforms are not secure by default, and each provider exposes different misconfiguration surfaces. A single configuration error can result in public network access, unrotated cryptographic keys, missing encryption, exposed services, and logging gaps — any of which can be leveraged for initial access, privilege escalation, or data exfiltration without exploiting a software vulnerability.

Platform-specific findings

• AWS: Most frequently affected by storage, network access, and identity management misconfigurations. AWS recorded the highest prevalence of misconfigurations in five of six security categories analysed, including permissive firewalls, exposed services, and weak encryption. Exposed services affect 76% of AWS accounts.
• Azure: Most common issues centre on storage security and identity protection — specifically unrotated access keys, publicly accessible storage, and missing MFA. Azure had the highest rate of misconfigured services. Exposed services affect 64% of Azure accounts.
• Google Cloud: Primarily affected by IAM weaknesses, including missing MFA, unused service accounts, and overly permissive service accounts. Exposed services affect only 8% of accounts — the lowest across providers. Google Cloud recorded the lowest prevalence in four of six categories.

Cross-platform findings

• Weak IAM controls and missing logging/alerting affect 80–98% of accounts across all three providers.
• Weak identity controls, excessive permissions, and insecure or incomplete configurations are the most common sources of cloud security risk across all providers.
• Exposed services showed the widest variation between platforms (AWS 76%, Azure 64%, GCP 8%).

Scale effects

• Weak IAM affects 87% of SMEs, 95% of midmarket, and 98% of large enterprises — the only category that worsens with scale, attributed to growing complexity of users, roles, and permissions.
• Average remediation times: SMEs 8–16 days; 1,000–5,000 employee organisations 35 days (the peak); 5,000–10,000 employees 19 days; largest enterprises 10 days. Midmarket organisations manage enterprise-scale cloud environments without dedicated security resources.

Confidence caveat: All findings are single-sourced from Intruder's report. The methodology, sample size, and data collection period are not disclosed in the source material. Treat prevalence figures as directional rather than precise.

4. Mitigation & containment

P1 — within 24 hours

• Audit IAM across all cloud providers: identify unused service accounts (GCP), overly permissive roles (all providers), and accounts without MFA. Prioritise production and crown-jewel data environments.
• Identify unrotated access keys in Azure and AWS — enumerate all keys, flag those with no rotation record, and force rotation of any key older than your organisation's policy threshold.
• Verify that logging and alerting are enabled on all cloud accounts. The report flags missing logging/alerting as a top issue across 80–98% of accounts. Confirm CloudTrail (AWS), Activity Logs / Diagnostic Settings (Azure), and Cloud Audit Logs (GCP) are active and exporting to a central SIEM.

P2 — within 72 hours

• Enumerate publicly accessible storage (S3 buckets, Azure Blob Storage, GCS buckets) and restrict access to authenticated/authorised principals only. Verify encryption-at-rest is enabled.
• Review firewall and network security group rules for permissive ingress (0.0.0.0/0 on non-HTTP/S ports). Restrict to known CIDRs or remove public exposure where services are internal-facing.
• Identify exposed services across all accounts — the report notes 76% of AWS accounts and 64% of Azure accounts have exposed services. Map all internet-facing endpoints and validate each is intentionally public.

P3 — within 7 days

• Implement automated cloud security posture management (CSPM) across all providers to continuously detect drift. Manual periodic audits are insufficient given the 35-day remediation peak at midmarket scale.
• Enforce least-privilege IAM: review all custom roles, eliminate wildcard permissions (* actions/resources), and implement break-glass procedures for administrative access instead of standing privileged roles.
• Establish provider-specific configuration baselines — the report explicitly states that the same security issue manifests differently across AWS, Azure, and GCP and requires different approaches to identify and remediate.
• Reduce remediation cycle time: the 35-day average for 1,000–5,000 employee organisations is a material exposure window. Set internal SLAs of ≤7 days for critical misconfigurations (public storage, missing MFA on privileged accounts, permissive firewalls).

5. Indicators of compromise

No indicators of compromise available in the source material. This advisory addresses systemic misconfiguration risk, not a specific threat campaign or intrusion.

Behavioural indicators

6. Detection

Insufficient indicators to author detection rules. The source material describes configuration states and statistical findings, not threat artefacts (strings, file hashes, command-line patterns, or network indicators) that would populate a YARA or Sigma rule. The behavioural indicators in §5 should be implemented as CSPM policy rules rather than threat-detection signatures.

7. Sources

• Intruder / Help Net Security, "Weak IAM affects up to 98% of cloud environments," https://www.helpnetsecurity.com/2026/08/14/intruder-cloud-misconfiguration-trends-report/, 2026-08-14

8. Adverse Trace position

This is a systemic misconfiguration advisory, not a vulnerability or active-threat alert — there is no CVE, no KEV entry, and no named actor (no MITRE profile to confirm). The severity for EMEA financial services is high not because of a single exploitable flaw but because the findings indicate that the majority of multi-cloud environments have excessive permissions, unrotated keys, and logging gaps that could enable privilege escalation and undetected data access. The scale effect — IAM weakness worsening with organisation size to 98% of large enterprises — is particularly relevant for large financial institutions with complex multi-cloud estates. The 35-day remediation average at midmarket scale is a material exposure window that should be addressed through automated CSPM and enforced SLAs. We will monitor for any subsequent reporting that corroborates Intruder's findings with independent data or discloses active exploitation of these misconfigurations. Clients should prioritise the P1 actions in §4 and ensure DORA Art. 24 testing programmes explicitly cover cloud configuration baselines.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.