Top 5 Cloud Security Misconfigurations in 2026
From publicly accessible S3 buckets to over-privileged IAM roles, we break down the most systemic cloud misconfigurations found in our enterprise assessments. Learn how to implement continuous posture management to prevent catastrophic cloud data breaches.
Cloud breaches are rarely the result of a cloud provider being compromised. They are the result of customers configuring their side incorrectly — and then not noticing for months. The infrastructure is sound; the defaults, the drift, and the permissions granted "temporarily" three years ago are not.
This is what the shared responsibility model actually means in practice. AWS, Azure and Google secure the platform. Everything you build on it — identity, network exposure, storage access, key management, logging — is yours. The most common cloud incidents are not sophisticated; they are an access policy nobody reviewed and a storage bucket nobody knew was public.
This guide covers the misconfigurations we find most often in enterprise cloud assessments, why each one persists despite being well known, and the specific controls that prevent recurrence rather than just fixing today's instance.
- 01Over-privileged identity is the single largest cloud risk — and the least visible, because nothing breaks.
- 02Public storage exposure persists because access is granted in several places, and fixing one does not close the others.
- 03Unrestricted management ports remain common. Attackers find them within minutes of exposure.
- 04Missing or unmonitored logging turns a contained incident into an unanswerable one — you cannot investigate what you never recorded.
- 05Fix at the template, not the instance. A misconfiguration corrected in the console returns on the next deployment.
1. Over-Privileged Identity and Roles
This is the most consequential and the most persistent. Wildcard permissions get granted during development to unblock a deployment, the project ships, and nobody revokes them — because revoking permissions risks breaking something, while leaving them costs nothing visible.
The result is an environment where a compromised application role can read every bucket, or a CI/CD pipeline identity can modify production infrastructure. Attackers do not need to escalate privilege when the privilege is already there. Machine identities compound this: service accounts and workload identities typically outnumber human users several times over, hold broad standing permissions, and are excluded from MFA by design.
What actually works: derive permissions from observed usage rather than from what a developer requested. Every major cloud provider now exposes access analysis showing which granted permissions were never used — that report is the fastest route to meaningful least privilege. Combine it with short-lived credentials and just-in-time elevation so standing access approaches zero.
2. Publicly Exposed Storage
Every provider has made this harder, and it still happens — because exposure can originate in several independent places. A bucket policy, an object-level ACL, a permissive presigned URL configuration, or a CDN distribution sitting in front of otherwise private storage will each expose data on their own.
Teams commonly check one, find it correct, and conclude the data is private. The failure is not carelessness so much as a genuinely confusing permission surface where several mechanisms overlap.
What actually works: enable account-level public access blocking so individual buckets cannot opt themselves into exposure, enforce encryption by default, and verify exposure from the outside. An external check that actually attempts anonymous access is worth more than any number of internal policy reviews — which is precisely what attack surface management is for.
3. Unrestricted Network Exposure
Security groups permitting inbound access from anywhere to SSH, RDP, or database ports remain routinely present in enterprise environments. These are almost always temporary rules for troubleshooting that were never removed, and they persist because nothing draws attention to them.
The exposure window is not theoretical. The entire public address space is scanned continuously by automated infrastructure, and a newly exposed management port is typically discovered and probed within minutes.
| Exposure | Why it happens | Control that prevents recurrence |
|---|---|---|
| SSH / RDP open to the internet | Temporary troubleshooting rule never removed | Bastion or provider session manager; deny-by-default in IaC policy |
| Database port publicly reachable | Convenience during migration or a vendor integration | Private subnets only; enforce via guardrail policy |
| Overly broad peering or transit | Flat connectivity chosen to avoid routing complexity | Segment by environment and sensitivity |
| Management plane open | Kubernetes API or admin consoles left publicly accessible | Private endpoints with allow-listed access |
4. Disabled, Incomplete or Unmonitored Logging
Logging is disabled to control cost, enabled in one region but not others, or enabled everywhere and reviewed by nobody. All three produce the same outcome during an incident: you know something happened and cannot establish what.
This turns a manageable incident into an unbounded one. Without reliable audit trails you cannot determine which data was accessed, which forces worst-case assumptions in breach notification — and for Indian organisations, CERT-In's six-hour reporting obligation assumes you have the telemetry to know an incident occurred at all.
What actually works: enable audit logging across all regions and accounts, write it to an isolated account an attacker cannot reach with production credentials, set retention against your investigation and regulatory needs, and — critically — route it into a monitored SOC. Logs nobody reads are an archive, not a control.
5. Unmanaged Secrets and Keys
Credentials in environment variables, in source control, in container images, or in infrastructure-as-code state files. Long-lived access keys that have never been rotated. Encryption keys with permissive policies that undermine the encryption they exist to provide.
Secrets in source control deserve particular emphasis because deletion does not remediate them — the value remains in git history and in every clone and fork. The only correct response to a committed secret is rotation, not removal of the commit.
What actually works: a managed secrets service with short-lived, automatically rotated credentials; workload identity federation so applications assume roles rather than holding static keys; and secret scanning in the pipeline that blocks the commit rather than reporting it afterwards.
The pattern behind all five: each is trivial to fix once and near-certain to return, because the fix is usually applied to the running resource while the source — a template, a module, a pipeline default — is left unchanged. If the same finding reappears in consecutive assessments, you are remediating symptoms.
Why Posture Tools Alone Are Not Enough
Cloud security posture management is genuinely valuable and should be running continuously. It finds known misconfiguration patterns quickly and at scale, which is exactly what automation is good at.
What it does not do is reason about your business. A tool can tell you a role holds broad permissions; it cannot tell you that this particular role is assumable by a public-facing function and therefore constitutes a direct path from the internet to your customer database. Chained exposure — where several individually acceptable configurations combine into a real attack path — requires someone who can hold the whole environment in mind. That is the gap a manual cloud security assessment fills, and why we treat CSPM as the continuous layer beneath periodic expert review rather than a replacement for it.
- 01Run access analysis and remove permissions that have never been used.
- 02Replace static keys with workload identity and short-lived credentials.
- 03Enable account-level public access blocking on storage, then verify externally.
- 04Remove internet-facing management ports; use a bastion or session manager.
- 05Enable audit logging in every region and account, written to an isolated account.
- 06Route cloud telemetry into a monitored SOC, not just a storage bucket.
- 07Add secret scanning that blocks commits, and rotate anything already committed.
- 08Enforce guardrails in infrastructure-as-code and pipeline policy, so drift cannot ship.
- 09Track recurrence — the same finding twice means the source was never fixed.
How Adayptus Helps
- Cloud Security Assessment — manual, expert-led review across AWS, Azure and GCP, with a free retest.
- Cloud Security Posture Management and CWPP — continuous coverage between deep assessments.
- Cloud Identity Review — the over-privilege problem, addressed directly.
- Container & Kubernetes Security — where cluster defaults create their own exposure.
- Attack Surface Management — outside-in verification of what is actually reachable.
- Managed SOC & MDR — so cloud telemetry is monitored rather than merely retained.
Related reading: CSPM vs CWPP vs CNAPP explained and Kubernetes and container security best practices.
Frequently Asked Questions
Click any question to expand the answer.
QWhat is the most common cloud misconfiguration?
Over-privileged identity. Wildcard permissions granted during development to unblock a deployment are rarely revoked afterwards, because removing permissions risks breaking something while leaving them costs nothing visible. The result is that a compromised application role or pipeline identity already holds the access an attacker would otherwise have to escalate to obtain. Machine identities make it worse, since they typically outnumber humans and are excluded from MFA by design.
QIs cloud security the provider's responsibility?
Only partly. Under the shared responsibility model the provider secures the underlying platform — physical infrastructure, hypervisor, managed service internals — while you remain responsible for everything you configure on top: identity and permissions, network exposure, storage access, encryption key policy, logging and application security. Almost all cloud breaches originate on the customer side of that line, which is why assessments focus there.
QIs a CSPM tool enough to secure our cloud?
No, though it is a necessary layer. Posture tools find known misconfiguration patterns quickly and continuously, which is exactly what automation does well. What they cannot do is reason about your business — a tool can report that a role holds broad permissions, but not that this role is assumable by a public-facing function and therefore forms a direct path from the internet to your customer data. Chained exposure of that kind requires manual assessment.
QA secret was committed to our repository. Is deleting the commit enough?
No. The value persists in git history, in every clone, in forks, and potentially in CI caches and mirrors, so removing the commit does not remove the exposure. Treat the credential as compromised and rotate it — that is the only reliable remediation. Then add secret scanning that blocks the commit at the pipeline rather than reporting it after the fact, and move the value into a managed secrets service with automatic rotation.
QWhy do the same misconfigurations keep reappearing?
Because the fix was applied to the running resource rather than its source. A permissive security group corrected in the console returns on the next deployment if the Terraform module still defines it that way, and an insecure default in a shared template propagates to every team that uses it. Fix at the template and enforce guardrails in pipeline policy so non-compliant infrastructure cannot deploy. Track recurrence as a metric — repeat findings are the clearest signal you are treating symptoms.
QHow often should we assess our cloud environment?
Posture monitoring should run continuously, since cloud environments change daily and a misconfiguration introduced on Monday should not wait until a quarterly review. Layer a deeper manual assessment at least annually and after significant architectural change — a new account structure, a migration, a merger, or a major platform adoption — because that is where chained exposure and identity attack paths are found. The two are complementary rather than alternatives.
Mike T.
Strategic Intelligence Division
Adayptus Consulting is a premier provider of enterprise cybersecurity solutions, specializing in Managed SOC, Penetration Testing, and GRC strategy. Our intelligence division regularly publishes research to help CISOs navigate the evolving threat landscape.
