How should teams govern forwarded SSH access in a PAM programme?

What makes forwarded SSH access a governance issue in PAM?

Forwarded SSH access is not just a connection convenience. In a PAM programme, it creates a privileged session path that can extend trust from the bastion into downstream systems, so governance has to cover who may use it, what they may reach, and how the session is constrained, observed, and ended. Treating it as ordinary transport misses the access control decisions embedded in the flow.

SSH forwarding can also collapse boundaries that teams assume are separate, especially when a bastion inherits credentials or can relay authentication material deeper into the environment. A sane PAM design therefore defines forwarding as an approved capability with explicit scope, not an incidental by-product of remote administration.

When that scope is unclear, the same flow that helps administrators reach hard-to-access hosts can also become a route for overreach, lateral movement, or uncontrolled reach into internal services. For that reason, forwarded SSH deserves the same policy attention as other privileged remote access paths, including approval, audit, and revocation logic.

How should teams define control boundaries for SSH forwarding?

Start by separating the session authority from the transport mechanics. The policy should say which users, roles, or break-glass paths may use forwarding, which bastions or jump hosts are allowed to broker it, and which destination hosts or subnets are in scope. If forwarding is unrestricted by destination, it usually becomes a hidden general-purpose tunnel.

It also helps to distinguish direct admin access from mediated access. A team may permit SSH for maintenance but still disallow agent forwarding, nested hopping, or reuse of the same session into unrelated systems. That distinction matters because forwarding can carry more reach than the original login appears to suggest.

Good governance also sets time and context limits. If the bastion is meant to be a controlled intermediary, its privileges, session lifetime, and ability to inherit or relay access should be tightly bounded. That keeps the control model aligned with the principle that the broker should not quietly become a second administrator.

What should PAM teams monitor and review for forwarded SSH sessions?

Forwarded SSH should be treated as a privileged session event with traceable scope, not merely as an encrypted channel. Teams should be able to answer who initiated the session, what destinations were reached, whether agent forwarding or port forwarding was used, and what commands or interactive actions occurred where logging is available.

For this reason, session controls work best when they are paired with inventory and review. A PAM programme should know which bastions permit forwarding, which user groups can use them, and whether any destinations are exempted for operational reasons. That makes exception handling explicit instead of allowing forwarding to spread by habit.

The practical test is whether an auditor or responder can reconstruct the effective privilege path after the fact. If the answer is no, then the programme has visibility over the SSH connection but not over the real access path it created.

Risk and Threat Considerations

Forwarded SSH can turn one trusted session into a broader internal access bridge, which raises blast-radius and lateral-movement risk if the bastion, user workstation, or downstream host is compromised. The main exposure is not the encrypted transport itself, but the additional authority the forwarding flow may carry across trust boundaries.

Failure mechanism: An attacker or insider abuses a permitted forwarding path, steals the session context, or pivots through a bastion that is allowed to reach more systems than intended. If agent forwarding, unrestricted destinations, or long-lived access are allowed, the forwarding path can become an unmonitored relay for privileged movement.

Impact: Compromise can spread beyond the original admin target, credentials or session material may be reused against internal hosts, and the organisation may lose the ability to prove where privileged access actually went. That increases the chance of unauthorized access, incomplete logging, and slow incident containment.

Practitioner Guidance

What to prioritise: Treat forwarded SSH as a governed exception path. The first control decision is whether you need forwarding at all for a given role or support workflow; if not, disable it by default and require explicit approval for any exception.

What to verify: Confirm that the bastion policy limits destination scope, rejects unnecessary agent forwarding, and records enough session detail to reconstruct the access path. If the logging only shows login events but not the onward path, the control is incomplete.

Common mistake: Teams often secure the jump host but forget to govern what the jump host can inherit or relay. That mistake turns a single privileged entry point into a de facto internal proxy with far wider reach than the ticket or approval described.

Practitioner takeaway: The right model is to approve forwarded SSH only as narrowly bounded privileged access, with explicit reach, strong session oversight, and a clear end point for the authority it carries.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities that have persistent access?
• How should security teams govern API keys used for generative AI access?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?