Secure remote access with zero trust (ZTNA)
Replace network-wide VPN with zero trust access. Each user reaches only the apps they are allowed, from a device that passes a posture check, signed in with a passkey.
Key facts
- Access model
- Per-application ZTNA based on user identity plus device posture, instead of network-level VPN access.
- Sign-in
- Passkey sign-in; one policy engine for users, apps and devices.
- Same platform, more controls
- SWG, CASB, DLP, FWaaS and sandbox on the same policy engine, multi-tenant.
- Encryption
- Post-quantum TLS 1.3 (X25519MLKEM768) and hybrid ML-KEM key exchange (NIST FIPS 203) on SSE connections.
- Detection
- AI Security, Detection & Response built in.
- Hosting
- Nexapp-hosted in India or self-hosted.
Why replace VPN?
One stolen VPN password can open far more of your network than the user ever needed. A traditional VPN puts a remote user on your network. Once connected, a stolen password or an infected laptop can reach far more than the one application the user needed. VPN concentrators are also exposed to the internet and are frequent targets for exploitation. They give you little visibility into what each user did.
ZTNA reverses the model:
- Your applications are not exposed. Users connect to a policy broker, not to the network, so internal apps are not reachable from the internet.
- Least privilege by default. A branch manager gets core banking and email. A vendor engineer gets one server, for a set window.
- Device posture counts. An out-of-date device, or one missing your required controls, gets restricted access or none.
- Every session is recorded. You see who accessed what, from which device, when, and what policy allowed it.
How it works
- Connect your identity source. Users sign in with passkeys through Nexapp SSE.
- Publish applications, not networks. Define private apps in your data centre, cloud or branches. For branch-hosted apps, Nexapp SD-WAN edges connect them to the SSE fabric.
- Write one policy. Set user or group, device posture, application and action in one policy engine. The same engine covers web (SWG), SaaS (CASB) and data (DLP).
- Your users connect from anywhere. The InstaAccess client connects them over ZTNA/SSE, SSL VPN or IPsec VPN. One client covers new zero-trust access and your existing VPN profiles.
- Monitor and respond. Sessions and alerts feed AI Security, Detection & Response.
Mapped to what Indian regulators expect
No regulator certifies a remote-access product. The obligations sit with your organisation. You get controls and evidence that support them.
| Your obligation | How Nexapp helps you meet it |
|---|---|
| RBI Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions (31 Jul 2026): MFA for privileged users and for telework access to critical systems | Per-app ZTNA with identity and device posture; passkey sign-in; segmentation of user access by application rather than network |
| RBI 2026 Directions: 6-hour incident reporting to RBI (DAKSH) | Central session logs and detection alerts that speed investigation and reporting |
| CERT-In Directions (2022): 6-hour incident reporting, 180-day ICT log retention within India, clock sync to NIC/NPL | Central logging you can retain in India when Nexapp-hosted in India or self-hosted. |
| DPDP Rules 2025 (substantive duties from about May 2027): access control, encryption, logs kept at least one year | Identity-based access, encrypted sessions and exportable access logs, so you can prepare now |
| SEBI CSCRF (in force for most regulated entities) | Access control, logging and SOC-integration evidence for your ongoing audits |
Check the Direction that applies to your entity type (commercial bank, SFB, payments bank, UCB, NBFC or AIFI). RBI issued seven separate Directions on 31 July 2026.
Remote access for vendors and third parties
Bank RFPs routinely require vendor remote access to go through controlled channels. With ZTNA, you give each third party time-bound, fully logged access to named systems. You do not hand out VPN accounts or open firewall rules.
Quantum-safe from the browser to the application
Your remote-access traffic crosses public networks, which makes it a target for harvest-now, decrypt-later collection. Nexapp SSE uses post-quantum TLS 1.3 (X25519MLKEM768) and hybrid ML-KEM key exchange, with ML-DSA authentication (FIPS 204). A cryptographic bill of materials (CBOM) shows you which algorithms are in use. Post-quantum mode is on by default.
Part of one SASE platform
Remote access is often your first SSE project. It sits on the same platform as Nexapp SD-WAN, NGFW and Instaroute routers, so your branch users and remote users follow the same policy. Start with one router. Grow to full SASE.
Related guides
Frequently asked questions
What is the difference between ZTNA and VPN?
A VPN connects a user to a network.
ZTNA connects a verified user on a checked device to one application at a time. ZTNA limits what a stolen credential can reach and keeps internal applications off the public internet.
Does ZTNA help us meet the RBI 2026 Directions?
It helps you meet the Directions' MFA requirements for privileged users and for telework access to critical systems.
It also gives you logs for incident reporting. The obligation remains with your bank or NBFC. We supply the controls and evidence.
Where are logs and user data stored?
Nexapp SSE runs hosted by us in India or self-hosted in your environment, so you control residency.
Do users need an agent?
Your managed devices use the InstaAccess client, which supports ZTNA/SSE, SSL VPN and IPsec VPN.
As a rule, managed employee devices use an agent so you can check posture. Browser-based access, where offered, suits contractors on unmanaged devices.
Can we run ZTNA alongside our existing VPN during migration?
Yes. The InstaAccess client supports ZTNA/SSE alongside SSL VPN and IPsec VPN, so your users keep one client throughout.
Move applications and user groups in phases. Start with high-risk access such as vendors and privileged users. Retire VPN profiles as each group moves.
How does MFA work?
Nexapp SSE supports passkey sign-in, which is phishing-resistant.
Is the connection quantum-safe?
Your connections use post-quantum TLS 1.3 (X25519MLKEM768) with hybrid ML-KEM key exchange.
This protects against harvest-now, decrypt-later.
See per-app access with device posture working on your own applications.
24×7 NOC in Pune · 75,000+ devices deployed · 400+ enterprise and banking customers since 2014.