Independent analysis by NHI Mgmt GroupSource article: Teleport, “Remote Access That Works Behind NAT, CGNAT, and Uncontrolled Firewalls” (May 28, 2026)

TL;DR: Teleport shows that inbound SSH and VPN assumptions break down behind NAT, CGNAT, customer firewalls and transport switching, leaving field devices unreachable when IPs change or networks block inbound paths. The durable model is outbound-only access with device identity and short-lived authorization, so policy survives network changes instead of depending on stable addresses.


At a glance

What this is: NHI Mgmt Group's analysis, drawing on Teleport's blog post: Traditional remote access patterns fail for devices behind NAT, CGNAT and restrictive firewalls, while identity-bound outbound access is more resilient.

Why it matters: IAM and NHI teams need this shift because access policy tied to IP addresses and standing network paths does not survive real-world fleet mobility, customer-controlled networks or credential reuse.

👉 Read Teleport's analysis of identity-based remote access for fleets behind NAT and firewalls


Context

Remote access for field devices fails when the access model assumes stable IPs, reachable inbound ports and a network the operator controls. That assumption breaks in customer sites, mobile fleets and carrier-managed environments, where NAT, CGNAT, firewalls and transport changes are common.

The identity question is not whether a device can be reached once, but whether authorization still holds when the network changes underneath it. For NHI programmes, that means access control, session provenance and credential lifespan have to be designed around device identity rather than network location.


Key questions

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. That avoids dependence on inbound ports, customer firewalls, and carrier translation layers. The key is to bind sessions to identity and policy, not to a public IP address that may change or never exist.

Q: Why do VPNs become unreliable for field devices and remote fleets?

A: VPNs often assume a stable interface, predictable routing and a long-lived tunnel that survives network changes. Field devices move between Wi-Fi, cellular and satellite, and many customer networks restrict persistent inbound connections. When the transport changes, the tunnel can die and the operator loses control until a new session is established.

Q: What breaks when remote-access policy is tied to IP addresses?

A: IP-based policy breaks when the device moves, is renumbered, or sits behind shared carrier translation. The same device can present different addresses over time, so address-based rules lose precision and can either block legitimate access or overgrant it. Identity-bound policy avoids that drift by anchoring authorization to cryptographic identity and labels.

Q: What should organisations do when a fleet device is retired or stolen?

A: Revoke its remote-access credentials immediately and remove its lifecycle labels from the access catalogue. If credentials are long-lived, a stolen or decommissioned device can keep tunnelling into the environment long after the business has lost track of it. Lifecycle offboarding has to be as authoritative as the original enrollment.


Technical breakdown

Why NAT and CGNAT break inbound SSH

NAT hides devices behind a shared public address and only allows inbound flows when port forwarding is explicitly configured. CGNAT pushes that translation into the carrier network, so the fleet operator cannot open the path at all. In that model, SSH and similar inbound tools fail because the client cannot initiate a routable TCP session to the device. The key technical point is that reachability is not just a firewall problem; it is an addressability problem combined with a control problem.

Practical implication: stop treating public reachability as a prerequisite for remote administration in unmanaged networks.

How reverse tunnels change the connection direction

A reverse tunnel flips the control plane so the device initiates an outbound connection to a proxy, then multiplexes operator sessions back through that channel. Because the outbound path usually rides on port 443, it survives many customer firewalls that would block inbound SSH or VPN traffic. This is also why reverse tunnels are more resilient to network handoffs: the device can reconnect from whatever interface is currently available without requiring the outside world to rediscover it.

Practical implication: design remote access so the device dials out first, rather than waiting to be dialled in to.

Why identity must replace IP-based authorization

IP-based authorization fails when a device changes site, transport or carrier assignment. Identity-based access binds policy to cryptographic identity and device labels instead of address ranges, so permissions follow the device across networks and tenants. That also shortens the trust window, because access can be issued as an ephemeral certificate rather than a standing credential that persists across reboots. In practice, the authorization layer becomes stable even when the network path is not.

Practical implication: bind access policy to device identity and metadata so authorization survives relocation, transport changes and customer-specific networks.


Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Identity-based remote access is now a fleet governance requirement, not a convenience feature. The article shows that address-centric remote access fails as soon as devices move across customer networks, carriers or transports. That is not a transport edge case, it is the normal operating environment for modern fleets. Practitioners should treat network location as volatile and design remote access around cryptographic identity, not routable IPs.

Standing remote-access credentials are the weak point once devices operate without human presence. The article notes that devices can reboot, reconnect and continue operating without manual intervention, which makes long-lived VPN or SSH credentials especially hard to govern. When revocation lags behind device retirement or theft, access outlives the asset. The practical lesson is that credential lifespan must be aligned to device lifecycle, not deployment convenience.

Reverse tunnels create the right technical primitive, but identity is what makes them governable. Outbound connectivity solves reachability, yet it does not by itself answer who may connect, to which device, and under which conditions. Binding sessions to device labels, roles and short-lived certificates turns a tunnel into a governable control plane. That is the difference between connectivity and access governance, and NHI programmes need to manage both.

