Why CSPM and CIEM stop at visibility in cloud access control

At a glance

What this is: This is a blog post arguing that CSPM and CIEM are visibility tools, not remediation controls, and that cloud access control still depends on policy-driven enforcement at runtime.

Why it matters: IAM, PAM, and cloud security teams need to treat posture findings as input to enforcement, not as an end state, because recurring over-permissioning and standing privilege keep the same risks alive.

Context

CSPM and CIEM are often used as cloud visibility layers, but they do not themselves change how access is granted or revoked. That leaves organisations with reports full of misconfigurations and excessive permissions but no mechanism to enforce the decision at the point of access.

For identity teams, the governance gap is straightforward: discovery without enforcement keeps standing privilege in place. The article frames this as an operational limitation in cloud access control, not a tooling coverage problem.

The practical question is not whether teams can see access risk. It is whether they can make policy decide access in real time, so remediation stops depending on tickets, spreadsheets, and review cycles.

Key questions

Q: What breaks when CSPM and CIEM are used as the main access control layer?

A: They expose cloud misconfigurations and excessive permissions, but they do not change who can act at runtime. That means standing privilege survives, the same entitlement drift returns in the next reporting cycle, and remediation stays manual instead of becoming a control decision.

Q: Why do over-permissioned cloud identities keep coming back after review?

A: Because review alone does not remove the access model that creates the problem. If privilege remains persistent until a person intervenes, teams will keep rediscovering the same excess access, only later and at greater operational cost.

Q: How do teams know if cloud entitlement governance is actually working?

A: Look for whether privilege is being prevented at issuance rather than cleaned up after discovery. If the same users or workloads keep showing up in CIEM reports, the programme is still measuring risk, not reducing it.

Q: Should security teams prioritise JIT access over more posture reporting?

A: Yes, when the problem is persistent privilege rather than blind spots. More reporting helps teams locate the issue, but JIT access changes the exposure window itself, which is what lowers the practical risk in cloud environments.

Technical breakdown

Why CSPM and CIEM are observability layers, not control planes

CSPM discovers cloud misconfigurations and CIEM surfaces excessive entitlements, but both primarily report on state after it already exists. They are observability engines: useful for finding drift, not for changing the access outcome when a request is made. That distinction matters because visibility can tell you that access is unsafe, while control decides whether the request is allowed, denied, or constrained. In cloud identity governance, those are different functions. A tool that highlights privilege does not automatically remove it, shorten it, or bind it to intent. Practical implication: treat posture findings as inputs to a control decision, not as the control itself.

Practical implication: use CSPM and CIEM findings to inform enforcement design, not as proof that the access problem is solved.

Standing privilege persists when runtime policy is absent

Standing privilege means access remains available until someone manually changes it. That model works poorly in dynamic cloud environments because entitlement drift accumulates faster than teams can review dashboards. The article’s core point is that over-permissioned identities are visible long before they are actually governed. Without runtime policy, the same excess access reappears in the next reporting cycle, only with new symptoms. This is why visibility alone tends to produce repeated findings rather than lasting reduction in risk. Practical implication: map every recurring entitlement finding to a control that can deny or narrow access at request time.

Practical implication: replace recurring review-only workflows with controls that enforce least privilege when access is requested.

Policy-based just-in-time access closes the gap between detection and remediation

Just-in-time access changes the governance model by making privilege temporary and task-scoped instead of persistent. In practice, policy evaluates context, intent, and entitlement at the moment of access, then grants only what is needed and removes it when the task ends. That shifts identity security from post-hoc cleanup to active control. The important point is not automation for its own sake, but removal of standing access as the default state. For cloud programmes, that narrows the blast radius of both human and non-human identities. Practical implication: move remediation upstream into the issuance decision, where access can be approved, constrained, and expired automatically.

