Why do traditional PAM deployments still create risk in cloud-native environments?

Why This Matters for Security Teams

Traditional PAM was designed around a relatively bounded model: a human administrator requests access, receives a controlled session, and finishes work within a known window. Cloud-native environments do not behave that way. Privilege now lives across CI/CD, Kubernetes, cloud control planes, databases, and ephemeral workloads, so a vault and session recorder can only cover part of the attack surface. The practical gap is not just technology, but governance drift between where access is granted and where it is actually used.

The result is a familiar pattern: exceptions for service accounts, shared break-glass credentials, duplicated secrets, and manual approvals that lag behind deployment speed. That is why current guidance from the NIST Cybersecurity Framework 2.0 pushes organisations toward broader access visibility and continuous risk management rather than isolated control points. NHIMG’s research on the Top 10 NHI Issues shows how quickly unmanaged non-human access becomes systemic once identities proliferate across platforms. In practice, many security teams encounter privileged sprawl only after an over-permissioned automation path has already been used in production.

How It Works in Practice

Cloud-native privilege is distributed, temporary, and often machine-initiated, which makes classic PAM controls incomplete by design. A modern control model has to recognise that the protected thing is not just a human admin session, but every workload, API client, pipeline runner, and automation agent that can act with authority. That is why NHI governance increasingly focuses on workload identity, short-lived credentials, and runtime policy checks instead of long-lived static access.

In practice, organisations reduce PAM-driven risk by separating authentication from authorisation and by treating access as a just-in-time decision. A secure implementation usually includes:

• workload identity as the primary identity primitive, using standards such as SPIFFE/SPIRE or OIDC-backed tokens to prove what the workload is
• short-lived secrets and ephemeral tokens issued per task, not broad standing access cached in a vault
• policy-as-code evaluated at request time, so approval can reflect environment, target system, change window, and workload risk
• session logging and recording for humans, but also API-level telemetry for agents, pipelines, and service-to-service calls
• tight scoping of cloud roles so an access path cannot be reused across clusters, accounts, and support tools

This is consistent with the emerging direction in the OWASP NHI Top 10, which treats over-privilege and credential persistence as core failure modes rather than edge cases. The operational objective is not to replace PAM everywhere, but to place it inside a broader identity fabric that also covers non-human access paths. These controls tend to break down when legacy applications require shared credentials or when platform teams cannot issue short-lived tokens without breaking automation.

Common Variations and Edge Cases

Tighter privilege controls often increase operational overhead, requiring organisations to balance speed of delivery against the cost of more frequent credential issuance, policy maintenance, and exception handling. That tradeoff becomes sharper in hybrid environments, where some systems still depend on static secrets while cloud-native services can support ephemeral identity.

Best practice is evolving, and there is no universal standard for this yet. Some teams keep PAM for high-risk human admin access while using separate controls for service accounts and workloads. Others move toward a zero standing privilege model that minimises persistent access altogether. The right answer depends on whether the main risk is interactive admin misuse, automation sprawl, or agent-driven behaviour that changes too quickly for manual approvals.

NHIMG’s Ultimate Guide to NHIs makes the underlying issue clear: cloud identity is now an architecture problem, not a vault problem. A useful benchmark is the distinction between controlling access to a privileged shell and controlling access to the cloud actions that shell can trigger. In practice, PAM still matters, but it becomes risky when teams mistake session control for complete privilege governance.

Related resources from NHI Mgmt Group

• Why do secrets create disproportionate risk in NHI environments?
• Why do cloud environments create more secrets risk than traditional datacenters?
• Why do static access keys create more risk in cloud-native environments?
• When does shift left create more risk than it reduces?