Cloudflare Access alternatives expose the gaps in cloud access governance

At a glance

What this is: This comparison piece argues that ZTNA alone does not close cloud access governance gaps when teams need fine-grained control, complete audit trails, and just-in-time access across databases, Kubernetes, and cloud accounts.

Why it matters: IAM and PAM teams should treat network access and privileged access as separate problems, because hybrid environments still require credential governance, session visibility, and standing privilege reduction.

Context

Cloud access governance is broader than whether users can reach an application. In hybrid estates, teams still need to decide who can touch cloud accounts, databases, and orchestration layers, how that access is approved, and how it is recorded for audit and incident review.

The article's core point is that Cloudflare Access addresses network-layer access well, but not the full privileged access problem. That distinction matters for IAM and PAM programmes because access policy, session logging, and just-in-time privilege are separate controls, not interchangeable features.

Key questions

Q: How do security teams close cloud access governance gaps when ZTNA is in place?

A: 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.

Q: When does just-in-time access fail to reduce privilege risk?

A: JIT fails when access is still broad, poorly logged, or not revoked after task completion. If approval does not narrow the scope of access and expiry is not enforced, the control only changes how access is granted, not how long it remains dangerous. In that case, standing privilege is still the real problem.

Q: What are the signs that cloud access logging is not good enough for investigations?

A: The warning sign is that you can see a session began but cannot reconstruct what happened inside it. If you lack query history, command history, or replayable session evidence, then audit and incident response will depend on assumptions instead of records. That is usually a sign the logging layer stops too early.

Q: What happens when offboarding only removes SSO access from a hybrid environment?

A: Users can remain active in downstream databases, servers, or cluster tooling if those resources are not tied back to the same identity control point. That creates orphaned access paths and delayed revocation. Effective offboarding must close every privileged path, not just the primary login route.

Technical breakdown

Why ZTNA does not equal cloud-account governance

Zero Trust Network Access narrows exposure by putting an identity gate in front of applications and private resources. That works well for reducing VPN dependence and limiting lateral movement, but it does not automatically provide granular authorization inside cloud accounts or workloads. Cloud access governance needs to control entitlements on the resource itself, not just the path to it. When the control plane stops at network access, privileged actions inside AWS, GCP, Azure, Kubernetes, or databases still require a separate authorization and audit layer.

Practical implication: treat ZTNA as one layer in a broader privileged access architecture, not as a replacement for cloud entitlement governance.

Why SSH-only just-in-time access is not enough

Just-in-time access is most useful when it can grant short-lived privilege across the resource types teams actually use. If JIT only covers SSH, then databases, Kubernetes, and cloud consoles remain governed by other mechanisms that may still rely on standing access or manual elevation. The result is uneven privilege reduction across the environment. A mixed estate needs a consistent issuance model so that temporary access, expiry, and approval do not vary by protocol.

Practical implication: map each resource class to the access pattern it actually supports, then close the gaps where JIT stops at the protocol edge.

Why auditability depends on session-level visibility

Access logs are not the same as complete activity records. Basic logs can show that a session started, but they may not capture queries, command history, or replayable actions inside databases and admin sessions. For incident response and compliance, teams need evidence of what happened after authentication, not only who connected. Without granular activity logging, security teams cannot reliably reconstruct privileged use or prove least-privilege enforcement in practice.

Practical implication: require session-level telemetry for privileged workflows, especially where investigations depend on reconstructing database, shell, or Kubernetes activity.

NHI Mgmt Group analysis

Cloud access governance breaks when network control is treated as privileged access control. A ZTNA gate can decide whether a session is allowed to begin, but it does not by itself define the entitlement model inside the resource. That leaves cloud accounts, databases, and Kubernetes clusters with a governance gap that IAM teams must close separately. The practical conclusion is that access path control and privilege control are related, but not the same control.

SSH-only just-in-time access creates a split privilege model. When one protocol gets ephemeral access and the rest of the stack does not, teams end up with inconsistent governance across the same application estate. That inconsistency is where standing privilege survives in practice, even when a programme believes it has adopted least privilege. Practitioners should treat protocol-specific JIT as partial coverage, not programme maturity.

