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.
At a glance
What this is: This is an analysis of why cloud PAM is moving beyond bastions and SSH-only control toward native governance for cloud services, non-human identities, and just-in-time access.
Why it matters: It matters because identity teams responsible for cloud access need controls that cover service accounts, roles, and ephemeral access paths, not just interactive administrator sessions.
👉 Read P0 Security's analysis of next-gen PAM for cloud security
Context
The core problem is that privileged cloud access no longer lives only in SSH sessions or a small set of administrator endpoints. Once teams must govern access to cloud services, roles, and workloads across AWS, GCP, and Azure, proxy-centric PAM starts to miss the identities and paths that actually carry risk.
In this model, the governance gap is not simply operational friction. It is the mismatch between legacy bastion workflows and the way cloud platforms issue, scope, and revoke access natively through cloud IAM and service APIs. The article frames that mismatch through a company trying to secure developer access across multiple cloud environments.
The article also shows why cloud PAM conversations now sit at the junction of privileged access, NHI governance, and just-in-time access. That is the practical shift: identity control must follow the resource model of the cloud, not the network path of the data centre.
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. Cloud operations now depend on native identity planes, service accounts, cloud APIs, and ephemeral workflows, so a bastion can broker SSH without actually governing the broader privilege surface. Teams then lose visibility into who can act, where, and for how long.
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. Ephemeral access narrows that window and makes the issuance event, not the stored string, the governance object. That is why cloud admin access should be brokered and time-limited rather than managed as a durable secret.
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. Access should expire automatically, be tied to a federated identity, and be logged in a way that supports audit and incident review. The goal is to eliminate standing privileged access while keeping operations workable.
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.
Technical breakdown
Why SSH proxy PAM breaks in cloud environments
SSH proxy and bastion models were built to mediate a narrow class of interactive access: a person connecting to a server. In cloud environments, privileged activity spreads across services, roles, and orchestration layers that are not represented by a terminal session alone. If a control plane only governs the SSH hop, it can miss access to S3, Kubernetes, or IAM role assumption that happens outside the bastion path. The result is partial visibility, fragmented enforcement, and a false sense that privileged access is fully centralised when it is not.
Practical implication: map every privileged cloud pathway, not just SSH, before assuming a PAM control covers the environment.
Cloud-native IAM APIs versus agent-heavy access mediation
Cloud-native PAM uses the platform’s own IAM and session services to grant and revoke access at request time. That is different from proxy-based mediation, where agents or jump hosts sit in the path and become another operational component to maintain. Agent-heavy designs can create a new control bottleneck, especially when every instance or environment needs additional software and routing logic. Native integration matters because the cloud already exposes the authoritative access layer through provider services, so the PAM control should align to that layer rather than re-implement it indirectly.
Practical implication: prefer native cloud access primitives where possible, because they reduce drift between the policy engine and the actual authorization point.
Just-in-time access for non-human identities and developer workflows
Just-in-time access is no longer only a human administrator pattern. In cloud environments, service accounts, IAM roles, and operational workflows also need ephemeral access that is scoped to task and time. When access requests move through chat and ticketing workflows, the control has to issue privileges without creating durable standing access behind the scenes. The technical challenge is not only credential issuance but also lifecycle closure, so access can expire cleanly after the task, incident, or deployment finishes.
Practical implication: design JIT approval and expiry logic for both human and non-human identities, not just for interactive admin accounts.
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.
- BeyondTrust breach 2024: A stolen BeyondTrust Remote Support API key let a China state-sponsored actor reset accounts and reach US Treasury workstations in 2024.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Cloud-native authorization changes the unit of control from path to identity. In a cloud platform, the important question is not just which network path is used, but which identity, role, or service principal is allowed to act. That shift matters because the control point moves closer to the provider's own authorization layer, where scope can be narrower and revocation cleaner. The implication is that identity teams should evaluate access tooling by how directly it aligns with cloud-native authorization, not by how well it reproduces a data-centre workflow.
Cloud identity blast radius: Cloud PAM failures are often not total failures of access control, but failures of scope control across too many identity types. Once roles, service accounts, and human sessions are governed separately, unmanaged overlap becomes the real exposure. The lesson for practitioners is to measure how far a single privileged entitlement can travel across services, environments, and operating workflows.
Just-in-time access becomes a governance requirement, not a convenience feature. The article’s JIT discussion shows that ephemeral access is the only workable answer when static credentials and standing privileges create too much residual risk. That is especially true when developer workflows depend on Slack, PagerDuty, or ticketing systems to request access without slowing delivery. Practitioners should treat JIT as the default pattern for high-risk cloud privilege, with expiry and scope as first-class controls.
Identity discovery is the prerequisite for cloud PAM maturity. You cannot govern overprivileged roles, unused keys, or long-lived access if you cannot inventory where those entitlements exist. The article points to discovery and remediation as the practical bridge between policy and enforcement. For practitioners, cloud PAM should start with a complete identity map before it tries to optimise workflows.
From our research library:
- 74% of organizations report identity-related breaches, and privileged access is a leading cause of lateral movement.
- Read next: Cloud PAM and CIEM Guide
What this signals
Cloud PAM is converging with non-human identity governance because the meaningful control point is no longer the SSH session alone. Once access is distributed across cloud IAM roles, service accounts, and API-mediated paths, the programme has to govern identities rather than just network entry points.
Cloud identity blast radius: Privileged access risk in the cloud is increasingly defined by how far a single entitlement can move across services and workflows. That makes inventory, scope, and expiry more important than the mechanics of the original connection method.
The persistence of overprivileged machine access remains the clearest warning sign, with 97% of NHIs carrying excessive privileges, increasing unauthorised access and broadening the attack surface according to the Ultimate Guide to NHIs.
For practitioners
- 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. Include the systems each identity can touch, the clouds involved, and whether access is interactive, delegated, or automated.
- 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. Document where the current PAM model is blind to native provider authorization paths.
- 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. Require task-scoped justification so standing privilege is not recreated through workflow shortcuts.
- Reduce dependency on endpoint keys Eliminate SSH keys on unmanaged endpoints where possible and move privileged access to native cloud session services and short-lived authorization flows. Treat endpoint-stored keys as residual exposure, not an acceptable default.
Key takeaways
- Cloud PAM built only around SSH proxies and bastions leaves modern cloud services, roles, and service accounts outside the real control boundary.
- The access model that matters in cloud environments is identity-native, not path-native, because authorization now happens through provider APIs and role assumption.
- Just-in-time access and complete identity inventory are the practical levers that reduce standing privilege and narrow blast radius.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article centers on excessive privilege in cloud roles and service accounts. |
| NHI-07 — Long-Lived Secrets | It highlights SSH keys and other durable credentials as a cloud risk. | |
| NHI-01 — Improper Offboarding | Cloud access must be revoked cleanly when roles, tasks, or workflows end. | |
| Recommendation — Reduce standing cloud access by applying NHI-05 to roles, service accounts, and other machine identities. Replace long-lived cloud credentials with short-lived access flows that shrink exposure windows. Tie offboarding and expiry to every privileged cloud identity so access does not persist after need. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential rotation and lifecycle control are central to the article's PAM argument. |
| Recommendation — Apply IA-5 to govern creation, rotation, and revocation of privileged cloud authenticators. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about controlling cloud entitlements and authorization scope. |
| Recommendation — Use PR.AA-05 to align cloud PAM with least-privilege entitlements and authorization boundaries. | ||
| NIST Zero Trust (SP 800-207) | 3.1 — Verify explicitly | The shift to native cloud authorization aligns with zero trust verification of every access request. |
| Recommendation — Require explicit verification for each privileged cloud request rather than trusting network location. | ||
Key terms
- Cloud Privileged Access Management: Cloud Privileged Access Management is the discipline of discovering and controlling identities that can make high-impact changes in cloud environments. It covers human and non-human identities alike, with continuous enforcement of least privilege, task-scoped access, and lifecycle ownership across accounts, roles, and automation.
- 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.
- Cloud Identity: A cloud identity is any account, role, token, or credential used to access cloud services and resources. In practice, it includes both human and non-human identities that can authorize actions in infrastructure, applications, or automation pipelines. Governance depends on knowing which identity type is active and what it can do.
- 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.
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
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 17, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org