Notifications
Clear all
Topic starter
03/06/2026 11:51 am
TL;DR: Remote access fails on remote fleets when NAT, CGNAT, customer firewalls, and transport switching break inbound SSH and VPN assumptions, according to Teleport. The governing shift is away from IP-based trust and standing network paths toward identity-bound, outbound-only access that survives network change.
NHIMG editorial — based on content published by Teleport: Remote Access That Works Behind NAT, CGNAT, and Uncontrolled Firewalls
Questions worth separating out
Q: How should security teams provide remote access to devices behind NAT and CGNAT?
A: Use an outbound-only access model where the device initiates a reverse tunnel to a broker or proxy you control.
Q: Why do IP-based policies fail for distributed devices?
A: IP-based policies fail because the address is a property of the current network path, not the device’s identity.
Q: What breaks when remote access still depends on persistent VPN credentials?
A: Standing VPN credentials create revocation and reuse problems.
Practitioner guidance
- Replace inbound SSH assumptions with outbound-only access paths Standardize on a device-initiated tunnel for remote support so customer firewalls, carrier NAT, and transport changes do not force per-site exceptions.
- Bind authorization to device identity and labels Use cryptographic identity plus metadata such as customer, region, firmware version, and lifecycle state so policy still works when IP addresses change.
- Consolidate SSH, Kubernetes, and database access through one policy plane Route operational protocols through a single broker so audit trails, credential handling, and access controls stay consistent across a fleet.
What's in the full article
Teleport's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step reverse tunnel setup for remote fleets that must work across customer-controlled networks
- Implementation details for multiplexing SSH, Kubernetes, and database access through one outbound connection
- Label-based authorization examples showing how policy follows device identity instead of IP ranges
- Operational guidance for handling transport switching, TLS inspection, and reconnect behaviour
👉 Read Teleport's blog on remote access behind NAT, CGNAT, and firewalls →
Remote access behind NAT and CGNAT: what IAM teams need to know?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
03/06/2026 11:53 am
IP-based authorization is no longer a reliable governance model for remote fleets. The article shows that device location changes, carrier translation, and customer-controlled firewalls make address-based trust unstable. That means the access model is already decoupled from the actual identity of the device, which creates drift between policy intent and operational reality. Practitioners should treat IP dependence as a control boundary that has outlived its assumptions.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: How can teams keep remote access auditable across many customer sites?
A: Centralize access through one policy plane and make every session inherit device labels, engineer identity, and authorization scope. That creates consistent logs and makes it possible to answer who accessed which device, when, and under what conditions without reconstructing access from fragmented site-specific network rules.
👉 Read our full editorial: Identity-based remote access for fleets behind NAT and firewalls
