Secure Remote Access for Employees: VPN vs ZTNA in Practice

The ₹8.4 lakh lesson a 90-person firm learned in one Tuesday morning

In March 2025, a Bengaluru engineering firm with about 90 staff on Sarjapur Road learned what "always-on VPN" actually costs. Their FortiGate 100F had a 200-tunnel licence. They had 74 people connecting every morning at 9:15. The firewall's SSL-VPN was configured in full-tunnel mode, meaning every packet, including a YouTube stream and an Office 365 sync, went through the office.

Their leased line was a 200 Mbps 1:1 from a Tier-2 ISP. At 9:20 every weekday, that line saturated. Latency on their cloud ERP, hosted in Mumbai, went from 30ms to 900ms. The AP/AR team could not post invoices. On the Tuesday in question, a 40-minute outage during a client audit cost them a contract renewal worth approximately ₹8.4 lakh in annual recurring revenue. The fix was not a bigger pipe. It was split tunnelling plus routing Microsoft 365 and their ERP SaaS traffic straight out of the local internet, which took an afternoon and one firewall policy change.

That is the shape of this problem. Secure remote access for employees is not a product you buy once. It is a set of decisions about what traffic goes where, what device is allowed to connect, and how much trust you extend by default. Get those wrong and you pay in either money, productivity, or a breach.

This piece covers the four decisions that actually matter in an Indian SME context in 2026: VPN or ZTNA, device posture checks, split tunnelling, and contractor access. Then it covers the hard part — how to retire an always-on VPN without locking out 200 people on a Monday.

First, the number that should change your thinking

If you are still sizing your VPN concentrator for "50% concurrent remote users," your model is three years out of date. In the 200-500 seat deployments we manage around Bangalore, the concurrent remote ratio on a typical Wednesday is now 38-55%, and on a Friday it can touch 65%. Monday is the lowest, because people come in.

The IT team at one Whitefield client tracked this properly for eight weeks in 2025. Peak concurrent SSL-VPN sessions on their FortiGate 90G: 132 out of 240 staff, at 10:40 AM. Their licence was 100 tunnels. People were getting "session limit reached" errors and calling the helpdesk.

The old fix — buy 250 SSL-VPN licences — would have cost them roughly ₹3.2 lakh in SKU uplift. The new fix, a ZTNA broker in front of the same 240 seats, cost more (see the pricing table below) but gave them per-app access control and eliminated the tunnel bottleneck entirely, because ZTNA does not tunnel.

That is the fork in the road. Let's price it properly.

VPN vs ZTNA: the honest 2026 comparison

Both are legitimate ways to give remote employees access to internal resources. They work differently and they solve different problems.

VPN gives you a tunnel. Once you are inside the tunnel, you are on the network, and network access maps to broad reachability. An SSL-VPN user on a FortiGate or a SonicWall can typically ping the entire 10.x.x.x range, reach every internal server not firewalled from the VPN subnet, and print to office printers. It is flat, it is simple, and it is the reason ransomware that lands on a remote laptop reaches the file server at 2 AM.

ZTNA gives you per-application access after a policy decision. The user authenticates to a broker. The broker checks the device posture and identity, then connects the user to exactly one application on one hostname. The user cannot see the network, only the app. Products that do this well in an Indian mid-market context: Cloudflare Zero Trust, Zscaler Private Access, Palo Alto Prisma Access, Fortinet's own ZTNA (built into FortiOS 7.4+ on your existing FortiGate), and for smaller shops Twingate or Tailscale.

Here is the comparison that matters when you are the person signing the PO.

The pricing above is real for 2026, based on quotes we have run for Bangalore clients. Note the shape of it: VPN is cheaper up front and more expensive in admin time. ZTNA is more expensive up front and cheaper in admin time, and it is dramatically better on breach containment.

Where VPN is still the right answer

We install and maintain plenty of SSL-VPN deployments and will continue to. They make sense when:

• Your remote user count is under 80 and likely to stay there.
• You already own a capable firewall (FortiGate 60F/90G, SonicWall TZ series, Sophos XGS) with unused tunnel licences.
• Your internal applications are mostly file shares and an on-prem ERP, and there is no cloud presence.
• You do not have an identity provider running conditional access, and building one is a six-month project you do not want.

The trade-off we tell clients honestly: VPN concentrates your risk on the perimeter. If the firewall is patched, the MFA is enforced, and the internal network is segmented, VPN is not the disaster it is made out to be. Fortinet's CVE-2024-55591 and the earlier CVE-2018-13379 SSL-VPN bugs were ugly, but they were exploitable primarily because appliances were publicly exposed and unpatched. Patch cadence matters more than architecture choice for the first round of defence.

