Top Cloud Security Misconfigurations in 2026: 59% Still Have Old Keys

Every cloud security review I have done in the last few years has found the same handful of problems, in roughly the same order, and almost none of them were exotic. This post covers the top cloud security misconfigurations in 2026: long-lived access keys, overprivileged IAM, IMDSv1, public storage, open network paths and missing logs. For each one I look at what the current data says, from the Verizon 2026 DBIR and Datadog's 2025 State of Cloud Security mainly, and give the fix that actually removes the problem rather than the one that produces a nicer dashboard. If you want to find these in your own AWS account this afternoon, the companion guide shows how to audit an AWS account with Prowler.

What counts as a cloud misconfiguration, and does it still cause breaches?

A misconfiguration is any setting that grants more access, exposure or silence than the workload needs: a bucket policy with "Principal": "*", a role with s3:* on every resource, a security group open to 0.0.0.0/0, a region where nobody turned on a trail. None of these is a CVE. Nothing gets patched; somebody has to change a setting.

The 2026 DBIR is a useful corrective to the idea that misconfiguration is the whole story. Verizon reports that exploitation of software vulnerabilities is now the top initial access vector at 31% of breaches, ahead of stolen credentials. GitGuardian's read of the report adds the numbers that matter for cloud: credential abuse fell to 13% as an initial vector but appears somewhere in 39% of breaches, and third parties were involved in 48% of breaches, up from 30% a year earlier.

That is the shape of a cloud breach. The attacker gets in through a bug, a phished laptop or a vendor, then finds a credential, and the misconfigurations decide how far that credential goes. Misconfiguration is rarely the door. It is the size of the building behind the door.

1. Long-lived access keys and exposed secrets

This is still number one, and the data has barely moved. Datadog found that 59% of AWS IAM users have an active access key older than a year, with no improvement on 2024, and the share of keys older than three years rose from 21% to 25%. Google Cloud is at 55% for service account keys older than a year and Entra ID at 40% for application credentials. Meanwhile 39% of organisations still use IAM users in some form, even though 79% already federate console logins.

Old keys matter because keys leak. GitGuardian's State of Secrets Sprawl 2026 counted 28.65 million new hardcoded secrets in public GitHub commits in 2025, up 34%, and more than 64% of valid secrets found in 2022 were still valid when retested in January 2026. I covered that report in more depth in the secrets sprawl post.

The cleanest recent example of what a leaked key buys an attacker is the Codefinger campaign, reported in January 2025. As The Register reported from Halcyon's research, the group used exposed or compromised AWS keys with s3:GetObject and s3:PutObject to re-encrypt objects with SSE-C keys only they held, then set lifecycle rules to delete the data in seven days. No AWS vulnerability was involved. AWS has since disabled SSE-C by default on new general purpose buckets from 6 April 2026, which closes that particular trick, but the key was the problem, not the encryption mode.

The fix is not "rotate every 90 days". The fix is to stop having the key. CI should use OIDC, workloads should use roles, and humans should use SSO with short sessions. Workload identity federation covers the mechanics.

2. Overprivileged IAM roles and third-party access

Outright admin is now rare on workloads. Datadog found fewer than 0.4% of EC2 instances have administrator privileges, which is real progress. But 19.4% are still overprivileged, mostly through excessive data access (17.9%), with smaller groups that can move laterally (3.8%) or escalate privileges (2.4%). On Google Cloud, 17% of VMs get admin-level access through the default compute service account.

Third-party roles are worse and getting worse. The average organisation has 13 third-party integration roles linked to about 2.5 vendors, 12.2% of them are dangerously overprivileged (up from 10%), and 2.25% do not enforce an external ID, which leaves them open to the confused deputy problem. Read that next to the DBIR's 48% third-party figure. Every vendor you connect gets a standing trust path into your account.

What works: start from IAM Access Analyzer's unused-access findings rather than from a blank page, cap what any role can do with SCPs and permission boundaries, require sts:ExternalId on every cross-account trust policy, and review vendor roles at renewal time, which is the one moment you have any bargaining power.

3. Is IMDSv1 still a problem in 2026?

Yes, less than before, but more than it should be. IMDSv1 answers any plain HTTP GET to 169.254.169.254, which means a server-side request forgery bug in your app becomes a credential theft bug. IMDSv2 requires a session token obtained with a PUT, which most SSRF primitives cannot send.

Datadog's numbers show the gap between "possible" and "done". Only 49% of EC2 instances enforce IMDSv2 (up from 32%), and the average organisation enforces it on 66% of instances. Yet 82% of instances only used IMDSv2 in the previous two weeks, so turning enforcement on would have broken nothing. Fewer than 3% of organisations use the account-level default, and the ones that do reach 95% or more enforcement.

