Topic starter
17/08/2026 4:40 pm
TL;DR: P0 Security says legacy PAM built around SSH proxies and bastions falls short in cloud environments because it does not govern modern services, non-human identities, or just-in-time access well enough. Static credentials and proxy-led control paths leave privileged access dependent on endpoint keys and network controls that cloud platforms increasingly outgrow.
Editorial analysis by NHI Mgmt Group, based on content published by P0 Security: “Why Enterprises Are Upgrading to Next-Gen PAM for Cloud Security”.
Key questions
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 static credentials create more risk than ephemeral access for cloud admins?
A: Static credentials create standing privilege, which means one leak can remain usable until someone finds and revokes it.
Q: How should security teams implement just-in-time access for cloud consoles?
A: Security teams should implement just-in-time access by binding privilege to a specific request, a short approval window, and a narrowly defined entitlement set.
Practitioner guidance
- Inventory every privileged cloud identity Build a complete inventory of human accounts, IAM roles, service accounts, and other workload identities that can reach production cloud resources.
- Replace SSH-only control assumptions Trace privileged access beyond bastions and proxies to include S3, Kubernetes, and cloud IAM actions that never traverse an SSH session.
- Enforce just-in-time access with expiry Grant high-risk cloud access for the duration of the task, then revoke it automatically when the approved window closes.
Bottom line: Cloud PAM built only around SSH proxies and bastions leaves modern cloud services, roles, and service accounts outside the real control boundary.
What's in the full article
P0 Security's full article covers the operational detail this post intentionally leaves for the source:
- The company’s cloud-specific evaluation criteria for moving from proxy-based PAM to native access control
- Details on how P0 uses AWS SSM, GCP IAP, and Azure Bastion in the access flow
- The governance workflows for secrets rotation, risk remediation, and cloud identity discovery
- The developer-facing JIT access integrations with Slack, JIRA, and PagerDuty
👉 Read P0 Security's analysis of next-gen PAM for cloud security →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
17/08/2026 4:46 pm
Legacy PAM is now a partial-control model, not a complete cloud access model. SSH proxies and bastions still address one slice of privileged access, but cloud privilege is distributed across services, IAM roles, and workload-driven actions. That creates a governance gap where the control exists, but not at the point where the access actually occurs. Practitioners should treat proxy-only PAM as incomplete coverage for cloud identity governance.
A few things that frame the scale:
- 74% of organizations report identity-related breaches, and privileged access is a leading cause of lateral movement.
A question worth separating out:
Q: When should organisations extend PAM controls to non-human identities?
A: Organisations should extend PAM as soon as service accounts, API keys, certificates, or automation identities can perform privileged actions. If those identities can modify infrastructure, access sensitive data, or bypass approval workflows, they need the same lifecycle discipline as human admins. Waiting until an incident creates avoidable risk.
👉 Read our full editorial: Next-gen PAM for cloud security is shifting identity control