By NHI Mgmt Group Editorial TeamPublished 2025-09-29Domain: Best PracticesSource: StrongDM

TL;DR: Cloudflare Access can reduce VPN dependence and support ZTNA, but StrongDM notes it lacks fine-grained cloud-account control, granular activity logs, and broader just-in-time access beyond SSH, which limits its fit for database, Kubernetes, and hybrid access governance. The practical issue is that access control, auditability, and standing privilege management still need separate design decisions, not just a network-layer gate.


At a glance

What this is: This is a comparison of Cloudflare Access alternatives, with the key finding that network-centric ZTNA alone does not solve fine-grained access control, auditing, or broader privileged access governance.

Why it matters: It matters because IAM teams still have to govern databases, servers, Kubernetes, and third-party access with controls that understand resource-level privilege, audit depth, and offboarding, not just user authentication.

By the numbers:

👉 Read StrongDM's comparison of Cloudflare Access alternatives for privileged infrastructure


Context

Cloudflare Access is a zero trust network access layer, but that is not the same thing as complete identity governance. The gap shows up when teams need to manage access to databases, Kubernetes, cloud accounts, and third-party resources with durable audit trails, precise privilege boundaries, and clean offboarding.

For NHI programmes, the practical question is not whether access can be brokered at the edge. It is whether the control plane can express least privilege at the resource level, preserve usable logs, and remove access cleanly when identities, roles, or vendors change. That is where many network-first models stop short.

In practice, this is a governance problem more than a connectivity problem. Organisations that treat ZTNA as a substitute for privileged access control usually end up layering other tools anyway, because authentication, authorization, session visibility, and credential custody are separate decisions.


Key questions

Q: What breaks when Cloudflare Access is used as a substitute for privileged access control?

A: The main failure is assuming network entry equals resource authorization. Cloudflare Access can broker access at the edge, but it does not by itself provide command-level visibility, database query logging, or full privileged session governance across cloud accounts, Kubernetes, and servers. That leaves teams with incomplete audit evidence and standing privilege elsewhere.

Q: Why do network-centric access tools struggle with hybrid infrastructure governance?

A: Hybrid environments mix applications, databases, servers, and cluster control planes, and each has different privilege semantics. A network-centric tool can authenticate a user and open a session, but that is not enough to govern the actions taken inside the session or to prove that privilege stayed within policy.

Q: How do security teams know if just-in-time access is actually working?

A: Look for full lifecycle coverage across the resources that matter, including database access, cloud accounts, Kubernetes, and third-party sessions. If JIT exists only for SSH or only at the edge, standing privilege is still present and the programme is only partially reducing risk.

Q: Should organisations replace VPNs before they have full privileged access governance?

A: They can replace VPN transport earlier, but they should not confuse that with completed governance. The safer sequence is to validate authorization, logging, and revocation across critical resources first, then use ZTNA or similar controls to remove broad network exposure without creating blind spots.


Technical breakdown

Why ZTNA does not equal resource-level authorization

Zero Trust Network Access brokers user access at the network edge, usually by validating identity, device state, and policy before a session is established. That model is effective for reducing exposure to public endpoints, but it does not automatically manage the privilege attached to the resource itself. Databases, servers, and Kubernetes clusters need authorization that understands commands, queries, and session actions, not just whether a user may connect. When the control plane stops at the application boundary, entitlement decisions remain coarse and privilege drift is harder to detect.

Practical implication: separate edge access from resource authorization and require a control plane that can govern the underlying privilege, not only the connection.

Why audit trails need command and session context

Access logs that only show successful login events are not enough for privileged environments. Security teams need to know which queries were run, which SSH commands were executed, and whether a Kubernetes session changed a cluster state. Without that detail, investigations become inference exercises and compliance evidence is incomplete. Session replay, command logging, and query-level visibility turn access from a binary event into an accountable trail. That matters most where multiple operators, vendors, or automation paths touch the same infrastructure.

Practical implication: require activity-level logging for databases, servers, and Kubernetes, not just authentication logs.

Why just-in-time access must extend beyond SSH

Just-in-time access is only useful when it can be applied consistently across the resources that actually create risk. If ephemeral access exists for SSH but not for databases, cloud accounts, or cluster actions, the programme still leaves standing privilege in place elsewhere. Teams often discover that a partial JIT model shifts risk rather than reduces it. Effective privileged access governance aligns credential issuance, session scope, and revocation across the full infrastructure path, including third-party access and offboarding events.

Practical implication: map JIT coverage across every privileged resource type and close the gaps where standing access remains.


Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Network access control is not privileged access governance. A control that verifies users at the edge can still leave databases, servers, and Kubernetes privileges poorly bounded. That distinction matters because identity governance fails when the programme mistakes session entry for entitlement control. Practitioners should treat ZTNA as one layer in the stack, not as a substitute for resource-level authorization.

