Businesses are increasingly relying on cloud adoption to make their operations smoother, scale faster, and speed up digital growth. However, mistakes in setting up these cloud applications can cause serious security problems and sensitive data exposure.
In fact, a shocking 99% of firewall breaches are caused by misconfigurations, with many of these leading to negative press, legal repercussions, and the depletion of customer trust.
Think of some of the biggest retail attacks of 2025: the notorious M&S breach, which led to around £300 million in lost profit, or retail giant the Co-Operative’s breach, which led to similarly severe profit losses and stock issues.
Both of these major attacks were caused by mismanaged IAM permissions, illustrating exactly why securing your cloud environments through proactive testing and configuration management is a critical part of any effective cybersecurity strategy.
What are Cloud misconfigurations?
Cloud misconfigurations are largely self-explanatory: when cloud resources within an organisation are set up incorrectly, exposing data or systems to risk.
Most cloud misconfiguration security incidents stem from human error, complexity, or default security settings that have been left unchanged by security teams.
When it comes to cloud security posture management, it is important to be aware of the cloud security shared responsibility model: cloud providers secure the infrastructure, but customers must secure and document configuration changes themselves.
How Cloud misconfigurations impact security
Cloud misconfigurations pose a serious risk to business security, with 45% of all breaches attributed to unpatched cloud risks. Here are some of the most notable ones to be aware of:
| Business Impact | What It Means | Consequence |
|---|---|---|
| Data exposure and breaches | Sensitive business data or customer records accessed due to insecure cloud configurations | GDPR fines, ICO investigation, and lasting reputational damage |
| Service downtime | Misconfigured cloud infrastructure taken offline by an attacker or internal error | Revenue loss, missed SLAs, and recovery timelines that extend well beyond the initial incident |
| Lateral movement | An attacker exploits a cloud misconfiguration to move through connected systems and escalate privileges | A single misconfigured IAM role or exposed storage bucket can lead to full environment compromise |
| GDPR non-compliance | Inadequate cloud storage controls are failing to protect sensitive data | Fines of up to £17.5 million or 4% of global turnover, mandatory breach reporting, and individual notifications |
| ISO 27001 non-conformance | Cloud security posture failing to meet ISMS requirements | Loss of certification, weakened partner confidence, and disqualification where ISO 27001 is a requirement |
Now that we have covered the repercussions of improper cloud security posture management, let’s investigate the most common cloud misconfigurations businesses encounter and how these can lead to forcible access by malicious actors.
The Most Common Cloud Misconfigurations
The most common misconfigurations that lead to security issues for teams include:
Publicly accessible storage buckets
- Cause: Cloud storage buckets misconfigured with overly permissive access settings leave sensitive files, customer records, internal documents, hardcoded credentials, publicly accessible with no authentication required. Open AWS S3 buckets and Azure Blob containers are the most common examples.
- Consequence: Automated tools scan for exposed buckets continuously. Once found, data is freely accessible to anyone who locates it, without any exploit, sophistication, or trace.
Overly permissive Identity and Access Management (IAM) policies
- Cause: IAM policies are written with * wildcards or admin roles assigned too broadly, giving cloud identities far more access than their function requires.
- Consequence: When that identity is compromised, an attacker inherits every permission attached to it, turning a minor foothold into full environment access through privilege escalation and lateral movement.
Unrestricted inbound/outbound traffic rules
- Cause: Security groups and VPC rules left at default or configured too broadly expose ports unnecessarily to the public internet. A common example is an inbound rule open to 0.0.0.0/0 on ports such as SSH (22), RDP (3389), or database ports, allowing any IP address in the world to attempt a connection.
- Consequence: Exposed ports are picked up by automated scanners within hours. Open ports and such misconfigurations invite brute-force attempts, while unrestricted outbound rules allow compromised workloads to exfiltrate data or communicate with attacker-controlled infrastructure undetected.
Disabled encryption and logging
- Cause: Encryption is disabled on storage volumes, databases, or data in transit, while logging and monitoring tools such as AWS CloudTrail or Azure Security Centre are switched off or misconfigured, leaving cloud environments effectively blind to suspicious activity.
- Consequence: Unencrypted data is readable the moment it is accessed by an unauthorised party, removing the last line of defence after a breach.
Without logging, there is no audit trail: meaning attacks go undetected, breach investigations stall, and demonstrating compliance with GDPR or ISO 27001 becomes impossible.
Poor secret and key management
- Cause: API keys and credentials are hardcoded into source code or plaintext config files and committed to repositories, sometimes public ones.
- Consequence: Automated bots scan repositories continuously for exposed secrets. A leaked key grants direct, authenticated access… often indistinguishable from legitimate traffic until significant damage is already done.
Default or weak access configurations
- Forgotten default passwords or configurations from initial setup phases
- Mention misconfigured Kubernetes dashboards and database instances
Now you know the key causes of misconfiguration-related cloud security breaches, let’s tackle the important stuff: prevention and the enforcement of proper security posture management.
How to prevent Cloud misconfigurations
To ensure your cloud environments are properly configured, reduce human error, and swiftly detect potential misconfigurations, your security teams should enforce these best practices:
| Best Practice | What It Means in Practice | Why It Matters |
|---|---|---|
| Use automated configuration scanning (CSPM) | Deploy a Cloud Security Posture Management tool to continuously scan your environment for misconfigurations | Manual reviews miss things. CSPM tools catch drift from secure baselines automatically, before attackers find it first |
| Regularly review IAM roles and access policies | Schedule routine audits of who has access to what, removing stale roles, unused accounts, and excessive permissions | Permissions accumulate over time. What was necessary six months ago may now represent unnecessary risk |
| Enable encryption at rest and in transit | Ensure all storage volumes, databases, and data transfers are encrypted using cloud-native controls | If data is accessed without authorisation, encryption ensures it cannot be read or used |
| Implement continuous logging and monitoring | Enable tools such as AWS CloudTrail or Azure Security Centre, and ensure logs are actively monitored and retained | Without logs, breaches go undetected, and investigations have no evidence to work from |
| Apply the principle of least privilege | Grant users, roles, and services only the permissions they need to perform their specific function | Limits the blast radius of any compromise: a restricted account can only do limited damage |
| Integrate cloud security into CI/CD pipelines | Embed security checks into deployment pipelines so misconfigurations are caught before they reach production | Fixing a misconfiguration pre-deployment costs minutes. Fixing it post-breach costs significantly more |
| Conduct regular penetration testing of cloud assets | Commission independent external testing of your cloud environment to validate that controls hold under real attack conditions | Configuration scanners find known issues. A skilled penetration tester finds what scanners miss |
| Understand the shared responsibility model | Clearly define which security obligations belong to your organisation and which belong to your cloud provider | Assuming your provider handles something they do not is one of the most common sources of cloud exposure |
| Enforce policy as code and security baselines | Define security requirements programmatically so infrastructure is deployed consistently and human error is removed from the equation | Manual configuration is inconsistent. Codified policy ensures every deployment meets the same security standard |
The role of Cloud pentesting in preventing misconfigurations
Cloud pentesting is so essential to overall organisational security as it can validate whether misconfigurations can actually be exploited, using real-world attack methods that simulate real hacker behaviour in a controlled environment.
CSPM vs. Penetration Testing: Know the Difference
CSPM (Detective)
- Continuously monitors cloud environments for misconfigurations and policy violations
- Flags what looks vulnerable, but does not confirm exploitability like pentesting
- Provides ongoing visibility for compliance frameworks such as EASA Part-IS and NIS2
- Think of it as your smoke alarm: it detects the risk, but does not tell you how bad the fire could get
Penetration Testing (Offensive Validation)
- Actively attempts to exploit identified weaknesses to confirm real-world impact
- Demonstrates whether an attacker could move laterally, escalate privileges, or exfiltrate data
- Produces evidential assurance that regulators and auditors expect
- Think of it as the fire drill: proving your defences hold under realistic conditions
Both are necessary: CSPM tells you the door may be unlocked, while a penetration test walks through it to see what could be stolen and how.
When Should I Pentest?
- Post-cloud migration. Validate that the new environment has been configured securely and that no attack paths were introduced during transition
- New application or significant update. Test before or immediately after go-live to catch exploitable vulnerabilities in fresh code
- Compliance preparation. EASA Part-IS audits, CAA ASSURE assessments, and NIS2 reviews increasingly require evidence of offensive testing, not just automated scanning
- Post-incident or near-miss. Following a ransomware attempt or anomalous access event, a penetration test determines how far an attacker could have progressed and whether residual compromise remains
- Significant infrastructure change. New firewall, network reorganisation, or third-party integration all expand the attack surface and warrant re-testing
When correctly configured, cloud services and applications are an excellent method of streamlining organisational operations.
Businesses shouldn’t feel threatened by the potential risks of cloud computing but rather take a proactive mindset to prevent cloud security failures and enforce proper access controls.
OnSecurity’s cloud pentesting expertise helps identify misconfigurations from an attacker’s point of view, testing access controls, APIs, and data flows.
