How should security teams expose SSH access to a device behind NAT or CGNAT without opening inbound ports?

Why This Matters for Security Teams

Exposing SSH to a device behind NAT or CGNAT is not just a networking problem. It is an identity and trust problem. When inbound ports stay closed, the device cannot be reached by default, so teams need a controlled outbound path that preserves least privilege, auditability, and revocation. That matters because SSH is often used for administrative access, recovery, and automation, which makes it an attractive target for credential theft and lateral movement.

Static port forwarding or router exceptions are usually the wrong answer because they widen the attack surface for the whole network segment rather than a single service. Current guidance suggests treating the device as a managed NHI-backed workload, then exposing only the SSH service through an authenticated tunnel. The same design principle appears in OWASP Non-Human Identity Top 10, which emphasizes credential misuse, over-privilege, and weak lifecycle control as recurring failure modes.

NHIMG research shows how often weak non-human identity hygiene becomes a real incident: in Ultimate Guide to NHIs, 97% of NHIs carry excessive privileges, which is exactly the kind of condition that turns a simple remote-access path into a broad compromise opportunity. In practice, many security teams discover tunnel abuse only after exposed management access has already been scanned, brute-forced, or repurposed for lateral movement.

How It Works in Practice

The clean pattern is outbound-only connectivity from the device to a trusted relay, bastion, or tunnel service. The device initiates the session, authenticates itself, and keeps the connection alive; the administrator then reaches SSH over that established channel without requiring the firewall or NAT device to accept inbound traffic. This is especially useful for home routers, CGNAT mobile links, and customer-managed environments where no inbound rule can be assumed.

From an operations perspective, the tunnel should be tied to a workload identity, not a shared password. That means the device or tunnel agent proves what it is with a cryptographic identity, then receives short-lived authorization for the SSH target. For agent and workload identity patterns, the operational model aligns with SPIFFE principles and should be governed with the same lifecycle discipline described in Ultimate Guide to NHIs — Key Challenges and Risks. A practical implementation usually includes:

• Per-device identity with unique enrollment and revocation.
• Short-lived tunnel credentials instead of persistent shared secrets.
• Policy enforcement that limits the relay to SSH on port 22, not arbitrary forwarding.
• Session logging, command visibility where appropriate, and immediate revocation on anomaly.
• Administrative access approval that is time-bound and task-bound.

For policy decisions, teams should prefer request-time evaluation using controls informed by zero trust, rather than static allowlists that never change. The NIST guidance on security controls and zero trust supports this direction, and the difference becomes important when the device is used for automation as well as human maintenance. These controls tend to break down when the tunnel agent is deployed as a long-lived shared service across many devices because revocation, attribution, and blast-radius containment become ambiguous.

That same operational discipline is why teams should also review NIST SP 800-53 Rev 5 Security and Privacy Controls alongside the remote-access design.

Common Variations and Edge Cases

Tighter remote access often increases setup and lifecycle overhead, requiring organisations to balance convenience against revocation speed, audit depth, and outage tolerance. The best pattern depends on whether the device is a one-off admin target, a fleet endpoint, or an unattended industrial asset.

For ad hoc support, a one-time tunnel with just-in-time authorization may be enough. For fleet management, the better pattern is a managed tunnel agent with centralized policy, device inventory, and automatic certificate renewal. For regulated or high-risk environments, the tunnel should be paired with jump-host controls, multi-factor approval, and session recording. Best practice is evolving here, and there is no universal standard for when a tunnel relay should also perform command brokering versus simple port forwarding.

Edge cases matter. If the device must survive intermittent connectivity, the tunnel should reconnect safely without reusing expired secrets. If the target is embedded or resource-constrained, the agent may need to be lightweight, but that is not a reason to weaken identity or logging. If the device sits inside a vendor-managed network, third-party access review becomes part of the design, not an afterthought. NHIMG notes that 92% of organisations expose NHIs to third parties in Ultimate Guide to NHIs, which is a reminder that remote access paths often outlive their original purpose.

Where teams get into trouble is using the tunnel as a permanent backdoor instead of a tightly governed access channel. Once that happens, the model stops being secure remote administration and starts becoming unmanaged exposure.

Related resources from NHI Mgmt Group

• How should security teams provide remote access to devices behind NAT and CGNAT?
• How should teams extend identity governance into on-prem systems without opening inbound access?
• How should security teams implement just-in-time access without leaving standing privilege behind?
• How should security teams expose APIs to AI systems without creating unsafe access paths?