PAM acquisitions expose the cloud-native access gap for IAM teams

At a glance

What this is: This is an analysis of how PAM market consolidation is amplifying long-standing cloud-native access gaps, especially around ephemeral credentials and dynamic authorization.

Why it matters: It matters because IAM and NHI teams need to decide whether to keep extending PAM into cloud environments or add controls designed for ephemeral workloads and machine-speed access.

👉 Read SGNL's analysis of PAM consolidation and cloud-native access gaps

Context

PAM is built to govern elevated human access, but cloud-native environments change the problem shape. Ephemeral infrastructure, infrastructure-as-code, and autonomous workloads create access lifecycles that do not map cleanly to static approval flows, which makes NHI governance a separate design concern rather than a side effect of PAM.

The article uses an acquisition event to surface a wider architectural question: whether existing privileged access programs can support Kubernetes, serverless functions, APIs, and developer workflows without creating workarounds. That is a common tension, and it is exactly where access sprawl, static secrets, and policy inconsistency tend to appear.

Key questions

Q: How should organisations govern access when PAM does not fit cloud-native workloads?

A: Use PAM for long-lived human elevation, but add runtime authorization for ephemeral workloads, APIs, and automation identities. The right control depends on the identity’s lifecycle, the target system, and the speed of the workflow. If access must exist for minutes or be embedded in code, static ticket-based privilege is usually the wrong model.

Q: What is the difference between PAM and continuous authorization?

A: PAM typically grants elevated access in advance and manages it through approval, checkout, and review. Continuous authorization evaluates access at request time using live context such as identity, environment, and task scope, then removes access when it is no longer needed. The first is access administration, the second is decision-making at runtime.

Q: Why do cloud-native systems increase the risk of static secrets?

A: Cloud-native systems often move too quickly for manual credential handling, so teams copy secrets into pipelines, containers, and scripts to keep delivery moving. That creates hidden persistence and weak rotation. The more ephemeral the workload, the more damaging it is to rely on credentials that outlive the task they were meant to support.

Q: Should security teams replace PAM with a new identity model?

A: No. PAM still matters for administrative access to stable infrastructure, but it does not cover all cloud and NHI use cases. Security teams should extend the control stack with dynamic authorization, policy-as-code, and lifecycle-aware NHI governance where access is ephemeral or machine-driven.

Technical breakdown

Why PAM hits limits in cloud-native access patterns

Traditional PAM systems were designed around humans requesting elevated access to long-lived servers or fixed administrative targets. Cloud-native systems are different because the target may exist for minutes, credentials may need to be issued and revoked automatically, and the access path may be embedded in code or CI/CD. Once access becomes transient and machine-driven, role queues and ticket-based approval loops become too slow to be the primary control. The architectural gap is not just speed, it is the mismatch between static privilege models and ephemeral identity lifecycles.

Practical implication: teams should classify which workloads are truly PAM-shaped and which require runtime authorization and lifecycle-aware NHI controls.

Continuous authorization versus pre-provisioned privilege

The central technical shift is from pre-provisioned access to continuous authorization. In a static model, privilege is assigned in advance and later reviewed. In a dynamic model, access is granted only when real-time context supports it, then withdrawn as soon as the task ends. This reduces standing privilege and limits blast radius, especially when service accounts, tokens, or agent identities are involved. The key design point is not merely just-in-time access, but just-in-time access combined with policy decisions that can evaluate workload identity, environment, and task context together.

Practical implication: replace blanket entitlements with policies that can evaluate identity, context, and task scope at request time.

Why developer workflow integration matters for secret sprawl

When security controls force developers out of their native workflows, they often reintroduce the very risks the controls were meant to remove. Copy-pasted secrets, local overrides, and hardcoded credentials are common failure modes when access is awkward to request or automate. In cloud environments, governance must meet developers where work happens, especially in CLI, GitOps, and automation pipelines. The security model has to be consumable by machines and operators alike, or teams will create shadow paths around it.

Practical implication: build policy and access controls into delivery pipelines so developers do not bypass them with static secrets or manual exceptions.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

PAM consolidation is less a product story than a governance stress test. When a core access-control category changes ownership, practitioners should assume roadmap uncertainty until proven otherwise. That matters because privileged access programs are often deeply embedded in audit, change control, and incident response processes. The practical conclusion is to map which controls are dependent on one vendor roadmap and which can survive a platform shift.

