When does SSH forwarding create more risk than value?

Why SSH Forwarding Becomes a Liability

SSH forwarding is most defensible when it is tightly scoped, time bound, and tied to a documented admin workflow. It becomes a liability when it is left on by default, because it can turn a single trusted SSH session into a covert transport for credentials, internal services, and data flows that bypass network segmentation. That undermines the intent of NIST Cybersecurity Framework 2.0 and the visibility goals described in Top 10 NHI Issues, where ungoverned access paths often outlive the task that created them.

The real issue is not forwarding itself but the control plane around it. If a jump host, service account, or automation identity can create tunnels without a strong business justification, then every forwarded connection becomes a potential blind spot for logging, inspection, and approval. In practice, many security teams discover the problem only after an incident review shows that an otherwise legitimate SSH path was used to reach systems that should never have been directly exposed.

How It Works in Practice

Forwarding can be useful for short-lived administrative access, database maintenance, or temporary reachability during incident response. In those cases, best practice is to treat it like a privileged capability rather than a convenience feature. That means explicit enablement, constrained source hosts, session logging, and rapid revocation when the task ends. It also means aligning the access path with NHI governance so that machine-to-machine reachability is visible, reviewable, and tied to ownership.

For security teams, the practical question is whether the forwarding path is compensating for a missing control or quietly replacing one. If a team uses SSH tunnels to reach internal services because network policy is too rigid, that may be acceptable for a contained break-glass workflow. If the same pattern becomes the default way automation reaches production, the tunnel is no longer a workaround. It is now an alternate network layer that security tools may not inspect consistently. Guidance in Ultimate Guide to NHIs — Key Challenges and Risks and the authorisation discipline described by NIST Cybersecurity Framework 2.0 both point toward least privilege, but the operational translation is stronger: prove the use case, scope the tunnel, and monitor the session as if it were a privileged API call.

• Enable forwarding only for named administrative workflows, not broadly on all hosts.
• Bind usage to role, host, and session duration, then revoke access immediately after use.
• Log both the SSH session and the downstream destinations reached through the tunnel.
• Prefer explicit service exposure controls over tunnels when a stable operational path is needed.

These controls tend to break down when teams use forwarding as a permanent network shortcut for production automation because the tunnel becomes normalised and stops receiving privileged-access scrutiny.

Common Variations and Edge Cases

Tighter forwarding control often increases operational friction, so organisations have to balance emergency access against the risk of creating a shadow transport layer. There is no universal standard for when forwarding is acceptable, but current guidance suggests treating it as a temporary exception, not a standing entitlement. That is especially true for environments with high NHI density, where privileged automation already expands the attack surface and weak visibility compounds the problem, as highlighted in Ultimate Guide to NHIs — Why NHI Security Matters Now.

There are a few legitimate edge cases. Break-glass access during outages may require forwarding when alternative paths are unavailable. Ephemeral lab environments may tolerate it when systems are isolated and destroyed quickly. Legacy estates may also depend on it where replacing the pattern would create greater downtime than risk reduction. Even then, the decision should be documented, reviewed, and paired with compensating controls such as PAM, JIT access, and strong audit trails. Where the process cannot be made observable, the safer answer is usually to remove forwarding and redesign the access path.

Related resources from NHI Mgmt Group

• Why do non-human identities create more risk than many human accounts?
• Why do non-human identities create more remediation risk than many human accounts?
• When do non-human identities pose the greatest risk to organizations?
• How should teams reduce the risk of exposed AI credentials being abused?