> ## Content Index
> Fetch the complete content index at: https://blog.stratum.my/llms.txt
> Use this file to discover other available public pages before exploring further.

# Cloud Security Misconfigurations Vary Widely Across Providers
- URL: https://blog.stratum.my/cloud-misconfigurations-provider-comparison/
- Published: 2026-09-09T13:49:49.000Z
- Updated: 2026-09-09T13:49:49.000Z
- Description: A 2026 study of 3,000 organisations shows that weak IAM controls and missing logging are almost universal, but exposed services, permissive firewalls and weak encryption differ sharply between AWS, Azure and Google Cloud.
- Author: JW
- Tags: cloud security, misconfigurations, AWS, Azure, Google Cloud

Enterprises of all sizes are still wrestling with cloud misconfigurations that leave data exposed and attackers with a foothold. Intruder’s 2026 Cloud Security Index surveyed 3,000 organisations using Amazon Web Services (AWS), Microsoft Azure and Google Cloud, revealing both universal weaknesses and stark provider‑specific gaps. The findings matter now because more businesses are moving critical workloads to the public cloud, and the same misconfigurations that slipped past last year are still showing up in breach investigations.

## What the data shows

Across every provider, two problems dominate: weak identity and access management (IAM) controls and missing logging. Both affect between 80 % and 98 % of accounts, regardless of whether the organisation runs on AWS, Azure or Google Cloud. Those issues alone can enable unauthorised access and make it hard to detect malicious activity.

Beyond those near‑universal flaws, the study highlights four further categories where providers diverge dramatically, exposed services, permissive firewalls, weak encryption and misconfigured services. AWS records the highest prevalence in three of those categories, while Google Cloud consistently scores the lowest.

## Provider‑specific misconfiguration rates

| Provider     | Issue                                                    | Prevalence |
| ------------ | -------------------------------------------------------- | ---------- |
| AWS          | Weak IAM controls                                        | 80‑98 %    |
| Azure        | Weak IAM controls                                        | 80‑98 %    |
| Google Cloud | Weak IAM controls                                        | 80‑98 %    |
| AWS          | Missing logging                                          | 80‑98 %    |
| Azure        | Missing logging                                          | 80‑98 %    |
| Google Cloud | Missing logging                                          | 80‑98 %    |
| AWS          | Exposed services                                         | 76 %       |
| Azure        | Exposed services                                         | 64 %       |
| Google Cloud | Exposed services                                         | 8 %        |
| AWS          | Permissive firewalls                                     | 83 %       |
| Azure        | Permissive firewalls                                     | 45 %       |
| Google Cloud | Permissive firewalls                                     | 34 %       |
| AWS          | Weak encryption                                          | 49 %       |
| Azure        | Weak encryption                                          | 35 %       |
| Google Cloud | Weak encryption                                          | 8 %        |
| AWS          | Misconfigured services                                   | 68 %       |
| Azure        | Misconfigured services                                   | 80 %       |
| Google Cloud | Misconfigured services                                   | 37 %       |
| AWS          | S3 buckets without HTTPS enforcement                     | 87 %       |
| AWS          | IAM policies allowing privilege escalation               | 83 %       |
| Azure        | Storage account key rotation not enabled                 | 67 %       |
| Azure        | Storage account access keys enabled                      | 66 %       |
| Azure        | Storage account public network access enabled            | 61 %       |
| Azure        | Entra ID users without multi‑factor authentication (MFA) | 55 %       |
| Google Cloud | OS Login not enabled                                     | 76 %       |
| Google Cloud | OS Login MFA not enabled                                 | 77 %       |
| Google Cloud | Unused service accounts                                  | 75 %       |
| Google Cloud | Overly permissive service accounts                       | 53 %       |
| Google Cloud | Permissive ingress to sensitive ports                    | 34 %       |

The biggest gap is exposed services, AWS reports 76 % of accounts with internet‑facing services, while Google Cloud reports only 8 %.

![Close-up view of a computer displaying cybersecurity and data protection interfaces in green tones.](https://images.pexels.com/photos/5380618/pexels-photo-5380618.jpeg?auto=compress&cs=tinysrgb&h=650&w=940)

*Photo by* [*Tima Miroshnichenko*](https://www.pexels.com/@tima-miroshnichenko?ref=blog.stratum.my) *on Pexels*

## How organisation size influences risk

Weak IAM controls remain high across the board, but the prevalence rises with organisation size: 87 % of small‑to‑medium enterprises (SMEs, ≤ 250 employees), 95 % of mid‑market firms (251 to 10 000 employees) and 98 % of large enterprises (over 10 000 employees) suffer from weak IAM.

Remediation speed also varies. Mid‑market organisations take an average of 35 days to fix cloud issues, compared with 8 to 16 days for smaller businesses and about 10 days for large enterprises. Faster remediation correlates with more mature security processes, but the data shows that size alone does not guarantee better IAM hygiene.

## What you should do next

- **Audit IAM policies now**, the near‑universal weakness means every account should be reviewed for over‑privileged roles, unused users and missing MFA.
- **Enable comprehensive logging**, without logs you cannot detect or investigate incidents.
- **Prioritise provider‑specific gaps**, if you run on AWS, focus first on reducing exposed services and tightening firewall rules; Azure customers should address storage key rotation and public network access; Google Cloud users should enable OS Login and clean up unused service accounts.
- **Track remediation timelines**, set internal targets (e.g., 10 days for critical findings) and compare against the industry averages above.
- **Consider size‑adjusted resources**, mid‑market firms may need additional staffing or automated tooling to close the 35‑day remediation gap.

By translating the index numbers into concrete actions, you can move from a data‑heavy report to a practical security roadmap.

![A person in a blue jacket analyzing business analytics on a laptop outdoors during winter.](https://images.pexels.com/photos/7013070/pexels-photo-7013070.png?auto=compress&cs=tinysrgb&h=650&w=940)

*Photo by* [*Firmbee.com*](https://www.pexels.com/@firmbee-com-22729701?ref=blog.stratum.my) *on Pexels*

## Terms used in this article

- **IAM (Identity and Access Management)**, controls that define who can do what in a cloud environment.
- **MFA (Multi‑Factor Authentication)**, a security step that requires two or more proof of identity, such as a password plus a phone code.
- **OS Login**, a Google Cloud feature that ties Linux‑host access to Google identities and can enforce MFA.
- **Entra ID**, Microsoft’s cloud identity service, formerly Azure Active Directory.
- **S3**, Amazon’s Simple Storage Service, used for object storage.
- **Service account**, a non‑human account used by applications or services to interact with cloud APIs.

---

*This article is based on Intruder’s 2026 Cloud Security Index. The study does not explain why AWS shows higher rates of exposed services, permissive firewalls and weak encryption, nor does it provide a detailed causal analysis for Google Cloud’s lower prevalence.*