Perimeter 81 alternatives show the limits of SASE for access

At a glance

What this is: This is a comparison post about access alternatives, with the key finding that infrastructure access needs tighter control than network-centric SASE patterns provide.

Why it matters: It matters because IAM teams must govern human, NHI, and privileged infrastructure access with controls that follow the resource, not just the perimeter.

👉 Read StrongDM's comparison of Perimeter 81 alternatives for infrastructure access

Context

Perimeter 81 is presented here as a cloud-based SASE option for remote access, but the governance problem is broader than network entry. Infrastructure access to databases, servers, and Kubernetes still requires identity controls that can hide credentials, log sessions, and enforce least privilege at the point of use.

For IAM and PAM teams, the real question is not whether access is centralized. It is whether access can be governed across the full lifecycle of a privileged session, including onboarding, offboarding, vendor access, and auditability. That is where infrastructure identity controls diverge from perimeter-first models.

Key questions

Q: How should security teams govern privileged access to databases, servers, and Kubernetes?

A: Security teams should govern privileged access at the resource layer, not only at the perimeter. That means using SSO for identity, just-in-time access for privilege, hidden credentials where possible, and session recording for accountability. The control objective is to reduce standing privilege and preserve evidence for review.

Q: Why do SASE tools often leave PAM gaps in infrastructure environments?

A: SASE tools focus on secure entry, but PAM must also control what happens after entry. Infrastructure access still depends on credentials, session duration, command execution, and auditability. When those are handled outside the access layer, teams retain hidden privilege even if the network boundary looks controlled.

Q: What breaks when end users still see database credentials or SSH keys?

A: Direct exposure of credentials breaks least-privilege design because access can be copied, reused, or retained beyond the intended session. It also weakens offboarding and recertification because the organisation cannot easily prove who has what and why. The result is a larger blast radius and weaker audit evidence.

Q: What is the difference between secure remote access and governed privileged access?

A: Secure remote access gets a user to a system, while governed privileged access controls the privilege used inside that system. The first is about connectivity and trust at the edge. The second is about entitlement scope, session visibility, and the ability to revoke or review access precisely.

Technical breakdown

Why SASE alone does not govern infrastructure access

SASE centralizes access policy at the network layer, but it does not by itself eliminate the identity objects that matter most in infrastructure. Databases, servers, and Kubernetes still rely on credentials, keys, session authorization, and command-level logging. When those are managed separately, teams end up with fragmented control points that are hard to audit consistently. The architectural issue is that network access and resource access are not the same thing. A user can pass through a secure edge and still hold standing privilege deeper in the stack. A control plane for infrastructure access closes that gap by making the resource, session, and identity relationship explicit.

Practical implication: Treat SASE as a boundary control, not a complete privileged access model.

How hidden credentials change the PAM model

The post highlights an access pattern where end users do not directly handle database credentials, SSH keys, or VPN passwords. That is a PAM pattern, not a perimeter pattern, because the control objective is to reduce standing privilege and limit credential exposure. Hidden credentials narrow the attack surface by removing direct reuse, but they also shift trust to the broker or control plane that mediates access. In governance terms, the security question becomes who can authorize access, how long the access lasts, and what evidence exists after the session ends. This is the core difference between identity-centric access management and simple secure connectivity.

Practical implication: Base your privileged access design on mediation, not shared secrets.

Why session observability matters more than generic connectivity

StrongDM emphasizes query logging, SSH and RDP session capture, and kubectl activity because infrastructure governance depends on evidence, not just authentication. Connectivity tools can prove that a user connected. They cannot always prove what the user did after connection. Session-level telemetry gives auditors and security teams a control signal that supports recertification, incident review, and segregation of duties checks. For teams managing infrastructure identities, this is where access policy becomes operationally defensible. Without this layer, the programme may know who entered, but not what privilege was exercised.

Practical implication: Require session evidence for any access path that can change data, systems, or workloads.

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

Perimeter-centric access models do not solve privileged infrastructure governance. They can centralize entry, but they do not remove the need to control credentials, session actions, or resource-level privilege. For databases, servers, and Kubernetes, the identity question is what happens after the user is admitted. Practitioners should read this as a reminder that secure access and governed access are not interchangeable.

