Zero Trust Network Access (ZTNA): A Practical Rollout for Indian Enterprises

• 24 June, 2026
• No Comments

Zero Trust Network Access (ZTNA) is one of the most discussed — and most misunderstood — security architectures in Indian enterprise IT today. Every vendor has a slide deck. Few have a practical deployment plan that works within Indian network constraints: mixed-vendor environments, legacy devices that can’t be replaced, budgets approved in phases, and teams that need to keep the lights on while transforming.

This guide lays out a rollout that works in Indian enterprises — not a greenfield fantasy.

What ZTNA Actually Means in Practice

Forget the marketing. ZTNA means: access is granted based on who you are and what device you’re using, not where you’re connecting from. There’s no “trusted inside” versus “untrusted outside.” Every access request is evaluated individually — whether it comes from the office LAN, a coffee shop, or a data centre rack.

The core components of a practical ZTNA deployment:

• Identity provider — who is the user? (Azure AD, OKTA, or local AD)
• Device posture check — is the device compliant? (OS patched, antivirus running, disk encrypted)
• Policy engine — does this user + device combo have permission for this application?
• Connector/proxy — the actual access gateway that enforces the decision

Phase 1: Identity-First Access (Weeks 1-4)

Before you can enforce zero trust, you need to know who’s on your network. Most Indian enterprises have no reliable identity-to-IP mapping.

• Deploy 802.1X on core switches. Every device authenticates before it gets an IP. Finance team members authenticate against AD and land on the finance VLAN automatically. Guest devices land on an isolated guest VLAN with internet-only access.
• Use FortiAuthenticator or NPS as your RADIUS server. Integrate with your existing AD or Azure AD.
• Expected cost: ₹5-10 lakh for 200-500 users (switches and RADIUS licensing). No new hardware if you already have managed switches.
• Outcome: 60% of lateral movement risk eliminated on day one.

During this phase, you learn something critical: which devices on your network can’t do 802.1X (printers, cameras, legacy sensors). You’ll handle those in Phase 2 with MAC authentication bypass (MAB) — a fallback that validates by MAC address and drops unknown devices into a quarantine VLAN.

Phase 2: Microsegmentation (Weeks 5-8)

Now that you know who’s on which VLAN, lock down inter-VLAN traffic with least-privilege firewall rules on your FortiGate.

• Create functional VLANs: Finance, HR, IT-admin, Production, IoT, Guest, Management
• Default-deny inter-VLAN: By default, no VLAN can talk to another unless explicitly permitted
• Permit only what’s needed: Finance can talk to the ERP server (port 443, specific IP). Nothing else. HR can talk to payroll app (port 443, specific IP). Nothing else.
• Log all denied traffic: You’ll be surprised what you find — especially broadcast storms and misconfigured devices trying to reach random servers
• Expected cost: ₹2-5 lakh for FortiGate policy configuration and testing. Mostly labour, not licensing, if you already have a FortiGate with UTM features.
• Outcome: Ransomware can’t jump from a workstation to the server VLAN. A compromised CCTV camera can’t reach the finance network.

Phase 3: ZTNA for Remote and Third-Party Access (Weeks 9-12)

Replace your VPN with ZTNA for remote users and third-party vendors. This is where the real security improvement lives.

• FortiGate ZTNA: If you already have a FortiGate running FortiOS 7.2+, you have ZTNA capabilities built in. No additional hardware needed. Configure ZTNA rules alongside traditional firewall rules — they coexist in the same policy engine.
• ZTNA access proxy: Instead of giving a remote user full network access via VPN, ZTNA gives them access to specific applications only. The user never gets an IP on your internal network. They authenticate, their device is checked, and they’re proxied to the application — nothing more.
• EMS/ZTPS for device posture: FortiClient EMS checks each device for OS patch level, antivirus status, disk encryption, and firewall status before granting access. A device that fails posture check gets quarantined, not connected.
• Vendor/ZTP access: Third-party vendors get application-specific ZTNA access with time-bound sessions. The vendor engineer authenticates, accesses only the specific appliance they’re managing, and the session expires when the ticket closes. No permanent VPN accounts.
• Expected cost: ₹5-8 lakh for EMS licensing for 200 users (if not already licensed). Labour included in Phase 2 if you use the same team.
• Outcome: No more “VPN was left connected” incidents. No more vendor accounts in your AD that never get disabled. No more lateral movement from a compromised remote device.

Handling the Hard Parts

Every ZTNA rollout hits these snags. Here’s how to handle them:

• Legacy devices that can’t do 802.1X: Use MAC authentication bypass (MAB) as a fallback. Register the MAC in your NAC system, assign it to the correct VLAN automatically. For unregistered devices, drop them in a restricted VLAN with minimal access.
• Application incompatibility with proxied access: Some legacy ERP or SCADA systems expect direct IP connectivity. For these, use ZTNA application segmentation rules that restrict the allowed source IPs, rather than proxying. Gradual migration over 6-12 months.
• User pushback: “I used to just connect and everything worked.” Expect this. Solve it with good communication: explain what zero trust means in terms of “your data is safer, and if your laptop is compromised, the attacker can’t reach the company servers.” Most users accept the extra authentication step once they understand the benefit.
• Mixed-vendor environment: ZTNA works across vendors as long as you standardise on your identity provider. Use Azure AD or OKTA as the single source of truth. Your FortiGate, switches, and endpoints all reference the same identity store.

Measuring Success

After 12 weeks, you should have:

• ✅ Every authenticated user on a known VLAN with least-privilege access
• ✅ All remote access shifted from VPN to ZTNA application-specific proxying
• ✅ Device posture checking enforced before any access is granted
• ✅ Third-party/vendor access time-limited and application-specific
• ✅ Audit trail for every access request — who, what device, what app, when
• ✅ Compliance evidence for DPDP Act and CERT-In requirements

Ready to Start?

At P J Networks, we’ve deployed ZTNA across Indian manufacturing, healthcare, BFSI, and government enterprises. We know the specific challenges of Indian network environments — mixed-vendor hardware, legacy systems, budget phasing — and we build rollouts that work within those constraints.

Contact our team for a zero-trust readiness assessment. We’ll map your current architecture and deliver a phased rollout plan with budget estimates — no sales pitch, just engineering.

P J Networks has been securing Indian enterprises since 2001. We’re a Fortinet MSSP partner with deep expertise in ZTNA, NAC, and network segmentation.