Pomerium alternatives expose the limits of access proxy models

At a glance

What this is: This is a vendor comparison of Pomerium alternatives, with the key finding that proxy-based access alone is often not enough for database, server, and Kubernetes governance.

Why it matters: It matters because IAM teams need access models that work across human users, NHI credentials, and privileged infrastructure paths without leaving revocation, logging, or credential exposure gaps.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.

👉 Read StrongDM's comparison of Pomerium alternatives for secure access

Context

Pomerium-style access proxies simplify how users reach internal applications, but they do not by themselves solve the underlying identity governance problem. The primary issue is not remote access convenience, it is whether access to databases, servers, and Kubernetes is still bound to hidden credentials, standing privileges, and weak offboarding controls.

For IAM and security teams, the distinction matters because application access, infrastructure access, and NHI credential governance are not the same control problem. A proxy can front the session, but it does not automatically eliminate secret sprawl, over-privileged service access, or the need to prove that access ends when the user or vendor relationship ends.

Key questions

Q: How should teams govern proxy-based access to databases and Kubernetes?

A: Treat the proxy as a policy layer, not the full control plane. Teams should verify that backend credentials are hidden, access is time-bound, and activity is logged at the protocol level. If the resource still accepts standing secrets or direct entitlements, the proxy has reduced friction but not eliminated privilege risk.

Q: Why do identity-aware proxies still leave NHI risk in place?

A: Because many infrastructure resources still depend on service credentials, tokens, or keys outside the proxy session. If those credentials remain valid after access ends, the organisation still has NHI exposure, even if user login is centralised. The risk shifts from authentication to entitlement persistence and secret sprawl.

Q: What do security teams get wrong about just-in-time access for privileged systems?

A: They often treat JIT as a login feature rather than a lifecycle control. JIT only reduces risk when it is paired with short-lived entitlements, clean revocation, and full session evidence. Without those elements, teams may still have standing privilege hidden behind a temporary approval flow.

Q: Should organisations replace VPNs with an identity-aware proxy for all access?

A: Not automatically. Proxies can improve app access and reduce exposure for some use cases, but databases, servers, and Kubernetes usually need stronger privilege controls, hidden credentials, and deeper auditing. The decision should be based on whether the control actually reaches the resource boundary.

Technical breakdown

Identity-aware proxy models and where they stop

An identity-aware proxy sits in front of an application and enforces authentication and authorization before a session is established. That is useful for reducing direct exposure to internal apps and for centralising SSO policy. But the model is still a front-door control. If the downstream resource has separate credentials, long-lived keys, or unmanaged service access, the proxy does not remove the real entitlement risk. In practice, the proxy governs entry, while the resource layer still governs blast radius. That split is acceptable for some app access patterns, but it leaves deeper infrastructure and NHI governance unanswered.

Practical implication: map which access paths are truly proxy-governed and which still depend on separate secrets, keys, or direct resource permissions.

Why database, server, and Kubernetes access need deeper control

Databases, servers, and Kubernetes clusters carry different identity mechanics from browser-based app access. They often rely on SSH keys, database credentials, tokens, kubectl permissions, or embedded secrets, which makes access revocation and audit fidelity more difficult than a single SSO session. A system that only standardises entry does not automatically standardise the entitlement itself. For infrastructure, the governance question is whether the control plane can hide credentials, log activity at the protocol layer, and revoke access centrally without leaving orphaned access behind.

Practical implication: require protocol-level visibility and central revocation for infrastructure access, not just SSO front-end enforcement.

Just-in-time access and audit trails in privileged environments

Just-in-time access is the difference between persistent privilege and task-scoped privilege. In privileged infrastructure, the objective is not merely to authenticate a person once, but to bound the lifetime of the entitlement, reduce standing privilege, and preserve evidence of every sensitive action. Stronger models combine short-lived access with session logging and hidden backend credentials so the operator never handles the underlying secret directly. That reduces exposure, but only if lifecycle events, approvals, and revocation are actually wired into the access plane rather than bolted on later.

Practical implication: align JIT access with session recording and lifecycle-driven revocation for every privileged resource.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

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

NHI Mgmt Group analysis

