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.
Why user-centric ZTNA stops short of privileged system governance
User-centric ZTNA improves how people reach applications, but it does not automatically govern what happens after a user reaches an admin plane, database endpoint, or cluster control path. Privileged systems often rely on separate credentials, session controls, and approval workflows, so access brokered at the front door can still leave privilege scope, revocation, and audit evidence split across different controls and owners.
Where the governance gap actually appears
The gap is usually created by a mismatch between user access policy and privileged execution authority. A user may authenticate once and satisfy the ZTNA policy, yet still trigger a second trust decision for database roles, SSH keys, API tokens, Kubernetes service accounts, or break-glass paths.
That means the real governance question is not just “can the user connect?” but “who can do what, for how long, and how is it proved afterward?” If those answers live in different tools, then access review, revocation, and session evidence become fragmented even when the network boundary looks modern.
For privileged systems, the most important boundary is often the one between interactive access and delegated authority. A zero trust access layer can reduce exposure at the edge, while a separate Privileged Access Management Guide is still needed to govern elevation, session control, and standing privilege inside the target system.
Why databases, servers, and Kubernetes are different
Databases, servers, and Kubernetes clusters tend to have their own privilege model because the unit of control is not the same as the user identity. The access path may begin with a user or device, but the consequential action is often performed by a role, token, kubeconfig, agent, or administrative session that must be managed separately.
That separation matters most when the system holds production data, can alter infrastructure, or can propagate access into other environments. ZTNA may be perfectly adequate for the entry channel, yet still leave overprivileged database roles, long-lived admin credentials, or weakly governed cluster access unchanged.
In practice, the governance gap shows up when teams can say who logged in, but not who could elevate, approve, reuse, or review the underlying privilege artifact. That is why a user-centric remote access control needs to be paired with workload and session-level identity controls such as the ones described in Guide to SPIFFE and SPIRE and Just-in-Time Access and Zero Standing Privilege Guide.
What good governance looks like in a ZTNA-plus-privilege model
Good governance treats ZTNA as the access entry control and privileged access management as the control over execution authority. The two layers should be linked, but not collapsed into one policy, because they answer different questions and produce different evidence.
At minimum, governance should make it clear which systems are user-brokered, which are privilege-brokered, who owns each approval path, and what evidence survives session end. That includes revocation speed, just-in-time elevation, session recording, and periodic review of standing access across admin roles and machine-facing credentials.
A mature model also distinguishes interactive admin access from service-to-service or workload-to-workload trust. A user-centric control plane can protect the first hop, but it does not replace the need to govern the credentials and identities that actually operate the system, which is why a broader zero trust program is more effective when it extends beyond the user perimeter into the internal trust paths covered by Zero Trust Identity Guide.
Risk and Threat Considerations
The main risk is false confidence: organisations assume a modern access gateway has solved the privileged access problem when it has only reduced one part of it. That leaves standing privilege, stale admin paths, and weak evidence capture available for abuse, especially in systems where a single elevated session can reach sensitive data or critical infrastructure.
Failure mechanism: A user passes ZTNA policy, then uses separate credentials or a delegated token to obtain privileged access that is not governed, recorded, or revoked with the same rigor as the front-door session.
Impact: Attackers or insiders can preserve access after user session expiry, hide privilege escalation inside ordinary admin workflows, and force incident responders to reconstruct activity from disconnected logs and approval records.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | User-centric ZTNA starts with authenticating the user before access is brokered. |
| IA-9 — Service Identification and Authentication | Privileged systems often rely on separate service, workload, or API identities beyond the user session. | |
| AC-6 — Least Privilege | The gap is about downstream privilege scope and excessive reach after initial access. | |
| Recommendation — Enforce strong user authentication before granting remote access paths. Authenticate non-human system interactions separately from user access. Limit each admin path to the minimum permissions needed for the task. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The question contrasts user-centric access with broader zero trust governance across privileged paths. |
| Recommendation — Extend zero trust policy decisions beyond entry access into privileged system actions. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Privileged systems often depend on non-human credentials whose excess scope creates the governance gap. |
| NHI-07 — Long-Lived Secrets | Revocation gaps often persist because privileged access is backed by secrets that outlive user sessions. | |
| NHI-01 — Improper Offboarding | The governance problem includes delayed revocation of privileged access after role or session change. | |
| Recommendation — Right-size machine and service credentials that can reach privileged systems. Replace long-lived privileged secrets with expiring, reviewable access paths. Tie privileged credential revocation to joiner-mover-leaver and session end events. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | The answer is about separating user access from privileged authority and review. |
| GV.RM-01 — Risk Management Strategy | The gap is a governance issue requiring explicit ownership and risk decisions across teams. | |
| Recommendation — Link identity, authorization, and access review for privileged systems. Assign clear ownership for privileged access risk across security and platform teams. | ||
Practitioner Guidance
What to verify: Confirm whether privileged systems have their own access owner, approval model, and session evidence, rather than relying on the remote access team’s policy alone. If database, server, or cluster access can outlive the ZTNA session, the governance gap is already real.
Decision rule: If a system can change data, keys, roles, or infrastructure, treat its privileged path as a separate control surface and require explicit review of elevation, revocation, and logging.
What good looks like: The organisation can answer, for every privileged path, who approved it, when it expires, what it can reach, and what artefact proves what happened.
Practitioner takeaway: ZTNA narrows the doorway, but privileged governance is about controlling the keys inside the building, and that is a distinct accountability problem.
Related resources from NHI Mgmt Group
- How should security teams govern privileged access in user-centric ZTNA environments?
- What signals show that identity governance is still too user-centric?
- Why do passwords and traditional MFA still leave privileged systems exposed to escalation attacks?
- Why do single-platform agent controls still leave a governance gap?