Skip to content
ZERO-RISK100% replacement guarantee on every hire.See how we work
Back to blog
MANAGED SASE6 MIN READ

Is your VPN setup quietly putting you at risk?

A VPN feels safe. It has been around for a long time. It has a login. It encrypts traffic. For many companies it is the main way remote staff reach internal systems. That familiarity is exactly why it deserves a careful look.

SHAREinX
Is your VPN setup quietly putting you at risk? illustration

A VPN feels safe. It has been around for a long time. It has a login. It encrypts traffic. For many companies it is the main way remote staff reach internal systems. That familiarity is exactly why it deserves a careful look.

The thesis: a VPN setup can quietly put you at risk, usually through five weaknesses that build up over time. None of them is dramatic on its own. Together they explain why zero-trust access, which gives each user access only to the apps they need, is replacing the VPN for many organisations.

1. Broad network access

A traditional VPN puts the user on the internal network. Once connected, they can often reach far more than they need: file servers, admin consoles, databases. If an attacker steals one set of credentials, they get the same broad reach.

That is the central problem. VPNs authenticate the person at the door, then trust them inside.

Fix: move to access that is per application. A user who needs the HR system gets the HR system. Nothing else is visible to them.

2. Unpatched appliances

VPN devices sit on the edge of your network, reachable from the internet. That makes them a favourite target. Flaws in such devices are found regularly, and attackers act on them fast. The risk is highest when the device is old, out of support or patched late because patching means downtime.

Fix: keep a list of every VPN and edge appliance with its software version and support status. Set a patch window and stick to it. Where you can, retire the appliance and move access to a cloud service that the provider patches for you.

3. Shared or stale accounts

VPN accounts have a habit of outliving their owners. A contractor finishes a project, the account stays. A team shares one login for a supplier. A former employee's credentials still work. Nobody notices until something goes wrong.

Fix: tie VPN access to your identity system. Require multi-factor authentication. Remove accounts when people leave, automatically if you can. End shared logins, and set an end date on contractor access.

4. Little visibility into what users do after connecting

Once a user is inside the tunnel, many VPNs show you only that they connected. You may not know which systems they touched, how much data they pulled or whether their behaviour changed. If an incident occurs, reconstructing events is slow and incomplete.

Fix: log access by user and application. Send logs to a place where someone looks at them. Alert on unusual patterns, such as access at odd hours or a sudden bulk download.

5. Poor performance that pushes users to bypass it

When the VPN is slow, people start finding workarounds. They disconnect to join video calls. They email files to personal accounts. They use unapproved tools. Each workaround is a hole in your controls, created by a tool that was meant to protect you.

Fix: measure the user experience. Send internet and cloud traffic directly through a secured cloud gateway, not back through head office. Keep the private tunnel for what really needs it, and then replace that with application-level access.

How to check your own setup

Ask these six questions this week:

  • If one user's login were stolen, what could the attacker reach?
  • When were our VPN devices last patched, and are they still supported?
  • How many VPN accounts belong to people who have left or finished a contract?
  • Can we see which applications a user accessed during a session?
  • Do we use multi-factor authentication for every VPN user?
  • Are people bypassing the VPN, and why?

If you struggle to answer two or more, you have found your starting point.

What zero-trust access looks like for users

For the user, the change is mostly good news. They sign in with their normal identity, and the apps they use appear. There is no manual tunnel to start, and no waiting while video traffic bounces through head office. Apps they should not use are simply not visible.

For the administrator, the change is more work at first and less afterwards. You must define who needs what. That exercise is useful in itself, because it often shows access nobody can justify. Start with groups by role, not individuals, and keep exceptions few and dated.

Reducing the blast radius today

If you cannot change platforms soon, you can still limit damage. Segment the internal network so a VPN user does not land on a flat network. Restrict VPN access by group. Require MFA and block legacy sign-in methods. Turn on logging and send it to a place someone watches. Set session limits and review the unusual ones. None of this replaces a better model, but each step shrinks what a stolen login can reach.

A worked example

Suppose a contractor finishes a project but keeps a VPN account for months. Their laptop is not managed, and a family member uses it. Malware steals the saved credentials. An attacker signs in from another country at night. The VPN allows it, because the password is right and nobody has asked for a second factor. Once inside the network, the attacker scans for file servers and finds a share with wide permissions. By morning, data has left.

Every link in that chain is ordinary. Remove any one of them and the story changes. An expiry date on the contractor account stops it. MFA stops the sign-in. Device checks block the unmanaged laptop. Per-app access hides the file server. Alerts on a sign-in from a new country would at least raise a flag. That is why layered fixes beat any single product.

Why the old habits persist

VPNs persist because they work well enough and everyone knows them. Replacing one feels like risk with no visible reward. The reward is real, though: fewer tickets, fewer standing exposures and a clearer view of access. Frame the change that way when you ask for budget. Show the number of stale accounts, the age of the devices and the tickets caused by slow connections. Concrete local facts persuade better than general warnings.

Also ask who can see the logs today. A log that nobody reads is a record of an incident, not a defence against one.

Common mistakes

  • Adding more VPN capacity to fix performance instead of changing the traffic path.
  • Treating multi-factor authentication as the only fix. It does not address broad access.
  • Switching off the VPN before checking which systems depend on it.
  • Moving to zero trust but copying "allow all" rules into the new policy.
  • Forgetting third-party and contractor access.

What to do next

Start with an inventory of VPN users, devices and what they reach. Clean up stale accounts. Patch or plan to retire old appliances. Then choose one group of users and one set of apps to move to application-level access as a pilot.

Brandsmashers assesses VPN setups and migrates companies to managed zero-trust access. If you would like a clear view of where your own setup stands, a short scoping call is a good place to start.

SHARE THIS ARTICLEinX

NEXT STEP

Need help with this?

KEEP READING

More insights.

ALL ARTICLES