Granular activity logs are now a governance requirement, not a nice-to-have. Access decisions lose much of their value if teams cannot later see what an authenticated user or vendor actually did inside the session. This matters most in hybrid estates where database queries, shell activity, and Kubernetes commands all carry different blast-radius implications. The implication is clear: audit evidence must be built into the access layer, not bolted on after the fact.

Complete audit trails expose the identity gap that ZTNA leaves behind. A team can reduce VPN usage and still fail to govern privileged behaviour if it cannot attribute actions to specific users, sessions, and resources. That is why cloud access governance sits at the intersection of IAM, PAM, and session monitoring rather than inside network security alone. The practitioner takeaway is to align the access model to the resource model, not to the transport layer.

Cloud access alternatives are now being judged by governance depth, not just connectivity. The market signal here is that practitioners are comparing tools on their ability to express least privilege, collect forensic evidence, and support heterogeneous environments. That shifts buying criteria away from simple remote access replacement and toward full privileged access management across cloud and hybrid estates. The implication is a more demanding standard for any access platform that wants to sit in the control path.

From our research library:

• 74% of organizations report identity-related breaches, and privileged access is a leading cause of lateral movement.
• Read next: Privileged Access Management Guide

What this signals

Privilege governance now needs to follow the resource, not just the gateway. Teams that stop at application reachability still leave cloud accounts, databases, and orchestration layers to be governed elsewhere, which is where standing privilege and weak audit evidence survive. That makes privileged access management the more durable control layer for hybrid estates.

Cloud access governance gap: The control failure here is not lack of authentication, but lack of policy depth after authentication. When the resource itself is not governed, security teams cannot prove least privilege, and access reviews become a paper exercise instead of a control.

90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs. That is a reminder that zero trust only works when the identities behind services, workloads, and admin paths are governed with the same discipline as human access.

For practitioners

• Define separate controls for network access and privileged access Map which parts of your environment only need reachability and which require entitlement enforcement, session logging, and approval workflows. Do not let a ZTNA policy stand in for resource-level authorization.
• Inventory protocol-specific access gaps List databases, Kubernetes clusters, cloud consoles, and SSH endpoints separately, then identify where just-in-time access stops or where standing privilege still exists. Use that inventory to find partial coverage.
• Require session-level audit evidence Verify that privileged access produces query logs, command logs, or replayable session records rather than only connection metadata. Preserve those records in a system the security team can search during investigations.
• Rework offboarding for hybrid access paths Make user deprovisioning revoke cloud, database, and server access through the same identity control point so that access does not survive in a secondary tool after SSO removal.
• Review where ZTNA ends and PAM begins Document the boundary between application reachability and privileged action control so platform owners know which team owns policy, telemetry, and exception handling for each resource class.

Key takeaways

• ZTNA can narrow who reaches a service, but it does not by itself govern the entitlements, sessions, or audit evidence inside cloud resources.
• Hybrid environments still need separate controls for cloud accounts, databases, Kubernetes, and server access because protocol coverage is uneven.
• The practical decision is to pair network access controls with privileged access management and session recording so that access is both limited and explainable.

Key terms

• Cloud Access Governance: Cloud access governance is the set of policies and operational controls that determine who or what can reach cloud resources, under what conditions, and for how long. In practice, it connects access approval, entitlement review, monitoring, and revocation across human and non-human identities.
• Just-in-Time Access Request: Just-in-Time Access Request is a pattern that grants access only when it is needed and only for the duration required. It reduces standing privilege by making access temporary, policy driven, and task scoped. This approach is especially useful for contractors, sensitive systems, and short-lived operational work.
• Session Recording: Session recording is the capture of user activity during a privileged session, such as commands, queries, or administrative actions. It gives security and audit teams a verifiable record of what happened after authentication, which is essential when access itself is not enough to prove control.
• Privilege Access Management: Privilege Access Management is the discipline of controlling and monitoring elevated access to critical systems and data. It governs how privileged accounts, credentials, sessions, and commands are issued, used, recorded, and revoked, so administrative power is limited, traceable, and aligned to policy, risk, and operational need.

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.