That last figure is the lesson. AWS lets you set IMDSv2 as the account default per region with modify-instance-metadata-defaults, and add --http-tokens-enforced enabled so an instance configured for IMDSv1 cannot launch at all. Organisations can push the same setting through declarative policies. Defaults beat reminders every time.

4. Public S3 buckets and storage containers

Public buckets are the misconfiguration everyone has heard of and, happily, the one that has improved most. Datadog reports 1% of S3 buckets are effectively public, down from 1.5%, with 83% covered by Block Public Access. On Azure, 1.3% of blob containers are public, down from 2.6%. The S3 docs now state plainly that new buckets, access points and objects do not allow public access by default.

One percent sounds small until you multiply it by the number of buckets a mid-sized company has. The remaining ones are usually static sites, partner drops or "temporary" shares that someone later writes sensitive files to.

Two details catch people. First, Block Public Access does not rewrite existing policies or ACLs. Remove the setting and anything that was public becomes public again. Second, the account-level and organisation-level settings are the ones that hold, because anyone with broad S3 permissions on a bucket (including s3:PutBucketPublicAccessBlock) can turn off bucket-level blocking. Turn it on at the account (or organisation) level, and serve genuinely public content through CloudFront with origin access control rather than a public bucket.

5. Open security groups and exposed control planes

Security groups with SSH, RDP or database ports open to 0.0.0.0/0 keep appearing because they are the fastest way to unblock someone at 6 pm. The more interesting 2025 numbers are about control planes: Datadog found the API server internet-exposed on 39% of EKS clusters, 34% of AKS clusters and 54% of GKE clusters. Those endpoints still require authentication, but each one is a public target for the next Kubernetes authentication bug. The Kubernetes security post covers how quickly exposed clusters get probed.

Scanners have their own blind spots here. The Prowler 5.47.0 release notes from 29 October 2026 mention a fix: a single ingress rule using CIDRs that together cover the internet, such as 0.0.0.0/1 plus 128.0.0.0/1, used to pass the port 22 check. That is exactly the kind of thing someone writes to get past a policy. Use Systems Manager Session Manager or an identity-aware proxy instead of SSH from the internet, make cluster endpoints private, and treat any 0.0.0.0/0 ingress outside a load balancer as a ticket.

6. Logging switched off or never switched on

Missing logs do not cause breaches. They make them unknowable. CloudTrail event history is on by default, but it keeps only 90 days of management events, per region, with no data events and no organisation-level view. If you discover a compromise on day 120, or the attacker only read S3 objects, event history has nothing for you.

The baseline is an organisation trail (or CloudTrail Lake event data store) covering all regions, delivered to a bucket in a separate log archive account that the workload accounts cannot delete from. Add S3 data events at least for buckets holding sensitive data, enable GuardDuty in every region, and keep AWS Config recording so you can answer "when did this security group change?"

The data in one table

Misconfiguration	Current data point	Source	Fix that holds
Long-lived keys	59% of IAM users have a key older than 1 year; 25% of AWS keys older than 3 years	Datadog 2025	OIDC for CI, roles for workloads, SSO for humans
Leaked secrets	28.65M new secrets on public GitHub in 2025; 64%+ of 2022 secrets still valid	GitGuardian 2026	Pre-commit scanning plus revocation, not just deletion
Overprivileged workloads	19.4% of EC2 overprivileged, under 0.4% admin	Datadog 2025	Access Analyzer unused access, SCPs, boundaries
Third-party roles	12.2% overprivileged, 2.25% without external ID; third parties in 48% of breaches	Datadog 2025, DBIR via GitGuardian	Least-privilege vendor roles, required sts:ExternalId
IMDSv1	49% of EC2 enforce IMDSv2; under 3% of orgs set the default	Datadog 2025	Account default plus enforcement
Public storage	1% of S3 buckets and 1.3% of Azure containers public	Datadog 2025	Account or org Block Public Access, CloudFront OAC
Exposed control planes	Public API server on 39% EKS, 34% AKS, 54% GKE	Datadog 2025	Private endpoints, no SSH from the internet
Thin logging	Event history keeps 90 days of management events only	AWS CloudTrail docs	Org trail to a separate log account, data events

A one-afternoon AWS baseline

Most of the fixes above are a few API calls. This script is what I would run in a single account to close the cheapest gaps. It prints the current state before it changes anything, and it is safe to run twice. I wrote it against the AWS CLI 2.39.3 command reference and have not run it against a live account for this post, so read it before you run it.

