Invisible tunnels and locked-down access in hostile edge networks

At a glance

What this is: This is an analysis of how a CRM platform for the car wash industry uses outbound-only tunnels and IP restrictions to reach legacy on-prem systems safely.

Why it matters: It matters because the same access pattern applies whenever teams must govern remote connectivity to sensitive systems without assuming modern network or identity conditions.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read ngrok’s analysis of remote access patterns in legacy car wash environments

Context

Remote access to legacy infrastructure is a governance problem before it is a networking problem. When systems live on ageing Windows servers behind multiple firewalls and NAT layers, the real issue is how to expose data and admin paths without creating standing access that no one can later explain or revoke.

The article’s core lesson is that operational constraints, not ideal architecture, define the control model. That intersects with NHI governance because service processes, CLI agents, tunnels, and API access all behave like non-human identities that need lifecycle control, scope limitation, and auditability.

For identity and security teams, the useful takeaway is not the car wash vertical itself but the pattern: older environments often force indirect access, and indirect access only stays safe when it is explicitly bounded rather than assumed to be benign.

Key questions

Q: What breaks when healthcare remote access is not tied to certificate and identity lifecycle controls?

A: When remote access is not tied to lifecycle controls, access persists after the business need ends, and attackers can reuse trusted paths that were meant to be temporary. In healthcare, that can expose patient data, disrupt clinical services, and make vendor support channels a liability instead of a control. Certificate renewal and revocation discipline is the difference between governed trust and stale trust.

Q: Why do legacy platforms create more access governance risk?

A: Legacy platforms often preserve long-lived permissions, shared accounts, and undocumented exceptions because stability was valued over lifecycle discipline. That makes standing privilege easier to miss and harder to remove. The risk is not the platform itself but the accumulation of access that no longer matches current operational need.

Q: How can security teams know whether a remote access path is actually controlled?

A: Look for three signals: clear ownership of the access mechanism, a documented revocation process, and separate policy for admin and data movement. If the path is justified only by convenience or uptime, it is probably outgrowing its original scope. Controlled access should be visible in logs, reviews, and offboarding records.

Q: What is the difference between a convenience tunnel and governed remote access?

A: A convenience tunnel is built to make connectivity easy, while governed remote access is built to make connectivity bounded, reviewable, and revocable. The difference is not the protocol alone. It is whether the access path has an owner, a scope, a stop condition, and enough logging to support accountability.

Technical breakdown

Why outbound-only tunnels change the trust boundary

Outbound-only tunnelling moves the trust boundary from the customer network to the access service. Instead of opening inbound ports, the local agent establishes an initiated connection that the remote side can traverse under policy control. That reduces exposure of internal systems, but it does not eliminate the need for strict authorisation, because the tunnel becomes a privileged pathway into legacy assets. In practice, the security question shifts from can someone reach the server to who can initiate, maintain, and use the tunnel, and under what restrictions.

Practical implication: treat the tunnel agent itself as a privileged access path and govern it with least privilege, logging, and revocation controls.

How IP allowlisting and separate admin paths reduce blast radius

IP allowlisting constrains which source addresses can reach an exposed endpoint, while separate admin and data-pull channels reduce the chance that a convenience integration becomes a general-purpose access route. This is a classic segmentation pattern, but it works only if the allowlist is tightly maintained and the paths are truly separated in policy, not just in naming. When legacy systems cannot support modern identity-aware access at the device edge, the compensating control is a narrow, explicitly documented network and application boundary.

Practical implication: define distinct access lanes for data extraction and administration, then verify that each lane has its own authorisation and monitoring.

Why service-based reconnect logic matters for operational resilience

Running the tunnel agent as a service creates persistence across reboots and transient failures, which is useful for uptime but dangerous if ownership and lifecycle controls are weak. A service account or daemon can quietly re-establish access long after the original administrator has moved on, which means availability features can turn into standing access if they are not tied to change control and offboarding. The governance issue is not the service model itself, but the absence of clear identity ownership for the runtime component.

Practical implication: bind every long-lived access service to an owned identity, a revocation path, and a review schedule.

NHI Mgmt Group analysis

Legacy environments create hidden identity surfaces. The article shows that remote access is no longer just about firewalls and ports when the real estate is made up of older Windows hosts, vendor-managed POS layers, and ad hoc networking. Those components behave like non-human identities in practice because they authenticate, persist, and reconnect on behalf of the business. Practitioners should recognise that the access problem is lifecycle governance, not simply connectivity.

