For most remote access programs, the best answer is no longer “one VPN for everyone,” but a mix of segmented VPN access, ZTNA for user apps, and microsegmentation for server-to-server control. A traditional VPN can still work well, but only if it is split into tight zones with clear rules. If every remote user lands on the same internal network, a stolen laptop or reused password can turn into a very expensive afternoon.
TLDR: VPN segmentation limits what remote users can reach after they connect, while ZTNA checks identity, device health, and app access before each session. For example, a finance contractor may get access only to one payroll app, not the full finance subnet. In many mid-sized firms, moving from flat VPN access to segmented access can cut reachable internal systems by 70% to 90%. ZTNA and microsegmentation go further, but they require cleaner identity data and better operational discipline.
What VPN network segmentation actually does
VPN network segmentation means remote users do not all enter the same trusted zone. Instead, they are placed into separate network areas based on role, device type, risk, or business need. A developer might reach Git, CI tools, and test databases. A call center agent might reach a ticketing app and VoIP service. A third-party vendor might reach one jump host and nothing else.
This sounds obvious. Yet plenty of companies still run remote access like a hotel lobby: once you are in, you can walk around far too much. Honestly, it feels like many VPN setups were built during an emergency and then quietly became permanent.
Segmentation usually relies on:
- Separate VPN pools for employees, admins, contractors, and vendors.
- Firewall rules that restrict traffic between VPN users and internal systems.
- Network access control to check device posture before assigning access.
- Identity groups from directories such as Active Directory or cloud identity platforms.
- Logging and alerting to catch odd access patterns.
The goal is simple: connect users to what they need, not to the whole network.
VPN segmentation vs ZTNA
Zero Trust Network Access, or ZTNA, takes a different approach. Instead of placing a user onto the network, it grants access to specific applications. The user often never gets broad network connectivity. That matters a lot.
With a segmented VPN, a user may still receive an IP address inside a restricted network zone. With ZTNA, the access broker checks the user, device, location, risk score, and application request. Then it allows or blocks that specific session.
Here is the practical difference:
- Segmented VPN: “You are in the contractor VPN zone. You may reach these IP ranges and ports.”
- ZTNA: “You are this contractor, on this managed laptop, requesting this app, at this time. Approved.”
ZTNA usually gives stronger control for web apps, SaaS tools, and private applications that can sit behind an access proxy. It also reduces the risk of malware scanning internal networks after a compromised VPN login.
The catch is that ZTNA is not magic. Older thick-client apps, admin tools, file shares, and odd legacy systems can be painful to integrate. Expect to waste time on exceptions. Some tools add 5 to 10 extra seconds to login flows when device checks, browser redirects, and MFA prompts stack up. Users will complain if the rollout is clumsy.
Where microsegmentation fits
Microsegmentation controls traffic at a much finer level. It focuses on workloads, servers, containers, and sometimes endpoints. Instead of trusting traffic because it is “inside,” microsegmentation asks whether this system should speak to that system at all.
Think of it this way:
- VPN segmentation controls the remote entry point.
- ZTNA controls user-to-application access.
- Microsegmentation controls system-to-system communication.
If ransomware reaches one virtual machine, microsegmentation can stop it from spreading to database servers, domain controllers, or backup systems. That is its real value. It contains damage after something goes wrong, because something eventually will.
When segmented VPN still makes sense
VPNs are not dead. The “VPN is obsolete” line is too neat and often wrong. A segmented VPN can still be the right choice when users need broad protocol support, admin access, or connectivity to legacy systems that were never built for modern access brokers.
Segmented VPN works well for:
- IT administrators who need SSH, RDP, database tools, and management consoles.
- Engineers who access dev environments, repositories, and build systems.
- Industrial systems where remote access must pass through strict jump points.
- Mergers and temporary projects where speed matters, but risk still needs limits.
The key is to avoid the lazy version. Do not create one “remote users” group with access to half the company. Build separate zones. Review them every quarter. Remove stale users fast. It drives me crazy when vendor accounts survive for six months after the contract ends, still sitting inside a production VPN group.
When ZTNA is the better option
ZTNA should be high on the list when most remote work centers on applications rather than raw network access. It is especially useful for distributed teams, BYOD policies, and cloud-heavy environments.
ZTNA is a strong fit for:
- Private web apps used by sales, HR, support, or finance teams.
- Contractor access where each person needs one or two specific systems.
- Managed and unmanaged devices with different access rules.
- Risk-based access tied to MFA, location, device posture, and identity signals.
For example, a healthcare provider might allow remote staff to access a scheduling portal through ZTNA, while blocking direct access to the patient database subnet. If a password is stolen, the attacker still needs device checks, MFA, and app-level approval. That does not make the provider invincible. It does shrink the blast radius.
When microsegmentation should come first
Microsegmentation should move up the priority list when the biggest risk is internal spread. This is common in data centers, hybrid cloud setups, and environments with sensitive workloads.
It helps answer questions like:
- Should this web server talk to every database?
- Should a printer ever connect to a domain controller?
- Should a test server reach production payment systems?
- Should backup infrastructure accept traffic from regular user devices?
In many networks, the honest answer is “no,” but the firewall rules say “yes” because nobody cleaned them up. Microsegmentation forces clarity. It maps traffic, builds policies, and blocks needless paths. The first policy review can be awkward. Teams often discover forgotten services, mystery connections, and servers nobody wants to own.
A practical comparison
- Security strength: ZTNA and microsegmentation usually beat basic VPN segmentation. A well-built segmented VPN is still far better than a flat VPN.
- User experience: ZTNA can feel smoother for app access. VPNs may work better for technical users who need multiple tools.
- Legacy support: VPNs win. ZTNA may need proxies, connectors, or workarounds.
- Operational effort: Microsegmentation often takes the most planning. Poor asset data will slow the project.
- Speed of deployment: VPN segmentation can be improved quickly if firewall and identity groups are already usable.
Best practice: use them together
The strongest design is usually layered. Use ZTNA for common business apps. Use segmented VPN for technical and legacy access. Use microsegmentation to restrict movement between internal workloads.
A sane rollout might look like this:
- Map remote access use cases. List who needs what, and why.
- Split VPN users into role-based groups. Start with employees, admins, vendors, and contractors.
- Move simple private apps to ZTNA. Prioritize apps with external users or sensitive data.
- Apply microsegmentation to crown jewels. Protect identity systems, databases, backups, and production workloads first.
- Measure access reduction. Track how many systems each role can reach before and after the change.
Metrics keep the work honest. If a vendor previously reached 400 internal hosts and now reaches 3, that is progress people can understand. If admin VPN users still reach every subnet, the project is not finished.
The bottom line
VPN segmentation is a control, not a strategy by itself. It reduces risk, but it still grants network access. ZTNA gives tighter user-to-app control. Microsegmentation limits damage inside the environment. The right choice depends on your apps, users, devices, and tolerance for messy legacy systems.
If you need a starting point, fix the flat VPN first. Then move suitable apps to ZTNA. After that, use microsegmentation to protect the systems attackers would target next. That path is practical, measurable, and much safer than pretending one remote access tool can solve every problem.
