Resource-scoped access removes the backup network blast radius

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Twingate's blog post: Reciprocal backup access should be scoped to one authenticated resource because exposing SSH or rsync to a remote network creates unnecessary blast radius.

Why it matters: This matters because backup-sharing patterns often spread beyond homelabs into vendor and partner access, where network-level reachability can become a privilege escalation path and a governance problem.

Context

Reciprocal backups are a simple answer to the 3-2-1 problem, but they often rely on a trust model that is broader than the task requires. Opening a port, forwarding it through a router and handing a remote key holder network reachability creates a durable exposure that outlives the backup job itself.

The governance issue is not backups as such, but how access is framed. Identity and access management basics apply here because the correct unit of control is the resource, not the subnet, and that distinction becomes more important as home labs resemble small production environments.

Key questions

Q: How do I prevent a shared backup connection from exposing my whole network?

A: Limit the backup channel to one host and one port, then authenticate it with a dedicated account, key, or certificate rather than network-wide trust. Separate the backup listener from the production network with firewall rules, segment the backup system, and allow only the exact source and destination needed for that replication path.

Q: Why do open SSH or rsync ports create a bigger backup risk than people expect?

A: Open SSH or rsync ports enlarge the attack surface because any reachable service can be probed, brute-forced, or abused if it accepts a remote party can authenticate. If the backup account or key is over-privileged, that same access can often reach backup data, snapshot controls, or adjacent systems.

Q: How does Zero Trust Network Access work for backup sharing?

A: Zero Trust Network Access for backup sharing creates an app-specific, identity-aware access path instead of exposing the backup network directly. It verifies the requesting user or workload, applies policy before connection, and usually allows only the backup service, port, and source identity approved for that session.

Q: What should teams do when a shared backup relationship ends?

A: Revoke the access path immediately, remove any associated keys, certificates, or user accounts, and close the firewall rules or tunnels that enabled the backup exchange. Then rotate credentials, confirm the backup partner cannot still reach the repository, and document the offboarding in configuration and access records.

Technical breakdown

Why exposed rsync and SSH create an attack surface

Traditional reciprocal backup setups expose a service on an internet-reachable host, then depend on patching discipline and protocol hardening to keep it safe. That means the risk is inherited from the backup service itself, plus any vulnerabilities in the daemon, key exchange, authentication or module configuration. The problem is not limited to rsyncd. Any protocol exposed through a forwarded port becomes part of the public attack surface, which gives scanners, exploit kits and opportunistic attackers a direct path to the backup endpoint.

Practical implication: Constrain backup services so they are not internet-exposed, even when they authenticate with keys or SSH.

How resource-scoped access differs from network-level access

Zero Trust Network Access changes the access boundary from the network to the resource. A user or device reaches a named hostname, service or share, while the rest of the network remains invisible and unreachable. That model matters because backup tasks need only one endpoint, but VPN-style or port-forwarded access grants a whole routed environment. Resource scoping reduces both enumeration and pivot opportunities by making the policy follow the target asset instead of the surrounding LAN. See the IAM and IGA Basics.

Practical implication: Define backup access around one host and one port, not around the entire site or subnet.

Why identity binding matters more than shared keys

A portable SSH key can be copied, reused and left behind long after the task is over. Identity-bound access is different because the policy attaches to a managed identity and can be revoked centrally without changing the network. For reciprocal backups, that means the remote party can authenticate to the one allowed resource without inheriting a reusable credential that also works elsewhere. The important distinction is not just authentication, but lifecycle control over who can still use the access path after the backup relationship ends.

Practical implication: Bind backup access to managed identities and revoke the relationship when the shared task ends.

Threat narrative

Attacker objective: The attacker aims to exploit the exposed backup service or pivot from it into other reachable systems on the same network.

1. Entry occurs when a backup service is exposed through a forwarded SSH or rsync port on a public IP address.
2. Credential access follows because the remote key or login becomes a portable trust token with broader reach than the backup task requires.
3. Escalation and lateral movement become possible if the authenticated shell or service can pivot into the rest of the LAN.
4. Impact is the exposure of backup infrastructure and adjacent home or small-office systems to scanning, exploitation and unintended reachability.

Breaches seen in the wild

• Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.

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