Remote-access policy should be expressed in device metadata, not network assumptions. The article’s label-based authorization model is a better fit for fleets because customer, region, lifecycle and firmware state all change faster than address inventories can be maintained. This is where NHI governance and operational IAM converge: policy has to follow the device through its lifecycle. Practitioners should design for label drift, not static subnets.

Teleport's model illustrates a broader identity shift for unmanaged infrastructure. When a device can roam, fail over between transports, and reconnect without help, the old boundary between connectivity tooling and identity tooling disappears. Access review, revocation and tenant isolation all depend on the same authoritative identity record. The implication is straightforward: fleets need identity-native remote access, not a patched-up VPN perimeter.

What this signals

Identity-native remote access is the governing pattern for unmanaged fleets. When devices can move between customer sites, carriers and transports, access control has to follow identity rather than network position. The operational question for practitioners is whether their current remote-access model can still authorize, audit and revoke access when the device is no longer on a predictable subnet.

Session governance now matters as much as connectivity. A reverse tunnel solves reachability, but the programme still needs strong issuance, short-lived privilege and clear session provenance. If remote access is tied to standing credentials or address lists, device mobility turns into governance drift very quickly.

Label-bound authorization is the named control shift here. Customer, region and lifecycle metadata give access policy something stable to bind to when IPs are not stable. That is the practical bridge between remote access operations and NHI lifecycle governance, especially where devices are deployed across many customer-owned environments.


For practitioners

  • Implement outbound-only remote access Install an agent on field devices that initiates outbound connections to a controlled proxy so remote administration no longer depends on inbound reachability or customer port opening.
  • Replace IP-based access rules Bind authorization to device identity and labels such as customer, region and lifecycle state so access survives site moves, carrier changes and transport switching.
  • Use short-lived access certificates Issue ephemeral credentials for engineers and devices so a stolen or decommissioned unit cannot retain usable remote-access credentials for long periods.
  • Multiplex administrative protocols through one tunnel Carry SSH, Kubernetes and database traffic over a single outbound session to reduce exposed endpoints, lower agent overhead and keep the Kubernetes API off the public internet.
  • Tighten revocation and lifecycle offboarding Ensure retired or reassigned devices lose access as soon as lifecycle labels change, and verify that decommissioned assets are removed from the access catalogue without manual ticket dependency.

Key takeaways

  • Remote access fails quickly when it depends on inbound reachability, static IPs or customer-managed firewall exceptions.
  • The article’s core fix is to move to outbound-only tunnels and identity-bound authorization so access survives network change.
  • For fleet operators, lifecycle labels and short-lived credentials are the controls that turn connectivity into governable remote access.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-04 — Insecure AuthenticationRemote access fails when inbound SSH and VPN assumptions cannot authenticate across changing networks.
NHI-07 — Long-Lived SecretsThe article warns that long-lived VPN credentials on devices survive reboots and decommissioning.
NHI-05 — Overprivileged NHIIdentity-based access must constrain engineers and devices to only the labels and roles they need.
Recommendation — Replace inbound authentication assumptions with device identity that can authenticate from outbound tunnels. Shorten credential lifespan and revoke remote-access secrets as part of device lifecycle offboarding. Scope NHI access to device labels and limit privileges to the minimum session needed.
NIST SP 800-53 Rev 5IA-5 — Authenticator ManagementRemote-access credentials need lifecycle control, rotation and revocation when devices are mobile or decommissioned.
Recommendation — Apply authenticator management to rotate and revoke device remote-access credentials promptly.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThe article centres on binding permissions to identity and labels rather than network location.
Recommendation — Define access permissions with identity and label-based authorization instead of IP-based trust.
MITRE ATT&CKTA0006;TA0008 — Credential Access; Lateral MovementLong-lived remote-access credentials can enable persistent credential use and movement across fleet devices.
Recommendation — Track remote-access credential exposure as credential access risk and contain lateral movement paths through segmentation.

Key terms

  • Reverse Tunnel: A reverse tunnel is an access path initiated by the device rather than the operator. It lets the remote system establish an outbound connection to a broker, then carry privileged sessions back through that channel when inbound access is blocked or impractical.
  • Carrier-Grade NAT: Carrier-Grade NAT is a provider-side address translation layer that lets many subscribers share one public IP address. For remote access, it makes inbound connections unreliable or impossible because the fleet operator does not control the translation boundary.
  • Label-Bound Authorization: Label-bound authorization is a policy model that grants access based on device attributes such as customer, region, firmware or lifecycle state. It is more durable than IP-based rules because the policy survives transport changes, relocation and address reassignment across customer-managed networks.
  • Ephemeral Privilege: Ephemeral privilege is access that exists only for a short task or runtime window, then should disappear. In cloud and container environments, the challenge is not granting it, but proving it was created, used, and removed within the intended boundary before it becomes a lingering exposure.

What's in the full article

Teleport's full article covers the implementation detail this post intentionally leaves for the source:

  • Step-by-step reverse tunnel architecture for devices behind NAT, CGNAT and customer firewalls
  • Examples of multiplexing SSH, Kubernetes and database access through a single outbound tunnel
  • Configuration guidance for certificate pinning and TLS inspection environments
  • A label-based role example showing how policy survives network changes and tenant moves

👉 Teleport's full post covers reverse tunnels, multiplexed sessions and label-based policy in more implementation detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on June 3, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org