PAM controls for cloud and Kubernetes access: BeyondTrust vs Delinea

At a glance

What this is: This is a comparison of BeyondTrust and Delinea that shows legacy PAM strengths still matter, but cloud and Kubernetes access patterns create fit gaps around deployment, integration and auditability.

Why it matters: It matters because PAM teams now have to govern infrastructure access across cloud, Kubernetes and distributed operations without falling back to static credentials and brittle admin workflows.

Context

Privileged access management is the set of controls that decides who can reach high-value systems, when they can reach them, and how their activity is recorded. In cloud and Kubernetes environments, those controls are tested by ephemeral workloads, distributed admin access and tool sprawl that do not map neatly to older server-first assumptions.

This article frames BeyondTrust and Delinea as two traditional PAM approaches being evaluated against modern infrastructure requirements. The useful question for identity programmes is not which product has more features, but which access model can reduce standing privilege, preserve auditability and fit cloud-native operations without adding new credential distribution paths.

Key questions

Q: What breaks when traditional PAM is used for cloud workloads?

A: Traditional PAM often breaks down in cloud workloads because it was built around discovery, onboarding, and event capture on stable systems, not ephemeral resources. That creates heavy rule creation, manual maintenance, and limited coverage for dynamic applications and cloud services. The result is partial deployment, stale privilege, and governance gaps that leave excessive access in place.

Q: Why do cloud and Kubernetes environments change privileged access risk?

A: They increase risk because privileges are exercised across many systems, often by multiple teams and tools, which expands the number of places where credentials, logs and approvals must stay aligned. When those elements diverge, the organisation loses confidence in who accessed what, and standing access becomes harder to spot and revoke.

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: What should teams do when their PAM stack cannot support Kubernetes or cloud workflows?

A: They should redesign the access path around the environment, not around the old administrative model. That means choosing controls that can broker access across databases, servers and clusters without forcing local installation, credential sharing or disconnected logs. The goal is to remove exception handling from the operating model, not just document it.

Technical breakdown

Why cloud and Kubernetes access strains legacy PAM models

Traditional PAM was built around privileged humans, managed servers and relatively stable administrative paths. Cloud and Kubernetes change that shape: access is more distributed, roles are more dynamic and the control plane must often govern databases, clusters, applications and infrastructure from a single policy layer. That creates friction when a PAM design still expects local installation, server-bound administration or manual privilege elevation. The result is not simply convenience loss. It is a mismatch between how modern infrastructure is operated and how older privileged-access workflows were designed to be enforced.

Practical implication: assess whether your PAM architecture can govern cloud and Kubernetes access without reintroducing static credentials or environment-specific exceptions.

Credential hiding versus credential lifecycle control

Hiding credentials from end users is useful, but it is not the same as governing the full credential lifecycle. If access still depends on distributed secrets, SSH keys or isolated password vaults, the programme may reduce exposure without eliminating entitlement sprawl. Strong auditability also depends on whether access is issued, used and revoked in a way that can be tied back to a policy decision. In cloud and Kubernetes environments, lifecycle control matters more than credential concealment alone because the blast radius of a leaked secret can expand quickly across platforms.

Practical implication: treat secret concealment, rotation and revocation as separate control objectives, not a single PAM capability.

Integration and auditability are the real selection criteria

The article’s comparison shows that integration depth and audit logging are not secondary features in modern PAM, they are the decision point. If a tool works only where it can be installed locally, or if it cannot fit cleanly into SSO and third-party workflows, teams end up building compensating controls outside the PAM layer. That weakens governance because the access record becomes fragmented. For regulated or multi-team environments, the question is whether the control plane can provide one auditable view across servers, databases, applications and clusters.

Practical implication: validate SSO, logging and third-party integration before standardising on any PAM model for cloud-native access.

Threat narrative

Attacker objective: The attacker wants durable privileged access that can move across modern infrastructure without clean visibility or easy revocation.

1. Entry begins when privileged access is managed through distributed credentials, SSH keys or other reusable secrets across cloud and Kubernetes environments.
2. Privilege escalation occurs when those credentials are not tightly scoped or audited, allowing admin access to spread across systems and workstreams.
3. Impact follows when auditability is fragmented and credential sprawl makes it harder to contain misuse or reconstruct who accessed what and when.

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.
• Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.

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