Where VPN stops making sense

It stops making sense when:

• You are running more than 80-100 remote users on hardware licensed for fewer tunnels.
• Your contractors (support, AMC vendors, freelance developers) need access and you are provisioning them AD accounts with network reachability. That is where incidents come from.
• You have DPDP Act obligations to demonstrate data access controls. VPN network access is difficult to evidence.
• Your users are hitting SaaS more than internal apps. Full-tunnel VPN sending Office 365 traffic through your office is a productivity tax you are choosing to pay.

If you are in the middle — 100-150 remote staff, mixed on-prem and cloud — Fortinet's ZTNA on your existing FortiGate is the most economical upgrade path we have deployed in the last 18 months. You do not throw away the hardware. You add FortiClient EMS and configure ZTNA rules against the same appliance. A 120-user deployment typically lands at ₹2.4 lakh-₹3.8 lakh (2026) all-in, versus ₹8 lakh+ for a SaaS ZTNA suite.

Device posture checks: the part everyone skips

It is 2026. Someone in your finance team is going to open a link on a personal Windows 10 laptop that has not been patched since 2023 and has a cracked copy of an old antivirus. If that person can reach your Tally server, you have a problem.

Device posture checks are how you stop that. Both modern VPN clients and ZTNA brokers support them. FortiClient, for example, can check OS version, patch level, disk encryption status, antivirus presence, domain join status, and whether the firewall is running before allowing a tunnel or app session.

What to actually check

Go minimal. A posture policy with 15 rules will fail half your legitimate users and your helpdesk will quietly disable it. Five checks are enough for most SMEs:

1. OS version — Windows 11 23H2 or later; macOS 14 Sonoma or later. Block Windows 10 from March 2026 onward (EOL October 2025).
2. Disk encryption — BitLocker enabled or FileVault on. No exceptions. This is the single most important check.
3. EDR/antivirus running — not just installed. Running, with current signatures.
4. Patch currency — critical patches within 14 days. You rarely check this directly; you check the EDR agent's compliance status.
5. Screen lock — a 10-minute idle lock, enforced via Intune or GPO.

Skip the firewall check. Skip the domain-join check if you have any Macs. Skip anything requiring a custom script — it will break.

The compliance problem you will hit

Around 1 in 5 users will fail posture on day one. Their laptop needs a BitLocker key and an admin has to enable it. That is not a technical problem; it is a logistics problem. Build a two-week rollout window where posture enforcement is in "monitor" mode, an email goes out listing failed checks, and IT has the bandwidth to remediate.

One Indiranagar client — 140 staff, mixed Windows and Mac — ran posture enforcement in blocking mode immediately. By 11 AM on day one, 31 users were locked out, including two of the founders. We had to flip it back to monitor mode within the hour. The lesson cost them a morning and gave IT a reputation hit with the CEO. Do the two-week window.

If you are deploying Intune or a similar MDM to enforce posture, this is the kind of work our end computing practice handles as a project rather than a one-off.

Split tunnelling: how to do it without breaking your ERP

The default in most firewall templates is full tunnel. Every packet from a remote laptop goes through the office firewall. That is what caused the ₹8.4 lakh outage above.

Split tunnelling routes only specific destinations through the tunnel and lets everything else go direct to the internet. Your SaaS apps (Microsoft 365, Zoho, Salesforce, Slack, Google Workspace, all the browser tabs your staff have open) route over the local internet. Only the on-prem file server, ERP, Tally, and the print server go through the office.

The routing table that works for a typical Indian SME

Compliance pitfalls

If you have DPDP Act obligations on personal data (customer KYC, employee records, health data for HR portals), split tunnelling needs a data-flow conversation with your DPO or legal advisor. When data leaves the office and hits a home broadband line, you have extended your processing boundary. Most Indian SMEs handle this by requiring company-managed laptops and BitLocker for any split-tunnel-enabled user, which is a reasonable control.

Also watch DNS. Split DNS resolves internal hostnames to internal IPs and public hostnames to public IPs. If you point a split-tunnel client at internal DNS but do not configure the search suffix correctly, name resolution breaks intermittently and users complain about "slow file server" when the real issue is DNS fallback. Test on one user for a week before rolling out.

Contractor access: where the real breach risk lives

Here is where most Indian SME setups fall apart. A vendor's engineer needs to look at your ERP for two weeks. You create an AD account, add them to the VPN group, and give them a laptop from your spares. They use a personal laptop instead. They forget to remove the account. Six months later the account is still active because nobody audits.

