Should organisations move from PAM to an identity-centric control plane?

Why This Matters for Security Teams

Moving from PAM to an identity-centric control plane is not a branding exercise. PAM remains essential for administrator session control, but it does not by itself unify service accounts, API keys, workload identities, and human privilege into one governance layer. That gap is why organisations keep finding privilege only after something is exposed. NHI Mgmt Group research shows that 97% of NHIs carry excessive privileges, which makes discovery without control a recurring pattern rather than an edge case. See the Ultimate Guide to NHIs and the breach analysis in 52 NHI Breaches Analysis for the operational impact.

The practical issue is coordination. PAM can lock down a privileged session, but it often does not tell a team whether the same identity also exists in code, CI/CD, SaaS, cloud APIs, or an agentic workload. An identity-centric control plane gives security teams a single trust and policy view so that RBAC, JIT, rotation, vaulting, and offboarding are applied consistently across identity types. Current guidance suggests this matters most where secrets and service identities move faster than ticket-driven access reviews. In practice, many security teams encounter privilege sprawl only after an incident has already forced them to map the blast radius.

How It Works in Practice

An identity-centric control plane does not replace PAM so much as place PAM inside a broader decision and enforcement model. The control plane should ingest identity inventory, correlate ownership, classify privilege, and connect each identity to policy, lifecycle state, and usage context. That lets teams decide whether an identity should be interactive, machine-to-machine, or short-lived JIT access, rather than assuming one access model fits all. For governance structure, align the operating model to NIST Cybersecurity Framework 2.0 and use the standards guidance in Ultimate Guide to NHIs — Standards.

In practice, the control plane should answer four questions at request time: who or what is this identity, what is it allowed to do, under what conditions, and for how long. That is where PAM, IGA, and discovery become operationally useful together. PAM can still broker high-risk human sessions. IGA can approve ownership and role assignment. Discovery can detect shadow credentials and stale entitlements. The identity-centric layer then uses those inputs to drive policy-as-code, vault rotation, JIT issuance, and offboarding workflows. For evidence of why this matters, NHI Mgmt Group notes that 91.6% of secrets remain valid five days after notification, which shows how slow remediation is when controls are fragmented; the pattern is visible across Top 10 NHI Issues.

• Inventory all privileged identities, not just admin users.
• Bind each identity to an owner, purpose, and expiry.
• Route high-risk human access through PAM, but govern machine and agent identities centrally.
• Use JIT for standing privileges that do not need permanent access.
• Rotate and revoke secrets automatically when the task or trust signal changes.

These controls tend to break down in large hybrid estates where legacy apps, cloud IAM, and SaaS permissions all use different entitlement models and no single system can enforce lifecycle state consistently.

Common Variations and Edge Cases

Tighter identity control often increases integration overhead, requiring organisations to balance governance depth against operational speed. That tradeoff is real, especially in environments with many business units, outsourced administration, or platform teams that already rely on PAM for break-glass access. Best practice is evolving here: there is no universal standard for how much decisioning should sit in PAM versus a broader control plane, but the direction of travel is clear. The stronger model is the one that can enforce least privilege at creation time, not just during review.

There are also edge cases where PAM should remain the primary control. For example, highly regulated administrative access, interactive emergency sessions, and legacy infrastructure with no native workload identity still benefit from session brokering and recording. But when teams extend PAM to cover API keys, certificates, service accounts, and autonomous agents, the model often becomes brittle. That is especially true for systems that need intent-based authorisation, because static roles cannot express what an agent is trying to do in real time. External guidance such as NIST Cybersecurity Framework 2.0 supports the shift toward continuous governance, while NHI breach research such as the Cisco DevHub NHI breach shows how exposed machine identities can bypass human-focused controls.

The cleanest rule is this: keep PAM where interactive privilege is the problem, but move to an identity-centric control plane where the real risk is unmanaged identity sprawl across humans, workloads, and secrets. In mixed environments, the answer is usually a converged model rather than an all-or-nothing replacement.

Related resources from NHI Mgmt Group

• How should organisations stop identity governance from stalling in practice?
• How should organisations phase an identity governance programme to reduce risk?
• When should organisations prioritise AI identity governance over new AI deployments?
• Why do PAM and IGA need to be aligned in enterprise identity programmes?