TL;DR
- Weak IAM can undermine every other cloud security control
- In one Azure assessment, managed identity abuse led to Key Vault secrets being exposed
- Control plane access can be enough to bypass protections without public exposure
- Common issues include excessive privileges, weak MFA, and poor role assignment
- Least privilege, short-lived credentials, and stronger access controls reduce the risk
Introduction
Identity and Access Management, or IAM, is one of the most important security controls in any cloud environment. If it is weak, attackers can often work around the protections that sit on top of it.
We see this regularly in cloud penetration tests. Once an attacker has access to compromised credentials, they can often make changes that undermine other security controls. In some cases, that means modifying network security rules to expose services that were previously protected. Databases, key management systems, and secrets stores can all become reachable through a single API call if the wrong identity has the wrong permissions.
That is why insecure IAM so often sits at the centre of serious cloud security incidents. It is not just another configuration issue. It is the control that governs access to almost everything else.
Why IAM goes wrong
IAM is difficult to manage well.
Cloud environments are dynamic by nature. New services appear, teams change, applications scale, and permissions evolve over time. At the same time, organisations need to manage a growing mix of human users, service accounts, managed identities, roles, policies, and trust relationships.
The result is often a compromise between security and convenience. Permissions get granted too broadly. Authentication controls are not applied consistently. Role assignments become hard to track. Over time, these gaps create opportunities for attackers to gain access, escalate privileges, and move further into the environment than they should.
A real example from an Azure assessment
During an Azure assessment, we were able to abuse managed identities to extract privileged cloud credentials.
None of the target resources were publicly accessible. On paper, the environment looked reasonably locked down. In practice, the identities available to us gave control-plane access that let us modify the firewall rules protecting an Azure Key Vault.
We added our own IP address to the allowlist and then accessed the vault contents. That allowed us to dump all stored secrets, including credentials for the client’s Azure B2C environment. From there, the attack surface expanded significantly.
This is a good example of how cloud compromise does not always start with an exposed service. Sometimes the route in is through the control plane. If IAM is too permissive, an attacker does not need direct access to a sensitive resource. They only need permission to change the rules around it.
Common IAM issues we see in cloud assessments
Unrestricted resource deployment
Allowing users to deploy resources directly through the cloud portal, CLI, or SDK without peer review reduces organisational control. It increases the chance of misconfiguration, encourages shadow IT, and can give attackers a simple route to create or expose infrastructure once they have access.
Overly privileged roles
Users and services often end up with more permissions than they need. This can happen through direct assignments, inherited policies, or a combination of role-based and resource-based access. When those identities are compromised, the attacker inherits that same reach.
Insecure role assignments
Granting permissions directly to individual users instead of managing access through groups, roles, or policy makes IAM harder to audit and maintain. It also increases the chance of hidden admin access building up over time.
Cross-environment access
Poorly controlled trust relationships between subscriptions, accounts, or projects can give attackers a path to move laterally. In Azure, AWS, and GCP alike, cross-environment access needs tight control. Otherwise, compromise in one area can become compromise across many.
Weak authentication controls
Weak password policies, poor conditional access design, and inconsistent multi-factor authentication all make account compromise more likely. High privilege roles without strong authentication are especially dangerous.
Quick wins to reduce IAM risk
Limit direct access to cloud environments
Use deployment pipelines and peer review to enforce security checks wherever possible. That gives organisations more control than allowing broad direct access through portals and command line tooling.
Apply least privilege properly
Grant only the permissions needed for each role. Separate administrative activity from day-to-day user activity with dedicated admin accounts. Where possible, start with no access and add permissions gradually based on a real requirement.
Use short-lived authentication
Prefer managed identities, service accounts, and short-term tokens over static credentials. Long-lived access keys and hard-coded secrets create unnecessary risk and are often left in place for too long.
Enforce strong authentication
Require multi-factor authentication for privileged accounts and apply conditional access policies to reduce the likelihood of account takeover.
Enable logging and monitoring for IAM activity
Track role changes, policy edits, permission grants, and authentication events using cloud-native logging and alerting. If IAM changes are not being monitored, it becomes much harder to spot abuse early.
Implement just-in-time access
Reduce standing privilege by granting elevated access only when it is needed. Approval workflows and step-up authentication can make this much harder for attackers to abuse.
Rotate credentials regularly
Automate credential rotation wherever possible so that access keys, passwords, and tokens are not left unchanged for long periods.
IAM failures rarely stay contained
The danger with IAM weaknesses is not just initial access. It is what that access allows an attacker to do next.
A single over-permissioned identity can be enough to expose secrets, weaken network controls, create persistence, or pivot across environments. Once that happens, the rest of the cloud security stack may still be technically present, but it is no longer doing its job.
That is why IAM deserves much more attention than it often gets. In the cloud, access is everything. If identities are not properly controlled, attackers do not need to break through every defence. They can simply ask the platform to let them in.
