The quietest risk in your cloud is IAM

Most cloud breaches do not start with a clever exploit. They start with a credential, a role, or a policy that allowed more than anyone intended. Identity and Access Management is the layer that decides who can do what inside your cloud, and it is the layer attackers care about most once they get a foothold. It rarely throws alerts on its own. A role with a wildcard permission does not page anyone at 2am. It just sits there, working as configured, until someone uses it the way it was always able to be used. That is why IAM is the quietest risk in your cloud, and why we treat it as a first-class target in every cloud assessment we run.

For regulated companies, this is not an abstract concern. NIS2, DORA, ISO/IEC 27001, and SOC 2 all expect you to control access, prove least privilege, and detect misuse. The auditors look at your IAM design. The attackers look at your IAM mistakes. Those are two different reviews, and passing one does not mean you survive the other. This post explains what IAM risk actually looks like in modern cloud environments, how we test it, what you get from an assessment, and how it connects to the frameworks you already answer to.

What IAM actually means in a cloud environment

IAM is the set of identities, credentials, permissions, and policies that govern access to your cloud resources. In a traditional network, access was mostly about being inside the perimeter. In cloud, the perimeter is the identity. If an attacker holds a valid credential or assumes a role with the right permissions, they are inside, regardless of network controls. AWS, Azure, and Google Cloud each implement this differently, but the principle holds across all three. Permissions attach to identities, identities authenticate with credentials, and the blast radius of any compromise is defined entirely by what those permissions allow.

The trouble is that IAM grows by accretion. Someone needs access for a project, a role gets created, the project ends, and the role stays. A service needs to talk to a database, so a developer attaches a broad managed policy because it works and the deadline is real. Multiply that across years and teams, and you get an identity layer that no single person understands. We see this in nearly every environment we assess. The customer believes their access is tight. The data says otherwise.

• Human identities cover employees, contractors, and administrators who log in interactively, usually through a federated identity provider or directly in the cloud console.
• Machine identities cover service accounts, instance roles, and workload identities that authenticate without a human present, and these now outnumber human identities by a wide margin in most environments.
• Credentials include passwords, access keys, session tokens, certificates, and OIDC trust relationships, each with a different lifecycle and a different failure mode when leaked.
• Permissions and policies define the actual capability, and they are where intent and reality drift apart, because a policy says what is allowed, not what is needed.
• Trust relationships and role assumption let one identity become another, which is powerful for legitimate automation and dangerous when an attacker chains assumptions to escalate.

Why IAM is the quietest risk you carry

A misconfigured firewall rule often shows up in a scan. An unpatched server triggers a vulnerability alert. An over-permissioned IAM role does neither. It is valid configuration. It passes policy-as-code checks if those checks only look for obvious anti-patterns. It survives audits because the access exists for a documented reason, even if that reason expired two years ago. The risk is silent precisely because nothing is broken. The permission is working as written. The problem is that what it permits is far larger than what the business needs.

This is why IAM problems tend to surface only during an incident or a focused assessment. When an attacker compromises a single workload, they do not stop at that workload. They enumerate what the attached identity can do, look for paths to assume more powerful roles, and follow those paths until they reach data or control. The difference between a contained incident and a full account compromise is almost always the IAM design. We cover the broader picture in our cloud security assessment work, but identity is the part that turns a small mistake into a large one.

Attackers do not break into your cloud. They log in, then they find out how far that login can reach.

The common IAM failure modes we find

After enough assessments, the same patterns repeat. They are rarely exotic. They are the predictable result of speed, turnover, and the fact that IAM is hard to reason about at scale. None of these require an attacker to be sophisticated. They require an attacker to be patient and to read what the cloud will tell anyone who asks.

• Wildcard permissions such as actions set to a broad pattern grant capability nobody reviewed, and they often hide inside policies that look specific at a glance.
• Long-lived access keys for service accounts sit in code, CI systems, and developer laptops, and a single leaked key can authenticate from anywhere with no expiry to save you.
• Privilege escalation paths exist where a low-privilege identity can modify its own policy, create a new user, or pass a more powerful role to a service it controls.
• Cross-account trust relationships configured without external IDs or tight conditions let an attacker who controls one account pivot into another that trusted it too generously.
• Dormant identities from former employees, decommissioned projects, and abandoned automation remain active with their permissions intact, offering quiet entry points nobody monitors.
• Over-broad managed policies attached for convenience grant administrative-adjacent capability to identities that only needed read access to one bucket.

How we test IAM, step by step

We assess IAM from two directions at once. The first is configuration review, where we read the actual policies, roles, and trust relationships to understand what is possible. The second is adversarial testing, where we behave like an attacker who already has a foothold and try to escalate, move laterally, and reach sensitive resources. Reading the configuration tells you what could go wrong. Acting on it tells you what actually does. Both matter, and a review that only does one of them gives you half a picture. This adversarial approach sits inside our offensive security practice and informs the application-layer testing we describe on our application security testing page.

