SSH tunneling secures transport, but not access governance

At a glance

What this is: This article explains SSH tunneling and local port forwarding, with the key finding that encrypted transport does not solve identity governance or auditability gaps.

Why it matters: It matters because practitioners often treat secure connectivity as a proxy for secure access, when IAM, NHI, and PAM controls still need to govern who can connect, how, and with what traceability.

👉 Read StrongDM's guide to SSH tunneling and port forwarding

Context

SSH tunneling, also called SSH port forwarding, creates an encrypted path between a local client and a remote service such as a database. The access problem is not the tunnel itself, but the assumption that transport security equals governance. For identity teams, the real question is how to control and audit the credentials that use the tunnel, especially when access is operationally sensitive but not publicly exposed.

That distinction matters in modern environments because port exposure is only one layer of risk. SSH tunnels can reduce direct internet exposure, but they do not by themselves solve lifecycle management, shared credential use, or privilege visibility. For teams building NHI and PAM programmes, the operational boundary is broader than encryption in transit; it includes identity, entitlement, and traceability.

StrongDM is used in the article as the source context for the access-management discussion, but the broader issue is industry-wide. Any organisation using SSH tunnels for administrative access still has to govern the identities behind those sessions, whether they are human operators, service accounts, or other non-human access paths.

Key questions

Q: How should security teams govern SSH tunneling in production environments?

A: Treat SSH tunneling as privileged access, not just encrypted connectivity. Require unique identities, explicit purpose, session logging, and revocation paths so the tunnel remains traceable. Without those controls, you may protect traffic in transit while leaving entitlement sprawl, shared keys, and weak auditability untouched.

Q: Why do SSH tunnels complicate access governance?

A: They complicate governance because they separate the security of the transport from the governance of the identity using it. A tunnel can be encrypted and still hide who actually accessed the service, which resource was reached, and whether the access was still justified. That is an accountability problem, not a networking problem.

Q: What breaks when SSH access still relies on shared credentials?

A: Shared credentials break attribution, make revocation slow, and make access reviews less meaningful. If multiple people or processes can use the same key, the organisation cannot prove who created a session, who used it, or whether the access should still exist. The control gap is identity ownership, not encryption.

Q: What is the difference between an SSH tunnel and a VPN for access control?

A: An SSH tunnel protects a specific application or port, while a VPN usually extends network-level access across many services. For practitioners, the difference matters because VPNs and tunnels can both improve transport security without automatically solving least privilege, credential lifecycle, or session traceability.

Technical breakdown

How SSH tunnels forward traffic to remote services

SSH tunneling works by wrapping application traffic inside an encrypted SSH session and forwarding it from a local port to a remote port. Local port forwarding with the -L flag sends traffic from localhost to a remote destination through the authenticated SSH connection. Reverse tunneling with -R inverts that flow so the remote host can reach a local service. The mechanism protects data in transit, but the tunnel is only as trustworthy as the identity used to create it and the endpoint access granted behind it.

Practical implication: Treat tunnel creation as a controlled access event, not just a networking convenience, and tie it to approved identities and logged sessions.

Why encrypted transport does not equal access control

An SSH tunnel secures packets, not the full decision path that allows a user or process to reach a resource. If credentials are shared, long-lived, or poorly scoped, the tunnel can preserve confidentiality while leaving entitlement sprawl untouched. This is a common governance blind spot in access workflows: teams focus on whether traffic is encrypted and forget to ask whether the identity behind the session is properly governed, revoked, and attributable.

Practical implication: Separate transport assurance from identity assurance in policy, reviews, and audit evidence.

Port forwarding, auditability, and the visibility trade-off

Port forwarding is useful because it avoids exposing internal services directly to the internet, but that convenience can reduce the visibility defenders rely on for investigation and review. Without session-level logging, identity binding, and entitlement context, a tunnel can become a clean transport path with weak governance metadata attached. In practical terms, the architecture can hide service reachability decisions inside a normal-looking SSH session unless access controls and telemetry are deliberately attached.

Practical implication: Require session logs, identity binding, and access review evidence for every forwarded connection to preserve traceability.

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

SSH tunneling is a transport control, not an identity control. The article makes the case for encrypted forwarding, but the governance boundary sits elsewhere: who can create the tunnel, what they can reach, and whether the session is attributable. That means SSH tunneling can reduce exposure without reducing access risk. Practitioners should treat the tunnel as one control layer inside a broader access model, not as a substitute for it.

