Cloud IAM and Zero Trust: Why Least-Privilege Is Still the Hardest Problem in Cloud Security

After a decade of zero trust as the dominant security philosophy, identity and access management remains the most commonly exploited attack vector. Here is why — and what actually works.

Every cloud security framework mandates least-privilege. Every cloud security assessment finds excessive permissions. Every post-incident investigation involving a cloud environment includes at least one finding about overprivileged credentials. And yet, despite a decade of zero trust as the dominant philosophy in enterprise security, identity and access management remains the most consistently exploited attack vector across cloud environments.

I have spent a significant portion of my career dealing with IAM governance problems in AWS environments. What I want to share in this article is not a theoretical treatment of the problem — it is the practitioner’s view of why organizations keep failing at this, and what it actually takes to fix it.

Why the Problem Keeps Repeating

The gap between IAM policy and IAM reality in cloud environments is, in my experience, almost always explained by three factors: the speed of cloud adoption, the organizational incentive structure, and the invisibility of excessive permissions until they are exploited.

Cloud environments grow fast. When an organization migrates to AWS or deploys a new workload, the path of least resistance for IAM is broad permissions. Getting something working quickly is prioritized over getting it working securely. An IAM role with Administrator Access works. An IAM role with precisely scoped permissions requires thought, iteration, and time. In a delivery-pressured environment, the first approach wins consistently. The broad permissions remain long after the initial deployment pressure has passed.

The organizational incentive structure reinforces this pattern. The engineer who requests broad permissions to get a project shipped on time faces no immediate consequence. The security engineer who tries to enforce least-privilege faces friction, escalations, and accusations of blocking delivery. Without a governance structure that makes the secure path the easy path — through tooling, templates, and enforcement — the outcome is predictable.

Excessive permissions are also largely invisible until they are exploited. Unlike a firewall misconfiguration that might cause an immediate operational impact, an overprivileged IAM role sits dormant, indistinguishable from a correctly scoped role, until a threat actor discovers it. The absence of visible harm creates a false sense that the risk is manageable.

What I Actually Did to Fix It

I want to be concrete about this because I think there is too much abstraction in how IAM governance is discussed. What I am about to describe is what we did in a real environment — an 18-account AWS Organizations estate that had been built through two merged companies with divergent IAM architectures, over 340 individual IAM users, multiple accounts with active root access keys, and pervasive AdministratorAccess grants that had accumulated over years.

The first thing we did was stop calling it a ‘cleanup’ project and start calling it a programme. IAM remediation at scale is not a one-time cleanup. It is an ongoing governance capability. The moment we framed it as a programme — with a defined charter, a budget, executive sponsorship, and a multi-quarter delivery plan — we had the organizational support to actually finish it.

The second thing was the entitlement review. We used AWS IAM Access Analyzer combined with custom Python scripts to produce a complete, risk-graded inventory of every principal, every policy attachment, every access key, and every active session across all 18 accounts. This took two weeks and produced a findings register of several hundred items. Without this baseline, everything else would have been guesswork.

The third was designing the target architecture before touching anything in production. The target state was: all human identities federated through IAM Identity Center using Azure AD as the IdP, no individual IAM users, no standing privileged access, all administrative actions through CyberArk just-in-time sessions with full recording, permission boundaries on all developer-created roles, and five Service Control Policies applied at the AWS Organizations root covering the highest-risk attack patterns.

The fourth — and the most consequential — was making the compliant path the easy path. We built Terraform modules with least-privilege IAM roles pre-configured for common developer use cases. We integrated them into the CI/CD pipeline as the default. We built SCPs that prevented the creation of overprivileged roles without explicit IAM administrator involvement. We made doing the right thing require less effort than doing the wrong thing. Adoption followed.

The Role of Service Control Policies

SCPs are the most underutilized IAM governance tool in AWS environments. They operate at the AWS Organizations level and apply to every principal in every member account — they cannot be overridden by IAM policies, even by an account’s root user. This makes them the governance floor that everything else sits on.

