According to Gartner, nearly 80% of data breaches in the cloud stem from misconfigurations,

These aren’t sophisticated attacks, they’re often the result of simple oversights such as overly open settings, excessive permissions, or forgotten credentials. The good news is that most can be identified and fixed with the right approach. So in this blog I wanted to share some of the common cloud misconfigurations we see and how to remediate them.

1. Insecure Default Settings

Cloud services prioritise usability and that often means permissive default settings such as open ports, public access flags, or default credentials that are rarely safe out-of-the-box. If these aren’t reviewed and hardened immediately, sensitive assets can be left wide open.

Why it happens: Teams move fast, and “secure by default” is mistakenly assumed.

How to fix it:

• Define and enforce secure landing zones or base templates across accounts.
• Review and harden default settings on every service post-deployment.
• Use automated policy checks (CSPM, IaC linters) to catch deviations from your security baseline.

2. Publicly Accessible Storage Buckets

Exposing a cloud storage bucket to the public is the digital equivalent of leaving confidential files on the street. Misconfigured S3 buckets, Azure Blobs, or GCP storage buckets have repeatedly led to high-profile data leaks.

Why it happens: Developers overlook bucket access controls or misinterpret policy settings.

How to fix it:

• Scan for any buckets with public permissions (e.g. allUsers, anonymous access).
• Block public access by default and enforce encryption.
• Continuously monitor for configuration drift using automated tools.

3. Overly Permissive IAM Policies

Granting excessive privileges, especially via wildcard permissions or catch-all admin roles, turns every identity into a potential breach point. It breaks the principle of least privilege and makes it easier for attackers to escalate access.

Why it happens: Convenience. Full-access roles get created to speed up delivery or bypass complexity.

How to fix it:

• Audit IAM roles and policies for overly broad access or wildcards.
• Remove or refactor legacy admin roles.
• Implement least privilege at every level, and use CIEM or IAM Access Analyzer to flag violations.

4. Stale or Unused Credentials

Long-forgotten keys, tokens, or service accounts that no longer serve a purpose are a silent risk. If leaked, they give attackers a direct line into your environment and may go unnoticed for weeks or months.

Why it happens: Credentials are rarely cleaned up when people leave or systems are retired.

How to fix it:

• Identify and revoke unused credentials (e.g. AWS access keys unused for 30+ days).
• Enforce regular key rotation.
• Prefer short-lived credentials (IAM roles, OAuth tokens) over permanent keys.

5. Exposed Dev/Test Environments

Development and staging environments often contain test data or partial copies of production logic. If publicly accessible, they become low-hanging fruit for attackers.

Why it happens: Test systems are spun up quickly and sometimes never taken down.

How to fix it:

• Restrict dev/test systems to internal networks or require VPN/MFA access.
• Monitor for public IPs, subdomains or endpoints tied to test environments.
• Implement expiry policies to decommission temporary environments after use.

Prevention Starts With Visibility

Not all misconfigurations are equal. Exposed resources like public buckets or internet-facing test servers should be remediated immediately. But the real fix is preventative.

Here’s what effective prevention looks like:

• Secure baselines: Start with hardened configurations that new resources inherit.
• Least privilege everywhere: Give every role and service the minimum access required.
• Continuous monitoring: Use cloud-native logs and automated tooling to detect changes in real-time.
• Credential hygiene: Enforce strict rotation and routinely audit for unused keys or accounts.
• Regular assessments: Conduct full-scope cloud security reviews to catch hidden issues and validate fixes.

Misconfigurations aren’t a failure of the cloud, they’re a failure to configure it correctly. But with the right foundations and practices in place, they’re entirely preventable.