Cloud misconfigurations

Misconfigurations are one of the most persistent and dangerous risks in cloud security. They’re often the initial weakness that allows attackers to pivot into sensitive systems. From exposed storage buckets to overly permissive identity and access management (IAM) policies, these gaps reduce the effectiveness of even the most advanced security controls.

Misconfigurations occur when you deploy cloud services with insecure settings, either through oversight, speed of delivery or lack of policy enforcement.

According to the Tenable 2025 Cloud Security Risk Report, misconfigured services are among the most common root causes of cloud exposure, with more than half of organizations (54%) storing at least one secret directly in AWS ECS task definitions, which creates a direct attack path.

Misconfigurations like these bypass other security layers by unintentionally granting access, turning off monitoring or leaving services publicly reachable.

Crucially, they’re easy to introduce — and hard to detect — without automated scanning and policy enforcement.

Across cloud providers, recurring misconfiguration patterns include:

• Publicly accessible storage buckets (e.g., S3, Blob Storage)
• Missing encryption for data at rest or in transit
• Disabled or missing logging and audit trails
• Overly broad IAM roles or lack of multi-factor authentication
• Serverless functions with unauthenticated endpoints
• Misconfigured security groups and open ports

Any one of these alone can introduce risk. In combination, these misconfigurations form the kinds of exploitable paths attackers routinely search for.

Misconfigurations aren’t limited to open ports or exposed storage. They also live in identity and access configurations.

Overly broad IAM roles, unused permissions and default service accounts can quietly introduce significant risks.

A service account with idle but powerful entitlements may not trigger alerts, but if it connects to a public-facing workload, it forms a critical exposure path.

Cloud infrastructure entitlement management (CIEM) tools help detect cloud misconfigurations, find toxic combinations and flag when permissions don’t align with usage.

Context matters. Teams need to understand who can access what and how that access interacts with runtime exposure.

Pairing identity analysis with misconfiguration detection strengthens your ability to spot and shut down real attack paths.

Misconfigurations in cloud infrastructure and identity systems often seem minor on their own. But when combined, they create exploitable conditions that allow attackers to move laterally, escalate privileges or access sensitive data.

Security teams that use exposure-aware tools can detect and correlate these risks and identify how misconfigurations, excessive permissions and service connections enable lateral movement.

Prioritizing fixes based on exploitability, rather than volume, leads to better outcomes.

Understanding these patterns strengthens your cloud security posture and speeds up incident response.

Example: Public EC2 instance + dev role with cross-account access

An AWS EC2 instance allows inbound internet traffic and uses an outdated IAM role. That role still holds cross-account permissions.

An attacker who gains access can pivot across environments and reach internal backups or code repositories.

Example: Stale admin credentials in CI/CD

A former DevOps admin role retains active access keys. Those keys live in an unencrypted parameter store and an old CI/CD script can still call them.

If a threat actor accesses the script, they can use the credentials to modify infrastructure at scale.

Example: Open firewall + default service account

A GCP Compute Engine instance uses a firewall rule that allows unrestricted inbound traffic. It also runs under the default service account, with access to storage and analytics resources.

A breach in that instance gives the attacker a clear path into your broader data plane.

Example: Role assumption without access conditions

An Azure service principal can assume a cross-subscription role that lacks conditional policies.

Even though the principal originated in a dev environment, it accesses production secrets because the role doesn’t enforce scope boundaries.

Modern cloud security platforms detect cloud misconfigurations through continuous posture assessments.

These tools evaluate resource configurations against known best practices, such as the CIS Foundations Benchmarks, and custom organizational policies.

Detection mechanisms span multiple layers:

• API integrations with AWS, Azure and GCP
• Infrastructure as code (IaC) scanning
• Runtime analysis of deployed resources
• Exposure graphing that links misconfigurations to real risk

This layered approach ensures you catch misconfigurations, whether introduced in code, through manual changes or provider defaults.

Infrastructure as code templates like Terraform, CloudFormation or Kubernetes YAML define much of today’s cloud infrastructure.

Detecting misconfigurations early and before deployment is essential.

Cloud-native scanning tools integrate directly into CI/CD platforms such as GitHub, GitLab or Bitbucket. They flag misconfigured resources in pull requests and suggest secure alternatives that comply with internal policies and external frameworks.

This shift-left model ensures insecure resources never make it to production in the first place, saving time and reducing downstream risk.

Detection is only part of the solution. Effective remediation strategies must address both infrastructure-as-code and live cloud environments.

In infrastructure as code security, automated policy enforcement tools can insert secure defaults or block merges with unresolved issues.

In runtime environments, teams may rely on remediation playbooks, pre-approved fix actions or integrations with configuration management systems.

In some cases, cloud provider native tools (like AWS Config Rules or Azure Policy) also enforce secure configurations.

Platforms that support exposure management analyze how misconfigured services connect to identities, data stores and internet-facing endpoints. It creates a clearer picture of exploitable paths.

For example, an open storage bucket might seem minor until linked to an over-permissioned service account and a publicly reachable API gateway.

Addressing just the bucket doesn’t eliminate the threat. Exposure-based prioritization ensures remediation efforts focus on misconfigurations that form real attack chains.

Compliance requirements often call for proof of secure configurations. Benchmarks like the CIS Foundations Benchmark or frameworks such as NIST 800-53 provide technical guidance that maps to regulatory expectations.

Scanning against these standards, and enforcing fixes before deployment can help you meet requirements. It also creates audit trails that demonstrate continuous compliance.

Interested to learn more about the potential impact of cloud misconfigurations, read about how our research team discovered that cloud misconfigurations expose sensitive data and secrets.