TL;DR: Enterprises are still trying to extend Zero Trust with privileged access patterns built for a more static era, even as remote work, machine identities, and third-party access increase backend exposure, according to Whiteswan Security. The real issue is that control sprawl now masks identity-based attack paths faster than conventional PAM-centric designs can govern them.
NHIMG editorial — based on content published by Whiteswan Security: zero-trust security posture for endpoints and servers
Questions worth separating out
Q: How should security teams extend zero trust beyond traditional PAM?
A: They should treat zero trust as a shared identity governance model across endpoints, servers, vendors, and machine identities, not as a PAM upgrade.
Q: Why do machine identities complicate privileged access management?
A: Machine identities complicate PAM because they expand the number of non-human access paths and shorten the time between privilege assignment and use.
Q: What breaks when privileged access tools are managed in separate consoles?
A: What breaks is the ability to see the full access chain.
Practitioner guidance
- Re-map privileged access paths across all identity types Inventory human, machine, and third-party access to endpoints, servers, and VPN-connected assets, then identify where the same privilege is governed by different teams or consoles.
- Separate trust boundaries by identity type Apply distinct access reviews and privilege rules for employees, service identities, and external vendors instead of assuming one PAM policy fits all.
- Reduce over-provisioned backend access Audit where VPN, endpoint, or server access grants broader reach than a task requires, and tighten the scope before layering additional zero-trust controls.
What's in the full article
Whiteswan Security's full article covers the operational detail this post intentionally leaves for the source:
- The product architecture behind the unified ZSP agent and how it is deployed across endpoints and servers.
- The specific access flows for passwordless trusted access and just-in-time privilege grants.
- The vendor's explanation of how its approach reduces gateways, vaults, and separate management steps.
- The implementation framing for teams comparing endpoint privilege, ZTNA, and server PAM in one environment.
👉 Read Whiteswan Security's analysis of zero-trust security posture for critical infrastructure →
Zero-trust security posture for endpoints and servers: what changes now?
Explore further
Legacy PAM was designed for a privileged-user model, not a distributed identity model. The control assumptions behind rotation, vaulting, and server-centric access review were built for a world with clearer user boundaries and fewer non-human actors. That assumption weakens when access is mediated by endpoints, vendors, and machine identities across multiple trust planes. The implication is that zero trust cannot be reduced to stronger PAM alone.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
- The same survey found that systems with least-privileged AI access had a 17% incident rate versus 76% for over-privileged systems, showing how scope, not authentication alone, drives outcome variance.
A question worth separating out:
Q: What frameworks should teams use to govern least privilege in zero trust?
A: Teams should anchor their programme in NIST Cybersecurity Framework 2.0 and NIST SP 800-207 Zero Trust Architecture, then map access rules to human, machine, and vendor identities separately. The goal is consistent governance, not a single tool, so that privilege is continuously scoped to the task and trust boundary.
👉 Read our full editorial: Zero-trust security posture for endpoints and servers still breaks on identity