TL;DR: Legacy PAM, VPN-heavy access, and manual provisioning slow infrastructure teams while weakening auditability and least privilege, according to StrongDM’s customer examples. The pattern is clear: access governance breaks when controls cannot keep up with multi-cloud scale, offboarding, and session-level accountability.
At a glance
What this is: This is a customer-case-study roundup showing where legacy PAM and VPN-based access controls break down across multi-cloud infrastructure.
Why it matters: It matters because IAM and PAM teams need access governance that scales with multi-cloud, supports JIT access, and preserves auditability without forcing manual provisioning.
Context
Managing infrastructure access becomes harder as teams add clouds, databases, and remote users faster than their governance processes can adapt. In this article, the central problem is not authentication in isolation but the gap between static access controls and dynamic operational reality.
The source cases repeatedly point to the same pattern: legacy PAM and VPN-centric access models create friction, delay, and incomplete visibility when organisations need session-level control, least privilege, and faster offboarding. For IAM and PAM programmes, that is a governance design problem, not just a tooling problem.
Key questions
Q: What breaks when legacy PAM is used for multi-cloud infrastructure access?
A: Legacy PAM breaks when it cannot keep privileged access aligned with how teams actually work across multiple clouds, databases, and administrative tools. The result is fragmented provisioning, inconsistent permissions, and weak audit evidence. When access has to be recreated across many consoles, control degrades into manual exception handling instead of governed lifecycle management.
A: Standing privileged access creates a persistent path to high-value systems, which increases the chance of misuse, credential theft, and accidental overreach. In sensitive environments, it also weakens accountability because access is not tightly scoped to a task. Just-in-time access improves governance by reducing exposure and making every elevated session easier to trace.
Q: What are the signs that access governance is failing in practice?
A: The clearest signs are slow remediation, repeated rubber stamp access reviews, and missed permissions outside traditional HR linked systems. If governance teams rely on manual audits, they often struggle to see access granted to non-human identities or systems adopted outside normal IT cycles. That usually means the organisation lacks reliable visibility and consistent enforcement of least privilege.
Q: How should organisations handle offboarding for privileged access that is not tied to one employee?
A: Treat offboarding as an identity lifecycle event for every privileged account, not only for staff departures. Revoke shared credentials, decommission unmanaged accounts, remove temporary access when projects end, and confirm that contractors and third parties lose access when the relationship ends. Otherwise, access remains after accountability has disappeared.
Technical breakdown
Why legacy PAM struggles in multi-cloud environments
Legacy PAM was built around bounded privileged sessions, relatively stable infrastructure, and a smaller set of access paths. In multi-cloud environments, access now spans databases, servers, Kubernetes clusters, and remote operators with different workflows and permission models. When the control plane cannot normalise those paths, teams end up with license juggling, manual exceptions, and outages during access changes. The technical issue is not only administration overhead. It is that the access model no longer reflects how work actually moves across cloud providers and tools.
Practical implication: map every privileged access path to the system that actually brokers it, then retire controls that cannot govern cloud-spanning session access.
How just-in-time access changes the privilege model
Just-in-time access shifts privilege from standing entitlement to time-bound session issuance. That matters because the attack surface is not the request itself but the period during which elevated access exists. In the StrongDM examples, the point is to issue access only when needed, revoke it automatically when the task ends, and preserve a log of what happened during the session. This is the operational bridge between least privilege and enforceable auditability. It also reduces the administrative drag of repeatedly provisioning and deprovisioning long-lived access.
Practical implication: move privileged workflows from persistent grants to task-scoped issuance and make session logging part of the control design.
Why centralized auditing matters more than scattered credentials
A fragmented estate forces auditors and responders to reconstruct who accessed what from separate cloud consoles, VPN logs, database grants, and tickets. That destroys confidence in recertification and slows investigations. Centralized auditing is not just a reporting feature. It is the mechanism that ties authentication, authorisation, and activity into one evidence trail. In the article’s cases, query capture, keystroke logging, SSH replay, and permission history are used to create a defensible record of access. For PAM teams, that means auditability must be designed into the access path, not bolted on afterwards.
Practical implication: require a single evidence trail for privileged access so recertification, incident response, and compliance all use the same source of truth.
Threat narrative
Attacker objective: The likely objective is to obtain and retain enough privileged access to move laterally across infrastructure and sustain control without clear audit evidence.
- Entry occurs through overextended privileged access paths such as VPNs, shared credentials, or manually managed cloud permissions.
- Privilege persists because access is issued as standing entitlement rather than as a bounded, task-specific session.
- Escalation follows when operators or attackers can reuse broad access across multiple cloud services, databases, or administrative tools.
- Impact is operational slowdown, poor auditability, and a wider blast radius when access is not tightly scoped or rapidly revoked.
Breaches seen in the wild
- Colonial Pipeline ransomware attack: A dormant VPN account with a leaked password and no MFA let DarkSide shut down a major US fuel pipeline for six days.
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 breaks first at the assumption of stable, reviewable privilege. The governance model behind traditional PAM assumes privileged access is relatively durable, visible, and easy to recertify after the fact. That assumption weakens when engineers move across AWS, GCP, Azure, databases, and Kubernetes through different consoles and workflows. The practical result is not just more admin work. It is a control environment where the policy exists, but the operating model outruns it.
Zero standing privilege becomes a governance requirement, not an optimisation. The article’s strongest pattern is that standing access creates friction, weakens accountability, and leaves teams with too much manual state to govern well. Once access is issued on demand and revoked automatically, the control objective changes from perpetual entitlement management to session-scoped authority. That is the right shape for infrastructure teams that need both speed and traceability.
Session visibility is the new audit boundary. Query capture, keystroke logging, and session replay matter because they turn privileged use into evidence rather than inference. Without that evidence, access reviews become trust exercises based on stale grants and incomplete logs. The implication is that modern PAM is less about where a user logs in and more about what can be proven about each privileged action.
Multi-cloud access governance now sits at the intersection of PAM, IAM, and offboarding. The article shows that fragmented cloud permissions, delayed provisioning, and slow deprovisioning all compound into the same governance failure. Teams cannot treat access lifecycle, audit evidence, and cloud-specific permissions as separate workstreams. The practitioner conclusion is that the access plane itself has become an identity governance control surface.
Identity blast radius is the right concept for this problem. As access expands across more clouds and tools, the security question is no longer only who has access, but how far that access can spread before it is contained. That makes permission scope, session duration, and revocation speed the decisive variables. IAM and PAM leaders should measure every privileged path by its potential blast radius, not just its approval status.
What this signals
Identity blast radius: when privileged access spans several clouds and administrative tools, the real control question is how far one entitlement can travel before it is revoked. That pushes PAM teams to think in terms of session scope, not just approval workflow.
Access reviews lose value when the privilege surface is too fragmented to reconstruct cleanly. The operational answer is to anchor governance on session evidence, lifecycle revocation, and a consistent control plane rather than on scattered grants.
The article reinforces that zero standing privilege is not a niche design choice. It is the practical response to infrastructure estates where manual provisioning and VPN-heavy access no longer match the pace of delivery.
For practitioners
- Replace standing privileged access with task-scoped issuance Use just-in-time grants for databases, servers, and Kubernetes access so elevated privilege exists only for the duration of the approved task.
- Unify cloud access policies under one control plane Map AWS, Azure, GCP, and other cloud permissions into a single governance layer so recertification and enforcement are not fragmented by platform.
- Capture session-level evidence for every privileged action Record queries, commands, and connection events so auditors and incident responders can reconstruct exactly what happened during access use.
- Shorten offboarding and deprovisioning workflows Remove access through a single lifecycle action wherever possible, and verify that revocation reaches cloud consoles, remote access paths, and database entitlements.
- Measure privileged blast radius by system and role Review how many environments, tools, and resources each role can reach before access is revoked, then reduce any path that crosses unnecessary trust boundaries.
Key takeaways
- Legacy PAM struggles when access has to span multiple clouds, remote workflows, and fast-moving infrastructure without enough centralisation to govern it cleanly.
- The operational evidence in the article points to manual provisioning, delayed access, and poor auditability as the recurring failure modes.
- Teams need session-scoped privilege, unified audit evidence, and faster offboarding if they want access control to keep pace with modern infrastructure.
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Standing privileged access across cloud tools mirrors overprivileged machine and admin access patterns. |
| NHI-01 — Improper Offboarding | The article repeatedly points to slow revocation and lifecycle cleanup gaps across access paths. | |
| Recommendation — Reduce standing access scope and issue privileged rights only for the task being performed. Verify that offboarding removes every privileged path, not just the primary login account. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The piece centres on credential and access lifecycle control for privileged infrastructure use. |
| Recommendation — Apply IA-5 to govern privileged authenticators, rotation, and revocation across infrastructure access. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about access entitlements and how they are issued, scoped, and removed. |
| Recommendation — Use PR.AA-05 to centralise entitlement governance and enforce least-privilege access paths. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The access model described can expand the impact of credential theft and movement across environments. |
| Recommendation — Map privileged access sprawl to credential access and lateral movement risk in your detections. | ||
Key terms
- Zero Standing Privilege: A control model in which an identity does not keep persistent access unless it is actively needed. For NHIs, this means credentials and permissions are issued for a narrow task and then removed. It reduces the time window and reuse value of stolen 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.
- Session evidence: Session evidence is the record of what an identity actually did after access was granted, including commands, queries, configuration changes, and resource actions. It is the proof layer that lets security and compliance teams reconstruct activity, investigate incidents, and validate that privilege did not exceed policy.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
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 June 8, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org