Replacing VPN access with PAM controls for servers and databases

At a glance

What this is: This is a PAM-focused guide on replacing VPN-style infrastructure access with gateway-mediated access to servers and databases, with the key finding that access can be centralised into auditable, role-based sessions.

Why it matters: It matters because IAM teams need to govern human, NHI, and privileged infrastructure access with the same lifecycle discipline, especially where network access, SSH keys, and database credentials have historically been loosely managed.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• NHIs outnumber human identities by 25x to 50x in modern enterprises.
• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.

👉 Read StrongDM's guide to replacing VPN access with gateway-based PAM

Context

VPN replacement for infrastructure access is not just a network design choice. It changes how privileged access is brokered, how sessions are recorded, and how much direct exposure engineers have to servers, databases, and private keys. For IAM teams, that makes the topic a PAM and governance issue as much as a connectivity issue.

The operational problem is familiar: broad network reach, scattered keys, and inconsistent role assignment create access paths that are hard to review and harder to revoke. A gateway-based model narrows that path, but it also puts more weight on inventory accuracy, role design, and session controls. The governance question is whether the access path is actually more controlled, not merely different.

Key questions

Q: How should security teams govern privileged access when replacing VPN access with gateway-based controls?

A: Security teams should treat the gateway as a privileged access broker, not a network convenience layer. That means defining who can reach which servers and databases, enforcing role-based assignment, and using session logs to support review and revocation. If the gateway is not governed as an access control point, the organisation has only moved the old problem into a new form.

Q: What breaks when access to servers and databases is managed through broad network reach instead of roles?

A: Broad network reach breaks least-privilege enforcement because users can often reach more systems than they actually need. When access is not expressed through roles or resource-level assignment, review becomes harder, exceptions multiply, and revocation is slower. The result is privilege sprawl that is difficult to prove, monitor, or contain.

Q: When should organisations replace shared infrastructure access with role-based session controls?

A: Organisations should do it when engineers, contractors, or platform teams share access paths that are difficult to audit or revoke individually. Role-based session controls are most useful when the environment has multiple servers, databases, or teams and the current model depends on persistent keys, ad hoc exceptions, or over-broad connectivity.

Q: What is the difference between network access and privileged session accountability?

A: Network access answers whether a user can reach a system. Privileged session accountability answers who accessed which resource, under what authority, and with what traceable session record. The first is about connectivity, while the second is about governance, attribution, and evidence for review or investigation.

Technical breakdown

Gateway-mediated access versus direct VPN reach

A gateway-mediated model places a broker between the user and the target server or database. Instead of exposing the internal network broadly, the client connects to a relay that reaches only the enrolled resources. That shifts trust from network-level reachability to resource-level authorization. In practice, the model resembles PAM more than traditional VPN access because access is expressed as a controlled session to a specific server or datasource, not as a general route into the environment. The security value depends on whether the gateway is treated as a governed access plane rather than just another network hop.

Practical implication: define the gateway as a privileged control point and review who can reach which enrolled resources.

Role-based provisioning for servers and databases

The post describes assigning access through user accounts or roles, with roles used to group engineers and distribute access at scale. This is a standard governance pattern, but it only works if role membership matches real operational boundaries. Composite roles can help when teams touch multiple domains, yet they also make entitlement drift easier to miss if role composition is not periodically reviewed. The underlying mechanism is entitlement inheritance: users receive access because they belong to a role, not because each resource was individually granted. That improves administration, but it raises the importance of certification and exception handling.

Practical implication: audit role composition and inherited entitlements before relying on group-based provisioning at scale.

Session identity, audit trails, and key handling

A central theme in the article is replacing long-lived private keys on developer laptops with managed session access. That matters because SSH keys, database passwords, and relay tokens are all forms of secrets that can outlive their intended use if distributed loosely. A gateway-based session model can improve traceability by tying activity back to the authenticated user, while still using service credentials behind the scenes to reach the target system. The control value comes from reducing secret sprawl and producing an auditable record of who accessed what and when.

Practical implication: treat session logs and secret handling as part of the same access-control design, not separate operational concerns.

Threat narrative

Attacker objective: The attacker seeks privileged access to internal servers and databases with enough trust and reach to move laterally and operate without clear session accountability.

1. Entry via exposed VPN access or broadly reachable infrastructure creates a wide initial trust boundary for engineers and privileged users.
2. Credential access or abuse follows when private keys, database passwords, or shared access paths persist on laptops and in administrative workflows.
3. Impact occurs when the broad access path allows unauthorised or difficult-to-audit access to servers and databases across the environment.

