Identity-based remote access for fleets behind NAT and firewalls

At a glance

What this is: This is an analysis of why inbound SSH and VPN patterns break for remote devices behind NAT, CGNAT, and customer-controlled firewalls, and why identity-based outbound tunnels are the practical replacement.

Why it matters: It matters because remote device access is an identity problem as much as a network problem, and IAM, PAM, and NHI teams need controls that survive changing transports, customer boundaries, and ephemeral access needs.

👉 Read Teleport's blog on remote access behind NAT, CGNAT, and firewalls

Context

Remote access for field devices breaks when teams assume they can always initiate inbound sessions to a stable address. In practice, NAT, CGNAT, customer firewalls, and roaming transports make that assumption false, which is why IP-based access models fail for fleets that move between sites, carriers, and networks.

The identity governance issue is not simply connectivity. When authorization still depends on IP allowlists or long-lived VPN credentials, the access model is tied to network location instead of device identity, which weakens auditability, tenant isolation, and revocation across NHI-managed fleets.

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 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. When devices move between Wi-Fi, cellular, satellite, or customer networks, the IP can change without warning. Identity-based policy survives those changes and preserves access control, auditability, and tenant isolation.

Q: What breaks when remote access still depends on persistent VPN credentials?

A: Standing VPN credentials create revocation and reuse problems. If a device is stolen, decommissioned, or compromised, the credential may remain valid long after the original owner intended access to end. That turns remote access into a long-lived trust relationship instead of a time-bounded operational privilege.

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.

Technical breakdown

Why NAT and CGNAT break inbound SSH for remote devices

NAT and CGNAT translate private device addresses behind shared public endpoints, so outside systems cannot reliably initiate a connection to the device. In normal enterprise networks, inbound SSH assumes a routable address and a controlled port, but those assumptions disappear in customer sites, cellular networks, and mobile deployments. CGNAT is especially restrictive because the operator does not control the upstream translation layer, so port forwarding is unavailable. The result is not a temporary routing inconvenience. It is a structural mismatch between inbound access design and the network reality of distributed fleets.

Practical implication: Treat address-based reachability as an invalid foundation for fleet access design.

How reverse tunnels and multiplexing change the access path

A reverse tunnel inverts the connection model. The device initiates an outbound connection to a proxy, then engineers ride back over that same session for SSH, Kubernetes, and database access. Multiplexing consolidates multiple protocols into one tunnel, which reduces per-protocol credentials, audit overhead, and bandwidth cost on constrained hardware. It also keeps the target service off the public internet, because the external endpoint is the proxy rather than the device itself. The architecture works because it aligns with networks that allow outbound HTTPS while avoiding inbound dependence on unknown firewalls.

Practical implication: Use an outbound session broker when devices sit inside networks you do not control.

Why device identity is safer than IP-based policy

Replacing IP addresses with device identity and labels makes authorization durable when transport changes, devices move, or network ranges shift. Policy can bind to attributes such as customer, region, firmware version, or lifecycle state instead of static subnets. That lets access survive network changes while still enforcing tenant isolation and time-bounded privileges. It also improves incident response because audit queries can filter by identity and metadata rather than reconstructing access from changing addresses. This is the core governance upgrade: policy follows the device, not the network it happens to occupy.

Practical implication: Bind access policy to cryptographic identity and labels, then review whether any remaining ACLs still depend on IP ranges.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Outbound-only access is the correct structural response when the network boundary is not yours. If the device can initiate the session, the fleet operator no longer needs inbound cooperation from every customer site, carrier, or site firewall team. This aligns with Zero Trust thinking because trust is established through identity and policy, not network provenance. For IAM teams, the implication is that remote device access belongs in identity governance, not in ad hoc network exception handling.

Identity-bound policy is the real control plane here, not transport choice alone. Reverse tunnels solve reachability, but the stronger governance change is that authorization survives transport switching only when it is anchored to cryptographic identity and device metadata. That makes labels such as customer, region, and lifecycle state part of the access decision. Teams that keep using static network rules will continue to rebuild access every time the fleet moves.

Lifecycle labels create a cleaner offboarding model for distributed devices. A device that is decommissioned should stop being reachable because policy no longer matches its lifecycle state, not because someone manually removed a route. That is the same governance problem IAM teams face with service accounts and machine credentials: offboarding must be policy-driven, not ticket-driven. The practitioner takeaway is that remote access tooling should be evaluated on how well it supports identity lifecycle, not just connectivity.

Ephemeral session governance matters more than persistent network access. When access is granted for diagnostics or maintenance, the useful unit is the bounded session, not the standing tunnel. That reduces the blast radius of a compromised engineer account and makes audit trails more meaningful because each session is tied to identity, role, and device labels. Practitioners should frame fleet access as short-lived authorization over persistent trust.

From our research:

• 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.
• That offboarding gap is why practitioners should also read Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for lifecycle design patterns.

What this signals

Identity-based remote access will become the default control pattern for distributed fleets. As more operational devices move across customer sites, cellular links, and roaming transports, network location will remain too unstable to serve as a trust anchor. Teams should expect access governance to shift toward device identity, metadata labels, and bounded sessions, with Zero Trust architecture providing the language for that shift through NIST SP 800-207 Zero Trust Architecture.

Fleet access programmes need a lifecycle model, not just a connectivity model. The practical signal is whether offboarding, revocation, and audit are tied to device state rather than tickets and manual cleanup. When those controls are missing, remote access becomes persistent by default, which is exactly the pattern NHI governance is meant to remove. Teams that already track machine identity in IAM should extend that discipline to field devices, service access, and operator sessions.

Ephemeral trust debt: the hidden risk in remote device operations. This is the accumulation of access that stays valid longer than the device or session that justified it. The more customer environments and transport changes a fleet crosses, the more likely it is that old assumptions linger in policy, logs, and credentials. Practitioners should use the Ultimate Guide to NHIs to pressure-test where identity still depends on infrastructure stability rather than cryptographic proof.

For practitioners

• 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.
• Remove standing access from decommissioned devices Tie offboarding to lifecycle state so retired hardware drops out of policy automatically instead of remaining reachable until someone manually revokes it.

Key takeaways

• Remote access for field devices fails when teams rely on inbound connectivity assumptions that NAT, CGNAT, and customer firewalls no longer support.
• Identity-bound outbound tunnels reduce operational friction while preserving auditability, tenant isolation, and policy continuity across changing networks.
• Lifecycle-aware device identity is the governance upgrade that turns fleet access from a network exception into a controllable identity process.

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.
• Device Identity: Device identity is the cryptographic proof that a specific machine is the thing being accessed, independent of its IP address or current network. In fleet governance, it allows policy, audit, and revocation to follow the device across locations and transports.
• Identity-Based Authorization: Identity-based authorization grants access based on verified identity attributes instead of network location. For remote devices, that means labels such as customer, region, or lifecycle state can control access even when the underlying transport changes.

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

👉 The full Teleport post covers reverse tunnels, multiplexing, and identity-based policy design in more operational depth.

Deepen your knowledge

Remote access for fleets behind NAT, CGNAT, and uncontrolled firewalls is covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are moving from IP-based access to identity-bound operational control, it is worth exploring.