Proxy-based access is a control layer, not an identity governance model. Identity-aware proxies can centralise authentication, but they do not erase the governance problem of who can still reach the underlying resource and with what credentials. Once teams move from web apps into databases, SSH, and Kubernetes, the question becomes whether the proxy hides the entitlement or merely decorates it. Practitioners should treat proxy-first access as a front door, not a complete access architecture.

Hidden credentials are the real control boundary in infrastructure access. The strongest part of this category is not SSO convenience, it is the attempt to keep backend credentials away from end users. That matters because direct exposure of database passwords, SSH keys, and tokens creates a separate revocation problem that access proxies alone cannot solve. This is where the operational boundary shifts from authentication to credential containment and auditability.

Standing access remains the failure mode that proxy models do not eliminate. If the underlying entitlement persists after the session closes, the access model has not removed privilege creep, it has only moved it behind a different façade. The practical conclusion is that organisations need to evaluate whether their access plane actually collapses standing privilege or simply makes it less visible to users and administrators.

Zero trust only holds when the control reaches the resource, not just the gateway. A proxy can enforce a trust decision at the edge, but zero trust governance requires continuous control over the resource itself, including revocation, session logging, and least-privilege enforcement. Otherwise the programme ends up with improved authentication and unchanged blast radius. IAM teams should judge these platforms by what they control after login, not by what they simplify before it.

From our research:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• That lifecycle gap makes the NHI Lifecycle Management Guide the next reference point for teams that need offboarding and rotation discipline.

What this signals

Credential-hiding matters more than access convenience. Teams evaluating proxy-based access should focus on whether the platform actually removes exposure to backend secrets or simply masks them behind a cleaner login flow. If the resource still depends on standing credentials, the governance problem has not been solved, only relocated.

Proxy adoption will increasingly be judged against lifecycle control. As access models expand from apps into infrastructure, organisations need to ask whether offboarding, revocation, and audit evidence travel with the session. That is where the operational gap appears, especially when third-party access and internal privilege share the same control path.

Hidden credential debt: proxy-centric access can lower user friction while preserving the organisation’s dependence on secrets that still need rotation, offboarding, and review. The broader programme implication is that identity architecture must prove revocation all the way to the resource, not just to the gateway.

For practitioners

• Separate application access from infrastructure access Inventory which paths are fronted by an identity-aware proxy and which still rely on SSH keys, database passwords, or kubectl permissions. Treat those as different governance problems and assign different control owners.
• Eliminate direct credential exposure for privileged resources Move database, server, and cluster access behind controls that hide backend credentials from end users and enforce short-lived access to the resource rather than to a static secret.
• Tie offboarding to central revocation events Require a single identity event to cut off all downstream access, including third-party vendor sessions, and verify that access ends when the relationship ends rather than when the proxy session times out.
• Log protocol-level activity for privileged sessions Capture database queries, SSH commands, and kubectl activity so reviewers can reconstruct what happened after access was granted, not just whether authentication succeeded.

Key takeaways

• Proxy-based access simplifies entry, but it does not automatically solve the governance problem of who still controls the underlying resource.
• The main risk remains hidden credentials and standing privilege in databases, servers, and Kubernetes environments.
• IAM teams should judge these tools by revocation, auditability, and credential containment, not by login convenience alone.

Key terms

• Identity-aware proxy: An identity-aware proxy is a control layer that authenticates a user before allowing access to a protected application or service. It centralises entry policy, but it does not automatically remove underlying credentials or entitlement risk unless the downstream resource is also governed.
• Standing privilege: Standing privilege is access that remains continuously available instead of being created only when needed. In infrastructure environments, it is a major source of blast radius because it can survive beyond the task, the session, or the user relationship if lifecycle controls are weak.
• Credential containment: Credential containment is the practice of preventing end users from handling the secrets that unlock backend systems. It reduces exposure by keeping passwords, keys, and tokens out of operator workflows, but it only works when revocation and logging are tied to the same control plane.
• Resource-level enforcement: Resource-level enforcement means the access decision is applied at the actual database, server, or cluster, not only at the network edge or login gateway. This distinction matters because a front-door policy can be clean while the protected system still carries standing access or unmanaged secrets.

Deepen your knowledge

Proxy-based access, privileged session control, and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are comparing access proxy models against deeper NHI controls, it is worth exploring.

This post draws on content published by StrongDM: Competitors and alternatives to Pomerium 2026. Read the original.