We have audited this specific problem for clients. The median number of dangling contractor VPN accounts in a 200-seat firm is 7. That is 7 users with broad network reachability and no business reason to exist.

The right way to onboard a contractor

1. No AD account. Contractors get access to one application and one application only.
2. ZTNA broker session only. No IPsec or SSL-VPN account. The broker handles the access, and it can expire.
3. Time-bound policy. Set the session policy to expire in 14, 30, or 60 days. Fortinet ZTNA and Cloudflare Zero Trust both support this natively.
4. MFA mandatory. No SMS if you can avoid it. TOTP minimum; FIDO2 if the vendor supports it.
5. Session recording for high-risk access (finance, HR, PII). Zscaler ZPA and Cloudflare both support session replay; Fortinet needs a separate CASB/FortiGate recording setup.
6. Kill switch on day 1 of the expiry date. Not end of day. Beginning of day.

If you are hiring contractors and letting them use whatever laptop they own, you need to think about device posture without a corporate device to posture. The answer is a managed VDI environment or an application proxy (e.g. using a browser-based ZTNA session that never runs on the local machine), not posture on a laptop you do not control.

The trade-off on SaaS ZTNA for Indian contractors

Cloudflare Zero Trust and Zscaler ZPA are excellent products. They are also priced per-seat (typically USD 6-10/seat/month for ZPA, Cloudflare from ~USD 7/seat/month for the paid tier) which for a 40-hour contractor is fine but for a five-person vendor team that logs in 4 hours a month is ₹25,000-₹40,000/year you are paying for access that mostly does not happen. For contractor-heavy usage, Fortinet ZTNA on hardware you already own, or Twingate at USD 5/user/month, is usually the better economic fit.

If you are setting up a repeatable contractor onboarding process and want it to survive staff turnover, our team at SynergyScape's end computing practice builds these as packaged workflows.

Retiring always-on VPN without an outage

This is the part the vendor whitepapers skip. You have 180 people on SSL-VPN. You have bought ZTNA. Now what?

We have run this migration four times in Bangalore in the last two years. The one that failed took eleven weeks and generated 340 helpdesk tickets. The one that succeeded took five weeks and generated 47. The difference was sequencing, not technology.

The five-week sequence that works

Week 1: Discovery. Inventory every VPN user. Export the SSL-VPN session list, the AD VPN group members, and last-login timestamps. Sort descending by last-login. That bottom 20% (people who have not connected in 30 days) get a courtesy email and their access is set to expire in six weeks. Do not cut them off yet.

Week 2: Pilot group. Pick 15 users from AP/AR, sales, and one or two executives. Move them off VPN and onto ZTNA. Give them a 30-minute walkthrough. Take their calls personally. You are looking for the two or three things that will break — usually a print server, an old internal website that requires an IP address, or an ERP client that does not want to connect to a hostname. Fix these before the next wave.

Week 3: First real wave (40-60 users). Sales and finance first. These are the users who complain loudest, so you want them early — no, wait, you want them early so the loud complaints surface while you can still fix them. By end of week 3 you should have real usage data on ZTNA session counts, posture failures, and any latency complaints.

Week 4: Second wave (remaining 100-120 users). All operations and support staff. Send daily emails: "If you use VPN, switch to ZTNA by Friday." Give them one override path — client software installer plus a phone number — for the ones who cannot work it out.

Week 5: Lockdown. SSL-VPN is still technically enabled but only accessible to a named allowlist (the ~15 users who you legitimately need to keep on it — often legacy application owners). Everyone else gets redirected to ZTNA. After 90 days, remove the allowlist and turn off SSL-VPN entirely.

The failure story, in detail

A 320-seat firm in Whitefield ran the migration in 2024 without a pilot. They flipped ZTNA on and VPN off in one Friday-evening change. Over the weekend nobody noticed. On Monday morning, four things broke:

1. The Tally server was reached by IP (192.168.10.14) by a custom in-house application. ZTNA issued a hostname, and the app did not resolve hostnames. Nobody had tested this because it was only used by 3 people in finance.
2. A printer used by the HR team at home required an IP address. ZTNA did not pass IP-level routing, and the HR head could not print offer letters during a hiring week.
3. SAP B1 client (used by 14 users in accounts) needed a route to the SQL server on 1433/TCP. Their ZTNA policy only opened 30015/TCP for the SAP client. The 14 users took 40 hours between them to resolve.
4. Two Mac users did not have FortiClient installed and their self-service portal did not have the Mac installer.

