TL;DR: User-centric ZTNA can simplify remote access, but it does not solve the deeper identity problem of how databases, servers, Kubernetes, and privileged credentials are governed at scale, according to StrongDM. The real issue is whether access, observability, and offboarding are unified across human and non-human workflows, not whether the VPN disappears.
At a glance
What this is: This article compares Proofpoint with alternative access approaches and argues that user-centric ZTNA leaves a governance gap when organisations need to control databases, servers, Kubernetes, and privileged credentials together.
Why it matters: It matters because IAM, PAM, and NHI programmes cannot treat remote access as solved if the underlying credentials, session visibility, and offboarding model remain fragmented.
Context
User-centric ZTNA narrows the access problem to the person at the edge, but that framing breaks down once the protected estate includes databases, servers, Kubernetes, and privileged credentials. A security model built around remote users does not automatically govern the resources, keys, and sessions those users reach.
In practice, the governance gap is not just about connectivity. It is about whether identity, authorisation, and audit coverage extend cleanly across human access, vendor access, and machine-mediated workflows without leaving hidden credentials or unmanaged pathways behind.
Key questions
Q: What breaks when remote access still depends on persistent VPN credentials?
A: Standing VPN credentials create revocation and reuse problems. If a device is stolen, decommissioned, or compromised, the credential may remain valid long after the original owner intended access to end. That turns remote access into a long-lived trust relationship instead of a time-bounded operational privilege.
Q: Why does user-centric ZTNA still leave a governance gap for privileged systems?
A: Because the hardest risk is not login, it is downstream reach. Databases, servers, and Kubernetes often depend on separate credentials and session controls, so a tool that brokers user access can still leave privilege scope, revocation, and evidence collection split across different teams and workflows.
Q: How can security teams tell whether access governance is actually unified?
A: Look for one workflow that covers provisioning, visibility, and offboarding across human access, vendor access, and privileged sessions. If a team can authenticate a user but cannot revoke all paths, record all commands, and map all reached resources from one place, governance is still fragmented.
Q: What is the difference between secure remote access and governed privileged access?
A: Secure remote access gets a user to a system, while governed privileged access controls the privilege used inside that system. The first is about connectivity and trust at the edge. The second is about entitlement scope, session visibility, and the ability to revoke or review access precisely.
Technical breakdown
Why user-centric ZTNA stops at the edge
User-centric ZTNA treats the human as the primary control point and brokers access by application or network session. That works when the main problem is replacing a VPN for remote users, but it is thinner when the real assets are databases, servers, and Kubernetes clusters that rely on separate credentials and protocol-specific controls. The model can authenticate the user while leaving the underlying machine credentials, SSH keys, or database secrets outside the governance plane. In other words, it secures the path without fully governing the destination.
Practical implication: map which critical resources still rely on credentials and session controls that sit outside your user-centric ZTNA layer.
Why hidden credentials change the security model
When access is mediated through hidden credentials, the security question shifts from network entry to credential lifecycle and session accountability. If end users never see the database password or SSH key, the platform can centralise authorization and logging around the session rather than around the secret itself. That reduces exposure, but only if the organisation can also govern issuance, revocation, and privilege scope across all resources that depend on that secret. The architectural benefit is control-plane unification, not just access concealment.
Practical implication: treat credential concealment as a control-plane decision and verify that revocation, least privilege, and audit all follow the same path.
How observability becomes the real differentiator
The article points to session recording, query logging, and command-level visibility as the practical distinction between access tools. That matters because governance fails when teams can grant access but cannot reconstruct what happened inside the session. For IAM and PAM teams, the question is whether the access layer produces complete evidence across databases, SSH, RDP, and Kubernetes rather than just an allow or deny decision. Without that telemetry, offboarding and investigations remain partial.
Practical implication: require full session and command visibility wherever privileged access is brokered, not only authentication events.
Threat narrative
Attacker objective: The objective is to exploit fragmented access governance to reach critical systems through whichever credential or session path remains least controlled.
- Entry occurs through user-level remote access that replaces a VPN but still leaves the organisation dependent on how downstream credentials are governed.
- Escalation happens when separate database credentials, SSH keys, or vendor access paths are not unified under one control plane and can persist beyond their intended scope.
- Impact is fragmented governance, where teams can authenticate users but still lack complete visibility, revocation, and accountability across critical systems.
Breaches seen in the wild
- SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
User-centric ZTNA solves transport, not governance. The model is effective when the problem is simply remote connectivity for a person, but it leaves a gap when the real control objective is governing databases, servers, Kubernetes, and privileged credentials together. That is why the debate should not be framed as VPN versus ZTNA. The real question is whether the control plane covers the full identity and access lifecycle across the resources people actually use.
Credential concealment only matters if revocation is equally unified. Hiding passwords and keys from end users reduces direct exposure, but it does not by itself solve offboarding, privilege drift, or evidence retention. If the access layer does not control issuance and termination as one workflow, hidden credentials become an administrative convenience rather than a governance outcome. Practitioners should measure whether revocation is as consolidated as provisioning.
Vendor access is a PAM problem even when the product is branded as ZTNA. The article’s own use cases show third-party and project-based access, which means the control boundary extends beyond employee login. That shifts the category from simple remote access into privileged access governance, where session scope, expiration, and auditability matter more than the transport mechanism. Teams should classify the use case by the access risk, not by the product label.
Identity blast radius is the right concept for this category. When a platform brokers access to databases, servers, and clusters, the critical question becomes how far one credential, one session, or one onboarding decision can propagate. A narrow user-centric view hides this blast radius because it focuses on login rather than on downstream reach. The operational test is whether access can be granted, observed, and removed without leaving unmanaged residual access behind.
From our research library:
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
- The average enterprise SaaS platform connects to 42 or more third-party applications through OAuth tokens, API keys, webhooks and automation platforms.
- Read next: Zero Trust Identity Guide
What this signals
Identity blast radius is the more useful lens than remote-access simplicity. When one platform touches databases, servers, Kubernetes, and vendor sessions, the real question is how far a single access decision can travel before it is revoked. That pushes IAM and PAM teams to evaluate the access plane by downstream reach, not by whether it removes the VPN.
User-centric ZTNA should be treated as one control layer, not the control model. The article’s core limitation is that it solves entry better than it solves governance across hidden credentials, session recording, and third-party expiry. Organisations that already run zero trust should check whether their access layer still leaves NHI-style credential lifecycle gaps outside the brokered session.
For practitioners
- Audit your user-centric ZTNA boundary Identify which databases, servers, clusters, and vendor access paths still rely on separate credentials, keys, or manual approvals outside the access plane.
- Unify offboarding across human and vendor access Make a single revocation event remove session access, hidden credentials, and third-party access paths so access does not outlive the relationship.
- Require command-level evidence for privileged sessions Log database queries, SSH and RDP sessions, and kubectl activity so investigations can reconstruct what happened inside the approved access path.
- Classify remote vendor access as PAM Treat project-based third-party access as privileged access and enforce expiry, scope limits, and review cadence accordingly.
Key takeaways
- User-centric ZTNA can simplify access, but it does not by itself unify governance across databases, servers, Kubernetes, and the credentials behind them.
- The main risk is fragmented control over hidden secrets, vendor sessions, and privileged actions, which weakens offboarding and auditability.
- Teams should evaluate remote access tools by whether they compress identity blast radius, not only by whether they replace VPNs.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article centres on access scope that extends beyond the user into databases, servers, and clusters. |
| NHI-07 — Long-Lived Secrets | The comparison highlights hidden credentials and keys that must not persist beyond the access need. | |
| NHI-10 — Human Use of NHI | User-centric ZTNA can mask how humans still depend on machine credentials behind the session. | |
| Recommendation — Apply NHI-05 to reduce standing access scope across brokered database, server, and cluster sessions. Map hidden credentials to NHI-07 and shorten their lifetime wherever access is still secret-backed. Use NHI-10 to separate human login from the non-human credentials that actually reach resources. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article’s risk is that valid access can propagate from a user session into broader resource reach. |
| Recommendation — Track brokered access for credential access and lateral movement paths that extend beyond the initial login. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about whether permissions and entitlements stay unified across remote access workflows. |
| Recommendation — Use PR.AA-05 to consolidate permissions, entitlements, and authorisations across the access plane. | ||
Key terms
- User-centric ZTNA: A remote access model that authenticates a person and brokers access to applications or network resources without exposing the full network. In practice, it reduces VPN dependence, but it does not automatically govern the credentials or privileges that sit behind the session.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
- Privileged credential governance: The policies and operating controls that govern high-risk credentials such as tokens, API keys, and application secrets. Effective governance covers issuance, rotation, revocation, ownership, and auditability so that access can be removed cleanly when a vendor incident occurs.
- Hidden Credentials: Hidden credentials are secrets that users do not directly see or handle during normal access. They reduce exposure of passwords, SSH keys, and database logins by placing them behind a control plane, which makes entitlement, rotation, and revocation easier to govern.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 7, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org