Remote access usually starts as a quick way to get people working from home, then never gets looked at again. We set up or replace it so staff sign in with MFA and reach the systems their job needs, and nothing else.
The “scoped by group” version is what gets written down as the client’s access policy.
Where remote access tends to go wrong
None of these stop people working, which is why they last. They show up when a password is phished, a staff member leaves on bad terms, or a contractor’s laptop is compromised.
The VPN lands on the whole network
One rule from the VPN range to the office LAN. A single stolen login then reaches every server, the backup console and the firewall’s own admin page.
Logins that don’t follow the person
Local accounts on the firewall, or one shared account, separate from the directory. Disable someone when they leave and their VPN still works.
MFA everywhere except the front door
MFA on email but not on the VPN, or only a text-message code. The VPN is the one sign-in that puts someone inside the network, so it needs the strongest check available.
A port forward nobody remembers
Remote desktop or a storage device’s admin page published straight to the internet “just for now”, years ago. It sits beside the new VPN, bypassing it.
A portal left behind on updates
A VPN portal faces the internet by design, and firewall VPN portals are a regular target for attackers. Old firmware on it is a risk in its own right, whatever the rules behind it say.
The office uses the same addresses as home
An office on 192.168.1.0/24, the same range many home routers hand out. The tunnel connects, the user is told they’re on, and nothing opens.
Contractors with access that never ends
The software vendor’s support login works every day of the year, from anywhere, to everything, long after the last job they did.
VPN or zero-trust: which suits this client
The right one depends on where the client’s systems live, what their software expects, and who needs to get in. We’ll tell you which we’d recommend and why before anything is built.
VPN with MFA
Staff connect into the office network through the firewall. Firewall rules then decide which systems each group can reach.
Fits when
The client already runs a capable firewall and the systems that matter sit behind it, in one office or data centre.
Software expects to be on the network: mapped drives, or a desktop app that talks straight to its database.
Most people need the same handful of systems, so a few group rules cover everyone.
The portal faces the internet, so its MFA, its firmware and the rules behind it matter more than anything else on that firewall.
Zero-trust network access
Staff never join the network. Each sign-in is checked, then connected only to the applications that person’s group is allowed. Everything else stays out of sight.
Fits when
Systems are spread across offices and cloud, and a single VPN back to head office no longer makes sense.
Contractors and vendors need narrow access to one system, ideally only for as long as the job lasts.
The client wants the device checked as well as the person, or wants to stop publishing a VPN portal at all.
Older software that uses many ports or finds its server by broadcast can need extra care, so those apps go into the pilot first.
Where the client’s firewall already does this well, we build on it rather than add another product. The firewalls we work with come from Fortinet, Palo Alto Networks, Cisco, Meraki, SonicWall, WatchGuard, Sophos, Check Point, Juniper and Huawei. Whether a given firewall is the right place for the client’s remote access, or a separate zero-trust platform is, is part of the recommendation.
The details users notice every day
Remote access complaints tend to come from a handful of settings, so these get decided and written down for every client.
Sign-in through the identity provider
Where the platform supports it, sign-in goes through the client’s identity provider, often Microsoft Entra ID. MFA, sign-in policies and leavers are then handled in one place, not a second list on the firewall.
Groups, not people
Access follows directory groups. A new starter in finance gets what finance gets by joining the group, with no firewall change and no one-off exceptions to forget later.
Split or full tunnel, on purpose
Split tunnelling keeps video calls and general browsing off the office link. Full tunnelling sends everything through the firewall for inspection. Either can be right; the choice and the reason get written down.
Internal names that resolve
The file share and the app server answer to the same names at home as in the office, so shortcuts, mapped drives and saved settings keep working.
Address ranges that can’t collide
The remote access pool, and where needed the office ranges it reaches, are chosen so they don’t overlap the networks people are sitting on at home or in a hotel.
Software that arrives ready
The client software is pushed to devices with the connection already set up. Staff sign in; nobody types a server address or imports a profile from an email.
The changeover
The old way and the new way run side by side until the logs show the old one is unused. Then it’s removed.
Old method
New access
1
Pilot
A few people from different groups go first: someone in finance, someone in the field, and whoever uses the awkward app. Nothing changes for anyone else.
2
Move everyone across
Groups move over with the software already installed and set up. The old method still works as a fallback while people settle in.
3
Prove the old path is quiet
Logs show who still connects the old way, and to what. Each one is tracked down, whether it’s a saved shortcut or a vendor’s bookmark, before anything is switched off.
4
Retire it
Port forwards removed, the old portal turned off, local VPN accounts deleted and old profiles taken off devices. Nothing is left switched off but still configured.
What the client is left with
Remote access in place
One sign-in with MFA, the client software on every device that needs it, and internal systems reachable by the names people already use.
Documented access policies
The group-by-system table from the top of this page, filled in for the client, with the reason for each line. When someone asks “can the bookkeeper get into payroll from home?”, there’s a place to look and a place to record the answer.
As-built documentation
What was configured and why: the platform settings, the identity connection, tunnel and name resolution choices, and how the client software was deployed. Enough for your team to support it from day one.