Total cost: 340 tickets over eleven days, approximately 90 hours of IT overtime (~₹65,000 in personnel time), a missed payroll filing that added a small late fee, and a CFO who now wants to review every IT change for six months.

Every one of the four issues would have surfaced in a 15-user pilot. That is the entire lesson.

What this actually costs in Bangalore, 2026

For a 200-user deployment with a mix of on-prem and cloud, here is the honest range we see in quoted and delivered projects.

For a 100-user mid-market deployment, budget roughly ₹3.5 lakh-₹6.5 lakh one-time plus ₹22,000-₹42,000/month for ongoing managed support, if you go the Fortinet-on-owned-hardware route. Add roughly ₹5 lakh-₹9 lakh/year in SaaS ZTNA licensing if you go Cloudflare or Zscaler. Both are complete solutions; the SaaS route is a clean Opex and the Fortinet route is a smaller cash outflow.

Note: prices above are exclusive of 18% GST. If you are on a composite AMC-plus-licence structure, the licence portion is typically invoiced as a supply of services (18% GST), and hardware as goods (18% GST too, so no difference there). No special treatment applies for ZTNA or VPN licensing in India.

Frequently asked questions

Is a VPN still secure enough for remote work in 2026?

Yes, if — and this is the whole sentence — it is patched monthly, MFA is enforced for every user with no exceptions, split tunnelling is configured so SaaS traffic does not go through the office, and the internal network is segmented so a compromised laptop cannot reach the file server. A well-run FortiGate SSL-VPN with those four things is more secure than a poorly configured ZTNA. Reverse the conditions and the reverse is true.

Do I need ZTNA if I already have Microsoft 365 and Entra ID?

You need something that gets your users to on-prem resources. If your only internal resources are file shares and a legacy ERP, and you can move them behind Entra Private Access, that can serve as a lightweight ZTNA for a small deployment. If you have Tally, SAP B1, custom applications, and on-prem AD, you want a proper broker — Fortinet ZTNA or Cloudflare Zero Trust are the practical picks.

How much does ZTNA cost for 100 users in India in 2026?

Fortinet ZTNA on owned hardware: roughly ₹1.8 lakh-₹3.5 lakh in licensing plus the hardware you already own. Cloudflare Zero Trust or Zscaler ZPA: roughly ₹5.5 lakh-₹11 lakh per year at 100 seats. Setup and implementation is separate: ₹1.6 lakh-₹3.2 lakh for a 100-user cutover with pilot, migration, and documentation.

Can I keep using my firewall vendor's VPN and add ZTNA later?

Yes — that is the migration path we recommend most often. Fortinet, SonicWall, Palo Alto, and Sophos all support some form of ZTNA or application access control on their current-generation firewalls. Add ZTNA, run it in parallel with VPN for 4-6 weeks, move users across in waves, then retire VPN. You do not have to choose one architecture at the start; you have to have a plan for retiring one.

What is split tunnelling and is it safe for compliance?

Split tunnelling sends only specific destinations (your internal servers) through the office tunnel and lets everything else (SaaS, web) go direct to the internet. It is safe if users are on managed, encrypted, EDR-protected laptops, and if you have a written policy about what data can be accessed from remote devices. For DPDP Act purposes, document the control set: managed device, encryption, EDR, MFA, conditional access. Without those, split tunnelling extends your processing boundary without controls.

How long does it take to retire VPN for 200 users?

Five weeks if you follow a pilot-first sequence: one week of discovery, one week of pilot with 15 users, two weeks of phased rollouts, one week of lockdown. Six to eleven weeks if you skip the pilot, because you will spend the extra weeks resolving breakages that a pilot would have caught. We have run both patterns; the maths is not close.

What to do next

If you have read this far, you probably have one of two situations. Either your VPN is strained and you are sizing up ZTNA for the first time, or you have already bought ZTNA and are staring at a 180-user migration you have not started.

The concrete next step is the same in both cases: export your current VPN user list and sort it by last-login date. You will have it in about ten minutes. The bottom 20-30% of that list is your starting point — those are the accounts you should be expiring or moving first, because they are the easiest wins and they tell you where the surprises are.

If you want a second pair of eyes on the design before you commit to a five or six lakh rupee spend, talk to our team. We have deployed this in Bangalore offices from 40 seats to 500, and we will tell you if your current firewall is the right platform for the next three years or if it is time to widen the footprint. Either answer is fine; what is not fine is buying a ZTNA licence and then figuring out the pilot in week six.