• We inventory every identity, human and machine, and map the credentials attached to each, because you cannot secure access you have not enumerated.
• We parse the full policy graph to find effective permissions, resolving the difference between what is written and what is actually granted once inheritance and conditions are evaluated.
• We hunt for privilege escalation paths using the same techniques attackers use, including policy modification, role passing, and trust abuse, then we verify each path is genuinely exploitable.
• We test lateral movement across accounts, projects, and subscriptions to see how far a single compromise reaches, which defines your real blast radius rather than your assumed one.
• We review detection coverage by checking whether the logging and alerting around identity events would actually catch the actions we just performed, because access control without detection is half a control.
• We validate findings by hand to remove false positives, so the report you receive contains real, reproducible issues rather than scanner noise.

What you get from an IAM assessment

A useful assessment does not hand you a list of every permission and call it a day. It tells you which problems matter, why they matter, and what to do about them in an order that reflects real risk. We write findings so that an engineer can reproduce them and a CISO can explain them to a board. Each issue includes the identity involved, the path we used, the resources it exposed, and a concrete remediation that fits how your environment is actually built. Generic advice to apply least privilege helps no one. Specific guidance on which policy to tighten and how does.

• A prioritized findings report that ranks issues by exploitability and business impact, not by raw count, so you fix the dangerous things first.
• Reproducible attack paths showing exactly how a compromised identity escalates or moves laterally, with the commands and conditions that make each path work.
• A remediation plan mapped to your specific cloud provider and environment, including the policy changes, trust conditions, and credential rotations that close each gap.
• An effective-permissions view that shows what your identities can actually do once all policies resolve, which is usually the first time the customer sees this clearly.
• Mapping to the controls your frameworks require, so the same work supports your NIS2, DORA, ISO 27001, or SOC 2 obligations rather than running parallel to them.
• A debrief with your engineers and leadership where we walk through the paths, answer questions, and agree on what gets fixed first.

IAM testing compared to scanning and posture tools

Cloud security posture management tools and IAM analyzers are useful. They catch obvious misconfigurations, flag public exposure, and give you a continuous baseline. They do not replace adversarial testing, and treating them as if they do is a common and expensive mistake. A scanner reports that a policy contains a wildcard. It does not tell you that the wildcard, combined with a particular trust relationship and a forgotten service account, produces a path from a low-privilege CI runner to your production data store. That chaining is where real risk lives, and chaining is what a human attacker does. We explain the broader distinction in our piece on penetration testing versus automated scanning, and the same logic applies directly to identity.

The honest framing is that tools tell you about individual weaknesses, while assessment tells you about attack paths. You want both. Use posture tooling for continuous coverage and broad hygiene. Use focused testing to find the paths that tooling cannot reason about and to validate that the issues it flags are actually reachable. If you are deciding between approaches more generally, our guide on PTaaS versus pentest versus automated scanning lays out the trade-offs in plain terms.

When and how often to assess IAM

IAM is not a one-time fix because your identity layer changes constantly. New services ship, new roles get created, contractors come and go, and acquisitions bring entire identity estates you now own. A point-in-time assessment is valuable, but its value decays. We recommend treating IAM review as a recurring activity tied to both the calendar and to change, rather than something you do once and forget. The cadence depends on how fast your environment moves and how regulated you are, but a few triggers should always prompt a fresh look.

• After any significant architecture change, such as a new account structure, a move to a new cloud region, or the adoption of a new workload identity model.
• Following a merger or acquisition, because you inherit identities, trust relationships, and credentials that were designed by people you have never met.
• On a regular annual or semi-annual basis as a baseline, aligned with your audit cycle so the findings feed directly into your compliance evidence.
• After a security incident anywhere in your environment, because the first question is always how far the compromised identity could have reached.
• When detection and response coverage changes, so you can confirm your identity-related alerting still catches the behaviors that matter, which ties into our managed detection and response work.

How IAM ties to your compliance obligations

Every framework that applies to regulated companies has access control at its core, and IAM is how you implement that control in cloud. ISO/IEC 27001:2022 organizes its 93 Annex A controls across four themes, and access control sits squarely in the organizational and technological themes, with explicit expectations around least privilege, privileged access, and identity management. SOC 2 Trust Services Criteria include logical access as a foundational area, and an auditor will ask how you provision, review, and revoke access. Strong IAM testing produces the evidence these reviews require, which is why we connect identity work to our GRC and compliance practice rather than treating them as separate efforts.

For financial entities, DORA, Regulation (EU) 2022/2554, has been in force since January 2025 and expects rigorous control over ICT systems, including access. NIS2, Directive (EU) 2022/2555, raises the bar for essential and important entities across more sectors, with explicit requirements around access policies and accountability. If you are working through these obligations, our explainers on NIS2, DORA, and ISO 27001 certification walk through what each one expects. The key point is that the IAM work that protects you from attackers is the same work that satisfies the auditors, if you do it properly and document it.

IAM is the quietest risk in your cloud because it fails silently and an attacker reaches it fastest. The way to manage it is to look at your identity layer the way an attacker would, find the paths that turn a small compromise into a large one, and close them in order of real risk. That is the work we do in our application security testing practice, alongside the offensive and detection work that surrounds it. If you want to know what your cloud identities can actually do, book a scoping call and we will map it with you.