Open an older cloud security checklist and the first item is almost always “check for public S3 buckets.” It is still worth checking. It is no longer where your risk is.
Datadog’s 2025 study, from telemetry collected in September 2025, found that 1% of S3 buckets are effectively public, down from 1.5% in each of the two previous years, and 1.3% of Azure Blob containers, down from 2.6% a year earlier and 5% in 2023. The industry fixed this one. Default-deny settings, better console warnings and a decade of embarrassing headlines worked.
Meanwhile the numbers that did not improve are all about identity.
Credentials that never expire
- 59% of AWS IAM users have an active access key more than a year old.
- 55% of Google Cloud service accounts have an active key older than a year - down from 62%, so moving in the right direction.
- 40% of Microsoft Entra ID applications have credentials older than a year, down from 46%.
A year-old access key is not a vulnerability in the scanner sense. It is a key that has been in a laptop backup, a CI log, a Slack message and two former employees’ shell histories. Tenable’s figures tell the same story from another angle: more than half of organisations store at least one secret directly in an AWS ECS task definition, 52% in Google Cloud Run, 31% in Azure Logic Apps workflows, and 3.5% of all EC2 instances have secrets sitting in user data.
Permissions nobody has ever reviewed
- 12.2% of third-party integrations are dangerously over-privileged - enough for the vendor to read all data in the account or take over the AWS account entirely.
- Nearly one in four Google Cloud VMs (23%) has overly permissive access to its project.
- 78% of organisations have at least one IAM role unused for more than 90 days, and 93% have at least one privileged service account.
That third-party figure deserves a moment. Most companies have a careful process for giving a new employee access and no process at all for the monitoring tool that was connected with the quick-start CloudFormation template in 2023.
Management planes on the public internet
This is the finding we see most often and the one clients are most surprised by. Datadog found 39% of EKS clusters and 34% of AKS clusters exposed to the internet, and GKE “reaching over one in two (54%).”
Usually nobody chose this. It is the default on a quick-start cluster, and the cluster that was spun up for a proof of concept is now running something that matters.
How attackers are getting into cloud environments
Google’s Cloud Threat Horizons report for the first half of 2026, with data covering the second half of 2025, shows a sharp reordering:
- Third-party or software-based entry: 44.5%, up from 2.9% in the first half of 2025, overtaking credentials for the first time.
- Weak or absent credentials: 27.2%, down from 47.1%.
- Misconfiguration: 21%, down from 29.4%.
- Exposed sensitive UI or APIs: 4.9%, down from 11.8%.
Google states plainly that the vector data “reflects a subset of observed activity and may not represent all customers.” The 2.9% number is also used for two different things in the write-ups we read. Quote the percentages if you like, but do not build an argument on the size of that one jump. Wiz, measuring environment findings rather than incidents, puts software remote code execution at “only 9%” of what it sees.
The combination that actually gets exploited
Tenable calls it the toxic cloud trilogy: a workload that is publicly exposed, critically vulnerable, and highly privileged. Any one of those on its own is a ticket in a backlog. All three on the same workload is a breach waiting for someone to notice it. The share of organisations with at least one fell from 38% in early 2024 to about 29% by mid-2025, which is progress and still means roughly one organisation in three.
Orca’s 2025 figures frame the same problem as reachability: 76% of organisations have at least one public-facing asset that enables lateral movement, and Wiz reports 30% of observed cloud environments contain at least one externally exposed machine tied to a high-impact lateral movement path.
Why a configuration scanner is not enough
Wiz reports that contextual analysis “eliminated more than half of the initial findings” across four major risk categories. That is the whole argument in one sentence: most of what a posture management tool reports is not reachable, not privileged, or not real in your environment.
The value is not in listing misconfigurations. It is in answering one question: starting from the internet with no credentials, what can somebody actually reach, and what can they do once they are there? That requires chaining the exposed thing to the over-privileged role to the data, which is what a test does and a scanner does not.
The logging problem nobody has a number for
We went looking for a credible 2025 or 2026 figure on missing cloud logging and could not find one. What we can offer instead is Mandiant’s qualitative finding, which is worse than a percentage: with threats achieving dwell times of nearly 400 days, “standard 90-day log retention policies leave organizations completely blind to the initial access vector and the full scope of the intrusion.”
If your CloudTrail, your audit logs and your identity provider logs roll off at 90 days, you are not retaining evidence. You are retaining the last three months of an incident that started a year ago.
A week’s worth of work that would move all of this
- List every access key and service account key older than a year. Rotate or delete.
- List every third-party integration and read what it can actually do. Most can do far more than the vendor needs.
- Check whether your Kubernetes API endpoints are reachable from the internet. Decide deliberately, either way.
- Find workloads that are exposed and vulnerable and privileged. Fix those before anything else on the list.
- Extend log retention past 90 days for identity, the control plane and the edge.
Where these numbers come from
Every figure above is from one of these. If one of them has moved on since we wrote this, believe the source and not us.
What to do about it
Where should we actually start if identity is the problem?
With an inventory of every key, service account and role, and the date each was last used. You cannot rotate what you have not listed. Almost every organization that runs this exercise finds credentials belonging to people who left, integrations that were trialled once, and at least one role with far more permission than its job needs.
Is a configuration review the same as cloud penetration testing?
No, and they answer different questions. A cloud security assessment measures the whole account against a benchmark and lists what is wrong. Cloud penetration testing starts from one foothold and shows what can be reached with it. If you have never had either, have the assessment first.
How often do cloud credentials need rotating?
The useful question is not how often but whether anything would break if one disappeared. If you cannot answer that, the key is undocumented, which is a bigger problem than its age. Start by making every key traceable to an owner and a purpose, then put an expiry on it.
Do public storage buckets still matter?
They still matter, they are simply no longer where most of the risk is. The industry genuinely fixed that one with default-deny settings and better warnings. Keep checking, but do not let a clean bucket report stand in for an identity review.
Want this done on your own systems?
We scope the work in writing first, so you know exactly what will be touched and when.
Book a free consultation Back to the blog