Breaches seen in the wild

• BeyondTrust API key breach — compromised BeyondTrust API key led to unauthorized SaaS access.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

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

NHI Mgmt Group analysis

PAM over VPN is really a control-plane shift, not just a connectivity change. The article frames gateway access as a simpler alternative to network tunnelling, but the deeper governance issue is that privileged access is being re-brokered through a session layer. That matters because auditability, entitlement scope, and revocation all become resource-specific rather than network-wide. The practitioner conclusion is to evaluate the access plane as a governance boundary, not a transport substitute.

Role inheritance becomes the real control surface once direct network access is removed. When servers and databases are assigned to users and composite roles, the policy problem moves from packet reach to entitlement design. That is where overexposure, inherited access, and stale role membership create risk. The practitioner conclusion is to treat role architecture as the primary privileged access decision, not the onboarding workflow.

Secret sprawl is the hidden failure mode that VPN replacement does not eliminate by itself. The post explicitly aims to reduce private keys on developer laptops, which is useful, but the larger NHI problem remains if relay tokens, database credentials, or SSH material are still distributed without lifecycle discipline. The practitioner conclusion is that reducing one secret pathway does not solve the broader secret governance problem.

Session accountability is the named concept that separates governed access from merely reachable access. StrongDM-style access is only meaningful if each session can be attributed, reviewed, and revoked through a consistent control process. That is the difference between infrastructure that is technically reachable and infrastructure that is operationally governable. The practitioner conclusion is to measure access by attribution quality, not just by connectivity success.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• The governance next step is to pair access review with lifecycle control, as explained in NHI Lifecycle Management Guide.

What this signals

Session accountability will matter more than network reach as teams modernise privileged access. A gateway can reduce exposure, but only if the programme can prove who accessed what and why. That is why the control conversation is shifting from perimeter design to evidence quality, role hygiene, and reviewability, especially for teams that already struggle to see all service identities.

Session accountability: the access model is only as strong as the audit trail behind it. If identity teams cannot map a session back to a user, resource, and privilege scope, the access model is operationally weaker than it appears. That is where the broader NHI problem shows up in human-administered infrastructure: visibility gaps, secret leakage, and stale access paths tend to reappear unless lifecycle governance is explicit.

The strongest programmes will connect privileged access tooling to the same governance logic used for NHI lifecycle management. For a broader control baseline, the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0 both reinforce the need for controlled access, logging, and recovery discipline.

For practitioners

• Map privileged access paths to a governed control plane Document which servers, databases, and administrative functions are reachable through the gateway and who approves those paths. Make the access path explicit so network reach does not become an informal privilege grant.
• Review role inheritance before scaling access Check whether composite roles or group-based provisioning are granting more access than engineers actually need. Validate inherited entitlements against job function, environment, and privilege level before onboarding more resources.
• Reduce long-lived secret distribution Remove private keys, database passwords, and relay tokens from uncontrolled endpoints where possible, and keep any remaining credentials in a managed lifecycle process with clear ownership.
• Align session logs with access reviews Use audit trails to tie each SSH or database session back to the user and resource, then feed those records into periodic access review and exception handling.

Key takeaways

• Replacing VPN access with gateway-mediated PAM changes the governance model from broad reach to resource-scoped sessions.
• Role inheritance, secret handling, and session logs become the real control points once direct network access is removed.
• If access cannot be attributed, reviewed, and revoked cleanly, the organisation has only renamed the old privilege problem.

Key terms

• Gateway-mediated access: A privileged access model where a relay or gateway brokers the connection between a user and an internal resource. It reduces broad network exposure by constraining access to specific systems, while shifting governance onto session controls, resource inventory, and authorization policy.
• Session accountability: The ability to tie a privileged action back to a specific user, resource, and access event. It is the practical proof that access was not only granted, but governed, and it depends on logs, identity attribution, and reviewable session records.
• Role inheritance: The assignment of access through roles that collect users and resources into reusable policy groups. It simplifies administration, but it also concentrates risk if the role structure is too broad, poorly reviewed, or allowed to drift away from actual operational need.
• Secret sprawl: The uncontrolled spread of credentials such as keys, tokens, passwords, and certificates across laptops, code, config files, and operational tooling. It weakens governance because revocation, rotation, and attribution become inconsistent across the access lifecycle.

Deepen your knowledge

Privileged access management, session accountability, and NHI lifecycle discipline are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are replacing VPN-style access with governed sessions, it is worth exploring.

This post draws on content published by StrongDM: Replacing Your VPN with strongDM. Read the original.