TL;DR: SSH tunneling encrypts client-to-service traffic and reduces the need to expose internal ports, according to StrongDM, but it also narrows visibility and leaves credential governance unresolved. For IAM teams, the transport layer is not the access-control layer, and that distinction matters across NHI, human, and delegated access paths.
At a glance
What this is: SSH tunneling encrypts traffic between a client and a remote service, but StrongDM’s analysis says it leaves access governance, credential management, and auditability unresolved.
Why it matters: IAM and PAM teams should treat tunneling as a transport control, not an access-control model, because identity governance still has to cover who can connect, how access is issued, and how it is reviewed.
Context
SSH tunneling, also called SSH port forwarding, creates an encrypted path between a client application and a remote service. In practical terms, it protects data in transit, but it does not decide who should have access or how that access should be governed.
That distinction matters in identity programmes because transport security and access governance solve different problems. A tunnel may reduce exposed ports, but it does not replace credential lifecycle control, audit trails, or policy decisions about shared access and privileged connectivity.
For teams managing NHI, human, and delegated access paths, the real question is not whether traffic is encrypted. It is whether the identity behind the tunnel is inventoried, authorised, reviewed, and recoverable when access changes.
Key questions
Q: What breaks when SSH tunneling is treated as access control?
A: The access model becomes invisible. Encryption still protects traffic, but it does not tell you who opened the tunnel, whether the credential was shared, or whether the destination should have been reachable at all. That creates a governance gap between connectivity and accountability that identity teams must close.
Q: Why do SSH tunnels increase auditability challenges for IAM teams?
A: Because the tunnel can hide the path while leaving only partial evidence behind. If logs do not tie the session to a unique identity and a specific target, reviewers cannot reliably reconstruct access decisions. Auditability depends on identity traceability, not on encryption alone.
Q: How should security teams govern SSH port forwarding in privileged access workflows?
A: They should treat port forwarding as a privileged entitlement that is issued to named identities, reviewed on a schedule, and removed when the use case ends. That keeps the transport feature inside a governed access process instead of letting it become an informal backdoor to internal services.
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
What SSH tunneling actually secures
SSH tunneling forwards application traffic through an encrypted SSH session, so data in transit is protected from interception and manipulation. The tunnel can be local or reverse, but the security property is the same: it shields packets on the wire. What it does not do is authenticate business intent, assign least privilege, or govern the identity behind the connection. That makes it a transport-layer control, not an access governance control. In practice, the tunnel can hide exposure while leaving entitlement, credential, and audit problems untouched.
Practical implication: treat the tunnel as encryption for traffic, not as a substitute for identity governance.
Why port forwarding changes the attack surface but not the access model
Port forwarding avoids exposing internal services directly to the internet, which narrows one part of the attack surface. But the service is still reachable through the SSH endpoint, and the security of that path depends on the credentials and authorisations attached to the SSH identity. If those credentials are shared, long-lived, or poorly tracked, the tunnel simply concentrates access behind a single control point. The underlying governance issue remains the same: who can establish the tunnel, under what conditions, and with what accountability.
Practical implication: govern SSH access as an identity path, not just a network route.
Why auditability falls behind when SSH becomes the default access path
SSH tunnels can reduce visible inbound exposure while also reducing observability if the organisation treats the tunnel as the end of the security story. Logs may show that a tunnel exists, but not always what data was accessed, which credentials were used to establish it, or whether the access was shared. That is why SSH tunneling often exposes a governance gap between connectivity and accountability. In identity terms, the control weakens when the organisation cannot tie a tunnel session back to a unique, reviewable actor and purpose.
Practical implication: pair tunneling with access logging, unique identities, and periodic review of who can reach each resource.
Breaches seen in the wild
- CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
SSH tunneling creates a transport advantage, not an identity control plane. Encrypting traffic and hiding internal ports reduces exposure, but it does not answer the governance questions IAM and PAM teams are responsible for. Who can reach the resource, which credential established that path, and how access is revoked all remain separate decisions. The practitioner takeaway is simple: a secure pipe is not the same thing as governed access.
Credential governance is the missing layer in most tunnel-first designs. The article’s own conclusion points to the gap: individual credentials must still be managed, and shared credentials are an unsafe fallback. That means the tunnel can be technically sound while the access model is still weak. The implication for identity programmes is that lifecycle, ownership, and review must sit alongside transport security, not underneath it.
Named concept: transport assurance without access accountability. SSH tunneling can reassure operators that traffic is protected while obscuring whether the access itself is properly attributable. That is the core governance failure mode here. Once access is mediated by an encrypted tunnel, organisations still need a way to prove who connected, why they connected, and whether the privilege should exist at all.
SSH tunneling fits the NHI problem space because the identity behind the connection is the control point. The service account, SSH key, or shared credential is what turns a network path into usable access. If that identity is long-lived or reused across people and services, the tunnel simply becomes a cleaner wrapper around weak governance. Practitioners should frame SSH as part of the NHI lifecycle, not as a network-only concern.
Access visibility becomes a first-class requirement once direct exposure is removed. Moving away from open ports and toward tunnels can be the right move, but it raises the bar for auditability, entitlement review, and role clarity. The control objective shifts from perimeter exposure reduction to traceable, policy-based access. For teams, the real question is whether the organisation can still explain every tunnel session after the fact.
What this signals
Transport assurance without access accountability: SSH tunnels can reduce exposed ports while still leaving identity governance unresolved. Teams that move to tunneling without reworking credential ownership, logging, and review risk replacing one visibility problem with another.
The practical shift is from perimeter thinking to identity traceability. Once access is hidden behind an encrypted path, the organisation must be able to prove who connected, what they reached, and whether that entitlement still makes sense.
For programmes that manage privileged access, the right control question is no longer whether a service is reachable externally. It is whether every tunnel is attributable, reviewable, and removable on demand.
For practitioners
- Define SSH tunneling as a transport control, not an access policy Document that tunneling protects data in transit and does not approve, scope, or certify access to the destination service. Make the separation explicit in IAM and PAM standards so teams do not treat encrypted transport as governance.
- Inventory every SSH identity that can establish a tunnel Map each SSH key, account, and shared credential to an owner, purpose, and target resource. Remove orphaned keys and tie each access path to a named lifecycle owner.
- Replace shared tunnel credentials with unique, reviewable identities Require individual access paths for admins and operators so tunnel use can be attributed and recertified. Shared credentials hide accountability and make revocation slow when access changes.
- Log tunnel establishment and destination access separately Record who opened the tunnel, which host or service was reached, and what session activity followed. Separate transport logs from application logs so review teams can reconstruct access without guessing.
- Review port-forwarding permissions as part of privileged access reviews Treat local and reverse port forwarding as privileged capabilities because they extend reach into internal services. Include those entitlements in recertification and remove them when the business need ends.
Key takeaways
- SSH tunneling solves a transport problem first and an access problem only indirectly, which is why identity governance still has to sit beside it.
- Encrypted port forwarding can narrow exposure, but it does not by itself create accountability, unique ownership, or reliable revocation.
- IAM and PAM teams should treat SSH tunnels as one layer in a governed access path, not as a complete control model.
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 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | SSH tunnel access still depends on identities that can be over-scoped or shared. |
| NHI-07 — Long-Lived Secrets | SSH keys and shared credentials often persist long after their intended use window. | |
| Recommendation — Audit SSH access paths for overprivileged identities and remove unused tunnel permissions. Rotate SSH credentials on a defined lifecycle and eliminate long-lived tunnel secrets. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centres on separating secure transport from access authorisation. |
| Recommendation — Apply PR.AA-05 to ensure tunnel entitlements are approved, scoped, and regularly reviewed. | ||
| CIS Controls v8 | CIS-5 — Account Management | Tunnel use relies on accounts that must be owned, reviewed, and removed cleanly. |
| Recommendation — Use account management controls to remove stale SSH identities and shared access paths. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | Tunnel misuse becomes a path from credential access into broader internal reach. |
| Recommendation — Map SSH tunnel abuse to credential access and lateral movement during threat hunting. | ||
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.
- Access Governance: Access governance is the policy and workflow layer that manages how access is requested, approved, certified, and revoked. In SaaS environments it helps standardise control across many applications, reducing inconsistency between teams. It is most effective when it covers both human accounts and non-human identities.
- Auditability: Auditability is the ability to reconstruct who or what acted, what permissions were used, and what data or tools were touched. For AI and NHI governance, it is the minimum evidence needed to investigate incidents, validate controls, and prove that autonomous actions stayed within approved scope.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 8, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org