Shared or persistent credentials are the real governance debt behind convenient tunneling. The article’s closing warning is the right one: secure transport does not fix insecure credential handling. When SSH access is still managed through shared keys or unmanaged local privileges, the tunnel can preserve old operating habits inside a newer access path. The implication is that the programme problem is credential lifecycle, not port forwarding syntax.

Port forwarding exposes a classic identity visibility gap. A forwarded session can be technically secure and still opaque from an audit perspective if the organisation cannot bind the connection to a specific person, workload, or approved use case. That is a familiar NHI governance failure mode: the access path works, but the accountability model is weak. Teams should read this as a visibility and attribution problem, not merely a networking one.

Zero Trust thinking breaks down when transport hardening is mistaken for verification. SSH tunnels can reduce attack surface, but they do not continuously validate posture, privilege, or session purpose. In ZT terms, the tunnel may be encrypted, yet the downstream entitlement may still be standing and overbroad. Practitioners should use this as evidence that network encryption is necessary but not sufficient for modern identity governance.

Named concept: tunnel security illusion. This is the false confidence that an encrypted SSH path solves the underlying access problem. It does not. The practical implication is that IAM, PAM, and NHI controls must govern the identity, the entitlement, and the session record separately from the encrypted transport.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• From our research: Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• For the broader control model, see OWASP Non-Human Identity Top 10, which frames secret sprawl, overprivilege, and lifecycle risk across non-human access paths.

What this signals

Tunnel security illusion: encrypted transport can create false confidence when the real issue is identity governance. If a team cannot tie SSH forwarding to a named, reviewable identity, the tunnel becomes a secure path with weak accountability, and that is where the programme risk lives.

SSH forwarding also reinforces why access programmes need identity context alongside network controls. The practical signal is simple: if forwarded sessions cannot be mapped to a person, workload, and approved purpose, then auditability is incomplete even when the packets are protected.

For teams formalising NHI governance, this is a reminder to align SSH access with the lifecycle model already used for other non-human identities. Access approvals, revocation, and recertification should cover tunnel-capable credentials just as they would any other privileged secret or service account.

For practitioners

• Separate transport approval from identity approval Require explicit approval for the identity creating the SSH tunnel, not just the endpoint or port being reached. Record the user, workload, purpose, and destination so the forwarded session is accountable after the fact.
• Bind SSH access to named identities Eliminate shared keys and unmanaged shared accounts where possible, and map each forwarded session to a unique, revocable identity. That lets access reviews focus on real entitlement instead of generic server connectivity.
• Log forwarded sessions as access events Treat port forwarding as privileged access and capture session start, destination, duration, and command context. Feed those records into review workflows so auditors can see who reached which internal service and why.
• Review standing access to tunnel-capable systems Check whether the bastion, jump host, or SSH gateway has more privilege than it needs. If the gateway can reach many systems, its compromise or misuse becomes a high-value path across the environment.

Key takeaways

• SSH tunneling protects traffic in transit, but it does not resolve identity ownership, entitlement scope, or session accountability.
• The governance risk is not the tunnel syntax itself, but the credential and audit model attached to the access path.
• Practitioners should govern SSH forwarding as privileged access with unique identities, logs, and revocation, not as a simple network convenience.

Key terms

• SSH tunneling: SSH tunneling is a method of carrying application traffic inside an encrypted SSH session between a client and a remote service. It protects data in transit, but it does not automatically govern who may open the tunnel, what the tunnel can reach, or how the session is audited.
• Port forwarding: Port forwarding maps traffic from one port to another so a local application can reach a remote service through an intermediary connection. In identity terms, the forwarding path matters less than the credential and session controls attached to it, because those determine accountability and revocation.
• Privilege visibility: Privilege visibility is the ability to see which identities can reach which systems, under what conditions, and with what level of access. For SSH-based workflows, it is the difference between knowing traffic is encrypted and knowing who actually exercised the access path.
• Access attribution: Access attribution is the practice of linking a session or action to a specific identity, purpose, and entitlement. Without it, a secure transport layer can still produce an unauditable environment where investigators know a connection happened but not who was responsible.

Deepen your knowledge

SSH tunneling, access attribution, and privileged session governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your environment still relies on forwarded access paths, this course is a practical place to start.

This post draws on content published by StrongDM: SSH Tunnel and SSH Tunneling (Port Forwarding) Explained. Read the original.