What do teams get wrong about Zero Trust and privileged access?

Why This Matters for Security Teams

zero trust fails in practice when privileged access is treated as a narrow admin problem instead of a control plane for every high-impact identity, including service accounts, CI/CD runners, and API keys. NIST’s NIST SP 800-207 Zero Trust Architecture makes continuous verification the baseline, but many programmes still leave standing privilege intact while focusing on network segmentation alone.

The result is predictable: attackers do not need to “break” Zero Trust if shared credentials, over-permissioned tokens, and weak session visibility remain in place. NHIMG research shows that Ultimate Guide to NHIs identifies 97% of NHIs carrying excessive privileges, which is a direct signal that entitlement sprawl is still common even in mature environments. Security teams often measure policy coverage, not whether privileged pathways are actually eliminated.

In practice, many security teams encounter lateral movement through service identities only after an incident review shows that privileged access was never brought into the Zero Trust design.

How It Works in Practice

Privileged access should be treated as an always-evaluated trust decision, not as a one-time approval. That means access is issued with the minimum scope needed, for the shortest practical time, and only after the request is evaluated against context such as workload identity, target resource, environment, and task purpose. For non-human identities, this is where static IAM models fall short: a bot, pipeline, or agent may not have a single fixed role, but it still needs cryptographic proof of identity and tightly bounded authority. The OWASP Non-Human Identity Top 10 is useful here because it frames the recurring failure modes: hard-coded secrets, over-privilege, and missing lifecycle controls.

In a workable Zero Trust model, PAM becomes part of the access fabric. That usually includes:

• JIT elevation for humans and workloads, with automatic expiry after the task ends
• Short-lived secrets or tokens instead of durable shared credentials
• Session recording and command-level logging for high-risk privilege use
• Policy-as-code decisions at request time, rather than static allow lists
• Separate identities for automation, with no reuse across environments

For workload identity, organisations increasingly align to SPIFFE-like patterns and ephemeral token issuance because the point is to prove what the workload is, not just what secret it knows. NHIMG’s Guide to SPIFFE and SPIRE is directly relevant for teams replacing long-lived shared secrets with verifiable workload identity. These controls tend to break down when legacy applications require embedded credentials and cannot request or renew short-lived tokens at runtime because the application itself was not designed for ephemeral trust.

Common Variations and Edge Cases

Tighter privilege controls often increase operational overhead, requiring organisations to balance friction against blast-radius reduction. That tradeoff becomes visible in environments with brittle legacy systems, cross-account automation, or third-party integrations that expect persistent access. In those cases, best practice is evolving rather than settled, and current guidance suggests phasing in Zero Trust patterns around the most dangerous pathways first instead of trying to replatform everything at once.

One common mistake is assuming that “least privilege” is enough if the privilege is permanent. It is not. Standing access still creates an opportunity window, especially where secrets are copied into code, configs, or CI/CD tools. NHIMG research shows that 96% of organisations store secrets outside secrets managers in vulnerable locations, which means PAM must be paired with secret hygiene, rotation, and ownership. The Ultimate Guide to NHIs and the 52 NHI Breaches Analysis both show that attackers reliably exploit the gap between policy intent and actual privilege exposure.

Another edge case is multi-tenant or outsourced operations, where ownership of the privileged path is unclear. In those settings, the control objective should be explicit: no shared admin accounts, no durable cross-environment credentials, and no privileged session that cannot be attributed to a single workload or operator.

Related resources from NHI Mgmt Group

• What do security teams get wrong about trust in zero-trust access models?
• What do security teams get wrong about zero trust in agentic access environments?
• What do teams get wrong about least privilege in privileged access programmes?
• What do organisations get wrong about Zero Trust conditional access?