Practical implication: use JIT access and policy enforcement to make privileged access ephemeral rather than persistent.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
• Microsoft SAS token exposure 2023: An over-permissive Azure SAS token in a Microsoft AI GitHub repo exposed 38TB, including workstation backups and Teams messages, for 3 years.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Cloud visibility is not cloud governance: CSPM and CIEM surface risk, but they do not govern access outcomes. That separation is why organisations can know exactly where cloud entitlements are excessive and still continue to operate with the same standing privilege. The practitioner lesson is that observability must be paired with enforcement if access policy is meant to change behaviour.

Standing privilege is the real control failure: The article correctly frames excessive permissions as a symptom, not the root problem. The root problem is an access model that allows privilege to persist until a human removes it, which is too slow for cloud operations. Teams should read every recurring CIEM alert as evidence that entitlement lifecycle is not under control.

Policy-based access converts findings into action: The meaningful shift is from report generation to runtime decision-making. A policy engine that can bind access to context and task scope removes the need to treat every alert as a manual remediation event. That is the point at which IAM, PAM, and cloud security stop operating as separate layers and start functioning as one control system.

Identity blast radius becomes the metric that matters: Once access is made ephemeral, the question changes from how many excessive entitlements exist to how far one entitlement can travel before it expires. That is a more useful governance measure than dashboard volume because it reflects actual exposure, not just audit noise. Practitioners should judge cloud control maturity by how much standing privilege they have eliminated.

Cloud access control needs a decision layer, not more alerts: The article reinforces a broader market pattern: security teams do not lack detection, they lack governable enforcement paths. That means cloud access programmes should be built around issuance, authorization, and expiry, not around ever-larger postures of warning messages. The practitioner conclusion is to fund the control plane, not the report queue.

What this signals

Runtime enforcement is the missing control plane: Cloud teams should stop treating posture tooling as a proxy for access governance. The real programme question is whether identity decisions are made at request time, because that is where standing privilege can still be prevented.

CSPM and CIEM will continue to matter for discovery, but they do not reduce exposure on their own. For IAM leaders, the maturity test is whether a repeated finding can be turned into an expired entitlement, not just another ticket or dashboard entry.

For practitioners

• Replace standing entitlements with just-in-time access Use policy to grant privilege only for the task at hand and let it expire automatically when the task ends. That reduces the time window in which cloud identities can be abused.
• Bind access decisions to context and intent Require the authorization layer to consider request context, workload need, and approval state before access is issued. Do not rely on periodic reviews to clean up excessive permissions after the fact.
• Treat recurring CIEM findings as control failures Track whether the same over-permissioned identities keep reappearing across reporting cycles. If they do, the issue is not visibility but the absence of an enforcement mechanism that changes the entitlement model.
• Shorten the remediation loop at issuance time Move the decision from quarterly review workflows into the access request itself so the control can deny, limit, or expire privilege before it becomes persistent.

Key takeaways

• CSPM and CIEM are effective at surfacing cloud access problems, but visibility by itself does not remove standing privilege or enforce least privilege at runtime.
• The repeated risk pattern is not lack of insight but lack of control, because the same excessive entitlements keep returning when remediation depends on manual review.
• Cloud security programmes need a decision layer that can issue, narrow, and expire access automatically if they want posture findings to translate into lower exposure.

Key terms

• Cloud Security Posture Management: Cloud Security Posture Management is a set of tools and processes that identify misconfigurations, policy drift, and exposure in cloud environments. It is strongest at discovery and weakest at enforcement, so it should be treated as a detection layer that feeds remediation rather than a control plane that changes access by itself.
• Cloud Infrastructure Entitlement Management: Cloud Infrastructure Entitlement Management focuses on who has access to what in cloud systems, especially excessive or unused permissions. It helps reveal overprivileged identities, but it does not automatically remove them. In practice, it is most useful when tied to policy enforcement and access expiry mechanisms.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Just-in-Time Access Request: Just-in-Time Access Request is a pattern that grants access only when it is needed and only for the duration required. It reduces standing privilege by making access temporary, policy driven, and task scoped. This approach is especially useful for contractors, sensitive systems, and short-lived operational work.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.