What Is Zero Trust Security and Why Does Your Business Need It?
Zero Trust is a modern security architecture built on the principle of 'never trust, always verify.' Learn why it's becoming essential for every business.
TL;DR
- In June 2026, the FortiBleed leak exposed 73,932 Fortinet VPN credentials β CISA issued an urgent warning to all affected organisations.
- VPNs are structurally broken: once an attacker is in, they can reach everything. That is the lateral movement problem.
- Zero Trust Network Access (ZTNA) fixes this by granting access to individual applications, not the whole network β and SMBs can start migrating today.
In June 2026, a threat actor published a dataset containing 73,932 Fortinet FortiGate VPN credentials β usernames, passwords, and device configurations scraped from exposed management interfaces. Security researchers confirmed the data was authentic. CISA issued an urgent advisory urging all Fortinet customers to rotate credentials, audit access logs, and treat any historical VPN session as potentially compromised.
This was not a novel attack. It followed the same pattern as dozens of prior VPN incidents: a vulnerability in the VPN appliance itself, exploited before patches were applied, resulting in mass credential theft.
Palo Alto Networks issued its own warning around the same time, alerting customers to active exploitation of a critical flaw in PAN-OS GlobalProtect VPN. The same week, two of the world's most widely deployed enterprise VPN products were under simultaneous attack.
The message is clear: VPN infrastructure has become the single most reliable entry point for attackers targeting businesses of all sizes. If you run a VPN today β whether FortiGate, GlobalProtect, Cisco AnyConnect, or any other β you are managing a target, not just a tool.
VPNs were designed in the 1990s for a world where the corporate network was a castle, employees worked inside it, and remote workers occasionally needed a tunnel to get back in.
That world no longer exists. But the VPN model persists β and its core assumption is now a liability.
When a VPN user authenticates, they are granted access to the network. Not one application. Not one file server. The network. Depending on configuration, that can mean access to finance systems, HR records, production servers, backups, and internal tooling β all reachable from a single compromised session.
Attackers call this lateral movement. Once they have a valid VPN credential β whether stolen via FortiBleed, phished from an employee, or purchased on a dark-web marketplace β they can explore and exploit the internal network largely unchecked. Security teams often cannot distinguish a legitimate remote session from a malicious one until significant damage has already been done.
The FortiBleed incident is a perfect illustration: the attackers did not need to break encryption or exploit complex logic. They needed one thing β a valid credential. The VPN then handed them the keys to the building.
1. Patch lag is unavoidable at scale. VPN appliances require constant patching. Most SMBs do not have the internal capacity to monitor and apply patches within the critical window before active exploitation begins. The gap between vulnerability disclosure and patch deployment is where attackers live.
2. VPNs have no application-level visibility. A traditional VPN cannot tell you which applications a remote user accessed, for how long, or whether their behaviour was anomalous. It grants access and then becomes invisible.
3. Cloud and SaaS make VPNs irrelevant for most traffic. If your users spend most of their day in Microsoft 365, Google Workspace, a CRM, or a project management tool, routing that traffic through a VPN appliance adds latency without adding security. Most organisations end up with split-tunnel configurations that undermine the VPN's security value entirely.
Zero Trust Network Access (ZTNA) is the modern replacement for VPN. Rather than granting access to a network, ZTNA grants access to specific applications β and only after verifying the identity of the user, the security posture of their device, and the context of the request.
Here is a simple analogy. A VPN is like a master key to an office building: if you have it, you can open every door. ZTNA is like a visitor pass system: you are let into the specific room you need, for the specific time you need it, and you cannot wander anywhere else.
ZTNA operates on three core principles:
The practical result: even if an attacker steals valid credentials, they cannot reach your file server, your backup system, or your finance tools. They can only attempt to access whatever that specific credential was authorised to reach β and even then, device posture checks and behavioural analytics can block the attempt.
For a deeper grounding in Zero Trust principles, see our guide: What Is Zero Trust Security?
| Dimension | Traditional VPN | Zero Trust Network Access | |---|---|---| | Access model | Grants access to the entire network | Grants access to specific applications only | | Blast radius | High β one stolen credential exposes the full network | Low β breach is contained to authorised applications | | Visibility | Minimal β knows user connected, not what they did | High β per-session, per-application logging and analytics | | Cost | High total cost: hardware, licensing, patching, support overhead | Lower long-term cost; cloud-native options reduce appliance spend | | Complexity | High β appliance management, firmware cycles, split-tunnel headaches | Lower operational burden; policy managed centrally via software |
The cost comparison deserves a note. ZTNA solutions β including Cloudflare Access, Tailscale, Zscaler Private Access, and Microsoft Entra Private Access β are often subscription-based and require no on-premises hardware. For an SMB running a single FortiGate appliance, the switch frequently reduces both licensing costs and IT overhead over a three-year horizon.
Moving from VPN to ZTNA does not require a single disruptive cutover. A staged approach lets you migrate applications one by one while maintaining continuity.
Audit your current VPN access. Identify every application, server, and resource that remote users currently access via VPN. Map which users or roles need access to which resources. This inventory is the foundation of your ZTNA policy. Also audit your firewall rules β many SMBs discover overly permissive rules that should be tightened regardless of the migration.
Select a ZTNA platform and deploy the connector. Choose a ZTNA platform suited to your environment. Most SMBs start with either Cloudflare Access (strong free tier), Tailscale (excellent for developer and hybrid teams), or Microsoft Entra Private Access (if you are already Microsoft 365-centric). Deploy the lightweight connector on-premises or in your cloud environment β this is the bridge between your internal resources and the ZTNA edge.
Migrate applications in priority order. Begin with your highest-risk, most externally accessed applications β typically remote desktop access, internal web tools, and management consoles. Define access policies (who, from which device posture, under which conditions) before enabling each application. Test thoroughly before moving to the next.
Decommission the VPN. Once all applications have been migrated and users have operated on ZTNA for at least 30 days without issues, begin decommissioning VPN infrastructure. Revoke credentials, close firewall ports, and remove the appliance from your attack surface. Document the change and update your incident response playbooks.
The full migration for a 50-user SMB typically takes 60β90 days when planned properly.
At Lasetech, we define secure remote access as an architecture that assumes credentials will be stolen β and is built to contain the damage when they are. We have been advising Istanbul-based and international SMBs on Zero Trust migration since before it became a regulatory requirement, and we take a structured, risk-based approach that matches migration pace to your operational reality. We do not sell you a product; we build you a posture.
Q: Is ZTNA only for large enterprises? No. ZTNA solutions have matured significantly β Cloudflare Access and Tailscale both have SMB-friendly pricing and require no specialised hardware. A 10-person business can deploy ZTNA in under a day.
Q: Can we run VPN and ZTNA in parallel during migration? Yes, and this is the recommended approach. During the transition period, VPN handles traffic for applications not yet migrated to ZTNA. Parallel operation for 60β90 days is standard practice.
Q: Does ZTNA work with Microsoft 365 and other SaaS tools? ZTNA is primarily used for access to private, internally hosted applications β not SaaS tools like Microsoft 365, which have their own identity and access controls. However, ZTNA integrates with the same identity providers (Azure AD, Okta, Google Workspace) that govern your SaaS access, giving you a unified access policy.
Q: My VPN has not been breached yet β is this still urgent? Yes. Both the FortiBleed leak and the PAN-OS exploitation were widespread campaigns, not targeted attacks. If your VPN appliance has internet-exposed management interfaces β and most do β it is a potential target. The question is not whether you have been targeted; it is whether you will know when you are.
Ready to move your business off legacy VPN? Contact Lasetech for a free remote access security review.
This article was prepared by Lasetech.
Zero Trust is a modern security architecture built on the principle of 'never trust, always verify.' Learn why it's becoming essential for every business.
Modern ransomware gangs use "EDR killer" tools to blind your defenses before striking. Learn how the Gentlemen RaaS group operates and how SMBs can fight back.
MFA is no longer foolproof. Device code phishing has surged 37x in 2026. Learn how this attack works and what SMBs can do to stay protected.