TL;DR: A small always-on device, such as a Raspberry Pi or Apple TV, can act as an exit node or subnet router for remote access, home troubleshooting, and backup connectivity, according to Tailscale’s guide. For identity and access teams, the interesting part is how persistent remote reachability creates a governance problem around device trust, network exposure, and lifecycle control.
At a glance
What this is: Tailscale argues that a small always-on node at a remote home can extend secure access, LAN routing, and backup connectivity without relying on a permanently running household computer.
Why it matters: For IAM and NHI practitioners, this is a useful example of how persistent network reachability creates a governance problem around trusted endpoints, change control, and who can rely on an always-available access path.
Context
A remote tailnet node is a small device that stays online at a home location and acts as a network anchor for remote access. In practical terms, that can mean an exit node, a subnet router, or a persistent support point for devices on the far side of the connection.
The identity angle is real because the device becomes a trusted access path rather than a one-off endpoint. Once a node is allowed to represent a location on the network, teams have to think about device trust, administrative visibility, and what happens when that device is repurposed, updated, or left unattended.
Key questions
Q: How should teams govern always-on remote access nodes in home or branch networks?
A: Treat them as trusted access infrastructure, not hobby hardware. Define the exact purpose, limit the routes they advertise, assign an owner, and review them on a schedule. If the device is supporting remote troubleshooting or backup access, make patching, reboot testing, and recovery procedures part of the control set.
Q: Why do always-on remote nodes create governance risk even when they are legitimate?
A: Because they extend trust beyond the user session and into a device that may sit unattended for long periods. If the node is compromised, outdated, or repurposed, it can still represent a live path into the remote network. The risk is persistence of access, not just the initial setup.
Q: What signs show a remote home node is becoming unmanaged?
A: Look for stale firmware, unclear ownership, missing review dates, and devices that still have routing privileges long after their original purpose changed. A node that is online but not actively maintained is a sign that access governance has slipped behind operational reality.
Q: Should organisations prefer a dedicated node over sharing a personal device for remote access?
A: A dedicated node is easier to govern because its purpose is narrower, its ownership is clearer, and its permission scope is easier to review. Shared devices create more uncertainty about who manages updates, who can use the access path, and when the trust relationship should end.
Technical breakdown
Exit nodes and subnet routers turn a device into a network control point
An exit node routes traffic through the remote device, so a user can appear to originate from the home network. A subnet router advertises access to other devices on that local network, which extends reach beyond the node itself to printers, routers, and other unmanaged assets. Those two roles are different, but both make the device part of the access path rather than a passive endpoint. The security implication is that the node inherits trust for routing and remote access, so its state matters as much as the user session that reaches it.
Practical implication: Treat the node as part of the trust boundary and apply the same inventory, access, and update discipline you would use for any privileged access path.
Always-on VPN depends on local device behaviour and power state
The guide shows that persistence is not automatic. Apple TV needs to stay configured as a home hub so it does not sleep, Android TV needs Always-on VPN, and Linux devices need update and access paths that survive remote administration. In each case, the connection depends on the device booting, staying powered, and maintaining its network extension. That means connectivity is tied to household conditions, not just software policy, which is why remote nodes can fail quietly if the physical device is disturbed or under-maintained.
Practical implication: Build operational checks around power, sleep settings, and update state so a remote node does not become a falsely trusted control point.
Remote access from an always-on node creates a lifecycle management problem
A node that lives in someone else’s house or on a family network may be useful for months or years, but its trust should still expire with the purpose it serves. The article’s examples show support use, backup use, and travel-style remote presence, all of which can outlive the original reason the node was deployed. That creates a lifecycle issue familiar to IAM teams: access granted for convenience often persists after the original business need changes. In this case, the asset is a device, not a user, but the governance pattern is the same.
Practical implication: Define ownership, review cadence, and offboarding criteria for remote nodes before they become permanent shadow infrastructure.
Threat narrative
Attacker objective: Gain durable remote network presence that can be reused for access, routing, or observation of the remote environment.
- Entry occurs when a pre-configured device is plugged into a remote home network and granted tailnet access as an always-on node.
- Credential access is effectively embedded in the setup because the node becomes a trusted route for remote sessions, exit traffic, and subnet reachability.
- Impact is persistent remote reach into home devices and services, which can help legitimate troubleshooting but also extends the blast radius of a compromised node.
Breaches seen in the wild
- SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Persistent remote reachability is a governance problem, not just a convenience feature. A device that stays online in a remote home becomes part of the access fabric, which means its trust status matters long after setup is complete. The same pattern appears in enterprise remote-access design: once an endpoint can route or represent a network location, its lifecycle has to be managed like an access entitlement. Practitioners should therefore treat always-on nodes as governed assets, not household gadgets.
Remote nodes expose a trust boundary that many access programmes leave implicit. The article shows how a small device can act as an exit node or subnet router, which makes it both a connectivity aid and a policy decision. That is the security lesson for IAM and NHI teams: control is not just who can connect, but which devices are allowed to stand in for a trusted location. Practitioners should make node ownership, revocation, and review explicit.
Device sleep, updates, and physical access are part of identity assurance for this model. An always-on remote node only remains trustworthy if it stays updated, reachable, and under active administration. That links operational hygiene to access assurance in a way identity teams will recognise from service accounts and other non-human access paths. The practical conclusion is that unattended reachability requires continuous governance, not a one-time setup.
Remote home nodes illustrate the same lifecycle risk that surrounds long-lived service access. Convenience-driven access paths tend to outlast the original use case, especially when the device sits in a location no one visits often. The result is stale but still functional access infrastructure, which is exactly where governance failures start. Practitioners should align remote-node review with the same offboarding discipline used for privileged and non-human access.
What this signals
Always-on remote nodes should be managed like small pieces of infrastructure, not like household accessories. The moment a device can represent a trusted location on the network, its update state, ownership, and offboarding path matter more than its form factor. For practitioners, that means node governance belongs in the same control conversation as other long-lived access paths.
Remote connectivity becomes safer when the trust model is narrow and explicit. The less a node is allowed to do, the easier it is to review and retire. Identity teams should read this pattern as a reminder that remote access design fails when convenience outruns lifecycle control.
For practitioners
- Inventory remote nodes as governed access assets Record who owns each always-on node, what network role it serves, and when its access purpose should be reviewed or retired.
- Enforce update and sleep-state checks Verify firmware, OS updates, and power or sleep settings so the node remains reachable without silently drifting out of support.
- Separate routing rights from general device trust Limit which nodes can act as exit nodes or subnet routers, and review those permissions before expanding access to home devices.
- Require offboarding for unused home nodes Remove tailnet access, revoke routes, and wipe the device when the remote support or backup use case ends.
Key takeaways
- Remote always-on nodes expand connectivity, but they also turn a small device into part of the trusted access path.
- The main governance challenge is lifecycle control, including ownership, updates, and retirement when the use case changes.
- Teams should govern exit-node and subnet-router permissions with the same discipline they apply to other long-lived access paths.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Remote nodes function as persistent access paths that need explicit authorization and review. |
| Recommendation — Apply PR.AA-05 to review which remote nodes are allowed to act as exit nodes or subnet routers. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article's core issue is lifecycle control over persistent access assets, which maps to account and access management discipline. |
| Recommendation — Use CIS-5 to ensure each remote node has a named owner, review cadence, and retirement path. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | An always-on node can be abused as a trusted route into the remote network, supporting credential-led movement. |
| Recommendation — Map remote-node abuse to TA0006 and TA0008 when hunting for misuse of persistent access paths. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Remote access depends on managed credentials and revocation discipline for the device's trusted role. |
| Recommendation — Apply IA-5 to control how remote nodes are enrolled, maintained, rotated, and removed from service. | ||
Key terms
- Exit Node: An exit node is a device that routes a client’s traffic through its encrypted tunnel to the wider internet. In practice, it becomes a trust broker for outbound traffic, so the operator must consider monitoring, segmentation, and whether the node should carry that level of privilege.
- Subnet Router: A subnet router is a device that advertises routes to another network segment, allowing tailnet members to reach systems that are not directly running Tailscale. It expands the security boundary beyond a single host, so compromise or misconfiguration of the router can affect a broader set of assets.
- Always-on VPN: A configuration that keeps a VPN connection active whenever the device is running. It improves continuity, but it also means the node’s trust and exposure persist across reboots, sleep states, and maintenance windows.
- Remote Access Lifecycle: Remote access lifecycle is the full sequence of granting, monitoring, limiting, and removing external access. In CJIS-regulated environments, it matters because support relationships and operational exceptions can leave access open long after the original need has ended.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners apply lifecycle control to access paths that behave like infrastructure.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org