Hidden credentials are a governance pattern, not just a convenience feature. Removing direct exposure to SSH keys, VPN passwords, and database credentials reduces reuse and leakage risk, but it also changes where trust sits in the architecture. The control plane becomes the enforcement point, which makes auditability and policy clarity more important, not less. The implication is that teams must assess mediation, not only connectivity.

Session logging is the evidentiary layer that perimeter tools usually leave incomplete. Query logs, shell activity, and kubectl commands turn access from a binary event into a reviewable record. That matters for access certification, incident response, and separation of duties because the programme needs proof of use, not just proof of login. Practitioners should treat session evidence as part of the control design, not as an afterthought.

Infrastructure access is becoming a control plane problem, not a network routing problem. The most useful architecture is the one that binds identity, authorization, and evidence to the resource itself. That aligns with Zero Trust principles and with modern PAM expectations for ephemeral, task-scoped access. The practitioner conclusion is straightforward: governance must follow the workload, not only the perimeter.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• The same survey found that only 13% of organisations feel extremely prepared for the reality of agentic AI, which shows how quickly governance models are lagging runtime behaviour.
• That gap is why teams should pair the Ultimate Guide to NHIs with infrastructure access reviews when they are redesigning privileged access paths.

What this signals

Infrastructure access governance is moving from network segmentation to session evidence. Teams that still treat connectivity as the end state will miss the control signals that matter for audit and incident response. The stronger model is one where access is granted narrowly, observed continuously, and revoked cleanly when the task ends.

Standing privilege remains the quiet risk in many infrastructure programmes. The 2026 Infrastructure Identity Survey found that 67% of organisations still rely heavily on static credentials, which means the control plane is often compensating for legacy habits rather than replacing them. Practitioners should expect credential brokering, session recording, and access certification to converge in the same workflow.

Zero Trust only becomes operational when it reaches the resource layer. Perimeter controls can reduce exposure, but they do not answer whether a user should query a database, run kubectl, or touch a server. That is why NIST SP 800-207 Zero Trust Architecture matters here, especially when paired with OWASP Non-Human Identity Top 10 guidance for hidden credentials and over-privilege.

For practitioners

• Map infrastructure access paths to the actual resource owner Inventory where databases, servers, Kubernetes clusters, and third-party vendors are accessed through network tools versus identity-aware control planes. Document which paths still rely on standing credentials, shared secrets, or unmanaged SSH keys.
• Separate connectivity from privilege Use SSO and network controls for entry, but enforce least privilege, just-in-time access, and session recording at the resource layer. That makes the approval point, the access duration, and the audit trail explicit.
• Require session evidence for privileged operations Make query logs, shell history, and kubectl activity part of recertification and incident response. If a control path cannot produce reviewable evidence, treat it as incomplete governance rather than acceptable access.
• Review offboarding as a full-session revocation problem Ensure that disabling the primary identity also terminates database, server, and cluster access in the same workflow. Offboarding should revoke the ability to re-enter through hidden credentials or stale group membership.

Key takeaways

• Perimeter-first access can centralize entry without resolving the privileged access risks inside databases, servers, and Kubernetes.
• Hidden credentials, session logging, and least privilege are the controls that turn access into something auditable rather than merely permitted.
• IAM and PAM teams should evaluate infrastructure access by evidence and revocation capability, not by whether a user got through the edge.

Key terms

• Privileged Access Management: Privileged Access Management is the discipline that governs elevated access to sensitive systems, commands, and data. In infrastructure environments, it focuses on limiting standing privilege, brokering sessions, and preserving evidence so that access can be reviewed, revoked, and audited with precision.
• Hidden Credentials: Hidden credentials are secrets that users do not directly see or handle during normal access. They reduce exposure of passwords, SSH keys, and database logins by placing them behind a control plane, which makes entitlement, rotation, and revocation easier to govern.
• 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.

Deepen your knowledge

Infrastructure access governance and hidden credentials are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are rebuilding privileged access controls for databases, servers, or Kubernetes, it is worth exploring.

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