The five SCPs we deployed in our environment addressed the highest-risk attack patterns. Deny root account API calls — root account actions should never occur in normal operations, and any root API call in a member account is either a control failure or an active compromise. Restrict approved regions — attackers who compromise credentials routinely deploy resources in non-standard regions to evade detection; region restriction prevents this and reduces data sovereignty risk. Enforce MFA for IAM user sessions — compromised static credentials without MFA allow immediate unrestricted access. Deny IAM self-modification — the most common privilege escalation path in AWS is a compromised low-privilege role attaching a more permissive policy to itself. Restrict S3 public access modification — S3 bucket misconfiguration is one of the most common causes of cloud data breaches.

Each of these SCPs is available in our public GitHub repository with full metadata, false positive documentation, and deployment guidance. They are demonstrative artifacts built from a real programme, not theoretical examples.

Just-In-Time Access Is Not Optional for Privileged Roles

Standing privileged access is the single highest-risk IAM configuration in any cloud environment. An engineer who holds permanent Administrator Access is an attack vector that exists continuously, regardless of whether that engineer is currently doing anything administrative. Their credentials can be phished, their session can be hijacked, their access keys can be exposed in a repository. The exposure is permanent.

Just-in-time access changes the risk profile fundamentally. An administrative session that exists for two hours, requires approval, is fully recorded, and is automatically revoked is a dramatically smaller attack surface than standing access. The resistance we encountered when introducing JIT through CyberArk was almost entirely about workflow disruption — engineers who were accustomed to always-on access objecting to having to request it. The resistance dissipated within weeks once the provisioning time was consistently under two minutes and the workflow was integrated into existing tools.

Zero tolerance for standing privileged access is achievable. In our environment, we went from multiple accounts with unmonitored permanent admin access to zero standing privileges across all 18 accounts. The ITGC audit finding that had been open for three years closed.

The Access Review Problem

Even a well-designed IAM architecture drifts over time. People change roles, projects end, permissions that were granted for a specific purpose are never revoked. The access review process is what prevents this drift from accumulating into the kind of overprovisioned environment I described at the start of this article.

Access reviews fail when they are treated as a compliance checkbox rather than a genuine governance process. The hallmark of a checkbox review is a high completion rate with a near-100% approval rate — every entitlement certified without meaningful examination. In our programme, we transformed the access review from a checkbox to a genuine governance process by three changes: automatic revocation for non-responses after a defined window (rather than defaulting to approve), reporting of decision patterns to management (making rubber-stamping visible), and role owner training on what the review is actually for.

The quarterly access review completion rate went from approximately 40% on-time with high rubber-stamping to 98% on-time with meaningful decision quality. That improvement required process redesign, not just better tooling.

IAM governance is hard not because the technology is complicated but because it requires sustained organizational discipline to maintain. The organizations that get it right are the ones that build it into operating processes, automate the enforcement, and treat access as a resource that requires active management — not a capability granted once and forgotten.

References

1. Amazon Web Services. (2024). AWS Identity and Access Management: User guide. https://docs.aws.amazon.com/IAM/latest/UserGuide
2. Amazon Web Services. (2024). Service control policies (SCPs): AWS Organizations user guide. https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html
3. National Institute of Standards and Technology. (2020). Zero trust architecture (SP 800-207). https://doi.org/10.6028/NIST.SP.800-207
4. Center for Internet Security. (2023). CIS Amazon Web Services foundations benchmark, v1.5.0. https://www.cisecurity.org/benchmark/amazon_web_services
5. MITRE Corporation. (2024). MITRE ATT&CK for cloud — IaaS platform. https://attack.mitre.org/matrices/enterprise/cloud/iaas
6. Kindervag, J. (2010). No more chewy centers: Introducing the zero trust model of information security. Forrester Research.
7. Cloud Security Alliance. (2023). Cloud controls matrix v4.0.6. https://cloudsecurityalliance.org/research/cloud-controls-matrix
8. (2024). 2024 Data breach investigations report. https://www.verizon.com/business/resources/reports/dbir
9. Kosta, N., Moreau, L., & Squicciarini, A. (2022). Cloud access control mechanisms: A survey. ACM Computing Surveys, 54(9), 1–36. https://doi.org/10.1145/3460813