A client's VPN was hacked last month. The attacker got valid credentials, connected to the VPN, and had full access to the internal network - including servers they had no business touching. The VPN treated them as a trusted insider.
This is the fundamental problem with traditional VPNs. They grant network access, not application access. ZTNA fixes this. Here's when to use each approach.
What is VPN?
VPN (Virtual Private Network) creates an encrypted tunnel between a remote device and the corporate network. Once connected, the device is 'inside' the network with broad access to resources.
IPsec VPN encrypts all traffic at the network layer. SSL VPN works through browsers and clients. Both have been the standard for remote access for 20+ years.
What is ZTNA?
ZTNA (Zero Trust Network Access) provides access to specific applications, not the entire network. Users authenticate, their device is verified, and they get access only to the applications they're authorized for.
Think of it this way: VPN is like giving someone a key to the entire building. ZTNA is like giving them a keycard that only opens the doors they need.
How They Compare
Security Model
VPN operates on a perimeter model: once you're past the VPN, you're trusted. ZTNA operates on zero trust: every access request is verified, regardless of location.
Impact: A compromised VPN credential gives the attacker network access. A compromised ZTNA credential gives access to one application.
Access Granularity
VPN grants network-level access. Users get an IP address and can reach any resource on the network (subject to firewall rules). ZTNA grants application-level access. Users can only reach specific, authorized applications.
Performance
VPN routes all traffic through the corporate network (full tunnel) or splits traffic (split tunnel). Either way, there's overhead. ZTNA connects users directly to cloud applications without backhauling through corporate infrastructure.
Result: ZTNA typically provides better performance for cloud applications.
User Experience
VPN requires client installation and periodic re-authentication. ZTNA can work through browsers with single sign-on. Modern ZTNA feels invisible to users.
Management Overhead
VPN: Manage the VPN concentrator, user accounts, and network-level access controls. ZTNA: Manage application-specific policies and user-device trust relationships.
When to Use VPN
1. Legacy applications that require network access. Some apps can't be proxied through ZTNA and need direct network connectivity.
2. Network-level troubleshooting. When IT needs full network access to diagnose issues.
3. Site-to-site connectivity. Connecting office networks together is still best done with IPsec VPN tunnels.
4. Budget constraints. VPN is simpler and cheaper to deploy than ZTNA.
When to Use ZTNA
1. Cloud-first organizations. If your apps are in SaaS, ZTNA provides better security and performance.
2. Zero Trust initiatives. ZTNA is a core component of Zero Trust architecture.
3. Contractor/vendor access. Give temporary, limited access without exposing the network.
4. BYOD environments. ZTNA verifies device posture before granting access.
Can You Use Both?
Yes, and we recommend it. Use ZTNA for cloud applications and contractor access. Use VPN for legacy apps and IT administration. FortiGate supports both through FortiClient (IPsec/SSL VPN) and FortiZTNA integration.
Best Practices
1. Start migrating to ZTNA for cloud applications. It's a quick win with better security and user experience.
2. Keep VPN for legacy applications that can't be proxied.
3. Enforce MFA on both VPN and ZTNA. This is non-negotiable.
4. Monitor access logs for both. VPN logs show who's connected to the network. ZTNA logs show who's accessing which applications.
Common Mistakes
Mistake 1: Thinking ZTNA replaces VPN entirely. It doesn't. VPN still has a role for network-level access.
Mistake 2: Deploying ZTNA without proper identity infrastructure. ZTNA needs strong identity verification (SSO + MFA) to work effectively.
Mistake 3: Ignoring legacy apps. Some applications will always need VPN access. Plan for hybrid deployment.
Conclusion
VPN and ZTNA aren't competitors - they're complementary. VPN handles network-level access; ZTNA handles application-level access. Start migrating cloud apps to ZTNA now, while keeping VPN for legacy systems. Both should have MFA enabled.
Want to go deeper? Explore [Protect security services](/en/products/protect), [industry solutions](/en/solutions), or [get a security assessment](/en/contact).
FAQ
Q: Is ZTNA more secure than VPN? A: Yes, for application access. ZTNA limits the blast radius of a compromised credential. But VPN is still necessary for network-level access.
Q: Can FortiGate do ZTNA? A: Yes. FortiGate supports ZTNA through FortiClient and FortiZTNA. You can define application-level access policies based on user identity and device posture.
Q: Do I need to replace my VPN with ZTNA? A: Not immediately. Migrate cloud applications to ZTNA first. Keep VPN for legacy apps and network administration.
Q: How does ZTNA handle device posture checks? A: FortiClient checks device compliance (OS patch level, antivirus status, disk encryption) before granting access. Non-compliant devices are quarantined.
Threat Landscape and Current Attack Vectors
Understanding the current threat landscape is essential for making informed security decisions. In 2025, the most common attack vectors include ransomware (up 150% from 2024), supply chain attacks (targeting software vendors and managed service providers), credential stuffing (exploiting password reuse across services), and zero-day exploits (targeting unpatched vulnerabilities).
According to the 2025 Verizon Data Breach Investigations Report, 68% of breaches involve a human element (phishing, stolen credentials, or errors). This means technology alone is not enough - you need people, processes, AND technology working together.
Implementation Roadmap
We recommend a phased approach to implementation. Phase 1 (Weeks 1-4): Assessment and design. Document current state, identify gaps, design target architecture. Phase 2 (Weeks 5-8): Deploy core components. Install and configure the primary solution in a test environment. Phase 3 (Weeks 9-12): Pilot testing. Deploy to 20-30% of users, collect feedback, refine configuration.
Phase 4 (Weeks 13-16): Full deployment. Roll out to remaining users with minimal disruption. Phase 5 (Weeks 17-20): Optimization. Fine-tune policies, optimize performance, and document procedures. This timeline works for most medium enterprises (200-500 users).
Compliance and Regulatory Considerations
If your organization is subject to regulatory requirements (PCI DSS, HIPAA, ISO 27001, GDPR), ensure your implementation addresses these requirements from the start. Retrofitting compliance is significantly more expensive than building it in. We recommend creating a compliance matrix that maps each regulatory requirement to specific technical controls.
Common compliance gaps we see: insufficient audit logging (PCI DSS requires 12 months of logs), missing encryption at rest (required by HIPAA and GDPR), inadequate access controls (required by ISO 27001), and missing incident response procedures (required by all frameworks).