What do organisations get wrong about PAM and zero trust?

Why This Matters for Security Teams

PAM and zero trust are often treated as separate workstreams, but for non-human identities they are the same control problem viewed from different angles. Zero trust says no request is trusted by default; PAM decides whether a privileged request should exist at all, for how long, and under what conditions. If privilege is persistent, standing access quietly defeats the premise of zero trust even when policy language sounds mature. NIST’s NIST SP 800-207 Zero Trust Architecture makes this dependency clear: access must be continuously evaluated, not assumed because an identity has a role.

The practical mistake is building a perimeter around identities instead of around each request. That is especially dangerous for NHIs, where service accounts, API keys, and automation tokens can outlive the workload that created them. NHI Mgmt Group’s Ultimate Guide to NHIs notes that 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, which reflects how closely the two disciplines depend on one another. In practice, many security teams discover that their “zero trust” programme still contains broad, durable privilege only after a service account is abused or a token is reused outside its intended context.

How It Works in Practice

The operational model is straightforward, but it is often implemented backwards. zero trust for nhis works best when identity is workload-based, privilege is just-in-time, and policy is evaluated at request time. PAM should not simply store credentials more safely; it should reduce the lifetime, scope, and reuse potential of those credentials. That is why current guidance increasingly favours ephemeral tokens, workload identity, and automated revocation over shared secrets and long-lived keys.

For agents, services, and pipelines, the sequence should look like this:

• Authenticate the workload with a cryptographic identity such as SPIFFE/SPIRE or a short-lived OIDC token.
• Evaluate the request against context-aware policy, not just a static RBAC role.
• Issue just enough privilege for the task, with a short TTL and no reusable standing access.
• Revoke access automatically when the task completes or the context changes.

This approach aligns with the direction described in the Guide to SPIFFE and SPIRE, where workload identity becomes the root of trust rather than a password, key, or manually approved exception. It also fits the standard zero trust model in NIST SP 800-207 Zero Trust Architecture, which emphasises continuous verification and policy enforcement on every request. In NHI terms, this is where PAM becomes an execution control instead of a vaulting control.

NHIMG research on the Ultimate Guide to NHIs — Standards also shows why this matters: 97% of NHIs carry excessive privileges, which means the usual role assignment model is already too coarse for most environments. These controls tend to break down when legacy applications require shared service accounts because shared credentials are difficult to scope, trace, and revoke cleanly.

Common Variations and Edge Cases

Tighter PAM often increases operational overhead, requiring organisations to balance stronger containment against release velocity and support burden. That tradeoff is real, especially in environments that depend on batch jobs, embedded devices, or legacy middleware where short-lived credentials and per-request policy are difficult to retrofit.

There is no universal standard for this yet, but current guidance suggests a few consistent exceptions and failure modes. Shared break-glass access may still be necessary, but it should be isolated, heavily monitored, and time-boxed rather than treated as a normal operating path. Likewise, some systems cannot support full request-time authorisation, so compensating controls such as network segmentation, token binding, and aggressive rotation become more important. For API-heavy estates, the most common error is leaving secrets valid far beyond the task they were meant to support, which turns a zero trust claim into a revocation problem.

The deepest gap is conceptual: teams often measure success by whether PAM exists, not by whether privilege is continuously constrained. That distinction matters because zero trust is not a product category, and PAM is not a checkbox. When access cannot be made ephemeral, the environment should be treated as partially trusted until the design changes. NHI Mgmt Group’s research shows how often this gap persists in real operations, particularly where offboarding, rotation, and visibility are weak.

Related resources from NHI Mgmt Group

• What do organisations get wrong about zero trust in hybrid work?
• What do security teams get wrong about Zero Trust and identity governance?
• What do organisations get wrong about caller ID and sender trust?
• What do security teams get wrong about zero trust in NHI environments?