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.
What should governance cover when SSH port forwarding is used?
SSH port forwarding should be governed as a controlled access path, not as a convenience feature. It creates a tunnel that can expose internal systems, services, and data flows through an authenticated session, so the control question is who may use it, for which destination, and under what approval and monitoring conditions.
That framing matters because port forwarding can bypass the normal user interface of a system while still delivering real operational reach. If you govern the tunnel, you govern the access path itself, which is the right control point for privileged workflows.
For practitioners, the key distinction is between allowed administration and ambient connectivity. A forwarded port that is tied to a named operator, a specific target, and a time bound use case behaves like an approved exception; a reusable forwarding rule behaves more like an informal network backdoor.
How does this fit into privileged access control?
In privileged workflows, SSH port forwarding belongs alongside other privileged entitlements such as session access, jump host use, and temporary elevation. It should be issued to named identities, limited to approved destinations, and removed once the use case ends. That keeps the access path inside the same entitlement model as other privileged actions.
Security teams should also decide whether port forwarding is allowed only through bastions or privileged session tooling, or whether direct forwarding from an operator workstation is acceptable. The more sensitive the target system, the stronger the case for brokering the session and recording the activity rather than relying on local SSH client settings alone.
Controls around forwarding are usually strongest when paired with access review, session oversight, and clear ownership. Privileged Access Management Guide is useful context for the entitlement model, while Privileged Session Management Guide shows how session brokering and recording make forwarded access more governable.
What should teams verify before allowing forwarding?
Teams should verify the identity behind the request, the business reason for the tunnel, the specific source and destination ports, and the expiry condition. If the forwarding is used for admin work, the access should be time bound and reviewed like any other elevated permission. If it is used repeatedly, it should be converted into a documented access pattern rather than left as an ad hoc exception.
It is also important to verify whether the forwarded service is already reachable through a safer control path, such as a bastion, remote access gateway, or just-in-time privileged session. If a simpler controlled path exists, forwarding should not become the default because it is easier for operators.
Where SSH itself is part of the privilege boundary, SSH Key and SSH Certificate Management Guide helps teams treat the underlying SSH trust material as governed access, not just transport. For entitlement hygiene, Access Reviews and Certification Guide is the right companion for periodic recertification and removal.
Risk and Threat Considerations
Port forwarding becomes risky when it is allowed broadly, left long-lived, or used without visibility. A tunnel can quietly bridge an external operator session to an internal service that was never meant to be reachable from that location, and it can persist even when the operator believes they are only “connecting for maintenance.”
Failure mechanism: The weakness is not SSH itself, but uncontrolled delegation of a live network path. If the forwarding rule is reusable, overbroad, or tied to a credential that outlives the task, an attacker who inherits that session or credential can pivot into internal services with little additional friction.
Impact: The likely outcome is unauthorized access to internal applications, lateral movement, or abuse of management interfaces that were meant to stay private. In privileged environments, that can become a quiet ingress route that bypasses network segmentation and weakens auditability.
When reviewing the control design, ISO/IEC 27001:2022 Information Security Management gives a useful governance anchor for access and privileged access discipline, while CIS Controls v8 supports the practical expectation that account and access pathways be controlled and reviewed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Port forwarding is an access path that needs explicit enforcement and restriction. |
| IA-9 — Service Identification and Authentication | Forwarding to internal services often relies on authenticated machine or service access. | |
| AU-2 — Event Logging | Governed forwarding needs audit visibility for privileged tunnel use. | |
| Recommendation — Enforce explicit approval and destination restrictions for forwarded SSH access. Authenticate the service path behind SSH tunnels before allowing privileged connectivity. Log forwarding events and retain records for review and investigation. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | SSH forwarding governance is fundamentally access control over a privileged path. |
| A.8.2 — Privileged access rights | Port forwarding in privileged workflows is a privileged entitlement that should be time bound. | |
| Recommendation — Define and enforce access rules for SSH port forwarding as a controlled entitlement. Review and time limit privileged forwarding rights. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The topic is about managing who may use a sensitive access path and removing it when no longer needed. |
| Recommendation — Restrict, review, and revoke SSH forwarding access when it is no longer justified. | ||
Practitioner Guidance
What to prioritise: Treat every forwarding path as an entitlement decision, not a network preference. The first control question should be whether the operator needs direct tunnel capability at all, or whether a brokered session, bastion, or time-bounded admin workflow would satisfy the task with less exposure.
What to verify: Confirm that forwarding is bound to a named identity, a specific destination, and an expiry condition, and that the access can be recertified or removed without breaking unrelated work. If you cannot explain who owns the entitlement, the workflow is already too informal.
Common mistake: Teams often govern SSH keys but ignore the forwarding behaviour attached to those keys. That leaves a technically authenticated path that is still operationally uncontrolled, which is exactly how an exception becomes a standing backdoor.
Practitioner takeaway: The safest posture is to treat SSH port forwarding as a narrowly scoped privileged exception with ownership, expiration, and auditability, not as a generic convenience feature for reaching internal systems.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org