The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
There is no universally most-secure cloud provider. Intruder’s analysis of 3,000 organizations over the 12 months ending July 2026 found that Google Cloud had the lowest prevalence in four of six measured misconfiguration categories, AWS had the highest prevalence in five categories, and Azure led in misconfigured services. Yet weak identity controls and missing logging affected most accounts on all three platforms. Provider choice matters, but identity governance, least privilege, logging, and continuous configuration management matter more.
What the 2026 cloud security index measured
The index groups cloud findings into six categories: weak IAM controls, missing logging and alerting, misconfigured services, permissive firewalls, exposed services, and weak encryption. Its percentages are the share of accounts in the study dataset with at least one finding in each category. They are not probabilities that an account will be breached.
Intruder analyzed 3,000 organizations using AWS, Azure, and Google Cloud during the 12 months to July 2026. The public summary does not provide provider-by-provider account counts, sampling rules, weighting, or raw records, so the figures are best used to compare directional exposure patterns rather than to rank every customer environment.
| Finding category | AWS | Azure | Google Cloud |
|---|---|---|---|
| Weak IAM controls | 97% | 90% | 87% |
| Missing logging and alerting | 98% | 80% | 82% |
| Misconfigured services | 68% | 80% | 37% |
| Permissive firewalls | 83% | 45% | 34% |
| Exposed services | 76% | 64% | 8% |
| Weak encryption | 49% | 35% | 8% |
Weak IAM appeared in 87% to 97% of accounts, while missing logging and alerting appeared in 80% to 98%. Those two categories are therefore baseline control problems, not quirks of one provider.
#1 Best Overall
Which provider appears most secure?
On this index’s six measures, Google Cloud shows the lowest prevalence in four categories: misconfigured services, permissive firewalls, exposed services, and weak encryption. AWS records the highest prevalence in weak IAM, missing logging, permissive firewalls, exposed services, and weak encryption. Azure has the highest rate of misconfigured services.
That result does not prove that Google Cloud is safer for every workload. The measurements describe configuration findings, not incident rates, loss severity, architecture quality, or the skills of the teams operating each platform. A well-governed AWS or Azure environment can be safer than a poorly governed Google Cloud project. Existing identity systems, regulatory requirements, network design, staff expertise, and the quality of your security tooling can outweigh the aggregate differences.
How AWS risk differs
AWS combines a very broad service catalog with detailed, powerful IAM policies. That flexibility is useful, but it creates more policy and network decisions to review. In the index, AWS’s largest named findings were:
Rank #2
| AWS finding | Accounts affected | Why it matters |
|---|---|---|
| S3 not enforcing HTTPS | 87% | Data can be sent without transport encryption when clients or policies permit HTTP. |
| Permissive ingress to sensitive ports through ACLs | 84% | Administrative or database ports may be reachable from untrusted networks. |
| Overly permissive network ACLs | 83% | Subnet-level filtering may allow unnecessary traffic. |
| IAM policies allowing privilege escalation | 83% | An attacker with a low-privilege identity may be able to obtain higher privileges. |
| VPC endpoints not enabled for EC2 | 82% | Instances may reach services through paths that are harder to constrain and monitor. |
High-value AWS checks
- Require HTTPS for every S3 bucket policy and enable account-level S3 Block Public Access unless a documented exception exists.
- Review IAM policies for actions that can create, attach, pass, or modify privileged roles. Separate administration from application identities and use short-lived credentials wherever possible.
- Centralize root-account ownership, prohibit routine root use, require strong MFA, and monitor root activity.
- Review VPC security groups, network ACLs, and public load-balancer listeners together. Removing a permissive ACL does not fix a public security group, and vice versa.
- Rotate access keys and remove unused users, roles, and keys. Treat every long-lived key as an incident risk if its owner and purpose are unclear.
- Enable organization-wide audit logging and alerts before attempting complex detection rules; otherwise, important administrative and data-access events may be missing.
AWS’s shared-responsibility model means Amazon secures the underlying infrastructure, while customers remain responsible for identities, data, configurations, applications, and many network controls. The provider’s Trust Center explains the division, but it does not configure your accounts for you.
How Azure risk differs
Azure had the highest prevalence of misconfigured services in the index at 80%. Its leading findings concentrate on storage accounts, Microsoft Entra identity controls, secrets, and platform security settings:
| Azure finding | Accounts affected | Practical concern |
|---|---|---|
| Storage-account key rotation not enabled | 67% | Long-lived keys increase the impact of theft and make ownership difficult to verify. |
| Storage-account access keys enabled | 66% | Applications may rely on broad shared secrets instead of scoped identities. |
| Storage-account public network access enabled | 61% | Storage endpoints can be reachable from networks that do not need access. |
| Entra users without MFA | 55% | Password compromise can provide direct access to cloud and connected services. |
| Trusted Launch not enabled | 45% | Virtual machines may miss available boot-integrity and virtualization protections. |
High-value Azure checks
- Replace storage-account keys with Microsoft Entra identities, managed identities, or narrowly scoped shared-access mechanisms where the application supports them.
- Set a rotation schedule for any remaining storage keys and secrets, record an owner, and alert before expiry rather than after an outage.
- Disable public network access on storage accounts and Key Vaults unless a documented business requirement exists. Use private endpoints and approved network paths for internal workloads.
- Measure MFA coverage for every Entra user, including administrators, guests, contractors, and emergency accounts. Phishing-resistant methods provide stronger protection than passwords or one-time codes alone.
- Review Key Vault secret expiry, access policies, role assignments, and diagnostic logging as one lifecycle control.
- Enable Trusted Launch for supported virtual machines and verify that the chosen image, operating system, and workload are compatible.
Entra is often the identity plane for Microsoft 365, SaaS applications, on-premises integrations, and Azure resources. An identity weakness discovered in Azure can therefore have consequences well beyond a single subscription.
How Google Cloud risk differs
Google Cloud recorded the lowest category prevalence in the index for four categories, but weak IAM still affected 87% of accounts. The most common named findings were concentrated in OS Login, service-account lifecycle, SSH controls, and network exposure:
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →| Google Cloud finding | Accounts affected | Practical concern |
|---|---|---|
| OS Login MFA not enabled | 77% | SSH access may not require a second factor tied to the user’s identity. |
| OS Login not enabled | 76% | Project or instance SSH keys can bypass centralized user lifecycle controls. |
| Unused service accounts | 75% | Stale non-human identities enlarge the attack surface and complicate ownership. |
| Overly permissive service accounts | 53% | Compromised workloads may obtain more project access than they need. |
| Permissive ingress to sensitive ports | 34% | Firewalls may expose administrative or data services to unnecessary sources. |
High-value Google Cloud checks
- Enable OS Login for supported Compute Engine workloads and require OS Login MFA for administrative access.
- Inventory service accounts by project, owner, workload, and last use. Disable or delete unused accounts after confirming that automation does not depend on them.
- Reduce service-account roles to the smallest set of API permissions and prevent broad project-level grants where a resource-level role is sufficient.
- Remove project-wide SSH keys that are no longer needed, use instance-level controls deliberately, and monitor key changes.
- Review default networks, firewall rules, and sensitive-port ingress. Explicitly deny unnecessary paths rather than relying on an implicit assumption that a service is private.
- Check key rotation and Shielded VM settings as part of the same compute-hardening review.
The lower Google Cloud rates for exposed services and weak encryption should not be interpreted as an absence of identity risk. OS Login, service-account permissions, and project-level IAM still require continuous review.
Why identity and logging dominate the decision
Cloud incidents often begin with valid credentials rather than an exploit against the provider. Google Cloud’s Office of the CISO and Mandiant reported that identity issues were used for initial access in 83% of incidents involving major cloud and SaaS-hosted environments in the second half of 2025. The same analysis said data was targeted in 73% of cloud-related incidents.
Rank #4
A separate 2025 report covering the first half of 2025 identified weak or absent credentials as the predominant initial-access vector at 47.1%, followed by misconfigurations at 29.4% and API or user-interface compromises at 11.8%. These are observed incident engagements, not probabilities for every customer.
Logging determines whether a team can distinguish normal automation from credential abuse. Turn on administrative, identity, network, storage, and data-access logs; send copies to a separate security account or project; protect them from alteration; and alert on high-risk events such as MFA removal, privilege changes, public exposure, key creation, and unusual data transfers.
Recommended Free Tools
A provider-neutral baseline for AWS, Azure, and Google Cloud
- Define identity standards. Require MFA for human users, prefer phishing-resistant methods for administrators, use least-privilege roles, and issue short-lived credentials. Review privileged access on a fixed schedule.
- Control non-human identities. Give every service account, role, key, and managed identity an owner, purpose, expiry or review date, and minimum permissions. Remove unused credentials promptly.
- Centralize and protect logs. Enable comprehensive audit logging in every account, subscription, and project. Keep an immutable or access-controlled copy outside the workload’s administrative boundary.
- Reduce exposure. Inventory internet-facing services, sensitive ports, public storage, public databases, and broad firewall rules. Require an owner and business justification for each exception.
- Protect data in transit and at rest. Enforce HTTPS or equivalent secure protocols, use provider-managed or customer-managed keys according to the workload’s needs, and monitor key rotation and expiry.
- Scan continuously. Use cloud security posture management or equivalent checks to detect drift after deployment. Assign each finding to a named team with a severity-based deadline.
- Test recovery and data movement. Verify that backups can be restored, credentials can be revoked, and suspicious transfers can be detected and stopped.
How fast should findings be fixed?
Intruder reports remediation times of roughly 7 to 16 days for smaller organizations, a peak of about 35 days for organizations with 1,000 to 5,000 employees, and around 10 days for organizations with more than 10,000 employees. These are reported patterns, not service-level requirements.
Use risk-based deadlines rather than one universal target:
- Immediate or same day: public exposure of sensitive data, active credential compromise, privilege-escalation paths, and internet-facing administrative ports.
- Within days: missing MFA for privileged users, broad service-account permissions, unrotated keys with uncertain ownership, and disabled audit logs.
- Within a planned change window: noncritical encryption, default-network cleanup, Trusted Launch adoption, and removal of unused identities after dependency checks.
Track exceptions with an owner, expiration date, compensating control, and documented business reason. A scanner that repeatedly reports the same unowned finding is not a security program; it is an inventory of unresolved risk.
Choosing a provider for your organization
Compare providers on the controls your team can operate consistently:
- IAM complexity: Can administrators understand and review effective permissions across accounts, subscriptions, projects, and third-party integrations?
- Logging coverage: Are the events you need available, affordable to retain, and easy to route into your detection system?
- Network and storage defaults: How quickly can teams identify and constrain public endpoints, firewall rules, and storage access?
- Identity integration: Does the platform fit your existing directory, MFA, workforce lifecycle, and privileged-access process?
- Remediation workflow: Can findings be assigned, measured, automatically fixed where safe, and verified after a change?
- Operational fit: Which provider’s architecture, policy language, and support model match your engineers’ skills and your regulatory obligations?
Multi-cloud operation increases the number of control planes and policy languages. The Cloud Security Alliance and Tenable reported in 2025 that 63% of organizations use more than one cloud provider, while 59% named insecure identities and risky permissions as their top cloud-infrastructure risk. Standardize the baseline across clouds, then add provider-specific checks instead of maintaining three unrelated security programs.
What the index means for AI workloads
Cloud identity and data controls become more consequential when workloads can call models, tools, storage, and external APIs. The 2025 Cloud Security Alliance and Tenable findings reported that 34% of organizations with AI workloads had experienced an AI-related breach. Apply the same least-privilege rules to model-serving identities, data pipelines, notebooks, agents, and automation accounts. Log prompts, tool calls, data access, and egress where lawful and appropriate, and separate development projects from production data.
Bottom line: risk is different, but the remedy is consistent
Google Cloud looks strongest on this particular 2026 prevalence index, AWS shows the broadest concentration of reported configuration gaps, and Azure’s leading issue is service misconfiguration centered on storage and identity. None removes the need for disciplined operations. The safest choice is the provider your organization can configure, monitor, and remediate continuously—with MFA, least privilege, protected logs, controlled exposure, key lifecycle management, and tested recovery in every environment.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Free tools Windows power users keep installed
One-click scans. No signup required.