Continuous Identity is best understood as a runtime governance pattern, not a PAM replacement. Static privilege remains useful for some infrastructure, but cloud-native and NHI-heavy environments need access decisions that are evaluated in real time. That means the field is moving toward layered control models where PAM protects legacy elevation paths and dynamic authorization governs ephemeral access. Practitioners should design for coexistence, not false replacement.

Identity blast radius is now the better metric than access volume. A small number of over-privileged workload identities can create more exposure than a much larger set of tightly scoped ones. The article points to a common enterprise mistake: treating cloud access as a permissions administration problem instead of a lifecycle and context problem. Practitioners should measure how far any one identity can move, not just how many identities exist.

Cloud strategy and access strategy can no longer be separated. If the cloud roadmap depends on workflows that PAM cannot support without friction, teams will accumulate exceptions and static credentials. That is how governance debt becomes operational debt. Practitioners should treat access architecture as part of cloud architecture, not an afterthought.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
• Only 44% of organisations have implemented any policies to manage their AI agents, even though 92% agree governance is critical to enterprise security.
• For a broader NHI control baseline, see Ultimate Guide to NHIs , Why NHI Security Matters Now for the lifecycle and governance patterns that static PAM cannot cover.

What this signals

Identity blast radius is the metric that should drive roadmap decisions. If a privileged account or workload identity can move across multiple cloud services, the issue is no longer how quickly access can be approved, but how far it can travel once compromised. Teams should tie access design to containment and recovery objectives, not just convenience.

With 70% of organisations already granting AI systems more access than human employees performing the exact same job, per the 2026 Infrastructure Identity Survey, the governance gap is structural. Existing IAM programmes were built for static roles and slower change cycles, while cloud and agentic systems now demand context-aware controls.

Practitioners should expect more overlap between PAM, workload identity, and policy-as-code tooling. That does not mean every platform must do everything. It means the control plane has to support both human elevation and machine runtime decisions without forcing developers back into manual workflows.

For practitioners

• Audit where PAM is still the right control Separate human administrative access to long-lived systems from workload, API, and pipeline access. Keep PAM where it fits, but do not force it to govern ephemeral resources it was not built to handle.
• Map ephemeral identities and access lifecycles Inventory Kubernetes service accounts, serverless functions, tokens, and automation identities, then document how each is issued, used, rotated, and revoked. This creates the baseline for deciding where runtime authorization is required.
• Move access decisions into delivery workflows Embed policy checks into CLI, GitOps, and CI/CD so developers can request and receive scoped access without leaving their native tools. If the workflow is awkward, expect shadow secrets and manual exceptions.
• Measure identity blast radius Assess how far a compromised service account or privileged token can move across cloud accounts, clusters, and applications. Prioritise the identities that can reach production data or control planes first.
• Plan for vendor roadmap disruption Identify any PAM dependencies that would slow your cloud roadmap if features stalled, changed, or shifted after acquisition. Build an alternative control path for the highest-risk cloud and NHI use cases.

Key takeaways

• PAM still matters, but it does not fully govern cloud-native and machine-driven access patterns.
• Ephemeral workloads and AI systems expose the limits of static privilege, ticket-based approval, and manual credential handling.
• Security teams should treat identity lifecycle, runtime context, and blast radius as core cloud architecture decisions.

Key terms

• Continuous Identity: A governance pattern that evaluates identity and access at runtime instead of relying only on pre-approved privilege. It is used to support cloud-native systems, APIs, and automation where access needs change quickly and standing credentials create unnecessary exposure.
• Identity blast radius: The amount of damage a compromised identity can cause before access is contained or revoked. In NHI environments, blast radius depends on what the identity can reach, whether it can escalate, and how quickly its access can be narrowed or removed.
• Ephemeral workload identity: A short-lived non-human identity used by infrastructure that exists only temporarily, such as a Kubernetes pod, serverless function, or automation job. These identities need lifecycle controls that match their runtime, including scoped issuance, rotation, and immediate revocation.

Deepen your knowledge

Cloud-native privileged access and NHI lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are extending PAM into workloads, APIs, and automation, it is worth exploring.

This post draws on content published by SGNL: Your PAM vendor was acquired. What does that mean for your cloud roadmap? Read the original.