CyberArk vs BeyondTrust exposes the limits of legacy PAM

At a glance

What this is: This is StrongDM’s comparison of CyberArk and BeyondTrust, and its central finding is that legacy PAM tools still struggle with onboarding, offboarding, auditability, and modern infrastructure access.

Why it matters: IAM and PAM teams should treat privileged access as a lifecycle and governance problem across databases, servers, and Kubernetes, not just as vaulting and admin control.

By the numbers:

• 64% of organizations struggle with productivity due to infrastructure access, according to StrongDM.

Context

Privileged Access Management is meant to control elevated access, but many deployments were built around a narrow admin model: vault the credential, approve the session, and log the activity. That model becomes brittle when the access surface spans databases, Kubernetes, cloud workloads, and third-party operators rather than a small set of privileged accounts.

StrongDM’s comparison argues that the real governance gap is lifecycle management, not just credential protection. When onboarding, offboarding, and audit collection are hard to execute consistently, PAM becomes an isolated control point instead of a broader access governance layer.

The article’s comparison is therefore less about which branded product is better and more about whether the organisation’s access model matches how modern infrastructure actually works. For teams running mixed environments, that question is typically more important than feature checklists.

Key questions

Q: What breaks when PAM only governs one vault in a multi-vault environment?

A: The programme loses a unified view of ownership, active usage, and lifecycle state. Secrets remain scattered across cloud-native stores, enterprise vaults, CI/CD systems, and code, so rotation and offboarding become guesswork. The practical failure is not storage drift alone. It is the inability to govern privilege coherently across the estate.

Q: Why does privileged access create productivity friction in modern infrastructure teams?

A: Because the more systems a team must touch, the more manual approvals, credential handoffs, and tool-specific steps accumulate. That friction pushes engineers toward workarounds, which can increase access sprawl and weaken governance if the security model is too rigid for operational reality.

Q: How do security teams know if PAM is actually working?

A: Look for evidence that elevated rights are short-lived, session activity is logged, and access reviews result in real removals rather than paperwork. If privileged access still appears in permanent roles, shared credentials, or undocumented emergency use, PAM is only providing visibility, not control. The operating question is whether privilege shrinks after use.

Q: Should organisations prioritise lifecycle access governance over feature comparisons in PAM?

A: Yes. Feature checklists matter, but they do not answer whether privileged access is being created, changed, and removed cleanly across the real infrastructure stack. Lifecycle governance determines whether a PAM programme will remain accurate after the first deployment wave.

Technical breakdown

Why vault-centric PAM breaks down in cloud-native access

Traditional PAM architectures assume privileged access is concentrated in a small set of accounts that can be vaulted, brokered, and reviewed. In practice, modern teams need access to databases, servers, Kubernetes, and SaaS-adjacent operational tooling, often through identity federation and short-lived sessions. That creates a mismatch between the control model and the actual resource graph. The result is not only harder administration but also weaker visibility across the full access path, especially when credentials are copied into scripts, forwarded through SSH, or scattered across admin workflows.

Practical implication: map where privileged access now lives across cloud and container estates before deciding whether vault-first PAM is enough.

How onboarding and offboarding expose PAM lifecycle gaps

Joiner-mover-leaver handling is where many PAM programmes reveal their structural limits. If onboarding requires separate provisioning of SSH keys, database credentials, VPN access, and application-specific entitlements, teams create multiple lifecycle paths that drift over time. Offboarding becomes even riskier because deprovisioning must be coordinated across all those paths, or access remains active in one system after it has been removed in another. This is a governance problem, not merely an operational inconvenience, because stale access undermines auditability and increases residual privilege.

Practical implication: examine whether a single access change actually revokes every dependent privileged path, not just the primary account.

Why auditability depends on command-level visibility

PAM is often sold as a way to know who accessed what, but high-value audit evidence requires more than session start and stop logs. Database queries, shell commands, kubectl actions, and permission changes are the artefacts that let security and compliance teams reconstruct actual behaviour. Without that detail, audit evidence becomes circumstantial rather than operationally useful. This is especially important in hybrid environments where access brokers, SSO, and infrastructure tools all contribute different slices of the access story. The real question is whether the control layer can produce a coherent record across those slices.

Practical implication: verify that your PAM stack records action-level evidence, not only session metadata.

Threat narrative

Attacker objective: The objective is to turn privileged infrastructure access into a durable control advantage that survives normal access review and offboarding processes.

1. Entry occurs through excessive or poorly governed privileged access paths, especially where credentials or remote access controls are spread across multiple infrastructure systems.
2. Privilege escalation follows when standing access, shared credentials, or weak lifecycle offboarding lets a user or operator retain more access than their role requires.
3. Impact is broader attack surface, slower incident response, and weaker auditability across databases, servers, and Kubernetes, which makes recovery and accountability harder.

