TL;DR: Legacy PAM tools built around SSH proxies and bastions fall short in cloud environments because they do not govern modern services, non-human identities, or just-in-time access well enough, according to P0 Security. Static credentials still dominate many deployments, and the real break is the assumption that privileged access can be safely managed with endpoint keys and network-path controls.
NHIMG editorial — based on content published by P0 Security: Why Enterprises Are Upgrading to Next-Gen PAM for Cloud Security
By the numbers:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
Questions worth separating out
Q: What breaks when PAM is built mainly around SSH proxies in cloud environments?
A: Proxy-centric PAM breaks when access is no longer concentrated in a single network path.
Q: Why do standing credentials create outsized risk in cloud and SaaS environments?
A: Standing credentials turn a single successful compromise into reusable enterprise reach.
Q: How do organisations know whether cloud PAM is actually reducing risk?
A: Look for shrinking credential lifetime, fewer standing entitlements, faster revocation, and better audit visibility across both human and non-human identities.
Practitioner guidance
- Audit standing privileged access across cloud and SSH paths Inventory every long-lived SSH key, cloud admin role, and service account that can reach production systems.
- Replace proxy dependence with native cloud access paths Where the platform supports it, move SSH access to native services such as AWS SSM, GCP IAP, or Azure Bastion so access is mediated by the cloud control plane rather than an external relay.
- Enforce just-in-time access for elevated operations Require time-bound, request-scoped elevation for administrator activity and keep standing privilege limited to documented break-glass use cases with explicit approval and post-use review.
What's in the full article
P0 Security's full article covers the operational detail this post intentionally leaves for the source:
- A closer look at the proxy-based deployment model and why it creates operational friction at scale.
- Specific cloud access patterns for AWS, GCP, and Azure that show how next-gen PAM fits into real environments.
- The vendor's own comparison points for SSH governance, JIT workflows, and non-human identity coverage.
- Implementation context for teams evaluating whether their current PAM architecture can support cloud-native access at all.
👉 Read P0 Security's analysis of next-gen PAM for cloud security →
Next-gen PAM for cloud security: are your controls keeping up?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
Proxy-based PAM is an identity control for yesterday’s cloud. It was built for a world where privileged access meant a person connecting through a network chokepoint to a small number of servers. That assumption breaks when privilege lives across cloud APIs, service accounts, Kubernetes, and temporary workflows. The implication is that PAM strategy now has to follow the identity plane, not the network path.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
- Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption.
A question worth separating out:
Q: Who is accountable when a cloud privileged account is misused?
A: Accountability should sit with the business owner of the privilege, the platform team that granted it and the governance function that approves its persistence. In practice, shared accountability fails when service accounts and administrative roles are left without clear ownership. Frameworks such as the NIST Cybersecurity Framework 2.0 support clearer access governance and review discipline.
👉 Read our full editorial: Next-gen PAM for cloud security is shifting identity control