Auditability is the control that determines whether access is defensible after the fact. If logs do not show queries, commands, and session actions, the organisation cannot reconstruct what was done or prove whether access matched policy. That is a governance failure, not a monitoring gap. Security teams should judge access tooling by evidence depth, not by login coverage alone.

Cloud access sprawl needs a privilege model, not just a connectivity model. Hybrid estates mix SaaS, cloud accounts, servers, and Kubernetes, which means identity programmes have to govern different resource types with different privilege semantics. A tool that simplifies one layer can still leave standing privilege intact in another. The practitioner takeaway is to design for the full access path, from identity proof to session closure.

Third-party access becomes brittle when edge controls cannot express project-scoped expiry. Vendor access is common in infrastructure operations, but it only stays safe when entitlement, duration, and revocation are bound together. If the access path cannot enforce those boundaries at the resource level, offboarding turns into manual cleanup. Teams should model vendor access as a lifecycle control, not a one-time onboarding event.

From our research:

  • Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, according to 2024 Non-Human Identity Security Report.
  • 23.7% of organisations share secrets through insecure methods such as email or messaging applications, according to the same report.
  • For a broader governance baseline, read Ultimate Guide to NHIs for lifecycle, rotation, and access review context.

What this signals

Privilege visibility is becoming the differentiator between access tooling and identity governance. When 52% of organisations say AI security decision-making is shifting toward platform and infrastructure teams, the control plane has to prove it can govern sessions, not just connections. The teams that treat edge access as the whole problem will keep discovering hidden privilege later in the lifecycle.

Standing access is the recurring failure mode. Partial just-in-time models reduce exposure only where they apply, which is why a unified privilege model matters more than a cleaner login experience. For readers building NHI programmes, the lesson is to align revocation, session scope, and evidence collection around the resource, not the network edge.

Access governance is moving from perimeter logic to lifecycle logic. That shift lines up with the NIST Cybersecurity Framework 2.0 emphasis on govern, identify, protect, detect, respond, and recover, and it requires the same discipline for service accounts, workloads, and vendors that teams already expect for humans. The practical signal is simple: if a tool cannot show who did what, where, and under which entitlement, it is not enough for modern infrastructure.


For practitioners

  • Map access by resource type, not by login path Inventory where your current control plane governs databases, servers, Kubernetes, cloud accounts, and third-party access separately. Identify where the edge policy ends and where manual entitlement management still begins.
  • Require command-level and query-level logging Confirm that privileged sessions produce evidence of what was executed, not just that a session existed. Use session replay where available and make log completeness a procurement requirement for sensitive infrastructure.
  • Close the standing-privilege gaps in partial JIT models Look for cases where just-in-time access applies to SSH but not to database, cloud, or cluster operations. Replace those partial controls with expiry and revocation rules that follow the resource, not the protocol.
  • Treat vendor access as a lifecycle control Bind project scope, expiration, and offboarding to every third-party session. If the platform cannot revoke access cleanly when a contract or project ends, require compensating controls before granting production reach.

Key takeaways

  • Cloudflare Access-style controls can simplify remote entry, but they do not by themselves solve privilege governance inside databases, servers, or Kubernetes.
  • Audit depth matters as much as access reduction, because login logs alone cannot prove what happened inside a privileged session.
  • Teams should evaluate access platforms on resource-level authorization, lifecycle revocation, and command-level evidence, not on network-layer convenience alone.

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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.AC-4Access permissions need to reflect resource-level privilege, not just network entry.
NIST Zero Trust (SP 800-207)SC-7ZTNA is relevant, but only when paired with resource authorization and session policy.
OWASP Non-Human Identity Top 10NHI-04Partial JIT and missing lifecycle revocation leave standing non-human privilege in place.

Use zero trust to broker access, then enforce resource-specific authorization and monitoring.


Key terms

  • Zero Trust Network Access: Zero Trust Network Access is a way to broker user access to internal resources without exposing the full network. It validates identity and policy before a session begins, but it does not automatically govern what privilege exists inside that session or whether the resource itself is properly controlled.
  • Privileged access governance: Privileged access governance is the discipline of controlling who can do high-risk actions, for how long, and with what evidence. It covers entitlement scope, session visibility, approval boundaries, and revocation, which makes it broader than simple authentication or remote connectivity.
  • Just-in-time access: Just-in-time access is ephemeral, task-scoped privilege granted only when needed and removed when the task ends. In infrastructure environments, its value depends on whether it applies consistently across every sensitive resource, not just one protocol or one login path.
  • Session replay: Session replay is a record of what happened inside an access session, not just that the session existed. It lets security and compliance teams review commands, queries, and changes after the fact, which makes it a key evidence mechanism in privileged environments.

Deepen your knowledge

Cloud access governance, privileged session controls, and NHI lifecycle management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme still treats edge access as the end state, it is worth exploring.

This post draws on content published by StrongDM: Competitors & Alternatives to Cloudflare Access 2026. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2025-09-29.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org