Should organisations keep classic PAM if they are moving to dynamic access controls?

Why Classic PAM Still Has a Job While Dynamic Access Control Takes Over

Classic PAM is still the right control for legacy estates that depend on vaulting, password rotation, break-glass accounts, and session recording. The problem is scope creep: teams often assume those controls also solve cloud workloads, service accounts, APIs, and AI-driven access paths. They do not. NHI security problems are broader than privileged human access, and the scale is already visible in the data: only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.

Dynamic access controls extend the model by deciding access at request time, not just by preloading credentials into a vault. That matters when workloads are ephemeral, identity is workload-based, and privilege should exist only for the duration of a task. Current guidance from the OWASP Non-Human Identity Top 10 and PCI DSS v4.0 points in the same direction: keep strong secret handling, but stop relying on static privilege as the default. In practice, many security teams encounter over-permissioned service accounts only after a secrets leak or lateral movement has already happened, rather than through intentional design.

How to Run PAM and Dynamic Controls Together Without Creating Gaps

The cleanest model is to treat PAM as the control plane for human and legacy privileged access, and dynamic access as the runtime policy layer for machines, workloads, and agents. For classic systems, PAM still owns vaulting, rotation, approvals, and session monitoring. For modern systems, access should be issued just in time, tied to workload identity, and revoked automatically when the task ends. That means short-lived secrets, intent-based authorisation, and policy evaluation at request time rather than fixed RBAC alone.

For AI and automation-heavy environments, the identity primitive should be the workload or agent, not a shared credential. Practitioners increasingly pair OIDC-based workload identity, SPIFFE/SPIRE-style identity, and policy-as-code engines so the system can decide whether a request matches the current task, context, and risk. That approach is aligned with the operational guidance in the Ultimate Guide to NHIs — Key Challenges and Risks and the control patterns discussed in the 52 NHI Breaches Analysis.

• Use PAM for vaulting and session recording where systems cannot support modern identity flows.
• Use JIT credentials for workloads, with short TTLs and automatic revocation on completion.
• Map every service account, API key, and agent to an owner, purpose, and policy.
• Evaluate access at runtime against intent, context, and risk, not just a static role.
• Log both credential issuance and action-level activity so investigations can reconstruct the full chain.

These controls tend to break down in environments with shared secrets, embedded credentials in CI/CD, or long-lived batch jobs that cannot renew identity cleanly.

Where the Boundary Gets Messy in Real Environments

Tighter access control often increases operational overhead, requiring organisations to balance revocation speed and policy precision against service continuity. That tradeoff is real in brownfield environments, where legacy apps expect a password, not a token, and where rotating credentials can break integrations. Best practice is evolving, but there is no universal standard for one replacement pattern yet.

Classic PAM may remain the least risky option for mainframes, vendor appliances, and other systems that cannot consume workload identity. In those cases, vaulting and session monitoring are still valuable, especially when paired with compensating controls like network segmentation and restrictive RBAC. By contrast, cloud-native services, agents, and automation pipelines should not be forced through the same model if they can support ephemeral access and runtime policy checks. The Ultimate Guide to NHIs — Standards and BeyondTrust API key breach both reinforce the same lesson: static access becomes brittle when secrets live too long or when ownership is unclear.

The practical test is simple. If a system can authenticate a workload cryptographically and authorise it per request, dynamic controls should lead. If it cannot, PAM remains necessary as a compensating layer. The risk appears when organisations declare PAM “done” and leave modern non-human access outside both vaulting and runtime governance.

Related resources from NHI Mgmt Group

• How should organisations govern access when identity controls are spread across IGA, AM, and PAM?
• When should organisations replace static secrets with ephemeral access for agents?
• When should organisations prioritise Zero Standing Privilege for non-human identities?
• How should security teams decide whether JIT access is safe for non-human identities?