Why do cloud security tools still fail when organisations have IAM in place?

Why This Matters for Security Teams

IAM can be technically “in place” and still leave the cloud exposed if identities are created faster than they are governed. The failure is usually not authentication, but entitlement hygiene: stale roles, shared secrets, orphaned service accounts, and permissions that were never revalidated after a project changed. NIST’s NIST Cybersecurity Framework 2.0 treats identity as a core control plane, yet many cloud environments still rely on broad, persistent access that outlives the workload it was meant to support. NHIMG research shows the gap clearly: The 2024 Non-Human Identity Security Report found that 88.5% of organisations say their non-human IAM practices lag behind or merely match human IAM maturity.

That matters because cloud security tools often monitor configuration, posture, and traffic, but they cannot compensate for an identity model that grants too much, too long, or to the wrong principal. Once a service account or API key is overprivileged, detection may alert on abuse only after data has already moved or infrastructure has already been altered. In practice, many security teams discover this only after a breached workload begins using valid access exactly as it was permitted to do.

How It Works in Practice

The practical fix is to treat cloud iam as a runtime authorisation problem, not a one-time provisioning exercise. Authentication proves who or what is connecting; it does not prove the access is still appropriate for the current task. For workloads and agents, best practice is shifting toward short-lived credentials, workload identity, and policy evaluation at request time rather than static role assignment. That means replacing long-lived keys with ephemeral tokens, binding access to the workload instance, and using context-aware policy engines so permission is granted only when the request matches the current task, environment, and risk posture.

This is where workload identity standards and policy-as-code become important. SPIFFE and related workload identity patterns help establish cryptographic proof of what the workload is, while frameworks such as NIST Cybersecurity Framework 2.0 reinforce least privilege, continuous monitoring, and access governance. For cloud teams, the workflow typically looks like this:

• Issue access just in time, only for the task being executed.
• Prefer short TTL secrets and automatic revocation over persistent keys.
• Bind access decisions to workload identity, not just to network location.
• Continuously review unused roles, shared credentials, and privilege creep.
• Log and correlate identity events with configuration changes and data access.

NHIMG’s Azure Key Vault privilege escalation exposure research and Snowflake breach coverage both illustrate the same operational lesson: valid identity is not the same as safe identity. These controls tend to break down when organisations centralise secrets or roles without per-workload scoping, because one compromised token can inherit far more authority than the original use case required.

Common Variations and Edge Cases

Tighter IAM control often increases operational overhead, requiring organisations to balance agility against revocation speed, audit effort, and release friction. That tradeoff becomes visible in hybrid estates, where legacy applications still depend on static credentials while newer cloud services support ephemeral identity. Current guidance suggests that organisations should not force a single IAM pattern everywhere; instead, they should phase controls by workload criticality and blast radius.

There is no universal standard for how aggressively every cloud role should be shortened, but the direction is consistent: reduce standing privilege, remove human-style assumptions from machine access, and make access contingent on context. For autonomous tools, this becomes even more important because behaviour can change at runtime. A workload that was safe yesterday may be dangerous today if it begins chaining APIs, automating retries, or moving laterally across services.

That is why identity reviews must include not just human users, but service accounts, CI/CD pipelines, agents, and integration tokens. NHIMG’s 230M AWS environment compromise coverage shows how quickly broad access can turn into large-scale exposure once credentials are reused or overextended. The practical rule is simple: if an identity can create, read, and delete across multiple systems, it is not “secured” by IAM alone, it is only documented by IAM.

Related resources from NHI Mgmt Group

• How should security teams reduce identity risk when IAM tools cannot show the full attack surface?
• Should organisations use experimental agentic security tools in production?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities in cloud environments?