Breaches seen in the wild

• 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.
• 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.

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 lifecycle governance problem, not a vaulting problem. The article is right to focus on onboarding, offboarding, and auditability because those are the controls that decide whether privileged access remains bounded in practice. When privileged access spans databases, servers, and Kubernetes, the question is not whether a vault exists but whether access follows the full identity lifecycle. Practitioners should evaluate PAM as an access governance layer, not a point product.

Standing privileged access creates a governance drag that modern operations can no longer absorb. The 64% productivity figure cited by StrongDM reflects a real control trade-off: the more manual the access path, the more teams work around it. That does not mean security should accept easier access by default, but it does mean control design has to reduce friction without reintroducing permanent privilege. The better lens is governed, short-lived access with full traceability.

Cloud-native environments expose the mismatch between admin-centric PAM and actual infrastructure behaviour. Databases and SSH were once enough to describe privileged access; Kubernetes, service orchestration, and multi-cloud operations widened the field. PAM programmes built for a fixed admin perimeter now struggle to represent who can do what, where, and for how long. Teams should treat this as a scope problem in access governance, not a usability complaint about a particular tool.

Auditability is only meaningful when the control records action, not just presence. Session logs that show who connected are not enough if they do not capture the commands, queries, and permission changes that define real privilege use. That is why infrastructure access governance increasingly overlaps with compliance evidence, incident reconstruction, and insider-risk detection. Practitioners should judge PAM by whether it produces usable proof of activity, not by whether it simply brokers the connection.

Privileged access in modern estates now needs a broader governance concept: identity blast radius. The core issue is not just whether access is approved, but how far one access path can reach across linked systems once granted. In hybrid infrastructure, a single privileged identity can touch databases, containers, secrets, and remote administration flows. The implication for teams is to design controls around blast-radius reduction, not around isolated account vaulting.

From our research library:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• Read next: Privileged Access Management Guide

What this signals

Identity blast radius is the better PAM design lens. Modern privileged access is not a single admin session but a chain of connected rights that can span databases, clusters, secrets, and remote tooling. When teams design around blast radius instead of isolated accounts, they get closer to the real control problem and can judge whether a PAM stack actually contains lateral movement potential.

The strongest signal from this comparison is that lifecycle governance now matters as much as access mediation. If offboarding is incomplete or onboarding requires manual exceptions, the programme is already leaking risk into operations, compliance, and incident response. Security leaders should watch for those exceptions because they usually reveal where the control model is no longer aligned to the estate.

For practitioners

• Define the full privileged access graph Inventory where administrative access exists across databases, servers, Kubernetes, cloud consoles, and remote support tools, then map the approval and logging path for each.
• Rework joiner-mover-leaver handling for privileged access Test whether one onboarding or offboarding action truly revokes access across every dependent system, including SSH keys, database credentials, VPN access, and remote admin paths.
• Require action-level audit evidence Validate that the PAM stack captures database queries, shell commands, kubectl actions, and permission changes, not just session metadata or login events.
• Reduce standing privilege in infrastructure workflows Replace persistent admin pathways with short-lived access and explicit approval where operationally possible, especially for high-value databases and cluster administration.
• Separate product fit from access governance Evaluate whether the current PAM model fits the organisation’s actual resource mix before comparing feature lists, pricing, or deployment complexity.

Key takeaways

• Legacy PAM can control sessions without fully governing the lifecycle of privileged access across modern infrastructure.
• StrongDM’s cited 64% productivity figure points to a real trade-off between rigid access controls and operational friction.
• Teams should judge PAM by whether it reduces standing privilege, improves audit evidence, and cleanly revokes access across all dependent systems.

Key terms

• Privilege Access Management: Privilege Access Management is the discipline of controlling and monitoring elevated access to critical systems and data. It governs how privileged accounts, credentials, sessions, and commands are issued, used, recorded, and revoked, so administrative power is limited, traceable, and aligned to policy, risk, and operational need.
• Joiner-Mover-Leaver Lifecycle: The joiner-mover-leaver lifecycle describes the access changes that should happen when a person or account is created, changes role, or exits the organisation. It is the basic operating model for keeping entitlements aligned to current need, and it becomes critical when automation replaces manual ticket handling.
• Session logging: Session logging captures activity performed during an access session, such as commands, queries, or remote actions. It supports investigation and accountability, but it only works as a control when the logs are complete, contextual, and connected to the approval and revocation workflow.
• 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.

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.