Not as a criticism. As a genuine question — and one worth sitting with for a moment, because the answer describes your access architecture more accurately than most assessments will.
You bought a modern access platform. It was deployed. It works. People are pleased with it.
And the VPN is still running.
What it is still there for
Ask which applications still require it and a list appears. It is never a long list, and it is never written down anywhere in full.
Thick clients. Something that expects a Kerberos ticket. An OT segment where the device initiates the session. A system a vendor supports on the condition that nothing about it changes. Possibly an acquisition that was never properly integrated and now never will be.
That list is the hard half of your estate. The new platform covered what it could cover, which was the applications that were easiest to cover — and that was a reasonable place to start, because it delivered value quickly and demonstrated the model worked.
Nobody did anything wrong. But the project that was supposed to retire the VPN did not retire the VPN.
So you added. You did not replace.
This is the point at which it stops being a procurement footnote and becomes an architecture problem.
You now run two access paths in parallel where you meant to run one. That is another internet-facing doorway on top of whatever was already exposed — another management plane, another set of credentials, another vulnerability stream, another thing to patch when an advisory lands on a Friday afternoon.
And it is worth being honest about the count. It is rarely two. Alongside the VPN and the new platform there are usually applications published directly to the internet, a remote-access route somebody set up for a supplier, an administrative interface that was only ever meant to be temporary. Every one of them is a doorway that has to be defended.
Both serve the same estate. Neither covers all of it.
The attack surface did not shrink. It grew — as the direct result of a project justified in part on shrinking it.
The business case nobody restated
Somewhere there is a paper that made the case for the new platform, and somewhere in that paper is an assumption that the VPN would be retired. License savings, perhaps. Reduced operational burden. One fewer thing exposed.
Nobody went back and revised it once the assumption turned out to be false.
That is not dishonesty. Nobody ever goes back. Projects are judged on whether they delivered what they said, and this one did — it just also left something behind that the case had assumed would go away.
The consequence is that the cost of the hard half has never actually been counted. It sits in the estate as a running expense and a standing exposure that no business case has ever had to justify.
And now the VPN is neglected as well as exposed
This is the part that should be uncomfortable.
Once a system is designated legacy and scheduled for removal, it stops attracting investment. The version upgrade is deferred — why upgrade something being retired next year. Access reviews slip, because the population using it is small and shrinking. Dormant accounts linger. The firmware is a version behind, then two. The engineer who understood it best moved to the team running the new platform.
Meanwhile it remains an internet-facing route onto your network.
A deprioritized front door is more dangerous than a maintained one. So the position is not simply that you failed to remove the VPN. It is that the VPN you still have is less well looked after than the VPN you had before the project started.
Why it is still there is the actual problem
The VPN persists for one reason: nothing available could front the awkward applications, so the old path had to stay for them.
That reason does not change by buying another platform with the same boundary. A second modern product, brokering access from outside your directory in the same way, produces the same outcome — another layer, another front door, and the same list left over at the end.
The list is the problem. Everything else is a symptom of the list.
What actually removes it
An enforcement point that can front the hard half.
Total Access Control terminates the session in front of the application, inside your environment — and it does that for the whole estate, not for a category of it. The SaaS and cloud applications your current platform already handles well, the internal web applications, and the ones that would not move.
Because it is inline — in the path of the transaction rather than alongside it, and operating within your identity environment rather than brokering from outside it — it can present the identity an application actually expects: a Kerberos ticket, an injected header, a session into an OT segment where the device initiates the connection. The awkward applications stop being awkward, because the thing in front of them speaks their language.
Where it runs is a separate question and a free one. Datacentre, private cloud, public cloud — that is a deployment decision to suit the estate. What matters architecturally is that it sits in the line between the user and the resource, for the whole session, rather than issuing a decision at the front door and stepping aside.
That distinction is the point. Something that fronted only the difficult applications would leave you with two platforms instead of one — which is the position you are already in, with better branding.
It goes in beside the VPN, not instead of it. One population moves — usually third parties or remote administrators, the group with the most risk and the least tolerance for a laptop rollout. Both paths run side by side. The next group moves once the first has become boring.
The VPN shrinks until it has nothing left to serve. At that point removing it is an administrative task rather than a project, which is the only way these things ever actually get removed.
Some estates keep one for a single purpose indefinitely, and that is a perfectly good outcome — provided it is a decision someone made rather than a residue nobody got around to clearing.
And the next one is already being sold to you
AI agents are arriving in production estates now. They act on behalf of people, they hold credentials, and they make requests against the same applications your staff use. A category of products is forming to govern them.
When one is put in front of you, the questions worth asking are the ones nobody asked about the platform that was supposed to reduce the number of doorways and instead added one:
- Does this make my life easier, or does it add another console to watch?
- Does it give me more control over access, or does it move some of that control somewhere else?
- Will people and agents be governed in one place, or in two?
- When this is deployed, what is left over — and who owns it?
None of those questions are about AI. They are the questions that should have been asked about the last platform, and the one before that.
The pattern is not the VPN. It is the assumption that covering part of the estate counts as progress.
So: why do you still have a VPN?
If the answer is a list of applications, that list is your architecture problem.
It is the thing to solve — not the VPN, and not with another platform that cannot reach the things keeping the VPN alive.