Resource-scoped access is the right governance unit for shared backup tasks. Backup sharing becomes safer when the policy names one endpoint and nothing else. That approach reduces the blast radius of compromise and aligns the access model with the task being performed, not the layout of the network. The implication for practitioners is that remote collaboration should be designed around resource entitlement, not around LAN reachability.

Standing network reachability is a governance failure, not just a technical convenience. A forwarded port, a router rule and a reusable key create access that persists beyond the backup window. That persistence is exactly what identity governance tries to avoid in human access programmes, and the same logic applies to shared infrastructure. The practitioner conclusion is to treat any always-on remote path as a control exception, not a normal operating state.

Backup credentials behave like privileged non-human identities once they can be reused or replayed. If a remote key can reach more than the backup target, the credential is no longer a narrow utility token but a broader access grant. That is the same governance problem that joiner-mover-leaver controls solve for stale access in people programmes. The practitioner takeaway is to revoke backup identities and their access path as a lifecycle event, not as an informal handoff.

Zero Trust Network Access makes reciprocal backups auditable in a way port forwarding never does. Connection logging at the policy layer gives operators a record of which identity reached which resource, instead of only seeing service logs on the destination. That matters because backup access is often delegated informally, then forgotten. The field-level implication is that auditability depends on where the control is enforced, not just on whether authentication exists.

What this signals

Resource scoping will matter more as small environments adopt enterprise-style sharing. Homelabs, startups and managed service relationships all face the same pattern: one task, too much reach. The governance response is to move from shared network access to named resource entitlement, because the control has to match the job being done.

Backup access is becoming an identity problem as much as an infrastructure problem. Once remote access is tied to a managed identity, revocation, audit and lifecycle control become part of the design rather than afterthoughts. That shift will favour programmes that can govern access at issuance time instead of relying on static network exposure.

Standing access paths create accumulation risk. A backup rule that was created for convenience can become a long-lived exception that nobody revisits. Practitioners should watch for any collaboration pattern where the operational shortcut is older than the reason it was approved, because that is where hidden exposure tends to persist.

For practitioners

• Define backup access as a single resource Scope each remote backup relationship to one hostname and one port, then deny subnet-wide reachability by default.
• Eliminate internet-exposed backup services Remove port forwards for rsync, SSH and SFTP endpoints and replace them with an outbound-only access path.
• Bind remote access to managed identities Use identity-based policy so the remote party can reach only the approved backup target and nothing else on the LAN.
• Revoke backup access on relationship end Treat the end of a backup-sharing arrangement as a lifecycle event and disable the access path, not just the account.
• Review lateral movement exposure from backup paths Test whether a valid backup login can enumerate or reach other services on the same network segment, then remove that path.

Key takeaways

• Shared backup arrangements often fail because they use network reachability as the control boundary instead of the specific resource being protected.
• The risk is not only internet exposure. A remote backup login can also become a pivot point into other services on the same LAN.
• The safer design is to bind access to one endpoint, use managed identities where possible and remove the path when the sharing relationship ends.

Related NHI Mgmt Group resources: IAM and IGA Basics · Joiner-Mover-Leaver (JML) Guide · MITRE ATT&CK T1550 Use Alternate Authentication Material Guide

Key terms

• Zero-Trust Network Access: Zero-Trust Network Access is a way to give users secure access to specific applications without placing them on the internal network. Access is granted only after identity, device posture, and policy checks, then limited to the requested resource. ZTNA reduces lateral movement by replacing broad network trust with per-session authorization.
• Reciprocal Backups: Reciprocal backups are a backup arrangement where two systems or organisations store copies of each other’s data. Each side acts as a backup target and a backup source, so the relationship depends on tightly scoped credentials, network segregation, and clear ownership of retention and recovery controls.
• Port forwarding: Port forwarding maps traffic from one port to another so a local application can reach a remote service through an intermediary connection. In identity terms, the forwarding path matters less than the credential and session controls attached to it, because those determine accountability and revocation.
• Rsync: Rsync is a synchronization tool that transfers only the differences between source and destination content. It is useful when files change incrementally, because it can reduce network usage and improve efficiency. The trade-off is higher local compute and disk activity during comparison and assembly.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. Explore the course if your role includes access governance, privileged credentials, or workload identity lifecycle control.