Start by separating reachability from authorization. ZTNA can control who reaches an application or private network, but cloud accounts, databases, and Kubernetes still need resource-level privilege rules, logging, and offboarding. If the same policy does not govern entitlement and session evidence, teams keep a blind spot even though the network layer looks controlled.
Cloud access governance still has to follow the resource, not just the network path
ZTNA narrows how users and systems reach cloud services, but it does not decide what an authenticated principal can do once inside. cloud access governance closes the gap by aligning network reachability with resource-level entitlements, session evidence, and lifecycle controls. That means reviewing cloud IAM, database roles, Kubernetes permissions, and service-account access as first-class controls, not as a byproduct of connectivity policy.
A useful test is whether the same control plane can answer both questions: “May this principal connect?” and “May this principal read, change, or delegate this resource?” If the answer differs by platform, teams are usually looking at a governance split rather than a true zero-trust posture. access governance is strongest when it can trace the user, workload, or automation identity to the exact entitlement used at the resource layer.
Cloud teams also need to treat offboarding and privilege drift as part of the same problem. A ZTNA policy can keep a session constrained, but it will not remove stale roles, unused keys, dormant service accounts, or cross-account permissions. Where cloud identities, workloads, and automation are in play, lifecycle control matters as much as the access decision itself, especially when multiple admin planes exist.
Why ZTNA leaves a blind spot in cloud privilege
ZTNA is designed to replace broad network trust with app-specific access, which is valuable for remote access and segmentation. The blind spot appears when organisations assume that network mediation equals authorization. In cloud environments, many of the highest-impact actions are exposed through control planes, APIs, and data stores, so the real control problem is effective privilege, not only entry.
This is where access governance becomes an entitlement problem. A user may be allowed to open a session to a cloud console, yet still require separate restriction on production databases, object storage, Kubernetes namespaces, and role assumption paths. Without those resource-level checks, ZTNA only reduces the blast radius at the edge; it does not reduce what an approved session can do after it starts.
For identity-heavy cloud estates, the practical overlap with lifecycle management is hard to ignore. NHIMG’s IAM and IGA Basics is a useful reminder that authentication, authorization, provisioning, and access review are different control layers, and cloud governance fails when they are collapsed into one.
What closes the gap in practice
The most effective pattern is to govern cloud access at the resource layer and then use ZTNA as an additional entry control. That usually means least-privilege roles, short-lived elevation where possible, strong audit logs, periodic entitlement review, and explicit offboarding of humans and non-human identities. In Kubernetes and cloud platforms, this also includes namespace boundaries, cluster roles, workload permissions, and any cross-account trust that can bypass normal user access flows.
Teams should also make session evidence usable. If an access decision cannot be paired with logs that show who accessed what, when, from where, and under which entitlement, the control is only partially verifiable. In cloud operations, verification is often the difference between “we blocked the network path” and “we actually reduced the access path.”
For lifecycle hygiene, the strongest internal control path is to remove stale access continuously, not just during periodic recertification. NHIMG’s Joiner-Mover-Leaver (JML) Guide fits this problem because cloud entitlement cleanup is ultimately a joiner, mover, and leaver issue, even when the access is delivered through ZTNA.
When cloud privilege and entitlement sprawl are the core issue, Cloud PAM and CIEM Guide provides the most direct navigation for right-sizing permissions and controlling escalation paths.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Cloud entitlements must be limited at the resource layer beyond network access. |
| AU-2 — Event Logging | Session evidence and resource actions must remain visible to prove cloud access decisions. | |
| AC-2 — Account Management | Offboarding and dormant access are central to closing cloud governance gaps. | |
| Recommendation — Apply AC-6 to right-size cloud permissions and reduce excess privilege after ZTNA access is granted. Log cloud resource actions so entitlement use can be traced to the authenticated session. Use AC-2 to remove stale cloud accounts and service identities when access is no longer needed. | ||
| NIST Zero Trust (SP 800-207) | AC-4 — Information Flow Control | ZTNA fits as a front-door flow control that must be paired with resource-level authorization. |
| Recommendation — Use information flow controls to complement ZTNA with resource-specific policy enforcement. | ||
| CIS Controls v8 | CIS-5 — Account Management | Cloud governance gaps often persist because accounts and privileges are not removed or reviewed. |
| Recommendation — Implement account management to continuously review and remove cloud access that no longer belongs. | ||
Practitioner Guidance
What to prioritise: Start with the cloud resources that can create irreversible impact, such as production databases, storage, Kubernetes control planes, and cross-account admin roles. Those are the places where ZTNA gives the least protection if entitlement is not separately controlled.
What to verify: Check whether every approved ZTNA path has a matching resource-level policy, an owner, an expiry or review process, and usable logs. If any of those four are missing, the gap is governance, not connectivity.
Common mistake: Treating ZTNA as a replacement for cloud authorization. It is better understood as a front-door control that still needs entitlement, offboarding, and audit controls behind it.
Practitioner takeaway: The right question is not whether the session was allowed in, but whether the resulting cloud privilege was intentionally granted, continuously reviewable, and quickly removable.
Related resources from NHI Mgmt Group
- How should security teams prioritise NHI remediation in cloud environments?
- How should security teams run access reviews for non-human identities?
- How should security teams govern non-human identities that have persistent access?
- How should security teams govern non-human identities in cloud environments?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org