Blog · 6 min read
Supporting hybrid teams without routing everything through a VPN
Written for: IT teams supporting home workers, travelling staff and devices at client sites.
Written by the 247connect Marketing Team · Last reviewed 27 August 2026
Two paths
In short
A VPN grants network access to a person. Remote support needs device access for an operator, and using the first to deliver the second creates a dependency that breaks at the worst moments: when the tunnel will not start, when the device is not enrolled, or when the machine belongs to someone else. Brokered outbound support access sidesteps all three.
Key takeaways
- A VPN is designed for a person reaching applications, not for an operator reaching a device.
- VPN-dependent support fails at the exact moment the VPN itself is the fault being reported.
- Brokered outbound connections need no inbound port and no tunnel, so coverage extends to any network.
- On-demand agents handle devices you do not own or manage, then leave nothing behind.
- Keep the VPN for application access. Keep support access independent of it.
The circular dependency
The most common support call about a VPN is that the VPN will not connect. If your support tool rides inside that tunnel, you have designed a system that cannot help with its own most frequent fault. The same applies to a device that has never enrolled, a new starter's laptop, or a contractor's machine.
It is not an argument against VPNs. It is an argument against making one the prerequisite for reaching a device.
What brokered access does instead
The endpoint agent makes an outbound connection to a broker. The operator console does the same. The broker authenticates both and relays an encrypted session. Neither side listens for inbound traffic, so a home router, a hotel network and a client's guest wi-fi all behave identically.
Because nothing needs to be opened, support coverage stops being a negotiation with someone else's firewall - which matters enormously for MSPs working across many client networks.
- Home broadband behind consumer NAT: works, no configuration.
- Mobile tethering: works, subject to bandwidth.
- Client site with a restrictive firewall: works over outbound HTTPS-style egress.
- Devices you do not own: on-demand agent for a single session.
Where you still want the VPN
Line-of-business applications that only listen on an internal network, file shares, print servers and legacy systems all still justify a tunnel. Keep it, monitor it, and patch its concentrator promptly, because it remains an attractive target.
The change being argued for here is narrow: do not let support access inherit the VPN's failure modes.
The security trade you are actually making
Removing the tunnel from the support path does not remove controls; it relocates them. Identity moves to per-operator authentication with MFA, authorisation moves to scoped device groups, and evidence moves to session logs. That is a stronger position than a shared administrator account reachable once the tunnel is up.
Our secure remote access guide sets out the full control set, and the vendor security questions page gives you the list to put to any supplier.
Frequently asked questions
- Is outbound-only access less secure than a VPN?
- It is a different trade. A VPN authenticates a person onto a network; brokered access authenticates an operator to a specific device and logs the session. For support work the second gives finer control and better evidence.
- Will a restrictive corporate firewall block it?
- Rarely, because the agent uses ordinary outbound connections rather than inbound listeners. Egress filtering to a named destination is the usual configuration where a client insists.
- What about devices with no agent installed?
- Use an on-demand agent that the user runs for a single session and which leaves nothing installed afterwards.
How this works in 247connect
247connect is built exactly this way: outbound brokered connections with no inbound ports, AES-256 encryption in transit, managed agents for company devices and on-demand agents for everything else, so support coverage does not depend on a tunnel starting.
More from the blog
RMM automation quick wins
Small, safe automations that remove the most repeated work from a service desk: disk cleanup, service restarts, agent recovery, patch retries, reboot nudges and the reporting that proves they worked.
An IT toolkit for small teams
The order to buy IT tooling in when you are a team of one to five: asset visibility, patching, backup, remote support, monitoring, then documentation. What to skip until later.
Measuring the value of IT support
Translating support work into figures that survive a budget conversation: downtime avoided, tickets per technician, first-contact resolution, travel removed and the cost per endpoint you can defend.
Related across the hub
How-to
Support a user with no install
How on-demand, attended remote support works when you cannot install anything permanently: one-time session applications, consent, what the user sees, and when this approach is the right choice.
Best practice
Supporting off-premise devices
Company technology now lives outside the office: home workers, point-of-sale terminals, kiosks, waiting-room screens, ATMs and production machines. A guide to supporting it with anytime access, a zero-trust security posture and structured user training.
Best practice
Supporting remote workers
An evidence-based, vendor-neutral guide to IT support for remote and hybrid workforces — what peer-reviewed research finds about productivity, inclusivity and access, and the support practices that follow from it.
How-to
Support a home worker
Practical guidance for supporting staff at home: home network problems you cannot control, personal devices, VPN and connectivity faults, and the etiquette of working on someone's machine in their house.