#!/usr/bin/env bash
# aws-baseline.sh: close the cheapest misconfigurations in one AWS account.
# Requires AWS CLI v2 (2.39.3 at time of writing) and admin-level credentials.
set -euo pipefail
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)

# 1. Account-level S3 Block Public Access (applies to all regions).
#    Check first: anything legitimately public will stop being public.
aws s3control get-public-access-block --account-id "$ACCOUNT_ID" || true
aws s3control put-public-access-block --account-id "$ACCOUNT_ID" \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

# 2. IMDSv2 as the default for new instances, in every enabled region.
#    Hop limit 2 so containers on the instance can still reach IMDS.
for region in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  aws ec2 modify-instance-metadata-defaults --region "$region" \
    --http-tokens required --http-put-response-hop-limit 2 >/dev/null
  echo "IMDSv2 default set in $region"
done

# 3. List active IAM access keys with their rotation dates, oldest first,
#    so a human can retire anything older than a year.
aws iam generate-credential-report >/dev/null; sleep 5
aws iam get-credential-report --query Content --output text | base64 --decode \
  | awk -F, 'NR>1 && $9=="true" {print $10, $1, "key1"} NR>1 && $14=="true" {print $15, $1, "key2"}' \
  | sort

# 4. List multi-region trails. Then run get-trail-status --name <trail> and
#    confirm IsLogging is true.
aws cloudtrail describe-trails --query 'trailList[?IsMultiRegionTrail].Name' --output text

Enforcement (--http-tokens-enforced enabled) is deliberately left out: turn it on per region after Prowler or Datadog shows no instance still using IMDSv1. In the credential report, columns 9 and 10 are key 1's active flag and rotation date, and columns 14 and 15 are the same for key 2.

Which CSPM tools find these misconfigurations?

Cloud security posture management (CSPM) tools run checks like the ones above continuously. The realistic options in 2026:

• Prowler, Apache-2.0, from prowler-cloud/prowler. Version 5.47.0 lists 668 AWS checks across 89 services and 50 AWS compliance frameworks when I ran prowler aws --list-checks and --list-compliance locally. It is the one I reach for first because it runs anywhere with a read-only role.
• AWS Security Hub CSPM, the service previously called Security Hub. AWS renamed it in 2025 and launched a new Security Hub that went generally available on 2 December 2025, correlating Security Hub CSPM, GuardDuty and Inspector findings. Native, multi-account, priced per check.
• Commercial platforms such as Datadog, Wiz and Orca, which add agentless scanning, attack-path graphs and a lot of correlation.

None of them fixes anything. The tool that matters most is the one whose findings someone owns, with a deadline. I would also catch misconfigurations before they deploy by scanning Terraform in CI, which the Terraform testing guide covers with Checkov.

FAQ

What is the most common cloud security misconfiguration?

By prevalence, long-lived credentials. Datadog found 59% of AWS IAM users have an active access key older than a year, and the number did not improve between 2024 and 2025. Public storage gets more headlines but is now around 1% of S3 buckets.

Is IMDSv1 disabled by default on new EC2 instances?

Not universally. AMIs registered with ImdsSupport: v2.0 launch IMDSv2-only, and you can set an account-level default per region, but otherwise the launch settings decide. Datadog found only 49% of instances enforce IMDSv2, so check yours with Prowler's ec2_instance_imdsv2_enabled check.

Does S3 Block Public Access fix existing public buckets?

It blocks access through public ACLs and policies while it is on, but it does not rewrite them. If someone later disables the setting, the old public policy takes effect again. Remove the public grants as well, and set the block at account or organisation level.

Do I need a CSPM tool if I use Terraform?

Yes, because not everything in the account came from Terraform, and drift happens. IaC scanning catches problems before deploy; a CSPM scan catches console changes, vendor-created resources and old accounts. An open-source scanner like Prowler on a weekly schedule is enough to start.

This quarter I would do three things in every account I am responsible for: delete or replace every IAM user access key older than a year, set the IMDSv2 account default in all regions and then enforce it once the scan is clean, and confirm the organisation trail lands in a log account nobody in a workload account can touch. Then I would schedule a weekly Prowler run so the next 6 pm security group exception shows up on Monday instead of in an incident report.

Related: Secrets Sprawl 2026: 28.65M Leaked Keys and 64% Still Valid Years Later, Workload Identity Federation Explained (2026): OIDC Instead of Cloud Keys and Kubernetes Security in 2026: First Attack in 18 Minutes, and What Stops It.