01
The most common ZTNA project. Application inventory, policy design per app, phased user migration, VPN decommission. 6-9 months for a 5,000-user environment.
// Symantec · ZTNA
Symantec ZTNA - historically Secure Access Cloud - gives users access to specific internal applications instead of a flat VPN network. It is the cleanest way to retire legacy VPN concentrators and adopt Zero Trust principles for hybrid work. CyberKIS deploys ZTNA for organizations replacing aging VPN infrastructure or modernizing toward SSE.
Also known as: Symantec ZTNA · Secure Access Cloud (legacy) · SaC
// 01 · Implementer perspective
ZTNA is conceptually simple and operationally subtle. The core idea: instead of giving a user network-level access ("you are on the corp LAN, do whatever you can route to"), give them application-level access ("you can access exactly these 6 apps, with policy checks per session"). The hard parts are real:
App discovery is the bottleneck. Most organizations don't have an accurate list of internal apps. CyberKIS spends the first 2-3 weeks of every ZTNA project just discovering apps via DNS logs, VPN session logs, and stakeholder interviews. Skipping this leads to missed apps and angry users in week one of cutover.
RDP / SSH / database access matters more than web. Most ZTNA marketing focuses on web apps. The harder use cases - RDP to internal servers, SSH to bastion hosts, direct database client access - are where organizations actually need ZTNA. Symantec ZTNA supports all of these; CyberKIS designs the connector / agent strategy.
Identity is non-negotiable. ZTNA requires a working IdP. If your AD / Entra integration is broken or your groups are messy, fix that BEFORE rolling out ZTNA. We have walked away from projects where the customer wanted ZTNA without fixing identity - it doesn't work.
VPN retirement is a 6-12 month project, not a cutover. You run VPN and ZTNA in parallel for months, migrate user populations and apps in waves, and only decommission VPN when the last app is on ZTNA. Plan accordingly.
// 02 · Capabilities
We deploy and support every capability listed below - not just the headline features.
01
The most common ZTNA project. Application inventory, policy design per app, phased user migration, VPN decommission. 6-9 months for a 5,000-user environment.
02
Usually driven by Symantec / Broadcom contract consolidation or SSE platform unification.
03
Rare; usually driven by enterprise standardization on Symantec stack across Cloud SWG, CASB, and ZTNA.
⏱ Typical timeline: Pilot 3-4 weeks. Full enterprise rollout: 6-9 months for a 5,000-user environment with 20-50 internal apps.
// 04 · Use cases
A non-exhaustive list of the scenarios that come up most often in CyberKIS ZTNA projects.
// 05 · FAQ
What buyers ask before scoping a ZTNA project.
A VPN gives you network access - once connected you are "on the LAN" and can reach anything routable. ZTNA gives you application access - you authenticate to a specific app, get a session for that app, and cannot see or reach anything else. The difference matters during a breach: a compromised VPN credential is a network-wide problem; a compromised ZTNA credential is one-app problem.
Yes - both with agent and clientless modes. Clientless RDP and SSH run through a browser-based session; with agent mode, native RDP / SSH clients connect through the ZTNA tunnel. CyberKIS configures both depending on use case (admins typically want native clients, contractors get clientless).
Yes. ZTNA is identity-driven by design - it requires an IdP for user context and policy evaluation. Symantec ZTNA supports Okta, Microsoft Entra (Azure AD), Ping, and SAML IdPs generally. The IdP also drives group-based policy (e.g., "Engineering group can access GitLab Enterprise; Sales cannot").
For most use cases, yes. A few legacy protocols (custom UDP, certain VoIP, multicast applications) don't map cleanly to ZTNA and need a different solution - but those are increasingly rare. For 90%+ of remote-access use cases, ZTNA is the modern replacement. Realistic timeline: 6-12 months from start to VPN decommission for a typical enterprise.
This is one of the best ZTNA use cases. Instead of issuing a contractor a VPN account (broad network access) plus an MFA token, you give them a ZTNA account scoped to exactly the 2-3 apps they need. Access expires automatically when the contract ends. Audit log shows exactly what they touched.
Cloud SWG / WSS
Cloud-delivered web security with SSL inspection, URL filtering, sandboxing, content disarm, and CASB integration. The cloud successor to the ProxySG appliance.
Read more →CASB / CloudSOC
Cloud Access Security Broker for SaaS - visibility into shadow IT, inline enforcement on sanctioned apps, API-based scanning for data at rest, and user behavior analytics.
Read more →// Get started
Tell us your environment, current state, and timeline. We will come back with a fixed-scope plan.