Outbound-only access is a control pattern, not a control outcome. Moving to reverse tunnels and constrained endpoints reduces exposure, but only if the tunnel identity is managed as a first-class asset. A tunnel that reconnects automatically can become standing access if ownership, expiry, and revocation are not explicit. The useful concept here is implicit access persistence: access that survives because the mechanism is designed for resilience, not because the business re-approved it.

Segmentation becomes the practical substitute for modernisation. When operators cannot replace legacy systems quickly, the realistic control set is separation of admin and data paths, narrow source IPs, and visible restrictions. That is not a substitute for modern IAM, but it is often the only defensible pattern available. Security teams should treat this as a transitional control model and document where the exceptions live.

Security acceptance depends on explainability as much as encryption. The article makes clear that some customers trust a direct connection more than a reverse tunnel because the latter is easier to misunderstand. That is a governance issue for identity and access programmes too: controls fail politically when the people approving them cannot see what the access path can and cannot do. Practitioners should design for explainable boundaries, not just technical correctness.

Machine access needs lifecycle ownership even in low-friction operating models. Tools that install as services, reconnect automatically, and operate across many customer sites are managing a distributed machine identity estate whether teams label it that way or not. That means ownership, review, and removal need to be as explicit as they are for human access. The broader lesson is that modern access governance has to extend into edge and embedded environments, not stop at the data centre boundary.

What this signals

Implicit access persistence is the control gap here: operational tooling that reconnects itself can survive long after the business context that justified it has changed. Identity teams should start mapping these runtime components as governed access paths, not just infrastructure utilities, and align reviews to ownership and revocation rather than uptime alone.

The practical signal for programmes is that legacy access patterns are increasingly hybrid identity problems. Where direct modern integrations are impossible, teams should pair network restrictions with explicit lifecycle controls and audit trails. For broader identity guidance, NIST SP 800-53 Rev 5 Security and Privacy Controls remains relevant, especially where access control and accountability need to be enforced across mixed estates.

For practitioners

• Classify tunnel agents as privileged runtime identities Assign an owner, purpose, expiry condition, and revocation path to every remote-access service or agent that can reconnect automatically. Treat the agent as a governed machine identity rather than a convenience tool.
• Separate administration from data extraction paths Build different policies, logging streams, and approval workflows for admin access and read-only data movement. If the same path can do both, the access model is too broad for legacy environments.
• Use source-IP restriction as a compensating control only Allowlisting can narrow exposure, but it should sit alongside strong service ownership and change tracking. Review every static IP dependency and remove any rule that no longer has an accountable business need.
• Document reconnect behaviour before deployment Any service that restarts or reconnects after failure should be documented as persistent access, not transient tooling. Record what triggers reconnection, who can stop it, and how it is removed during offboarding.

Key takeaways

• Remote access to legacy systems becomes an identity governance issue as soon as the access path persists beyond a single operator action.
• Outward-facing constraints such as reverse tunnels and IP allowlists reduce exposure, but they do not replace ownership, review, and revocation.
• Teams should model reconnecting services as machine identities, because that is the only way to keep convenience from turning into standing access.

Key terms

• Outbound-only tunnel: An outbound-only tunnel lets a private service reach an external relay without accepting inbound internet connections. It reduces exposure by removing the public entry point, but it does not replace authorization, which still has to be enforced by identity and scope controls.
• Implicit Access: Access that is not granted directly but is inherited through roles, groups, nested entitlements, or shared paths. It often expands the real exposure surface beyond the obvious permission list and is a common source of governance blind spots.
• Machine Identity: The digital identity of a machine, device, or workload — such as a server, container, or VM — used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
• Compensating Control: A compensating control is a measure that reduces risk when the ideal fix, such as immediate patching or redesign, is not possible. In OT, compensating controls often include session recording, access restriction, and tighter monitoring. They do not eliminate the underlying issue, but they narrow exposure until safer remediation can happen.

What's in the full article

ngrok's full article covers the operational detail this post intentionally leaves for the source:

• The exact YAML and service configuration used to run the tunnel agent across customer sites.
• How terminate-tls and IP policies were combined to constrain access at the network edge.
• Operational handling of old Firebird databases on port 3050 and other legacy runtime specifics.
• The practical workflow for installing and restarting the service across unreliable networks.

👉 The full ngrok article covers tunnel setup, service persistence, and access restriction details.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It helps practitioners connect runtime access patterns to the governance models their programmes need.