When should teams prioritise ZSP over conventional PAM approaches?

When ZSP is the better choice than PAM

ZSP is the better fit when the control objective is to remove standing privilege entirely, not just wrap it in stronger administration. That usually means the access path can be activated only at the moment of need, time-boxed tightly, and observed end to end. If the role still needs to sit broadly enabled between tasks, you are still operating a PAM pattern, even if it is well managed.

ZSP is most defensible for workloads, service identities, and admin paths that can be made eligible and activated just in time without breaking the business process. The distinction matters because ZSP changes the default from persistent authority to per-use authority, which shrinks the window for misuse and forces the team to prove that privilege is needed each time it is issued.

That is why teams should treat ZSP as a design choice, not a marketing label. If the underlying account, token, or role can be left dormant until an approved workflow requests it, then the access model can move toward privileged access that is granted on demand rather than continuously. If not, conventional PAM remains the practical control set for vaulting, brokering, session control, and emergency access.

What changes operationally when you remove standing privilege

ZSP works best when the team can accept more issuance friction in exchange for less persistent exposure. That usually means better workflow design, clearer approval boundaries, and stronger dependency on identity proof at the moment of elevation. It is especially useful where the same actor would otherwise carry broad rights for long periods just to complete occasional high-risk tasks.

For machine and service accounts, the question is not whether they are “privileged” in the abstract, but whether their authority can be scoped down to the exact task and time window. A service account security model that supports rotation, discovery, and least privilege makes ZSP practical; one that depends on always-on credentials and shared access patterns usually does not.

Where broad, persistent access is still required, a PAM program often provides the safer operating model because it can isolate credentials, broker sessions, and preserve accountability without pretending the privilege has disappeared. In other words, the right question is whether the access can be collapsed to a use-time grant, not whether the team prefers the label “zero.”

How to decide between ZSP and PAM in practice

Use ZSP when the access pattern is episodic, the privilege can be broken into discrete tasks, and the business can tolerate delays for approval or issuance at the moment of use. Use PAM when the account must remain broadly capable, when emergency recovery depends on always-available authority, or when the operational model still relies on standing elevated roles that are hard to decompose.

That decision becomes clearer in environments with break-glass or recovery paths. A break-glass emergency access model is usually PAM territory, because the control objective is availability under failure, not routine zero standing privilege. Trying to force every emergency path into ZSP can create fragility that looks elegant on paper but fails when the organisation most needs access.

For cloud estates, the same decision often hinges on whether permissions can be right-sized and reissued safely. Where the access path can be reduced to an approval-backed, time-bound elevation, cloud PAM and CIEM can support a clean transition toward ZSP; where inherited roles, cross-account trust, or operational admin duties remain broad, PAM remains the control that matches reality.

Risk and Threat Considerations

The security value of ZSP comes from reducing standing exposure, but the risk is that teams claim ZSP while leaving broad rights intact between activations. That creates false confidence, especially when privileged paths are hard to inventory or when operational exceptions quietly expand the amount of standing access.

Failure mechanism: Standing privilege remains embedded in the role design, so the account can still be misused, abused, or stolen outside the intended activation window, even if a JIT workflow exists on top.

Impact: The organisation retains privilege escalation risk, lateral movement opportunity, and emergency access exposure, while losing the clarity of knowing whether access was truly time-scoped.

Practitioner Guidance

Decision rule: If you cannot show that the privileged capability is absent when the session ends, do not describe the control as ZSP. Treat it as PAM with better workflowing until the access model is genuinely use-time only.

What to verify: Check whether elevation is bounded by time, task, and approval, and whether the account has any standing path that can still perform the same sensitive action outside the active session. Also verify that break-glass, recovery, and integration dependencies are separately designed rather than smuggled into the same elevated role.

Common mistake: Teams often equate “approved on request” with zero standing privilege even when the account remains permanently powerful. The label matters less than the actual blast radius between uses.

Practitioner takeaway: Choose ZSP only when the access can genuinely disappear until needed, because the control is about eliminating standing authority, not rebranding persistent privilege.

Related resources from NHI Mgmt Group

• How should security teams prioritise NHI remediation in cloud environments?
• When should security teams prioritise PAM over broader identity governance?
• When should teams prioritise PAM over additional cloud tooling?
• When should teams prioritise control continuity over feature parity in a PAM migration?