Cloud and Kubernetes access is exposing a PAM model that was designed for steadier infrastructure. The article’s real signal is not vendor feature comparison, but that privileged access governance is colliding with distributed admin patterns, local-install dependencies and environment-specific exceptions. In NHI terms, the access model has to follow the workload and the operator path, not force both back into a server-era pattern. The practitioner conclusion is to judge PAM by how well it governs modern operational topology, not by how closely it resembles legacy privileged login workflows.

Credential hiding is not the same as credential lifecycle governance. The article repeatedly points to password vaults, secret safes and hidden credentials, but those controls only address part of the problem. If access still depends on static secrets or manually managed rotations, the organisation has not removed the privilege dependency, only obscured it. That leaves the programme exposed to secret reuse, offboarding drift and audit gaps. The practitioner conclusion is to measure whether access can be issued, observed and revoked without reintroducing standing secrets.

Auditability becomes the selection criterion once infrastructure access is distributed. Traditional PAM can look adequate until cloud, Kubernetes and multi-team operations demand a single, trustworthy record of privileged activity across systems. When logging, SSO integration and third-party connectivity are weak, teams compensate elsewhere and the control plane fragments. That is why the category is shifting from vault-centric administration to policy-centric access governance. The practitioner conclusion is to treat audit continuity as a first-order requirement, not a reporting feature.

Identity blast radius is the key concept this comparison surfaces. The dangerous issue is not merely whether access is granted, but how far one privileged path can reach once it exists. In cloud and Kubernetes environments, an overbroad control plane or poorly integrated secret model can turn a narrow admin task into broad infrastructure exposure. The practitioner conclusion is to select controls that compress the blast radius of privileged access rather than just centralise it.

Modern PAM decisions are increasingly workload-shaped, not tool-shaped. The article shows that support for Kubernetes, cloud resources and distributed users changes the governance question itself. A PAM programme that only fits one administration style will force exceptions elsewhere, and exceptions become the real policy surface. The practitioner conclusion is to align privileged access design with the environments you actually run, then validate whether the governance model survives scale and heterogeneity.

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: Cloud PAM and CIEM Guide

What this signals

Identity blast radius is now the useful lens for PAM selection. Cloud and Kubernetes access does not just increase the number of privileged users or systems. It increases the number of paths a single privileged action can take before it is visible, which means the access model must compress that blast radius rather than merely centralise secrets.

PAM programmes that depend on local installation, shared passwords or disconnected approval trails will struggle in distributed operations. The governance question is no longer whether privileged access exists, but whether it can be brokered, observed and revoked without creating new trust edges in the process.

For practitioners

• Map privileged access by environment type Separate server, cloud, database and Kubernetes access paths so you can see where legacy PAM assumptions still fit and where they break down.
• Test for standing secret dependencies Identify whether users still need exposed SSH keys, local passwords or shared vault workflows to complete admin tasks, then measure how much of the environment depends on them.
• Validate audit continuity across tools Check whether session logs, authentication records and approval data remain correlated when access moves through SSO, third-party tools and cross-platform admin flows.
• Use environment fit as a selection criterion Score PAM candidates on cloud support, Kubernetes support, integration depth and revocation workflows rather than on feature counts alone.
• Reduce credential distribution paths Prefer models that avoid handing out individual database credentials and SSH keys to every operator, especially where access is frequent and cross-functional.

Key takeaways

• Legacy PAM still matters, but cloud and Kubernetes expose where server-era access assumptions stop being reliable.
• The real decision criterion is whether privileged access can stay auditable and governable across distributed workflows.
• Teams should prioritise environment fit, secret lifecycle control and audit continuity when comparing PAM models.

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.
• 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.
• Credential Sprawl: Credential sprawl is the uncontrolled accumulation of machine secrets, keys, and tokens across systems, teams, and environments. It usually starts with a single use case and ends with overlapping permissions, unclear ownership, and a larger attack surface than the organisation expected.
• Audit Continuity: Audit continuity is the ability to preserve a complete, correlated record of privileged access across tools and environments. It matters when access moves through SSO, clusters, databases and third-party systems, because broken logs create blind spots in governance.

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.